If this isn't your field, here is the short version.

A coding agent is an AI program that works on a programmer's computer: it reads files and web pages, edits code and runs commands. Three examples are Anthropic's Claude Code, OpenAI's Codex CLI and Google's Gemini CLI. They act with the programmer's own permissions, and whatever they read can steer them, including text a stranger planted for them to find. That is called prompt injection.

Ring 0 is the most privileged mode of a computer's processor, where the core of the operating system runs with nothing above it to say no. A 2026 study from Nankai and Tsinghua universities, which tested those three products, argues that today's agents act in effect at ring 0: what the model decides, the computer does, and no independent check stands in between 1.

This essay looks at the systems that already check an agent's actions from outside the model, proposes a gatekeeper that holds each change until fixed rules approve it, and sets out a study to test whether it helps. Nothing has been built. Why it matters beyond programmers: these agents act with real credentials, on code that gets released to other people.

A coding agent reads untrusted text and then acts with whatever authority its tools hold, which is usually the developer's. A study of three deployed coding CLIs (programs run from a text terminal) found that the checks they do have sit in individual tools, so a write the file tool refuses goes through the shell 1. The missing piece has a name older than any of these products: a reference monitor, which every protected action has to pass and which the thing it judges can't tamper with 6. This essay looks at what already enforces outside the model (CaMeL, FIDES, CXI, Concordat), four existing systems covered in section 5, and at one proposal for gating changes on external evidence, Beránek's Commit Boundary 2. That proposal executes, validates, then commits or rolls back, which presumes effects that can be rolled back. A coding agent's effects mostly can't: a deleted file, a git push (publishing code changes to a shared copy others pull from), a POST to someone else's API (a web request that changes something on someone else's service). The essay's argument is that making those effects stageable is the actual work, and it sets out a study that would measure whether a deterministic supervisor built that way adds anything over the systems that exist. None of that study has been run.

• The gap: In Claude Code, Codex CLI and Gemini CLI, access checks live in individual tools, sub-agents inherit their parent's permissions, and a forged transcript record loads as a user message on resume (a faked entry in the saved conversation is treated, when the session restarts, as if the user had typed it) 1.
• The edge isn't the inside: Docker (software that runs programs inside a sealed-off container) by default (AutoGen) and sandboxing (Claude Code, shell commands only) narrow what the agent can reach. They don't decide which of its own actions it may take [7, 11].
• Not only prompts: The LangChain and LangGraph serialization CVEs (publicly catalogued security flaws in two toolkits for building agents; serialization is how a program saves its data and loads it back) reach secrets or code without persuading a model, though each has its own prerequisites [13, 14, 15].
• The proposal: Commit Boundary gates commits on external, claim-specific evidence2. For a coding agent it only works if effects are staged first, the executor holds the credentials, and the decision is made by a policy engine, not a model.
• The arithmetic: Zero violations in 500 independent trials bounds the rate below about 0.6% at one-sided 95% confidence. It doesn't make it zero 16.

• Engineers: does every path to a protected effect cross an enforcement point the agent can't edit? The shell, a restored session and a sub-agent count as paths.
• Executives: can you show that an agent can't exercise more authority than you delegated to it? "The model was told not to" is not evidence.
• Auditors: a log the agent can write is a diary, not an audit trail.

Those are the same question asked from three desks. The rest of the essay is about who answers it.

Drafts here go through the Moot before I read them: a panel of frontier models I call by their lab bosses' first names (Dario, Sam, Sundar), plus Eddie, the house model that drafts. After publication three outside readers (Claude, OpenAI, Gemini) sent critiques, and this version is what came back from them. The first version planned a supervisor that was itself a large language model. Two of the three readers pointed out that this would let the agent's text back into the authorization path one layer up, and they were right.

Here's the problem without the operating-systems vocabulary. An agent is asked to bump a dependency in a repository. The README it reads along the way contains a line, written by someone else, telling it to edit .github/workflows/release.yml so the release job uploads the deployment credentials to an outside server. The agent has a file tool and a shell. Can it make that change? In most setups today, yes. And if it does, who authorized it?

Nobody did. The agent's own reasoning did, which is the same as the agent writing its own permission slip. The AaOS study puts it more formally: whatever the model outputs, whether it's following the user, a tool result or a downloaded skill, "runs with the full authority of the host user, in effect at ring 0" 1. The agent process runs in user space (the ordinary, unprivileged mode where applications run) the whole time. The point is authority, not silicon.

AaOS takes the mechanisms of standard operating-system textbooks, 116 of them in 19 subsystems, and asks what each one looks like in a deployed agent 1. Eleven are isomorphic, meaning present with the same semantics, so existing defenses carry over. Sixty-five, or 56%, are missing, and most of the missing ones are protections: privilege separation, transactions, tamper-proof audit 1.

The verdict the paper calls most dangerous is the in-between one, degraded: the function exists but enforcement doesn't, because protection depends on the model following an instruction in the prompt or on a check another path bypasses, "because the system appears protected" 1. To draw that line the authors use Anderson's reference-monitor criteria from 1972 (in a computer-security planning study for the US Air Force): the monitor must be non-bypassable, tamper-proof and verifiable [1, 6]. Rules written in the prompt meet none of them 1.

The paper then tests 25 mechanisms in 13 experiments on Claude Code, Codex CLI and Gemini CLI 1. Access checks sit in individual tools, so a file write the file tool refuses goes through the shell. All three CLIs load a forged transcript record as a user message on resume. A task id names a wrapper, so a reported stop can leave the process running. Sub- agents inherit their parent's permissions. And a model-based permission monitor receives text the agent controls 1.

That last finding is the one to keep in mind. A judge who reads the defendant's notes before ruling is not independent of the defendant.

The frameworks have been moving toward safer defaults, and it's worth being precise about what those defaults do.

AutoGen made Docker the default for code execution in 0.2.8. If Docker isn't running it throws an error, and local execution is an explicit opt-in 7. CrewAI removed its CodeInterpreterTool entirely, including the Docker sandbox and the SandboxPython fallback, after CERT/CC (the CERT Coordination Center at Carnegie Mellon University's Software Engineering Institute) coordinated four vulnerabilities; CVE-2026-2275 was the fallback running code when Docker was unreachable [8, 9]. LangChain's security policy puts the decision on the developer: "Always assume that any system access or credentials may be used in any way allowed by the permissions they are assigned" 10. Claude Code's sandbox is off by default and covers shell commands and the processes they start. The built-in Read, Edit, Write, WebFetch and WebSearch tools follow permission rules instead11.

