Legal

AI & Agent Terms

Effective date October 18, 2026

Part of the Terms of Service

Orbital runs AI coworkers that plan work, call tools, and take actions in systems you connect. This page answers the questions that follow from that: whether we train on your data, who processes your content, what an agent is allowed to do, who is responsible when it does something, what we log, and how connector credentials are handled.

These terms are part of your agreement with Constructr, Inc., which provides Orbital ("Orbital", "we", "us", "our"). Where they conflict with the Terms of Service on an AI or agent question, these terms govern. Where a Data Processing Addendum covers the same personal data, the DPA governs. Prohibited uses are in the Acceptable Use Policy.

1. The words we use

  • Customer Content - what you put into Orbital and what comes out: prompts and instructions, files, data an agent reads from or writes to a system you connect, agent outputs, and the content recorded inside agent transcripts.
  • Output - anything an agent produces: text, code, a document, a plan, a message, a pull request, a database write, an API call.
  • Agent - an AI coworker configured in your workspace, including the orchestrator and any specialised agent you create.
  • Harness - the agent runtime an agent runs on.
  • Model Provider - a provider of the AI models used to run an agent.
  • Connector - an integration that lets an agent read from or act in one of your systems.
  • Action - a step an agent takes with effect outside Orbital, such as writing to a repository, sending a message or changing a record.
  • Workspace - your Orbital organisation, its members and its agents. Your workspace is your tenant: the boundary inside which your data, agents and configurations stay.
  • Operational Telemetry - measurements about how the platform ran, not what it ran on. Defined and bounded in §2.3.
  • Customer-Specific Learning - improvements derived from your data that apply only to your workspace. Defined and bounded in §2.4.

These definitions are used the same way across the Terms of Service, this page and the Acceptable Use Policy.

2. Model training

Our position has three parts. We state them separately because they are genuinely different, and because a single sentence - in either direction - would mislead you. Read all three.

What it coversDefault
Tier 1Training shared models on your contentNever, without your explicit, separately documented opt-in
Tier 2Anonymised operational telemetryMay be used to improve how the platform runs
Tier 3Learning that improves your agents, inside your tenantMay be used within the scope you agree, never shared across tenants

2.1 Tier 1 - we do not train shared models on your content

We do not use Customer Content to train, fine-tune or evaluate any AI model that serves anyone other than you. That covers your prompts and instructions, your outputs, your files, data an agent reads from or writes to your connected systems, and the content inside your agent transcripts.

The only exception is if you opt in, and the bar for that is deliberately high:

  • Explicit. A distinct, affirmative act by someone authorised to make the decision for your organisation.
  • Separately documented. Recorded on its own, as its own agreement or written authorisation. Accepting these terms is not an opt-in. A checkbox in a sign-up flow is not an opt-in. Continuing to use Orbital is not an opt-in.
  • Scoped and revocable. It names what may be used and for what. You can withdraw it at any time for the future, and we will tell you what withdrawal does and does not reverse before you rely on it.

Where no such opt-in exists, this commitment is absolute. There is no "legitimate interests" route, no "de-identified so it does not count" route, and no quality-improvement exception that reaches your content.

2.2 Why there are two more tiers

Tier 1 is about your content. It is not a promise that we learn nothing from operating the platform, and it would be dishonest to imply that. Two kinds of learning do happen, and both are bounded below.

2.3 Tier 2 - anonymised operational telemetry

We use Operational Telemetry to optimise orchestration, model routing, token efficiency, reliability and cost - the work of making agents finish tasks faster, more reliably and for less money.

What it is. Counts, durations, identifiers, outcomes and costs: token and request counts, run durations, latency, error codes, tool and connector names, which model handled a step, policy decisions (allowed, denied, approval required), retry and failure patterns, and spend. We may aggregate it across customers.

What makes it anonymised. It describes the shape of a run, not its substance. It carries no Customer Content and no identifier that we could use, alone or with other data we hold, to reconstruct what a run was about or who it concerned. Where a field could carry content - a tool parameter, an error string - it is excluded, truncated or replaced with a type before the telemetry is stored.

The boundary, stated plainly because this is the seam that matters. Operational Telemetry is not Customer Content. It is never used to train models on your material, and tier 2 is not a back door into tier 1. If we cannot collect a measurement without capturing your content, we do not collect it.

2.4 Tier 3 - Customer-Specific Learning, inside your tenant

