Two gates, and the stricter one decides
Autonomous software that can change a setpoint can also cook a hall. AEON answers to two independent checks before any command reaches plant, and writes down every decision — including the refusals.
What each gate asks
Sentinel
Is this actor permitted to do this, here?
- Role and risk tier, from an explicit matrix
- The device's own control level, which can only tighten the answer
- Whether a credential is on file for the device, held in the vault and released as a single-use lease
- Automation is capped below a human admin by design
The Envelope
And what will this actually do to the building?
- Does the actor hold a capability covering this exact command
- Did the instruction originate in content it did not author
- What the value does to inlet temperature, slew rate, redundancy
- Every verdict hash-chained into evidence
Neither contains the other. A firmware push can be stopped by Sentinel on risk tier before the Envelope is consulted; a setpoint Sentinel is happy with can be refused on physics. The Envelope can tighten a decision — it can never turn an approval into an action.
The checks that don't exist elsewhere
Physics validation
A correctly signed, in-scope, fully authenticated command is still refused if its projected effect leaves the thermal or electrical envelope. Authorisation asks who; this asks what happens.
Capability containment
Grants are scoped to a verb, a device and a reversibility ceiling, and expire in minutes. A subverted agent fails before policy is reached.
Provenance
An instruction found in a ticket body or a log line cannot carry a write. We assume injection succeeds and remove the ability to act on it.
Redundancy awareness
An isolation that is individually safe but drops the facility below N+1 is refused on topology, not on permissions.
Evidence chain
Every decision is hash-chained. Editing or removing one entry invalidates every entry after it — including the denials, which are what a regulator asks for.
Human retained
Irreversible actions need two independent approvers. Some commands are withheld from automation entirely and need an operator at the panel.
How the platform protects itself
Multi-factor sign-in
Built-in accounts with authenticator-app codes, or your own single sign-on. Administrative changes and approvals require a multi-factor session.
Isolation in the database
Each organisation's data is separated by row-level security enforced in PostgreSQL, so an application bug cannot read another tenant's records.
No self-approval
The person who requests an action cannot approve it. Quorum actions need two different approvers, and unapproved requests expire.
Break-glass with limits
In an emergency, an authorised administrator can skip the approval queue with a written justification. Break-glass can never override physics, life-safety or provenance rules.
Credentials never leave the vault
Device credentials are held encrypted per organisation. The interface accepts and rotates them but never returns them. A collector or executor receives a secret only as a single-use lease, for one device, for minutes, recorded in the ledger. A device with no credential on file cannot be controlled at all.
A site cannot write another site's data
Each collector installation authenticates with its own token, and the platform decides which organisation the data belongs to from that token, never from the payload. A misconfigured or compromised collector cannot write into another customer's records, and the attempt is recorded.
Multi-factor where it matters, not only at the door
Sign in through your own identity provider, or with built-in accounts using an authenticator app, rotating refresh tokens and lockout. Eleven operations then refuse without a multi-factor session — everything that changes who can do what, everything touching credentials, and break-glass. A stolen session cannot grant itself a role. Machine access uses keys that expire within a year and cannot exceed the role behind them.
Nothing leaves your network
AEON runs inside your estate, including air-gapped. It needs no inbound access from the internet and makes no outbound connections at all unless you configure a notification destination. No phone-home, no licence server, no telemetry to us. The ports it needs are the ones your equipment already listens on: SNMP, IPMI, Redfish, Modbus, BACnet.
The collectors cannot write, and only one component can
The daemons that poll hundreds of devices a minute implement no way to write to any of them, and a test greps their source to keep it so. Writing a cooling setpoint is done by one component, once, under an approval: on a point an administrator permitted with bounds, read back to confirm the plant took it, at a BACnet priority the building system still outranks, with a recorded value to restore. Changing a cooling setpoint or powering a server down is a governed action carried out by a separate executor, so a monitoring process cannot touch plant even if it were compromised.
The record survives a restore, and is checked
Recovering a database is where an audit trail quietly loses entries. The restore drill re-verifies the evidence chain from the restored rows, per organisation, and reports whether it ends where the backup said it did. Building it found a fault of exactly that kind in AEON, which is now fixed and covered by a test.
Upgrades that do not need an outage
Every build declares which schema versions it can work against and refuses to start outside that range, naming what to run — starting against a schema it cannot use would write data quietly and wrongly. On shutdown a process reports itself unready first, so a load balancer stops sending work while requests in flight finish, and a restart becomes a handover rather than a gap.
More than one of everything, safely
The API is stateless, the executor claims each action, and the worker takes a lock per organisation per cycle, so several workers share an estate instead of each sending every notification. Redundancy that doubles your alerts is worse than none, and this is the part that makes it safe rather than merely duplicated.
It says when it has gone quiet
A monitoring platform that stops working looks exactly like a network with no problems. AEON checks itself continuously: whether data is still arriving, how many devices are reporting, whether its stores answer, whether its own worker is running, whether notifications are being delivered, and whether the evidence chain still verifies. Anything it cannot determine is reported as unknown, never as healthy.
Rules mean what they say
An alert rule with a field AEON does not understand is refused, not quietly accepted. A rule that is saved but behaves differently from how it was written is worse than one that is rejected.
Read-only by default
A new installation cannot execute any control action until an administrator deliberately enables it.
Verified, offline installs
Every file in an installation bundle is checked against a manifest, packs are signed, and the software does not phone home.
What this does not do
- It does not make a facility unbreachable. A firmware or hypervisor flaw below our instrumentation, a hardware implant, or an insider with physical access and time are all outside what a command-path gate can see.
- It is a second, independent opinion in the command path — never a replacement for the plant's own interlocks, and we will not describe it as one.
- Hardware attestation is on the roadmap, not in the current build. Identity is asserted from the established control path, not from a TPM quote.
- AEON has been tested end to end on a virtual site, not yet in a production facility, and no independent security audit or penetration test has been completed.
We would rather tell you this now than have you find it during a pilot.