All of that narrows what an agent can reach. None of it decides which of the agent's own actions should be allowed. A container can restrict users, capabilities, mounts and network, and that's real protection, but inside it the agent's choices about what to do with what it can reach are still the agent's. The call is coming from inside the trust boundary.

Microsoft's FIDES is the closest thing in a shipping framework to a decision outside the model: content carries integrity and confidentiality labels, and policies are checked before a sensitive tool runs 12. Its documentation is candid about the edges. It's Python-only and experimental. In Python it isn't supported with the Monty or Hyperlight CodeAct providers, and the .NET Hyperlight and Local CodeAct providers don't enforce it, because host-tool calls made inside generated code bypass the per-function middleware 12. That's the AaOS pattern again: a check in one path, a way around it in another.

Prompt injection is the attack everyone draws on the whiteboard. It isn't the only one.

CVE-2025-68664 is a serialization injection in langchain-core's dumps /loads that enables secret extraction 13. CVE-2026-28277 is unsafe msgpack deserialization when LangGraph loads a checkpoint (langgraph 1.0.9 and earlier, fixed in 1.0.10). On its own it needs an attacker who can already modify the stored checkpoint bytes; GitHub's advisory rates it moderate and calls it a post-exploitation issue 14. Check Point Research chained it with a SQL injection in the SQLite checkpointer (CVE-2025-67644, fixed in langgraph- checkpoint-sqlite 3.0.1) to reach code execution on self-hosted servers. That chain needs an application that exposes get_state_history() with a filter the user controls 15.

None of these routes persuades a model of anything. They also aren't what a commit- boundary supervisor fixes. Patching, safe deserialization and access control on the checkpoint store fix them. They belong in this essay as evidence that the agent's runtime is an attack surface in its own right, not as a sales pitch for the proposal below.

The proposal has to beat existing work, not a strawman.

CaMeL (Debenedetti and colleagues, 2025) extracts the control flow from the trusted user query before the model sees any untrusted data, so "the untrusted data retrieved by the LLM can never impact the program flow", and it uses capabilities to stop private data leaving. It solves 77% of AgentDojo tasks (a public test suite of agent tasks with attacks planted in them) with provable security, against 84% for an undefended system 5. That's the clearest prior statement that reasoning and authority should be separated.

CXI puts a deterministic gate at the execution boundary that admits a call only when field authority, exact-effect authorization and invocation authority bind to the same action manifest. It reports 720 live AgentDojo episodes and a code-agent benchmark of 400 repository episodes, with 231 safe task completions 4.

