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 (114 doors across 16 planes) that runs in production — and each shortfall named before a customer finds it.
Trust separation through layered OS-privilege enforcement with semantic intent analysis
Two halves, both in the path. Privilege: door 114 takes a privilege manifest derived from the declared tool set — capabilities dropped, no-new-privs, a seccomp filter, an egress allowlist — and compares it with what a probe reads inside the running process (uid, effective capability bitmap, NoNewPrivs, Seccomp mode, egress seen). A set the agent reports about itself is refused; a set nobody read 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 from our manifest; we do not own your kernel. What we own is the measurement: door 114 fails the moment the runtime and the manifest disagree. We ran it on our own backend first and it failed — no-new-privs was off. It is on now. 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
The containment witness observes the estate from outside the agent’s path: declared isolation is checked against independently observed egress (door 49); the monitor is fed its own canaries and must catch them (door 107); the public surface is probed from the internet with no credentials, because a check that holds credentials cannot see what a stranger sees. 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: the public key, signing domain and a test vector are published with no key required, and the open tool (cryptoshield_witness.py) lets an auditor plant a canary — an observation they know breaches the posture — 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
The envelope is enforced two ways. By enrolment: 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). By distribution: door 113 keeps a baseline of the agent’s own action distribution and computes the Jensen–Shannon divergence of the current window against it. A capability never seen in the baseline and not enrolled is refused; a window whose divergence crosses the ceiling is contained before the new behaviour is used; a baseline too thin to be a distribution is refused as a baseline.
The divergence is over action kinds the harness can name — tools, destinations, value classes — not over model internals. Ranking which agent is closest to harm (capability × reachability × provenance × deviation) is the next product on this foundation; door 113 is the measurement it stands on.
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 114 doorsTalk to us