We may use your data to make your agents work better: improving the agents, evaluations and configurations in your workspace, within the scope you have agreed with us. In practice that means things like tuning an agent's instructions against how your work actually went, building evaluation sets from your own runs, and learning which model or route handles your tasks best.

The commitment that makes this safe is isolation, and we state it as a commitment:

Nothing learned from your data is shared across tenants. Not as a model, not as a fine-tuned adapter, not as an evaluation set, not as a prompt or instruction, not as a routing heuristic, and not as an aggregate or statistic that could carry information specific to you. What is learned from your workspace stays in your workspace.

Tier 3 is on for your workspace unless a workspace administrator turns it off in your workspace settings. If you turn it off, we stop deriving new learning for your workspace, and existing customer-specific learning is deleted on the schedule for Customer Workspace Content in our Privacy Policy.

2.5 The seam between the three tiers

One table, so you can check us rather than take our word for it:

Touches your prompts, outputs and connected data?Leaves your tenant?Used to train a model that serves other customers?Can you switch it off?
Tier 1 - shared-model trainingOnly with explicit, separately documented opt-inOnly with that opt-inOnly with that opt-inOff by default; opt-in is revocable
Tier 2 - operational telemetryNoYes, as anonymised measurementsNoNo. It contains no Customer Content and no identifiers
Tier 3 - customer-specific learningYes, inside your tenantNoNoYes, in your workspace settings

2.6 How we hold model providers to this

A commitment about our own behaviour is worth little if the providers behind us behave differently, so we commit to the mechanism as well as the outcome:

  • Third-party model providers are used under paid API terms that contractually prohibit training on customer data.
  • Provider-side data-sharing and model-improvement settings are disabled.
  • Zero data retention is not yet enabled on our own provider accounts. Each provider retains content for a limited period under its standard terms, typically for abuse monitoring; the Sub-processors page gives the window for each. Where you bring your own provider account or key, retention is governed by your agreement with that provider, including any zero-retention arrangement you hold with it.

You can ask us for the current position on any provider in your serving path, and the Sub-processors page carries it per vendor.

2.7 Human review by our staff

Our staff look at your content only when there is a specific reason: you ask us for support, we are investigating an incident or a suspected policy violation, or the law requires it. Access is role-restricted, logged, and limited to what the reason requires. We do not run general content review across customer workspaces.

2.8 You do not train on us either

You may not use Orbital to generate material whose purpose is to train a competing agent-orchestration or agent-governance product, and you may not use Output to build a substantially similar service.

3. Who processes your content

3.1 Model and infrastructure providers

Running an agent means sending your content to an AI model, and running the platform means storing it on cloud infrastructure. We use third parties for both. We publish who they are, what each one processes, where it processes it, and whether zero-retention is enabled, on the Sub-processors page, and we keep that page current.

Our serving path includes Model Providers reached through the agent harnesses Orbital supports, together with cloud hosting, storage, logging and support providers.

3.2 Changes to providers

We will give you at least 30 days' notice before a new provider starts processing your content, by updating the Sub-processors page and notifying workspace administrators. If you object on reasonable data-protection grounds, tell us and we will work with you on an alternative; if there is not one, you may stop using the affected feature or end the affected subscription.

3.3 Harnesses and models you bring

Orbital is designed to run the agent harnesses and models your team already uses, and you can choose them per agent or per task. That choice changes the data flow, so it changes what we can promise:

  • Where the agent runs on a provider account Orbital holds, the commitments in §2 apply.
  • Where you configure your own provider account, API key, model endpoint or self-hosted harness, your content goes to that provider under your agreement with them. Their terms govern how they use and retain it. We pass through only what the agent needs, we log the call, and we cannot extend our training, retention or residency commitments to traffic we do not control. This is the usual configuration: most customers run agents on their own Claude Code, Codex or Antigravity accounts.

Check which configuration you are using before you rely on §2. We will tell you which applies to your workspace if you ask.

3.4 Where processing happens

Orbital is available as a hosted service and, on enterprise plans, with the control plane in your own VPC or data centre; an air-gapped option is available on request. Where you run the control plane yourself, model requests, connector traffic, logs and updates may still leave your network - placing the control plane inside your perimeter does not by itself mean nothing egresses. Ask us for the data-flow map for the deployment you are considering, and confirm it before you treat any boundary as closed. Orbital Cloud is hosted in the United States, and enterprise plans can choose a United States or European Union processing region. For self-hosted and air-gapped deployments, the network boundary and the supported components are agreed with you as part of the deployment.