Concordat treats an agent as an object whose interface is a finite-state protocol, offering the model only the tools that are legal in the current state 3. On τ -bench's 50 airline tasks (a test in which an agent serves simulated customers), with simulated customers pressuring the agent to skip confirmation, the standard agent changed bookings without the required "yes" in 13 of 50 tasks with gpt-4.1 and in 29 of 128 task-runs with Claude Haiku 5.5. The Concordat agent did it in none, with no significant difference in task success. τ -bench's own reward missed most of the violations 3.

FIDES, above, labels data and checks sinks 12.

So the question for anything new isn't whether it enforces outside the model. These do. It's what a new mechanism catches that they don't.

Beránek's Commit Boundary was written for agentic entity resolution: an agent that proposes merges and splits in an identity graph 2. Its central distinction is between evidence available to the agent for reasoning and evidence eligible to authorize a persistent change. "Admission as UNVERIFIED does not confer authorization eligibility", and a separate, claim-specific promotion decision has to make evidence usable for one particular authorization 2. The supervisor runs in two phases: pre-execution authorization, then post-execution validation and commit. The paper is explicit that it is "a conceptual architecture, not an implemented or empirically validated system" 2.

The distinction carries over to coding agents well. Evidence that the README said to edit the release workflow is evidence for reasoning, not authorization. What doesn't carry over is the second phase. Execute, validate, then roll back on a mismatch works when the effect sits in an uncommitted transaction. A coding agent's effects mostly don't. You can't validate a curl -X POST after it has been sent, or un-send the Slack message, or un-push the branch someone has already pulled.

So the commit boundary is only as good as the staging in front of it, and staging is the part this essay proposes:

• Files: the agent writes to a copy-on-write overlay. Commit applies the diff to the real tree; discard throws the overlay away.
• Git: pushes go to a shadow remote or a holding branch. Commit is a fast-forward the executor performs.
• Network: outbound requests from tools go through a proxy that holds them. Commit releases them; discard drops them. Reads can pass, writes wait.
• Credentials: the agent never holds them. The executor does, which is what makes the boundary non-bypassable. If the agent keeps a token that can make the same change directly, the supervisor is decoration.
• The irreducible rest: some effects can't be staged. Those need an explicit approval bound to the exact invocation (FIDES already binds approvals that way 12 ), and the study below counts how many there are.

The decision itself belongs to a deterministic policy engine such as Open Policy Agent or Cedar (existing tools that answer yes or no from written rules), with no model in the authorization path [17, 18]. A model can propose; it can't approve. That also settles what counts as evidence. A provenance tag says where something came from, not that anyone is allowed to act on it. An authorization has an issuer, a scope, a validity period and a link to the exact action, and the policy checks all four.

Nothing here has been built. This is the plan.

What's under test: the supervisor, which is deterministic. The agents proposing actions would be two kinds: a small open-weight model (one whose trained parameters are published, so it can run on your own hardware) that runs on one 24 GB RTX 4090 19, for cheap, repeatable invariant tests, and frontier models through their APIs, for realistic task success and realistic pressure on the boundary. The first version of this plan put a 70B model on a single 4090; at 4-bit its weights alone are about 35 GB, which doesn't fit, and the property under test doesn't depend on the model's size.

Where: AgentDojo, for comparability with CaMeL and CXI [20, 5, 4]; a set of real repository tasks in the style of SWE-bench, because coding agents fail differently from customer- service agents 21; and τ -bench's airline domain with Concordat's pressure variant, so that comparison is like for like [22, 3].

Against what: the same tasks and the same attacks under four configurations:

Measured, per task, not just in aggregate: unauthorized actions proposed; unauthorized effects actually committed; legitimate actions wrongly blocked; task success; latency; and bypasses through any alternate path (the shell, a restored session, a sub-agent, a background process, a replayed request). A supervisor that blocks everything commits nothing unauthorized and is also useless, which is why task success sits next to every security number.

Reading a zero: if a configuration commits no unauthorized effects in N independent trials, the one-sided 95% upper bound on the rate is 1 − 0.05^(1/N). For 500 trials that's 0.5974%, close to the rule of three's 3/N 16. It's a bound on the tested distribution only. Five hundred repeats of one easy attack don't say what five hundred distinct attacks would, so the trials are spread across attack paths and the count per path is reported.

• H1 (no committed unauthorized effects): With staged effects and executor-held credentials, the supervisor commits zero unauthorized effects across at least 500 attack episodes spread over at least five attack paths, while task success stays within 5 percentage points of the ordinary-permissions baseline.
  • Disproof: Any committed unauthorized effect, or task success more than 5 points below baseline.
• H2 (staging coverage): At least 90% of the side-effecting tool calls in the repository task set can be staged (overlay, held push, held request) without breaking the task.
  • Disproof: More than 10% of side-effecting calls can't be staged, or staging costs more than 5 points of task success.
