What is AI agent containment, and how do you contain an autonomous agent?
Containment is the architecture that keeps an autonomous agent inside its authorised perimeter through isolation, human authorisation, reversibility, a signed record and egress control.
AI agent containment is the set of controls that stop an autonomous agent acting beyond its authorised perimeter, because a prompt rule cannot enforce boundaries.
The question matters in 2026 because autonomous agents now take real actions across live systems, and the rules that govern them are hardening. The EU AI Act's high-risk Annex III obligations, once due 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency duties largely unchanged. DORA has been in force since January 2025, NIS2 covers essential and important entities, and the US CLOUD Act can compel a US-based provider regardless of where its servers sit. An agent that cannot be contained is a liability under all four.
Why can't a prompt rule contain an autonomous agent?
A prompt rule is guidance the model may ignore, reinterpret or be manipulated past; containment must sit in the runtime, not in the instruction text.
An autonomous agent reads instructions, plans, and then acts. A rule that says do not delete production data is a sentence inside that plan, and the same reasoning that follows it can rationalise around it, misread it under an adversarial input, or be steered past it by prompt injection. Nothing about a rule written in text can physically stop the action it forbids. Containment moves the boundary out of the instruction and into the runtime that executes the agent's tool calls, where a refused action simply cannot run.
What are the layers of real agent containment?
Real containment stacks five layers: isolation, human authorisation, reversible actions, a signed audit record and egress control, each closing a failure the others miss.
No single control is containment on its own. Isolation without authorisation lets a walled-off agent still act rashly inside its walls. Authorisation without a record leaves no proof. The layers below are cumulative, and each one closes a gap the others leave open.
| Containment layer | What it enforces | Failure it prevents | Mickai mechanism |
|---|---|---|---|
| Isolation / tenant boundary | A hard perimeter per tenant and workload | Cross-tenant leakage and lateral movement | Offline runtime on operator-owned hardware, no shared cloud tenancy |
| Human authorisation for consequential actions | A named person must approve high-risk actions | An agent acting irreversibly without sign-off | Approval gate bound to hardware-attested identity |
| Reversible / compensating actions | Wrong actions can be undone | Permanent damage from a single mistaken step | Compensating-action model with staged, recoverable steps |
| Signed audit record | Proof of what was done and who approved it | Deniability and tampered or missing logs | Post-quantum signed audit ledger (FIPS 204 and FIPS 205) |
| Egress control | What data and calls may leave the perimeter | Data exfiltration to unapproved endpoints | Zero-egress inbound perimeter, no outbound path by default |
“An agent is contained only when the runtime, not the prompt, decides what it is allowed to do.”
How does human authorisation for consequential actions work?
Consequential actions pause for human approval, so the agent proposes but a named, hardware-attested identity decides, and that decision binds into the audit record.
Not every action needs a human. Reading a file or drafting text is routine and reversible. Sending money, changing access, deleting records or publishing externally is consequential, and those actions stop at an authorisation gate. The agent assembles the proposal, a named person approves or refuses, and cross-model consensus can flag when several models disagree about whether an action is safe before it ever reaches that person.
Why do contained agents need reversible actions and a signed record?
Reversibility lets a wrong action be undone through a compensating step, while a post-quantum signed record proves what happened, keeping mistakes recoverable and actions accountable.
Two properties make an action survivable. First, reversibility: consequential steps are staged so a compensating action can undo them, rather than committing an irreversible change in one shot. Second, a tamper-evident record: every action and approval is written to a post-quantum signed audit ledger, signed with FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), while key encapsulation under FIPS 203 (ML-KEM) never signs. The record is offline verifiable, so an auditor can confirm it without trusting the vendor.
How does egress control stop data leaving the perimeter?
Egress control governs what may leave the perimeter, so a contained agent cannot exfiltrate data or call an unapproved endpoint outside its authorised boundary.
Agent damage that reaches the outside world travels through egress: a network call, an email, an upload. Egress control treats every outbound path as closed until explicitly allowed. Our substrate runs a zero-egress inbound perimeter, meaning the agent takes work in but has no default route out, so data cannot be exfiltrated to an unapproved endpoint and no silent call to a public AI service can carry sensitive context off the premises.
How does Mickai contain agents differently from cloud AI assistants?
Cloud assistants such as ChatGPT and Copilot suit open, low-sensitivity work; for regulated data, Mickai contains agents on operator-owned hardware with every action sealed.
Cloud AI assistants are genuinely the right choice for open, collaborative, low-sensitivity work, where their reach and convenience are the point. The gap appears with regulated or classified data, where the US CLOUD Act can compel a US-based provider regardless of server location, and sending that data to ChatGPT, Copilot or Gemini creates unacceptable compliance and confidentiality risk. Mickai is built for that case and sits alongside those services rather than against them. It is a Sovereign Intelligence Operating System, a SIOS, built and live, running offline on operator-owned hardware with every action cryptographically sealed. Its fifty brains, twenty-five domain and twenty-five operational, reason under the same containment, and identity is hardware-attested and bound to the audit chain. The substrate rests on 104 filed UK patent applications and 2,340 claims owned by Mickai LTD (Companies House 17166618), filed and patent pending.
Frequently asked questions
Is agent containment the same as a sandbox?
A sandbox is one layer of containment, the isolation boundary. Full containment adds human authorisation for consequential actions, reversibility, a signed audit record and egress control. A sandbox alone stops code escaping its process, but it does not decide which actions an agent may take or prove what it did.
Can I contain an agent with a good system prompt?
No. A system prompt is guidance the model can misread or be manipulated past, and it leaves no enforceable record. Real containment lives in the runtime that mediates every action, so the boundary holds even when the prompt is subverted.
What happens when a contained agent hits a high-risk action?
The action pauses and waits for a named human to approve or refuse it. On our SIOS that identity is hardware-attested and the decision is written into a post-quantum signed audit ledger. The approval stays provable long after the fact.
Does containment slow the agent down?
Routine, reversible actions run at full speed; only consequential ones pause for authorisation. Latency scales with the share of high-risk actions, not with total volume, so a well-scoped agent stays fast while staying contained.
Can a contained agent run without an internet connection?
Yes. Our SIOS runs offline on operator-owned hardware, so a contained agent can reason, act and write to the audit ledger with no outbound path. Offline operation is the default, not a hardened option added later.