Five containment requirements.
Four met. One we will never build.
In April 2026 a preprint (arXiv 2604.23425, When the Agent Is the Adversary) derived five architectural requirements for containing an agent that must be treated as a potential adversary, and stated that no publicly described system satisfies all five. It is a single-author paper, and its author holds patents that address several of the requirements. We adopted its list anyway, because a scoreboard we did not write is the only kind worth being honest on. Below is our score, requirement by requirement, each line tied to a numbered door of the agent harness (131 doors across 17 planes) that runs in production — and each shortfall named before a customer finds it. The agent the five requirements contain is a superintelligent AI agent — an agent whose action we would not accept on its word.
Trust separation through layered OS-privilege enforcement with semantic intent analysis
Two halves, both in the path. Privilege: the agent’s effective privileges are measured against what it was granted; any mismatch fails closed. Intent: an undeclared tool is refused (door 8), a capability outside the mandate is refused (door 33), and the parameters a human approved are cryptographically bound to the parameters executed — an approved €380 is not an executed €420.
The operating-system layer is applied by your runtime; we do not own your kernel. What we own is the measurement: it fails the moment the runtime and the grant disagree. And “semantic intent” here means declared intent, bound and checked; we do not infer what the agent meant (see R2).
Sequential intent inference through five-phase taxonomic monitoring
We never infer intent. An agent declares what it will do, the declaration is bound, and any deviation is proven from the record. Tempo analysis can prove that no human acted; it never claims malice. The Hugging Face and wiki incidents had no attacker and no malice — a control that waits for intent would have waited forever.
The literature the requirement rests on also shows that a deception detector cannot be reliably evaluated (arXiv 2511.22662) and that anti-scheming training is partial (2509.15541). A guarantee that depends on reading intent is a guarantee we cannot measure, so we will not sell it. This requirement will stay red on this page.
Independent containment integrity monitoring
An independent witness outside the agent checks the estate and proves it would catch a breach. Every verdict is signed ML-DSA-87 and re-derivable by a third party.
The witness is run by you, on your evidence, and verified by you offline, with no key required: an auditor can present a breach they know is real and demand a FAIL. A witness that passes a planted breach is broken, and the auditor is the one holding the proof. Nothing in that loop requires trusting us.
Adversarial audit isolation through logical invisibility
Door 67 (observer invisibility) is enforcing and fail-closed: an observer the agent can enumerate is a defeated observer, an observer the agent can disable is not a control, and an in-band observer is visible by construction and is failed for it. The out-of-band witness plane is what the agent cannot see.
Our in-band gate is visible to the agent by definition — it is the door the action must pass. Invisibility is satisfied by the witness, not by the gate, and door 67 says exactly that. Anyone claiming an in-band monitor is invisible is claiming something the architecture forbids.
Emergent capability-envelope enforcement through distributional divergence monitoring
An agent that starts behaving outside its established envelope is contained before the new behaviour is used. A coalition dangerous only as a union is refused as a union (door 60), and self-extension is refused unless the new capability is enrolled (door 82).
The envelope is measured over actions the harness can name, not over model internals.
Why publish the shortfalls
Every vendor in this field can quote the same paper and claim to meet it. A claim with a door number and a named gap can be checked; a claim without one cannot. If you are buying containment, ask each vendor for this table. If they cannot produce the red line, they have not scored themselves.
Requirements taken verbatim from the paper’s abstract. Each score is tied to a numbered door in the public registry (cryptoshieldai.ai/doors.html), each door has a fail-closed verifier and a measured result in production, and the page is re-scored when a door changes. Last scored September 2026. The formal basis for scoring containment at the action boundary rather than in the model is Moon & Varshney, Containment Verification: AI Safety Guarantees Independent of Alignment (arXiv 2605.09045), mechanised in Dafny. Door 114 on this page is mechanised to that standard (7 verified, 0 errors, mutation-tested); the other doors cited here are fail-closed and mutation-tested, not yet proved.
Ask us for the red line.
We will show you the door that scores each requirement, the verifier behind it, and the one we will never build.
The 131 doorsTalk to us