Security & Trust
Effective date October 18, 2026
Orbital, a product of Constructr, Inc., runs AI coworkers that act inside your systems. That means the honest version of a security page has to cover two things: how we protect the data you put in our platform, and how we bound what an agent is allowed to do in your environment.
We are an early-stage company. Where a control is in place we say so. Where something is on our roadmap we say that instead, and we date it. We would rather you found this page conservative than found it wrong.
The four questions we get asked most
Where is my data processed? In the United States by default. Enterprise plans can choose a United States or European Union processing region. The third parties that process data as part of the platform are listed on our sub-processors page, with the processing location for each. If you run Orbital in your own environment, see Deployment options below - the answer changes, but less than people assume.
Do you train models on my data? No - not on your content, and not on anything shared with other customers. We separate this into three cases and we would rather spell them out than give you a one-liner that turns out to have exceptions.
Your content is never used to train shared models. Your prompts, your files, the data your agents read from your systems, and your agents' outputs are not used to train, fine-tune or adjust any model that we make available to anyone else. The only exception is if you explicitly opt in, in a separate recorded agreement - not by accepting these terms, and never by a default setting you have to find and switch off. If you have not opted in, this is absolute.
We do use operational telemetry to make the platform faster and cheaper. That means things like how long a task took, how many tokens it used, which model it was routed to, error rates and whether a run succeeded. It does not include your prompts, your outputs, your files, or data read from your systems. Stripping the identifiers off your content does not make it telemetry - content stays content. We keep telemetry in a form that cannot reasonably be linked back to an individual, we commit publicly not to try to re-identify it, and we require anyone who receives it to do the same.
We may use your data to improve your own agents - and only yours. If we learn something from your data that makes your agents, evaluations or configurations work better, that stays inside your tenant. We will not share it with another customer, use it to serve another customer, or fold it into a shared model. That is a commitment, not a description of how the system happens to be built today.
How we hold the model providers to this. We use third-party model providers under paid commercial API terms that contractually prohibit them from training on your content, with model-improvement settings turned off. We have not yet enabled zero data retention on our own provider accounts, so each provider retains content for a limited period under its standard terms; our sub-processors page gives the window for each. Most customers run agents on their own provider accounts, in which case the provider processes content under the customer's agreement with it.
Can I export or delete my data? Yes. You can ask us for an export of your workspace data at any time, and for 30 days after your subscription ends; we provide it in a machine-readable format. When a workspace is deleted or a subscription ends, we remove your content from active systems within 30 days and from backups within 90 days. Section 8 of our Privacy Policy has the full retention table.
Is a DPA available? Yes. Our Data Processing Addendum is published in full - you do not need to ask for it. It covers our role as your service provider, what we process and why, our security measures, sub-processor notice, incident notification, and deletion on termination.
How we protect your data
Encryption. Data is encrypted in transit using TLS 1.2 or higher. Data in our managed storage, including backups, is encrypted at rest using AES-256.
Access to your data. Access by Orbital staff is limited to people with a documented business need, under least-privilege and deny-by-default rules. Every person has their own account; shared accounts are not permitted. Multi-factor authentication is required on our identity provider, source-code hosting, cloud consoles and production administrative interfaces, and production administrators must use a phishing-resistant factor such as a hardware security key. Standing production-admin access is discouraged in favour of time-bounded elevation, capped at eight hours.
When we access a customer environment. Support and troubleshooting access requires a recorded justification tied to a ticket or a written request, and is logged with who accessed what, when, and why. Access without a justification is treated as a security incident.
Access reviews. Our access control policy requires managers to review their team's access to customer-data systems every quarter, and the CTO to re-approve every privileged account annually. That policy took effect in August 2026, so the first full review cycle is still running.
Leavers. When someone leaves, identity-provider access is disabled within four hours and their sessions are invalidated.
Secrets. Credentials, API keys and tokens are held in a managed secrets store. They are never committed to source control, chat or email, and they are rotated on suspected exposure and on offboarding.
Backups. Customer data is backed up, and backups are encrypted and expire within 90 days. We maintain a business continuity and disaster recovery plan and review it at least every six months, and test restore procedures periodically.
Change management. Production changes go through a documented process with peer review. No single person can deploy to production unilaterally. Dependencies are scanned continuously for known vulnerabilities, and fixes are prioritised by severity: critical issues within 7 days, high within 30 days and medium within 90 days.
How we bound what an agent can do
This is the part that is specific to Orbital, and the part a general security page would miss.
Permission scopes. An agent only reaches what you let it reach. Scopes restrict access per connected system.
Signed policies. Policies define which actions are permitted. An action outside the granted scope is denied.
Approval gates. You can require a person to approve consequential actions before an agent takes them. Enforcement coverage varies by connector, so test an allowed and a denied action before you widen access.
Per-session credential grants. Where a connector supports it, credentials for your connected systems are granted per session rather than held open-endedly. Credentials are held encrypted in our connector gateway, are never placed in an agent's working environment, and are deleted when you disconnect a system.
Spending limits. You can set budget limits for configured workloads. What happens when a limit is reached depends on your configuration, including with concurrent runs, so include a limit-triggered run in your pilot.
Audit trail. Agent execution is recorded so you can inspect what an agent did, when, under what authority, and which actions were allowed or denied. The trail is append-only: records cannot be edited or deleted by customers or by Orbital staff, and they are kept for 12 months.
Deployment options
| Orbital Cloud | Self-hosted | Air-gapped | |
|---|---|---|---|
| Availability | Available now | Enterprise plan | On request |
| Control plane | Hosted by Orbital | Your VPC or data centre | Your isolated network |
| Network | Connects to Orbital Cloud | Egress set by your team | No outbound access |
| Updates | Managed by Orbital | You apply versioned releases | Offline release bundles |
One caution we would rather state ourselves. Running the control plane in your own environment does not by itself mean nothing leaves your network. Model requests, connector traffic, logs and updates each need to be looked at. Ask us for the data-flow map for the deployment you are considering, and review it before you decide.
Reporting a vulnerability
If you believe you have found a security vulnerability in Orbital, email security@withorbital.ai. Include enough detail to reproduce the issue. We will acknowledge your report within two business days and keep you updated while we investigate.
Safe harbour. If you make a good-faith effort to comply with this policy during your research, we will not pursue or support legal action against you. Please: only test against your own account or data; do not access, modify or delete anyone else's data; do not run denial-of-service tests, send spam, or use social engineering or physical attacks; and give us a reasonable chance to fix the issue before you discuss it publicly.
We do not currently run a paid bug-bounty programme.
Reporting a security incident
If you are an Orbital customer and believe your data has been affected by a security incident, contact security@withorbital.ai. Our notification commitments to customers are in clause 9 of the DPA.
Compliance roadmap
SOC 2. A SOC 2 Type II examination covering the Security and Confidentiality Trust Services Criteria has been scoped with an engaged auditor. The observation window has not yet begun, and no attestation report exists today. We will say so here when that changes. To ask which control documents we can share for your review, contact security@withorbital.ai.
Availability. We have deliberately left the Availability criterion out of our first SOC 2 scope, and we do not publish an uptime commitment. Response targets and escalation paths can be agreed in an enterprise agreement.
Other frameworks. We do not hold ISO 27001 certification. We do not offer a HIPAA Business Associate Agreement, and the platform is not configured for protected health information - please do not send it.
What we do not claim yet
We have left things off this page on purpose. As of October 18, 2026 we are not claiming:
- a completed SOC 2 report, or any other third-party certification;
- an independent penetration test;
- 24/7 security monitoring or a staffed security operations function;
- a formal tenant-isolation guarantee for agent runtimes;
- an uptime or availability commitment;
- data residency commitments beyond the United States and European Union regions described above.
If one of these is a requirement for your deal, tell us and we will tell you where it actually stands rather than guess.
Related documents
Privacy Policy · Terms of Service · Cookie Policy · Data Processing Addendum · Sub-processors · AI & Agent Terms · Acceptable Use Policy