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.
- Versioned when a rule changes underneath it. Making the record tamper-evident is in progress.
- Readable through the audit API today. Export as CSV, JSON or a signed PDF, per asset, per site or per period, is in progress.
- Readable by your auditor without a licence for our platform, once export ships.
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. On-site storage in an edge deployment is in progress.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 sitsSent to models on Amazon Bedrock under the terms named in your agreement. Keeping every model call inside the deployment region is in progress; today some calls use AWS cross-region routing.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 for you. Today that is Amazon Web Services in Singapore (ap-southeast-1); hosting in Vietnam is in progress. Fastest to stand up, and where every site starts today.
- Model
- Orbitify region
- Compute
- Orbitify region
- Leaves site
- Imagery and telemetry
Your cloud accountIn progress
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 edgeIn progress
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
Only the managed deployment runs today. Deployment inside your own cloud account and on-site edge deployment are in progress; if either is a requirement, raise it before a pilot so the timeline is agreed in writing.
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. The primary database and object storage are encrypted at rest with keys held in AWS key management. Extending encryption at rest to every supporting store, and keys you control in an in-tenancy deployment, are in progress.
Identity and access
Role based access by organisation, project and permission, with tenant isolation enforced by the database itself. Single sign-on through your identity provider, and approval and logging for every internal access to customer data, are in progress.
Network exposure
The platform does not connect to your OT network today. The on-site gateway is in progress, and is designed to open 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
Platform credentials are held in the cloud secret store and are never built into images. Connector credentials follow the same rule, scoped to one connector and never exposed through the API or the MCP surface. Moving every remaining credential into the secret store is in progress.
Backups and continuity
Point in time backups for 14 days within the deployment region, with a restore already rehearsed. Scheduled restore testing and a self-service export, so leaving does not mean losing the record, are in progress.
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
An export in open formats, without a fee: imagery, series, records and the decision traces. We produce it on request today; a self-service export is in progress.
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
- GDPRIn progressEU personal data protection
- Vietnam PDPLIn progressLaw 91/2025/QH15 and Decree 356/2025/ND-CP, in force since January 2026
- Vietnam Cybersecurity LawIn progressLaw 116/2025/QH15 and its implementing decrees, in force since July 2026
- Vietnam Data LawIn progressLaw 60/2024/QH15 on data, including core and important data
- Vietnam AI LawIn progressLaw 134/2025/QH15 on artificial intelligence, in force since March 2026
- ISO/IEC 27001In progressInformation security management
- ISO/IEC 27701In progressPrivacy information management
- ISO/IEC 42001In progressArtificial intelligence management systems
- SOC 2 Type IIIn progressService organisation controls, audited
- CSA STARIn progressCloud Security Alliance security, trust and assurance registry
How the work is done and reported
- IEC TS 62446-3In progressOutdoor infrared thermography of PV modules and plants
- IEC 61400In progressWind turbine design, operation and availability
- IEC 62443In progressSecurity for industrial automation and control systems
- NERC CIPIn progressCritical infrastructure protection for the bulk electric system
- ISO 55001In progressAsset management systems
- ISO 19650In progressInformation management across the built asset lifecycle
Status is stated per standard. Every entry is in progress: we are working towards it, and no audit has been completed and no certificate or report has been issued for any of them yet. Certified will appear only when an auditor has issued one. 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?
Access is role based and scoped to your organisation, and the database itself keeps one customer from reading another customer's rows. Approval and logging for every internal access to customer data is in progress. In a deployment inside your own cloud account, which is also in progress, we would have no standing access at all.
Are you SOC 2 or ISO 27001 certified?
Not yet. Every framework in the standards section above is listed as in progress, and none has been audited. ISO/IEC 27001 is the first certification we are working towards. 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 get it back in open formats, including the decision traces; we produce the export on request today, and a self-service export is in progress. 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?
Not yet — that is in progress. Today the platform runs managed by us on AWS in Singapore. Deployment into your own cloud tenancy, hosting in Vietnam, and an edge deployment that keeps collection, buffering and local analysis on site are being built. If one of them is a requirement, tell us before a pilot and we will agree the timeline in writing.