4. Inputs, outputs and ownership

  • Your Customer Content is yours. We claim no ownership of it.
  • As between you and us, Output is yours. To the extent we would otherwise hold any rights in Output, we assign them to you, and you may use Output for any purpose, including commercially.
  • Output may not be unique. The same or similar output can be produced for another customer from a similar request. Output generated for someone else is not yours.
  • You are responsible for the legality of what you put in, for having the right to put it in, and for checking that using or publishing an Output does not infringe anyone's rights.

5. What an agent may do

5.1 Authority comes from you

An agent has no authority of its own. Everything it can read, change or approve comes from a decision someone in your workspace made: the connectors you enable, the permission scopes you grant, the policies you apply, and the approvals you require. We do not broaden an agent's authority on your behalf, and an agent invoked by another agent holds no authority beyond what your workspace granted.

5.2 Approval for consequential actions

You decide which actions require a human to approve them before they run, and who may approve. An action you have marked for approval does not execute until a named person approves it, and the approval is recorded against the action. If an approval request expires without a decision, the action does not run.

We recommend requiring approval for anything that writes to a production system, moves money, sends communications outside your organisation, changes access or permissions, or deletes data. We do not set those boundaries for you.

5.3 What we commit to

  • An agent acts only within the authority your workspace granted it.
  • We do not use your agents, credentials or connectors for our own purposes.
  • Each action is recorded with the agent that took it, the authority it relied on, and the approval that permitted it.

5.4 Credentials and connector access

When you connect a system, you are delegating access to an agent. How that works:

  • Scope. Grant the least access the work requires. Where a connector supports scoped or read-only access, use it.
  • Custody. Credentials, tokens and keys you grant are stored encrypted and are used only to perform work in your workspace. They are not exposed to other customers, and are not returned to users in readable form.
  • Session grants. Where a connector supports it, access can be granted for a session rather than permanently, so an agent holds access only while it is working.
  • Revocation. You can revoke a credential or disconnect a connector at any time. Revocation stops new use immediately; work already in flight may complete or fail depending on the action.
  • Your warranties. You confirm that you are entitled to grant the access you grant, that doing so does not breach the connected system's terms or anyone's rights, and that you will tell us promptly if a grant should not have been made.
  • A caution we would rather state than imply. Credential storage, revocation and policy-enforcement coverage differ by connector. Ask us for the position on the specific connectors you plan to use, and test an allowed action and a denied action before you expand access.

Note that account log-in credentials and the contents of mailboxes and messaging systems are treated as sensitive personal information under California law. If your agents use connectors that reach those systems, that affects your own privacy obligations as well as ours. See Privacy Policy.

5.5 Stopping an agent

You can pause or stop an agent, a run or a workspace at any time. Stopping prevents further actions; it does not undo actions an agent has already completed. We may also pause activity ourselves to protect the platform, as described in the Acceptable Use Policy.

6. Human oversight and responsibility

6.1 You are responsible for what your agents do

An agent acting within the authority your workspace granted it is acting for you, and you are responsible for the consequences - the same as if a member of your team had taken the action. That includes actions in your own systems and actions in third-party systems you directed an agent to reach.

We are responsible for operating the platform as described in these terms and the Terms of Service: keeping an agent inside the authority you granted, holding approvals before gated actions run, and recording what happened.

6.2 Decisions about people

Where an agent's output feeds a decision that provides or denies someone financial or lending services, housing, education enrolment or opportunities, employment or contracting opportunities, work allocation, compensation, promotion, demotion, suspension or termination, or healthcare services, you must keep a real human in the decision. In practice that means the person deciding:

  1. knows how to interpret and use the agent's output for this decision;
  2. reviews that output together with the other information relevant to making or changing the decision; and
  3. has the authority to make or change the decision on their own analysis.

If your process does not meet all three, you are treating the agent as the decision-maker, and additional obligations apply to you under California law - including telling the affected person in advance that you use automated decision-making, explaining the specific purpose, and offering either an opt-out or a route to appeal to a human reviewer who can overturn the decision. Those obligations are yours, not ours: in this flow you are the business and we are your service provider. We will give you the information about how the relevant feature works that you reasonably need to meet them.

Some uses are prohibited outright rather than permitted with oversight - see Acceptable Use Policy §2.3 and §2.4.

6.3 Telling people they are dealing with an agent

If you deploy an agent that interacts directly with people outside your organisation, tell them they are dealing with an automated system, and do not present agent output as human-written where that would mislead. Some markets require this; we require it everywhere.

