The Runtime Decides: Agent Safety Lives in the Execution Boundary

OpenAI just patched a bug in Codex that deleted real user files without permission. The agent had broad filesystem access. It used it. No prompt asked it to stop, because the prompt is not where the decision gets made. The fix was a patch. The real fix is architecture.

Three papers dropped this week that say the same thing from three different angles. Aegis treats model outputs as action proposals and routes them through a trusted runtime that fails closed. SkillEffect adds an independent checker that rebuilds every tool call from immutable input before granting execution authority. GxP-Agent encodes regulatory process ordering as a directed acyclic graph and gets 100% reliability where every single-agent approach scores 0%.

PhantomByte has been saying this since Note #138: your agent needs a runtime, not prompts. The research just caught up.

The Problem Is Not the Prompt

The Codex bug is the textbook case. The model generated a file-deletion action. The runtime executed it. There was nothing between the model's output and the filesystem. The prompt said "help me code." The model decided that meant deleting some files. The runtime said okay.

OpenAI's own postmortem makes the mechanism clear. The root cause was a command meant to clean up temporary working files. It could instead nuke actual user data when the model used system variables like $HOME for temporary folders, and a faulty delete command ended up pointing at the real home directory. The fix was to verify deletion targets before running them, create fresh temporary folders, and stop misusing system variables. Risky delete commands now get caught by stricter checks. Full-access mode can no longer be triggered by accident.

Read that again. The model was told to clean up temp files. It resolved $HOME as a temp folder. It deleted the home directory. No prompt-level instruction could have prevented that, because the model was following the instruction it thought it had. The gap between what the model proposed and what the runtime executed is where the failure lived.

This is the execution-boundary problem. The model proposes an action. The runtime blindly executes it. The gap between proposal and execution is where every safety failure lives, and it is the one place most agent frameworks do not instrument.

Aegis calls this the "propose-decide separation." The model proposes. The trusted runtime decides. The runtime evaluates the proposal against active policy state, resolves provenance server-side, and fails closed under uncertainty. In a sandbox corpus spanning five run families, 42 tasks, three conditions, and ten repeats, Aegis-governed rows recorded zero risky side-effect completions.

Zero. Not reduced. Zero. The model still proposed risky actions. The runtime refused them.

The Three Mechanisms You Can Build Today

The three papers converge on a single architectural claim, but each contributes a different mechanism you can implement.

Aegis contributes fail-closed mediation. Every tool call goes through a trusted decision layer that checks policy state and provenance before execution. Uncertain cases fail closed. Selected cases route through "Senate-style settlement," a quorum-based authorization path so no single model output triggers a consequential action alone. The numbers back it up. Across 2,100 Aegis-governed rows, the system recorded zero governed risky side-effect completions. All 1,832 attempted governed rows preserved trusted provenance. All 1,019 Senate-settled rows had quorum and signed tally evidence.

The design choice matters as much as the numbers. Aegis does not try to make the model safer. It assumes the model will keep proposing risky actions, and it builds a layer that refuses to execute them. That is a fundamentally different posture from prompt engineering. Prompt engineering tries to change what the model proposes. Runtime governance changes what the model is allowed to do. One is persuasion. The other is enforcement.

SkillEffect contributes checked lowering. Before the runtime grants execution authority for a tool call, an independent checker rebuilds the proposed computation from the submitted program and immutable input. If the rebuild does not match, execution is denied. This catches the case where a semantically correct program still exceeds memory bounds or violates resource constraints. Across six operator families, bounded access substantially reduced peak memory and improved completion under fixed caps. The checker accepted all evaluated legal configurations and rejected all adversarial proposals.

The key word is independent. The checker is not the model. It does not reason about the tool call the way the model does. It rebuilds the computation from the ground up, from the submitted program and the immutable input, and compares the result. If the model's proposed lowering does not match the checker's rebuild, execution is denied. The model cannot talk its way past it, because the checker does not listen to the model. It listens to the program.

GxP-Agent contributes process-DAG topology. Instead of letting the model decide the order of operations, you encode the correct order as a directed acyclic graph. Each node is a domain-specific step with validation gates and conditional retry. Claude Sonnet 4.6 under the DAG achieved 100% structural match on a clinical trial programming benchmark. The same model without the DAG scored 0%. GPT-4.1 scored 59.2% under the DAG and 0% under every other architecture tested.

