Privacy Policy

This working draft describes Orchestrator's current private-beta data practices. Interesta will replace the contact placeholders and obtain legal review before this Policy is finalized.

This Privacy Policy explains how Interesta Inc. (Interesta, we, us, or our) collects, uses, discloses, and retains personal information when you browse Orchestrator, sign in with GitHub, join a workspace, configure agents, or connect a local runner.

Interesta's Privacy Officer is accountable for this Policy and for responding to privacy enquiries and complaints.

Depending on how you use Orchestrator, we collect:

• Account information: GitHub and Supabase identifiers, name, username, email address, profile metadata, authentication records, and session information.
• Workspace information: workspace names, memberships, roles, member display names, GitHub usernames and emails, invitation emails, invitation status, and related timestamps.
• GitHub information: connected repository and Project identifiers and metadata; branches; issue and pull-request titles, bodies, URLs, labels, statuses, relationships, reviews, comments, and workflow metrics needed to coordinate work.
• Configuration: agent prompts, providers, models, thinking levels, schedules, Docker-image references, repository settings, and local Kubernetes runtime configuration.
• Issue Planner information: feature briefs, questions and answers, interview transcripts, duplicate candidates and acknowledgements, proposals, test and validation expectations, creation ledgers, errors, and model-session identifiers.
• Runner and job information: runner identity, version, connection status, labels, capacity, provider availability, authentication mode, model-catalog metadata, jobs, attempts, events, status, errors, blocked reasons, session or turn identifiers, token usage, rate-limit information, and outcome evidence such as branch names, commit SHAs, pull-request URLs, and summaries.
• Website and technical information: authentication and workspace cookies, redacted page routes, referrers, browser and device information, approximate location, network and performance measurements, timestamps, and server or security logs.
• Communications: information you include in a support, legal, or privacy request.

Repository content can contain personal information about contributors or other people. You are responsible for ensuring that you have authority to provide and process that information.

GitHub sign-in requests the hosted repo, project, workflow, and read:orgOAuth scopes. Interesta stores the resulting GitHub access token and, when GitHub provides one, refresh token in Supabase so Orchestrator can read and update the authorized GitHub work. GitHub access is limited by the authorizing account's permissions, but the requested scopes provide broad read and write access to available public and private repositories, GitHub Project data, and GitHub Actions workflows, plus read access to organization and team membership.

AI-provider credentials are handled differently. The hosted app does not ask you to paste or store OpenAI, Anthropic, or OpenRouter API keys, an Anthropic setup token, or Codex OAuth root credentials. The runner reads those credentials from your local environment or local provider authentication.

Only sanitized authentication mode, provider availability, model catalogue information, timestamps, and related status or error data are synchronized to the hosted service. For each job, the selected provider credential is made available to a trusted local inference sidecar. An ordinary repository-agent container receives a random inference-proxy token rather than the provider root credential.

The runner token is stored as a hash by the hosted service and cached in owner-readable form on the runner host after validation.

Source checkouts are created in the kind/Kubernetes environment on the runner host you operate. A complete source checkout is not uploaded to Interesta's hosted systems as part of normal operation.

That does not mean repository information remains only on the runner. The hosted service stores selected GitHub content and repository-derived information needed to coordinate plans, jobs, events, statuses, and outcomes. The local inference sidecar also sends the selected provider credential and inference content directly to the OpenAI, Anthropic, or OpenRouter service you chose. Inference content can include prompts, source snippets, diffs, tool output, issue or pull-request content, and other repository context.

Provider processing is governed by the provider account, terms, settings, downstream model routing, and retention practices you select. Interesta does not control whether a selected provider retains or uses content under those terms. OpenRouter may route a request to a downstream model provider.

Issue Planner has a stricter boundary: its model workload receives a read-only checkout, no GitHub credential, and no GitHub mutation tool. A trusted initialization step uses the GitHub token to prepare or refresh that checkout.

The runner and hosted API apply field-name and string-pattern filtering intended to remove known credential fields and common token formats before events and outcomes are persisted. This is a best-effort safeguard, not a complete data-loss-prevention system.

Arbitrary secrets embedded in free-form text, source content, errors, prompts, GitHub content, or custom metadata may not be detected. Do not place credentials or other secrets in content sent through the service.

We use information to:

• authenticate users and maintain sessions;
• create and administer workspaces, memberships, invitations, and permissions;
• connect repositories and synchronize GitHub issues, Projects, pull requests, reviews, and workflow state;
• configure, dispatch, monitor, recover, and verify local agent jobs;
• resume Issue Planner interviews and create approved GitHub plans;
• synchronize provider availability and model catalogues without receiving provider root credentials;
• surface job status, token usage, evidence, and errors;
• secure, troubleshoot, support, and improve the reliability and usability of the service;
• measure aggregate website usage and performance; and
• enforce our terms, prevent abuse, and comply with legal obligations.

