The SOCI evidence enclave.
How Australian critical-infrastructure obligations become a continuous, cryptographically assured capability that keeps audit evidence current, for the AI agents now running inside regulated estates.
General information, not legal advice. This paper describes an operating pattern. Where it names a Tovel control, the status on the Platform page (shipped, governed paths, shadow, in build) applies. It does not assert coverage of any framework Tovel has not shipped, and it references no customer Tovel has not been cleared to name. Where a claim would need a record to back it, that record is described rather than asserted.
The obligation is continuous. The evidence has to keep up.
Australia’s critical-infrastructure regime asks operators to run a living risk-management program with controls that stay effective over time. Yet the evidence most teams produce for it, screenshots, exports and quarterly attestations, is stale the day it is collected.
AI agents widen that gap. An agent that reads private data, ingests untrusted content and can reach external systems is exactly the combination the regime is designed to keep controlled, and it changes state faster than any manual evidence cycle can track. The question a regulator, a board or an insurer will ask has moved from “what is your policy?” to “show me what actually happened, on that action, at that time.”
This paper sets out a model that answers that question by construction. Each application runs inside an isolated enclave; every agent turn passes through a fixed harness of controls; and every consequential decision seals into an append-only, hash-chained evidence locker you can export and verify. Obligation becomes a byproduct of operating.
A program you operate, evidenced on demand.
Under the Security of Critical Infrastructure Act’s risk-management program obligations, and the sector-specific security rules that sit alongside them, responsible entities are expected to identify material risks to their assets, apply and maintain controls, and be able to demonstrate that those controls are operating, on an ongoing basis. The telecommunications sector carries analogous security and competent-oversight expectations.
Two properties of the regime matter most for this paper. First, it is continuous: the obligation is to keep controls effective over time. Second, it is evidentiary: an operator is expected to show, on request, that a control was in force when a given action occurred, and who was accountable.
From attestation to demonstration. Holding a policy that says an action requires approval is no longer enough; you are expected to show the approval that was actually given, for the action that actually ran.
That shift is manageable for slow, human systems. It is unmanageable for autonomous ones unless the evidence is produced by the system itself, at the moment of action, in a form nobody can quietly revise later.
Why agents break the current model.
Most assurance today is reconstructed after the fact from logs that were never designed to be evidence. They are mutable, scattered across tools, and silent on the questions that matter: who was accountable, what data was touched, whether a human signed off. For a periodic control that is uncomfortable. For an autonomous agent it fails outright.
The dangerous combination
Risk concentrates when a single agent can, in one action, hold three capabilities at once: access to private data, exposure to untrusted content, and the ability to communicate externally. That combination turns a prompt injection or a poisoned document into exfiltration.
The shadow estate
The riskiest agents are usually the ones nobody registered: scheduled scripts with standing credentials, copilots wired to production, MCP servers with no owner. They generate no reliable evidence because no one decided they should.
Closing the gap requires the evidence to be a designed output of the runtime, produced at the point of action and sealed so it cannot be edited afterwards. Collecting more logs does not get there.
One isolated enclave per application.
You bring an application or agent; Tovel runs it inside a dedicated enclave in your AWS account. On governed paths, least-privilege scopes go in and signed receipts come out. Per-enclave egress limits and network recording are in build, so the boundary is a governance and workload boundary today, not a network containment guarantee.
- Boundary. Each application gets its own enclave with its own identity, policy and owner. Isolation between enclaves is enforced by the account structure and scopes you grant.
- Harness. Governed turns pass through the six layers described below, enforced at runtime.
- Evidence. Verdicts, approvals and checkpoint results seal into the locker. Trajectories and payloads stay in your account under your retention.
Inside the enclave, every agent carries a cryptographic identity, a trust tier and a named human owner. The enclave is the unit you assess, score and export, which is also the unit an auditor can reason about.
Six layers, on every turn.
Six control layers apply on governed paths, from the orchestration loop to a deterministic delivery checkpoint. The record shows which were applied on a given run.
- 01 Agent loop. A bounded, inspectable plan-act-observe loop. The plan is declared up front and each step is checked against it.
- 02 Model. Calls are restricted to an allow-list of approved foundation models. Inference stays in the Australian region.
- 03 Role-scoped tools. Least privilege, read-only by default. A single action cannot hold private data, untrusted content and external comms without a human.
- 04 Context. Retrieval, memory and caching are provenance-tracked, so poisoned context can be traced to its source and contained.
- 05 Guardrails. Policy, safety and content guardrails run per turn, aligned to the framework packs you have enabled.
- 06 Checkpoint. A deterministic checkpoint blocks delivery when a stage is incomplete, a signature fails or a fallback report fails. Model-judged review is an extension point.
A record you can export and verify.
Guardrail verdicts, human approvals, tool calls and checkpoint results on governed paths are written to an append-only evidence locker, hash-chained and signed, and exportable with their verification material. A receipt does not contain the raw payload. It contains proof of what was decided, by whom, under which policy and rules version, and with which approval fingerprint.
Residency
Governed workloads run on AWS Bedrock and AgentCore in the customer's AWS region, inside the customer's account. Residency is confirmed per data plane and inference profile at onboarding. Raw traces and payloads stay in your account.
Packs assemble on demand. A human reviews what leaves.
Because receipts are produced continuously and sealed as they are created, assembling them for an audit is an export step. Signed receipts export today with verification material; a formatted board or audit pack is in build. Posture is scored against the framework packs Tovel has shipped and you have enabled. Anything that leaves the enclave is reviewed by a named human first.
The result is the property the regime is really asking for: on any governed action, you can show the control that was in force, the data it touched, the person accountable, and the proof that the record was not edited afterwards. Product evidence supports an organisation’s obligations; it does not fulfil them on its own.
What we claim, and what we do not.
Regulated buyers distrust hype, so we are explicit about the line between what Tovel evidences today and what it does not.
We evidence
- Posture scored against the framework packs Tovel has shipped and you have enabled.
- Governed workloads on AWS Bedrock and AgentCore in your AWS region.
- A signed, hash-chained evidence locker for governed actions, exported with verification material.
- Human-in-the-loop and read-only defaults, on by design.
We do not claim yet
- Coverage of any framework pack Tovel has not shipped.
- Certifications or badges that are not independently verified.
- Customer names we have not been cleared to reference.
- Prompt-injection prevention, full network containment, or that every real-world event was captured.
- Anything a record in the evidence locker cannot back.
Five questions to bring to any agent-governance vendor.
- Is evidence produced at the point of action, or reconstructed later? Ask to see a single sealed record for one real action.
- Can a record be altered after the fact? Look for append-only storage and a verifiable hash chain.
- Where do data and inference actually run? Residency should be a location you can name.
- What stops one action holding private data, untrusted content and external reach at once? The control should be enforced in the tool layer.
- Which frameworks are scored, and which are explicitly not claimed? A vendor that names what it does not cover is easier to trust on what it does.
See the record being made.
A 30-minute walkthrough of a governed workflow, its controls and the evidence it leaves, then a scoped evaluation on your AWS estate once access is agreed.