6.4 What Orbital is not

We are not a professional adviser, we do not supervise your agents, and we do not review what they produce. We do not decide which actions in your business are consequential. Those are your decisions and we have deliberately built the platform so they stay yours.

7. Accuracy and reliance

7.1 Outputs can be wrong

AI models produce output by statistical inference. An agent can be confidently wrong, misread an instruction, miss context, use a stale version of a document, or produce output that is incomplete or non-unique. Output is not verified by us and is provided as-is. You are responsible for reviewing it before you rely on it.

7.2 Actions can be wrong too, and that is different

This is the part worth reading twice. Most AI products get a sentence wrong. An agent platform can get an action wrong - a record updated in your CRM, a message sent from your mailbox, a branch merged, a job retried against a live billing system. Those consequences are not undone by deleting the output.

That is why the platform has permission scopes, approval gates and spend limits, and why we recommend you use them before you widen what an agent may do. Start with one workflow, confirm what an allowed and a denied action look like, and expand from there.

7.3 No professional advice

Nothing Orbital produces is legal, financial, tax, medical, accounting or other professional advice, and nothing produced by an agent should be relied on as a substitute for a qualified professional. Do not use Orbital for medical diagnosis or treatment, for safety-critical control of physical systems, or in any setting where an error could cause injury.

7.4 No protected health information

Orbital is not configured for protected health information and we do not offer a Business Associate Agreement. Do not submit PHI.

8. Logging, transcripts and audit records

8.1 What we record

Running agents and proving what they did means keeping records. We keep these categories:

CategoryWhat it containsWhy
TranscriptsPrompts, instructions, agent reasoning summaries and outputs for a runSo you can read back what happened and so we can support you
Action recordsEach tool call and connector action: what was called, with what parameters, what came backSo an action can be traced to its cause
Policy and approval recordsWhich actions were allowed, denied or gated; who approved what, and whenThe governance record enterprises buy the platform for
Credential eventsThat a grant was made, used or revoked, by whom, for what - never the credential itselfAccountability without creating a second copy of your secrets
Usage and cost meteringTokens, runtime, spend by agent, team and goalBilling and budget controls
Platform and security logsAccess to the platform, administrative changes, security eventsSecurity and incident investigation

Action records can include the parameters an agent passed to a tool, which may contain Customer Content. Credentials are never written to action records; only the fact that a credential was used is recorded.

8.2 How long we keep it

Two different rules, because two different things are at stake.

  • Transcripts and content follow your data rights. We keep them while you need them and delete them on the schedule in the Privacy Policy, or earlier on request: within 30 days of deletion or termination from active systems, and within 90 days from backups.
  • Audit records - the action, policy, approval and credential-event records - are kept as an integrity record for 12 months. We do not edit or remove them on request during that period, because a governance record you can delete is not a governance record. If that conflicts with a deletion obligation you have, talk to us and we will work out what can be minimised, redacted or de-identified instead.

Backups may persist for up to 90 days after deletion, and security logs for up to 12 months.

8.3 Who can see your logs

Your workspace administrators, and the users you authorise. Our staff access them only for the reasons in §2.7, under role-restricted and logged access. We do not share them with other customers, and we do not use their content outside the three tiers in §2 - which means not for shared-model training (§2.1), and not across tenants (§2.4).

8.4 Getting your records out

You can ask us for an export of your transcripts and audit records at any time, and within 30 days after your subscription ends. We provide them in a machine-readable format.

9. Security and incidents

How we protect the platform, our current audit status, and how we handle incidents are on the Security page. We deliberately make no certification or audit claim on this page, so there is one place for that statement to live and one place to update it. If we become aware of a security incident affecting your content, we will notify you as described there.

10. Prohibited uses

What you may not do with Orbital, and what you may not have an agent do, is in the Acceptable Use Policy. A breach of that policy is a breach of these terms.

11. Changes

We may update this page. If a change materially reduces the commitments we make to you, we will give you at least 30 days' notice by email or in-product before it takes effect. Other changes take effect when posted. The current version's date is at the top, and we keep dated copies of previous versions.

12. Contact

Orbital is a product of Constructr, Inc., 1484 Pollard Rd, #3006, Los Gatos, CA 95032, USA.

Questions about these terms: legal@withorbital.ai. Data, privacy or sub-processor questions, and requests for the data-flow map for your deployment: privacy@withorbital.ai.