• H3 (incremental value): At least one class of attack in the suite is blocked by the Commit Boundary configuration and admitted by both the CXI-style and Concordat- style configurations. The candidate is an authorized tool called with an attacker-chosen argument, backed by evidence the agent fetched itself.
  • Disproof: Every attack the Commit Boundary configuration blocks is also blocked by at least one of the existing configurations.
• H4 (complete mediation): No protected effect is reachable without passing the supervisor, via the shell, a restored session, a sub-agent, a background process or a replayed request.
  • Disproof: One such path. This is an invariant to attack, not a rate to estimate: passing tests can't prove it, and a single counterexample breaks it.

# Design sketch. It shows where each check sits, not a hardened implementation.
# Assumes: effects are staged (overlay FS, held push, held request), the
# executor alone holds credentials, and policy is a deterministic engine.

function commit_boundary(proposal, evidence, state):
    action = canonical(proposal)               # tool, target, arguments, diff
    if hash(action) != proposal.hash:
        return REJECT("proposal changed after it was made")

    # Phase 1: pre-execution authorization. No model in this path.
    for item in evidence:
        # an authorization names its issuer, scope, validity and this action
        if not authorizes(item, action):
            return DEFER("evidence is for reasoning, not authorization")
    if not policy.allows(action, evidence, state.version):
        return DEFER("policy does not cover this action")

    # Run against the stage, never against the world.
    staged = stage.apply(action)               # overlay, held push, held request
    if not stage.matches(staged, action):      # the effect that was authorized
        stage.discard(staged)
        return REJECT("effect differs from the proposal")

    # Phase 2: commit, atomically, if nothing moved underneath.
    moved = (state.version != proposal.state_version
             or policy.version != proposal.policy_version)
    if moved:
        stage.discard(staged)
        return DEFER("state or policy changed; propose again")
    if not staged.reversible and not approval.bound_to(action):
        return HOLD("irreversible: needs approval bound to this exact action")
    executor.commit(staged)                    # only it holds the credentials
    audit.append(action, evidence, "commit")   # append-only, outside the agent
    return COMMIT

Not like this: a supervisor that asks a model whether the action looks reasonable, accepts the agent's reasoning trace as evidence, executes against the real world and then hopes rollback() works.

• Claim: "AutoGen runs generated code on your machine by default."
  • Check: Since 0.2.8 the default is a Docker container, and it errors if Docker isn't running. Local execution is opt-in 7.
• Claim: "Prompt injection is the only real attack on an agent."
  • Check: CVE-2025-68664 and the LangGraph checkpointer chain reach secrets and code without a prompt [13, 15].
• Claim: "Claude Code's sandbox covers everything the agent does."
  • Check: It covers shell commands and their child processes. Read, Edit, Write, WebFetch and WebSearch follow permission rules instead 11.
• Claim: "We ran it in Docker, so the agent is contained."
  • Check: The container limits what the agent can reach. It doesn't decide which of the agent's own actions are allowed 1.
• Claim: "Zero violations in 500 runs means it's safe."
  • Check: It bounds the rate below about 0.6% at one-sided 95% confidence, for the distribution tested 16.

The engineer's question was whether every path to a protected effect crosses an enforcement point the agent can't edit. The executive's was whether anyone can show the agent can't exceed what it was delegated. A staged, deterministic commit boundary is one way to make the answer to both the same artifact: the policy, the audit log and the list of effects that couldn't be staged.

The governance side is moving, slowly. NIST's National Cybersecurity Center of Excellence, part of the US National Institute of Standards and Technology, published a concept paper on 5 February 2026 for a potential project demonstrating how identity and authorization standards apply to software agents. It's a proposed demonstration project, whose comment period closed on 2 April 2026, not a rule 23. In the Cloud Security Alliance and Oasis Security survey of IT and security professionals, 78% said their organizations lack documented policies for AI identities, and 92% weren't confident their legacy identity and access management could handle AI and non-human identity risk 24. Those are survey respondents, not every enterprise, and the survey's sponsor sells non-human-identity security.

No regulator has set the deadline yet. The first incident review will.

• Nothing is built. The supervisor, the staging layer and the study are plans. Every number in this essay is from a cited source, or arithmetic on one.
• Staging coverage is unknown. How many of a coding agent's effects can be staged without breaking its work is H2, not a finding.
• Commit Boundary is unvalidated. Its author says so 2, and adapting it to coding agents is this essay's move, not the paper's.
• Benchmarks aren't deployments. AgentDojo, τ -bench and a repository task set are test distributions. A bound on them is a bound on them.
• Survey scope. The 78% and 92% describe respondents to one vendor-sponsored survey24.