Interesta does not sell personal information, use it for targeted advertising, or use Customer Content to train models operated by Interesta. A user-selected model provider handles inference content under that provider's own terms and settings.

We disclose information only as reasonably necessary:

• Within your workspace: workspace members can see the member roster, including names and emails, connected repositories, runner information, and non-planner jobs and events. Owners and administrators can also see invitations and Issue Planner records.
• To GitHub: to authenticate you and perform the repository and Project operations you authorize.
• To Supabase: for authentication, database storage, realtime updates, and access control.
• To Vercel: for hosting, delivery, Web Analytics, Speed Insights, and related operational processing.
• To your selected model provider: directly from the runner for inference, as described above.
• To an image registry: when your runner pulls a configured registry image. Registry credentials remain in your local Docker setup.
• For legal and safety reasons: when required by law or reasonably necessary to protect rights, safety, security, and the integrity of the service.
• In a business transaction: subject to appropriate safeguards in connection with financing, reorganization, merger, or sale of all or part of the business.

Interesta does not disclose AI-provider root credentials to GitHub, Supabase, Vercel, or ordinary agent containers.

Orchestrator uses Supabase session cookies to sign users in and refresh authentication. It also uses an HttpOnly orchestrator_active_workspace cookie to remember the selected workspace. That cookie is scoped to Orchestrator, uses SameSite=Lax, is marked Secure in production, and has a maximum age of one year. These cookies support authentication, security, and requested application functionality.

Vercel Web Analytics operates throughout the public and authenticated site. It collects aggregate page-view information such as timestamp, URL or route, referrer, approximate geography, browser, operating system, and device type. Vercel states that Web Analytics does not use third-party cookies and is not tied to an individual or IP address.

Vercel Speed Insights also operates site-wide and collects URL or route, browser, device, operating system, country, network-speed category, Web Vitals, and performance attribution. Before analytics or performance events are sent, Orchestrator removes query strings and replaces selected invitation, repository, run, and planning identifiers in URLs and routes with generic placeholders.

Orchestrator does not currently use advertising cookies or targeted-advertising trackers. We will reassess consent and notice requirements if measurement practices change.

Issue Planner briefs, interview transcripts, proposals, and related planning records expire after 30 days of inactivityand are scheduled for deletion. New activity extends that period.

Most account, workspace, membership, invitation, connected-repository, configuration, general job, event, telemetry, and outcome-evidence records do not currently have a fixed automated deletion period. They are generally retained for the workspace lifetime, until manually deleted, or until no longer reasonably required for service, security, dispute-resolution, or legal purposes.

Revoking GitHub authorization makes the GitHub token unusable but does not itself delete hosted records. Providers and analytics services retain information according to their own terms and account settings.

Local checkouts, containers, Kubernetes Secrets, and provider sessions are held in your environment. Job cleanup is designed to remove short-lived deployments, sidecars, Secrets, and proxy tokens, but issue and planning workspaces can persist between runs and cleanup can fail. You are responsible for inspecting and removing local resources when necessary.

Interesta uses safeguards designed for the nature of the information, including encrypted transport, Supabase row-level access controls, service-only access to stored GitHub OAuth credentials, hashed runner tokens, local workload isolation, short-lived credential boundaries, and event filtering.

No safeguard can guarantee absolute security. You are responsible for the runner host, local cluster, custom images, local credentials, provider accounts, and access granted to workspace members.

If a breach involving personal information occurs, Interesta will investigate and provide reports or notifications where required by applicable law.

Interesta and its service providers may process information in Canada, the United States, and other countries. Information can therefore be subject to the laws and lawful-access requirements of those jurisdictions. Interesta remains accountable for personal information under its control when a service provider processes it for us.

Subject to applicable law, you may ask to access or correct your personal information, withdraw consent, object to particular processing, or request deletion. Some requests may be limited by legal, security, contractual, or technical requirements. Withdrawing necessary processing may prevent continued use of Orchestrator.

You may:

• revoke Orchestrator's GitHub access through GitHub's authorized OAuth application settings;
• stop the runner locally and manage local Kubernetes or Docker resources;
• change provider credentials and provider-account settings directly with the provider;
• ask a workspace owner or administrator to update or remove your workspace access; and
• contact the Privacy Officer for an access, correction, deletion, consent, or complaint request once the contact details below are completed.

Signing out only ends the application session. It does not revoke GitHub authorization or delete hosted records.

Orchestrator is not directed to anyone under 18, and Interesta does not knowingly offer accounts to children. Contact the Privacy Officer if you believe a minor has provided personal information.

We may update this Policy as Orchestrator and its practices change. We will post the revised version and update its date, with additional notice where required by law.

Direct privacy requests or complaints to:

If we cannot resolve a privacy concern, you may contact theOffice of the Privacy Commissioner of Canada.

Our Terms of Service explain the conditions that apply to use of Orchestrator.