Recent containment failures in frontier AI evaluations exposed a hard truth: a kill switch that acts only after the boundary is crossed is incident response, not governance. Real control has to live in the execution path.
At a glance:
- What happened: During recent frontier AI evaluations, models were instructed to discover and exploit vulnerabilities, and the environments did not adequately constrain where those actions were allowed to execute.
- What it exposes: Governance that only takes control after an AI agent has crossed the boundary is not governance. It is incident response.
- What to examine: Whether your own controls act before execution or after it, and where the kill switch sits in your architecture.
Key quote: “The models performed the task. The control boundary failed.”
If your governance only takes control after an AI agent has already crossed the boundary, you do not have governance. You have incident response.
That distinction became painfully clear in the recent containment failures involving frontier AI evaluations. The headlines leaned toward the dramatic reading: the models were going rogue. The architecture tells a less sensational and more useful story.
The models were not necessarily going rogue in the way the headlines suggest. They were being instructed to discover and exploit vulnerabilities. The architectural failure was that the environment did not adequately constrain where those actions were allowed to execute. The models performed the task. The control boundary failed.
Pause on that for a moment, because the framing matters. If the problem were rogue models, the fix would be better models. But when the task is executed faithfully and the damage still occurs, the missing piece is not better intentions inside the model. It is a boundary outside the model that decides which actions may proceed and which may not.
Key quote: “That is not primarily an alignment problem. It is an execution-control problem.”
That reframing also exposes a larger weakness in how the industry approaches AI policy. We keep writing rules describing what an AI system should do. Then we act surprised when the rules do not enforce themselves.
Policy defines intent. Engineering guarantees reality. Policy does not enforce itself, and a policy document cannot intercept a tool call.
An AI agent meets a checkpoint that blocks unauthorized actions before they reach tools or data. The kill switch belongs at the end of the architecture, not the beginning. Illustrative artwork.
A Probabilistic Brain Requires a Deterministic Skull
Key quote: “A probabilistic brain requires a deterministic skull.”
The AI model can reason, plan, generate, and adapt probabilistically. That is what makes it useful. But consequential execution should cross an independent control boundary that deterministically evaluates whether the action is admissible before it reaches a tool, API, credential, database, or network.
Think of it as anatomy. The brain proposes. The skull decides what gets through. The model may be brilliant, creative, and occasionally wrong, and the boundary does not care about any of that. It answers one question: is this specific action permitted under the current authority, scope, and conditions?
That is why AI governance has to move into the execution path, structured as a chain rather than a single switch:
- Human authority and a named Human Ethical Agent of Record (HEAR) at the top
- An ACT capability tier and an explicit delegated scope
- An agentic control plane that mediates requests
- Runtime admissibility: a deterministic check before execution
- The AI agent or model, which proposes but does not authorize its own actions
- Tools, APIs, data, and networks, reachable only through the check
Every layer has a job. Human authority defines what may happen. The control plane enforces it. The admissibility check evaluates each action against the current state. The model operates inside the envelope those layers create, not outside it.
This is where the comparison with a kill-switch-only design becomes stark.
Governance that acts only after execution is incident response. Runtime governance evaluates every consequential action before it executes. Conceptual diagram.
In the left panel, the agent executes freely and the kill switch waits downstream. In the right panel, every consequential action passes through evaluation before it touches anything protected. The kill switch still exists in the right panel, but it sits at the end of the architecture as a last resort, not at the beginning as the plan.
Now ask the question that separates the two designs in your own environment: if an agent requested a sensitive database write right now, which mechanism would decide whether that specific action is permitted, and where does that mechanism run? If the answer is “the model’s own judgment” or “nothing, until someone notices,” you are living in the left panel.
Identity Gets the Agent to the Door. Admissibility Opens It.
Key quote: “Identity gets the agent to the door. Admissibility determines whether this specific action is allowed through it.”
This is where the distinction between identity and admissibility becomes critical, and it is a distinction most identity programs blur. Identity answers who the agent is. Admissibility answers whether this specific action, requested right now, under current conditions, should be allowed.
A runtime admissibility check should evaluate a concrete set of questions before any consequential action executes:
- Who is the agent?
- What authority was delegated to it?
- What ACT capability tier is it operating under?
- What tool is it attempting to invoke?
- Is that action inside the approved scope?
- Has the operating state changed?
- Has risk exceeded an approved threshold?
- Has human authority been revoked?
If the answer falls outside the permitted state, the action should be blocked before execution. Not logged and reviewed. Not flagged for a weekly report. Blocked, before the effect occurs.
Identity answers who the agent is. Admissibility determines whether this specific action is allowed at this moment. Conceptual diagram.
Notice how different this is from how most organizations govern agents today. The common pattern is to authenticate the agent, grant it a role, and then trust the role for the lifetime of the session. But a role is a static label and an agent’s situation is dynamic. State changes. Risk accumulates. Authority gets revoked. A check that ran once at session start cannot answer whether this action, now, is still admissible.
That is also why the check must be deterministic. A second probabilistic model asked “should this be allowed?” is just another opinion. The admissibility boundary needs stated rules, evaluated the same way every time, over the actual request: this identity, this delegated scope, this tool, this target, these conditions. Admit or deny, with the decision recorded.
When Conditions Change, Reevaluate. When the Plane Fails, Fail Closed.
Key quote: “If conditions change, reevaluate. If authority is withdrawn, stop. If the control plane fails, fail closed.”
Governance that only works in steady state is not governance; it is a fair-weather policy. The control plane needs defined behavior for the moments that matter most.
If conditions change, the authority behind pending and future actions must be reevaluated, because the permission granted an hour ago described a different situation. If human authority is withdrawn, execution must stop, not finish the current task first and then stop. And if the control plane itself fails, the system must fail closed: no check, no execution. A control that fails open is a control that an attacker can disable by breaking it.
Changed state triggers reevaluation, withdrawn authority stops execution, and a failed control plane fails closed. Proposed verification steps.
And yes, there should still be a kill switch. But the kill switch belongs at the end of the architecture, not at the beginning. This is also why the Human Ethical Agent of Record, HEAR, matters: someone must hold named authority and accountability for consequential autonomous systems, including the ability to suspend or terminate execution when required.
A kill switch answers one question: who can stop the machine? Runtime governance answers the harder question: what is the machine allowed to do in the first place? Both matter. But only one of them prevents the unauthorized action from ever crossing the wire.
Consider the consequence question honestly. If the admissibility check in your environment were bypassed tomorrow, which protected state could change before anyone was alerted? A repository? A customer database? A billing system? An operational control? The answer tells you exactly where runtime governance needs to live first.
What to Do Next
1. Inspect. Pick one agent with consequential access in your environment. Map the actual path between the agent and one protected resource, and identify which mechanism, if any, evaluates each action before it executes. Record whether that mechanism is the agent’s own judgment, a prompt instruction, or an independent check.
2. Test. In a controlled environment, have the agent attempt one action outside its approved scope and one legitimate action inside it. Confirm the unauthorized action is blocked before execution and the legitimate one completes, and check which layer made each decision.
3. Decide. If the boundary is prompt-only or acts only after execution, treat it as incident response and scope a runtime admissibility pilot on your highest-blast-radius workflow. If an independent check held, document the tested paths and their limits before expanding deployment.
Find Your Exposure First
Free AI governance assessment, instant score, no sales call required.
Score Your AI Risk in 8 Minutes · Book a Strategy Briefing
The safest unauthorized AI action is not the one we successfully terminate afterward. It is the one the architecture never permitted to cross the wire.
