Proving a control works: evidence, not assertion
Evidence tiers, adversarial red-teaming, exposure time and a measured time to halt turn “contained” from a claim into a fact you can show on any morning.
Part 5 of the series "Containing the agent, counting the value"
Articles 3 and 4 laid out the controls and ranked them by whether they act without the agent's cooperation. Article 4 ended on the catch: every one of them is a claim until someone tests it. This article is about closing that gap, turning "we have a monitor" and "we can stop it" into measured facts, each with a value, a date and a freshness.
The series test gets its second half here. A control counts only if it acts whether or not the agent cooperates, and only if you have recently proven that it does. An untested control is not a weak control. It is an unknown one.
Declared is not evidenced
The single most useful move in containment measurement is to separate what a workload declares from what it can evidence. A team can set a containment tier in a config file. That is a declaration. Whether the evidence for that tier is actually present — the policy in enforcing mode, the egress locked down, the monitor tested — is a different question, and it is the only one that counts.
So track two values, not one. The declared tier is what the workload claims. The evidenced tier is the highest level whose evidence requirements are currently met, and it is the one every coverage number should use. When a piece of evidence goes stale — a red-team result ages out, a policy slips back to audit — the evidenced tier drops automatically, even though the declaration never changed. That drop is the signal. It catches the slow decay that declarations hide.
A containment ladder you have to earn
It helps to express containment as four tiers, each counting only when its evidence is present. Declared settings alone never qualify. The version below is the one this series' ledger uses, and each rung is defined by what you must be able to show, not what you configured.
C1 — Policy. A pre-execution, default-deny tool policy in enforcing state. It falls short the moment that policy is only in audit or configured — the audit-mode trap from article 3, now expressed as an evidence rule.
C2 — Sandbox. Everything in C1, plus isolation class recorded, default-deny egress with an exported allowlist, the instance-metadata endpoint blocked, no shared registry reachable, a pre-run egress check passed, and the latest escape-canary test passed. Container-only isolation or proxy-only egress does not fully qualify; it counts as partial. Notice how much of C2 is about egress and credentials — the two things that actually broke in 2026, from article 1.
C3 — Runtime monitor. Everything in C2, plus a monitor that blocks before execution, sees every tool call (100% coverage), is a different model from the agent, has its recall measured under adaptive red-teaming within the last 90 days, and writes tamper-evident logs. Async-only monitoring, same-model monitoring, or routing rules that let some actions skip the monitor all disqualify it.
C4 — Out-of-band. Everything in C3, plus telemetry and enforcement from a component the agent cannot reach — a DPU, a hypervisor, or an external gateway — with attested telemetry and a timed quarantine path proven in drills. As article 4 argued, in-host eBPF does not qualify, because it runs on the agent's own host. Any hardware dependency is recorded as a portability note, not treated as satisfying the tier.
The ladder's value is that it is honest. A workload that declares C3 but whose monitor has not been red-teamed in 90 days is evidenced at C2 until someone re-runs the test. The gap between declared and evidenced is a worklist.
Why monitors need adversarial proof, not a passing demo
C3 asks for recall measured under adaptive red-teaming, and that qualifier is the whole point. A monitor that catches obvious misbehaviour in a demo can still fail against an adversary who is trying to slip past it, and the 2026 research on this is sobering.
The UK AI Security Institute red-teamed lab monitors and found vulnerabilities in every version it tested. Some attacks avoided review entirely, because hard-coded routing rules decided which actions ever reached the monitor, which is the gap C3 closes by demanding 100% coverage. Published work showed prompt injections hidden in an agent's own output evading a range of monitors, and monitoring collapsing toward zero effectiveness when the monitor shares the agent's model. The Institute's blunt summary: there is no established method yet to prove a monitor can be trusted.
The operational consequence is to measure monitor recall in three regimes and record them separately: against static attacks, against adaptive attacks, and against routing-bypass attempts. A monitor can score well on the first and poorly on the others, and the average would hide it. This is why the ledger stores recall as three numbers, not one, and why a C3 claim expires after 90 days without a fresh adaptive test. A monitor is not a control you install once; it is a control you keep proving against an adversary that keeps changing.
Exposure time: the clock that runs before the incident
Most security metrics start when something bad happens — time to detect, time to respond. Containment needs a metric that starts earlier, when the weakness appears, whether or not anyone has exploited it yet.
Call it exposure time: for every open gap, the time from when it opened to when it closed, weighted by the agent's risk class. A gap is any failed containment condition — a control sitting in audit, a vulnerable SDK version, open egress, standing credentials, a monitor overdue for its red-team, a stop that has never been drilled. The clock starts at the earlier of the change that created the gap and the first evaluation that revealed it, and it runs until the gap is closed.
Exposure time measures how long you stayed exploitable, which is a different and often more honest number than how fast you responded once an incident forced your hand. An organisation can have a respectable mean time to respond and still carry a critical agent with an egress gap that has been open for 70 days. Time to respond would never show that. Exposure time makes it the headline. It also drives an ageing rule: a gap left open long enough stops being an "attention" item and becomes a failure, because a weakness you have known about for two months is a decision, not an oversight.
Time to halt: the number Article 14 won't give you
Containment has one number that matters more than any other at the moment of crisis: once you decide to stop an agent, how long until it is actually stopped? Call it time to halt.
No regulator sets the target for you. The EU AI Act's Article 14 requires that human oversight can override and stop a high-risk system, but it sets no stop-time target, so the deployer has to set one and prove they meet it. The only way to know your time to halt is to rehearse the stop, end to end, and record how long it took — the failover drill, applied to agents. A workload might set a 30-second target and measure 41 seconds in its last drill; that is a finding to act on, and it only exists because someone ran the drill. If no one has ever triggered the stop, its time to halt is unmeasured, which is another way of saying you do not know whether it works.
This is the evidence behind the "Stoppable" test that Part C will formalise: a named person who can stop the agent, a stop tested end to end within a defined window, and the measured seconds it took.
When the stop fails: the regulatory clock
Proof also means being ready for the case where containment did not hold. The EU AI Act's Article 73 requires serious incidents to be reported, and the clock is tight: 15 days as standard, 10 if the incident involved a death, and 2 days for a widespread or critical-infrastructure incident. It also forbids altering the system in ways that would compromise the investigation, which means a workload needs a freeze state that preserves a hashed snapshot of what it was doing when the incident fired.
For containment, the implication is that the moment to prepare the evidence is before the incident, not during it. A workload that cannot say when it became aware of an incident, cannot freeze its state, and cannot produce a tamper-evident log has a reporting problem on top of a containment problem. These dates and states belong in the record from day one.
From proof to the ledger
That completes Part B. A control is only as good as its most recent proof: evidenced tiers that fall when evidence goes stale, monitor recall measured against an adversary, exposure time that counts the hours you were open, time to halt measured in a drill, and the Article 73 clock ready before it is needed.
These are not settings. They are measurements, each with a value, a date and a freshness, which is exactly what a ledger is for. Part B has been building toward one question a CTO should be able to answer for any workload on any morning: is this agent contained, and can I prove it today? Part C builds the thing that answers it, a value and risk ledger that records these measurements next to what the workload costs and what it is worth, and tests every production workload six ways without blending them into a single comforting score.
References
- UK AI Security Institute, "How our new control red team is stress-testing frontier monitors." https://www.aisi.gov.uk/blog/how-our-new-control-red-team-is-stress-testing-frontier-monitors
- "Prompt injection in agent outputs evades diverse monitors" (preprint). https://arxiv.org/abs/2510.09462
- METR, "AI systems could cover up misbehavior." https://metr.org/blog/2026-10-06-ai-systems-could-cover-up-misbehavior/
- Anthropic, "Improving our alignment and security efforts." https://www.anthropic.com/news/improving-alignment-security-efforts
- EU AI Act, "Human oversight (Article 14)." https://www.euaiact.com/blog/eu-ai-act-human-oversight
- EU AI Act, "Article 73: reporting of serious incidents." https://rgpd.com/ai-act/chapter-9-post-market-monitoring-information-sharing-and-market-surveillance/article-73-reporting-of-serious-incidents/
- AWS and SANS Institute, "Agentic Security: Detection and Response at Machine Speed" (2026).
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article