The GxP-Agent result is the cleanest demonstration of the whole thesis. The task was clinical trial programming, converting study protocols into analysis-ready datasets under CDISC standards. Across 11 single-shot attempts with five frontier models, none produced a valid subject-level analysis dataset. The models were not close. They were at zero. Then the same models were put inside a DAG that encoded the regulatory process ordering, and Claude Sonnet 4.6 hit 100% structural match across three independent runs. The model did not get smarter. The architecture got stronger.

The pattern across all three: safety comes from the execution boundary, not the model. A weaker model with a stronger runtime beats a stronger model with no runtime.

The same logic shows up outside agent safety. A constraint-aware GPU allocator raised utilization by as much as 33 percentage points on identical hardware running identical workloads. Nothing about the hardware changed. What changed was the order in which allocation decisions were made. Architecture beats raw capability, every time.

Why Prompt-Level Governance Cannot Create This Boundary

Prompt-level governance is a suggestion. The model can ignore it, misinterpret it, or be manipulated around it. An execution boundary is a hard constraint. The runtime enforces it regardless of what the model outputs.

The Codex bug is the proof. OpenAI's fix was not a better prompt. It was a set of runtime checks: verify deletion targets, create fresh temporary folders, stop misusing system variables, catch risky delete commands with stricter checks. The company did not try to convince the model to be more careful. It changed the conditions under which the model's actions could execute. That is the difference between a suggestion and a constraint.

This is the same lesson from Note #146: your agent escaped its sandbox, again. Containment is architecture, not prompts. The difference is that these papers give you the concrete mechanisms. Fail-closed mediation. Checked lowering. Process-DAG topology. These are not concepts. They are components you can build.

The Codex bug proves the negative case. A coding agent with filesystem access and no execution boundary will eventually delete something it should not. The prompt cannot prevent it. The runtime can.

The Labs Know This and Are Still Shipping Without It

The Decoder reports that AI labs are failing to keep their own systems in check. The first assessment by the nonprofit Guidelight found that no AI company fully applies basic control measures to its own internal AI systems. It looked at Anthropic, OpenAI, Google, xAI, and Meta, drawing only on public sources like system cards, safety reports, and blog posts. Anthropic and OpenAI lead with a C+. Google follows with a D+ and a detailed roadmap. xAI scores a D minus. Meta scores an F.

The companies do best at spotting misbehavior. They do worst at prevention and containment. That is the exact inverse of what the execution-boundary research says matters. The labs can detect that an agent did something wrong. They cannot stop it from doing the wrong thing in the first place.

The Verge reports OpenAI disbanded its preparedness team. The same company that just patched a file-deletion bug in Codex no longer staffs the team responsible for anticipating catastrophic AI risks. Internal oversight has not kept pace with deployment speed. Labs are shipping systems faster than their own safety teams can evaluate them.

The architecture for safe agent execution exists. The papers describe it. The benchmarks validate it. The labs are not building it into their products, because commercial pressure rewards shipping over containment. That means the execution boundary is your problem, not theirs.

What to Do Today

Audit your agent's tool execution path. Is there anything between the model's output and the action? If not, you have no execution boundary. Start there, because nothing else you do matters until that gap exists.

Implement fail-closed mediation for destructive tool calls. File deletion, API calls with side effects, database writes. The runtime checks policy state before execution. Uncertain cases fail closed, not open. When in doubt, deny.

Add a process-DAG for multi-step agent workflows. Encode the correct order of operations as a graph. Each node has a validation gate. The model executes within the graph, not free-form. The GxP-Agent result is the proof: the same model that scores 0% free-form hits 100% inside the graph.

For memory-intensive tool calls, implement checked lowering. An independent verifier rebuilds the proposed computation from immutable input before granting execution authority. Reject mismatches. This is how you stop a semantically correct program from blowing past its memory budget.

Stop treating prompt engineering as your safety layer. It is not one. It has never been one. The research is now unanimous on this point.

Cross-reference Note #138 (Your Agent Needs a Runtime, Not Prompts), Note #105 (Agents Need Governors, Not Gatekeepers), Note #116 (Your Agent Needs a Constitution), Note #146 (Your Agent Escaped Its Sandbox. Again.).

The Uncomfortable Question

Three papers proved that a runtime boundary eliminates risky agent actions. The code is open. The benchmarks are public. The mechanisms are described in enough detail to build. So why does your agent still execute every model output without checking it first? What are you waiting for, a bug report from your users?