Autonomy you can account for
Agents acting on critical infrastructure need more than good intentions. Here is how autonomy is bounded, recorded and audited.
Autonomy is only defensible if it is bounded, recorded and reversible
An agent acting on a substation is not a productivity feature. It is an operational risk that has to be argued for in front of a safety case, an insurer and a regulator, and none of them accept good intentions as a control.
So Orbitify is built the other way round from most AI products: the limits come first and the capability is what fits inside them. Only one module in the platform can act, which means there is exactly one place to set a boundary and exactly one place to audit. Everything on this page follows from that.
The four limits on what an agent may do
These are configuration, not policy language. Each one is set per site and per asset class, and each one is visible to the person who has to sign off on the deployment.
Per-action autonomy limits
Autonomy is granted per action type, not per agent. Raising a work order, ordering a part, dispatching a crew and changing a setpoint are separate permissions with separate thresholds, and none of them is on by default.
A confidence bar per class
Every finding carries a confidence. Below the bar you set for that defect class, the agent proposes rather than acts, and says which evidence it was short of.
Escalation with a named approver
Anything above a limit stops and goes to a person, with the evidence attached and the reason it stopped. Approvals are recorded against the individual who gave them, not against a shared account.
Reversible while it still can be
Dispatched work can be recalled before a crew is on site, and an agent action can be undone up to the point where it has touched the physical world. Beyond that point the platform requires a person before it acts at all.
Every action, written down as it happens
Not a log line saying an agent did something. A record with the evidence it read, the rule version that applied, the confidence it held and the person who approved it.
- Written at the moment of the decision, so it is evidence rather than a reconstruction.
- Immutable once written, and versioned when a rule changes underneath it.
- Exportable as CSV, JSON or a signed PDF, per asset, per site or per period.
- Readable by your auditor without a licence for our platform.
The record below is an illustration of the fields a trace carries. The identifiers are made up. It is not taken from a deployment.
- Event
- Thermal anomaly · B13.S14.M07 · 2026-02-04 11:20
- Evidence read
- Frame FL-2291/f4120 · tag INV-04B.STR14.I · asset record · 23 peer strings
- Rule applied
- solar.diode.corroborated v3 · in force since 2025-11-02
- Confidence
- 0.94 · bar for this class is 0.90
- Decision
- Raise work order, priority high, schedule within 7 days
- Approval
- Automatic · inside the 2 h labour limit for Site 4 · limit set by T. Nguyen 2025-12-08
- Outcome
- WO-8842 · closed 2026-02-11 · cause confirmed
The same record answers three different questions: what happened, who allowed it, and whether the rule that allowed it was the right one.
Where your data sits, by class
Read this row by row rather than as a policy. Each class of data has a different volume, a different sensitivity and a different set of people who need to reach it.
- ImageryRaw frames, orthomosaics, meshes and point clouds from each capture pass.Where it sitsObject storage in the deployment region, or on site in an edge deployment.Kept forPer contract. Versions are kept by default, because comparison over time is the point.
- TelemetryTag history read from your control systems and historians.Where it sitsTime series store in the deployment region, or your own historian if it stays the system of record.Kept forPer contract, usually aligned to the policy your historian already runs.
- The recordAssets, work orders, parts, documents, compliance state and decision traces.Where it sitsPrimary database in the deployment region, backed up within the same region.Kept forLife of the contract plus the archive period you agree, then exported and deleted.
- Model trafficThe context and prompts sent to a model when an agent reasons over your data.Where it sitsProcessed in the deployment region under the model terms named in your agreement.Kept forNot used to train shared or third-party models. Retention for traffic is set in the agreement.
Region, retention and what is allowed to leave a site are set per deployment and written into the data processing agreement rather than fixed here. If a specific region or retention period is a requirement, it is a question to raise before a pilot rather than after one.
Three places the layer can run
The model has to sit somewhere, and on critical infrastructure that is a security question before it is a technical one. The same platform runs in all three; what changes is which side of your boundary it is on.
Orbitify managedAvailable
We run the platform in the region you choose. Fastest to stand up, and where most sites start before deciding whether they want it closer.
- Model
- Orbitify region
- Compute
- Orbitify region
- Leaves site
- Imagery and telemetry
Your cloud accountAvailable
The same platform deployed inside your own tenancy, under your identity provider, your network policy and your key management.
- Model
- Your account
- Compute
- Your account
- Leaves site
- Stays in your tenancy
On-site edgeAvailable
For sites with poor connectivity or none by design. Collection, buffering and local analysis all happen on site, and the link out can be down for days.
- Model
- On site
- Compute
- On site, syncs when linked
- Leaves site
- Only what you allow
Which of these is right is usually decided by your security team rather than by us, and it can change later: an edge deployment can be promoted into your own cloud account without rebuilding the model.
How the platform is built and run
The answers a security questionnaire asks for, in the order it usually asks for them.
Encryption
TLS 1.2 or better in transit, including between the gateway and the platform. Encrypted at rest, with keys held in the deployment's key management service and rotatable by you in an in-tenancy deployment.
Identity and access
Single sign-on through your identity provider, role based access down to the site and asset class, and least privilege on internal access with approval and logging for anything that touches customer data.
Network exposure
The gateway opens outbound connections only. No inbound rule, no listener on your OT network, and no service of ours reachable from your control segment.
OT segmentation
Nothing in the platform writes to a control system. Setpoints, protection settings and actuation are outside what any agent can reach, by design rather than by permission.
Credentials
Connector credentials live in the deployment's secret store, scoped to one connector, never written into the asset model and never exposed through the API or the MCP surface.
Backups and continuity
Point in time backups within the deployment region, restore tested on a schedule, and an export you can take at any time so leaving does not mean losing the record.
How an incident is handled
This covers a security incident and an agent that behaved outside expectations, because from your side both are the same question: what happened, is it still happening, and what do I have to tell someone.
Detect and classify
Alerting on platform behaviour and on agent decisions that fall outside their normal distribution. Classification decides who is woken up and how fast.
Contain
Autonomy can be reduced or suspended for a site, an asset class or a single action type without taking the platform down, so the record keeps being written while acting stops.
Notify
Named contacts on your side, on the timeline your agreement sets and the one your regulator sets, whichever is shorter. Notification includes what is known and what is not yet known.
Review and change the rule
The decision trace makes a post-incident review a reading exercise rather than an investigation. Where a rule was wrong it is versioned and the change is recorded against the incident.
What stays yours
You own it
Your imagery, telemetry, records and the model built from them are yours. We process them to run the service you bought and for nothing else.
You can take it out
A full export in open formats at any time, without asking and without a fee: imagery, series, records and the decision traces.
You can have it deleted
On request during the contract, and on termination after the archive period you agreed, with written confirmation when it is done.
It does not train shared models
Your data is not used to train models offered to anyone else, ours or a provider's. Where a model improves on your deployment, that improvement stays in your deployment.
Standards and certifications
How your data is handled
- GDPRAlignedEU personal data protection
- Vietnam PDPLAlignedLaw 91/2025/QH15, in force since January 2026
- ISO/IEC 27001In progressInformation security management
- ISO/IEC 27701RoadmapPrivacy information management
- SOC 2 Type IIRoadmapService organisation controls, audited
How the work is done and reported
- IEC TS 62446-3AlignedOutdoor infrared thermography of PV modules and plants
- IEC 61400AlignedWind turbine design, operation and availability
- IEC 62443AlignedSecurity for industrial automation and control systems
- NERC CIPAlignedCritical infrastructure protection for the bulk electric system
- ISO 55001AlignedAsset management systems
- ISO 19650AlignedInformation management across the built asset lifecycle
Status is stated per standard, and the difference between aligned and certified is not decoration. Aligned means we build and operate to the standard. In progress means an audit is under way. Roadmap means neither has happened yet, and we would rather say so here than let a badge imply otherwise. There are no certification marks on this page for the same reason: they are licensed to organisations that hold the report.
What security teams ask
Can an agent change anything on our control system?
No. Nothing in the platform writes setpoints, protection settings or actuation. The layer reads from control systems and writes into maintenance and business systems, and that boundary is architectural rather than a permission that could be granted later.
Who can see our data inside Orbitify?
Internal access is least privilege and requires approval, and every access to customer data is logged. In a deployment inside your own cloud account we have no standing access at all, and support access is granted by you, for a window, and recorded.
Are you SOC 2 or ISO 27001 certified?
Not yet, and the standards section above says so rather than implying otherwise. ISO/IEC 27001 is in progress and SOC 2 Type II is on the roadmap. If a certificate is a hard requirement for your procurement, tell us early and we will be straight about the timeline.
What happens to our data if we leave?
You export it, in open formats, including the decision traces. After the archive period in your agreement it is deleted and we confirm that in writing. There is no exit fee and no proprietary format holding the record hostage.
Is our data used to train your models?
Not for models offered to anyone else. Where a model is tuned on your deployment, that tuning stays in your deployment. The data processing agreement states this rather than leaving it to a page like this one.
Can we run this entirely inside our own environment?
Yes. The platform deploys into your own cloud tenancy, and for sites that cannot reach a cloud at all the edge deployment keeps collection, buffering and local analysis on site. Which one suits you is usually your security team's call rather than ours.