An agent that can only read is a search box with worse latency. The value arrives when it can file the test, update the opportunity, or publish the dashboard — and that is precisely the capability a security review exists to constrain. This teardown describes the gate that sits in the execution path, and the three properties that separate it from a confirmation dialog.
The distinction is structural rather than a matter of degree. A confirmation dialog sits beside the execution path and can be routed around; a gate sits inside it and cannot. Everything below follows from putting it in the path.
From the standard
“a framework to better manage risks to individuals, organizations, and society associated with artificial intelligence (AI)”
The sequence
- model proposes a tool call
-
1 · POLICY VALIDATION Evaluated outside the model’s channel Against a policy the model cannot see, read back, or influence.
-
pass
2 · MANIFEST CHECK Is this tool in this turn’s manifest? Signed session manifest — platform ∩ tenant ∩ RBAC.
-
pass
3 · HUMAN GATE — WRITE ACTIONS ONLY Blast-radius diff rendered Approve · reject · escalate. Approval pinned to a version token and schema.
- approved · token still valid write executes
- trace: turn → call → args → result → approver
Reads pass through stages one and two. Writes pass through all three. The asymmetry is deliberate: read latency matters to whether the system gets used at all, and a read inside the user's existing permissions is not the risk the gate exists for.
Property 1 — the policy is outside the model's reach
The validation policy is not in the prompt. It is not in a system message, not in a tool description, and not in any text the model processes. This matters because the defence and the attack otherwise share a channel: anything written into the prompt to constrain the model is text an injected instruction can also address.
Placing the check outside that channel is what turns a successful injection into a failed tool call rather than an unauthorized write.
Property 2 — blast radius is shown, not described
The gate renders a diff of exactly what would change and how many records it reaches. Not a sentence describing the action — the field-level change itself, and the count.
… 11 more records, the same three fields
The failure this prevents
An approver shown "update the opportunity records" has no way to distinguish one record from eleven thousand. Approving it is not a decision; it is a reflex the interface has trained. Showing the count and the field-level change is what makes the approval mean something an auditor can rely on later.
Property 3 — approvals cannot be replayed
Every approval is pinned to an optimistic-concurrency version token and to the schema it was granted against. If the underlying plan changes after approval — a record edited by someone else, a tool definition updated, a parameter altered — the token no longer matches and the write is refused.
Refused, not re-approved automatically and not silently retried against the new state. The approval was granted against a specific thing, and when that thing changes the correct behaviour is to stop and ask again.
Where the capability is bounded, not just the action
The gate is the last line, not the only one. The tool roster available in any turn is computed as the intersection of platform capability, tenant entitlement, and the acting user's role, then compiled into a signed session manifest. A capability outside that intersection is not merely denied at the gate — it is absent from the manifest, so there is nothing for an injected instruction to reach for.
This is the difference between a system that refuses an unauthorized action and one where the unauthorized action was never expressible.
What the trace records
A distributed trace spans both planes, and for any write an auditor can reconstruct which turn triggered which tool call, with the arguments it was given; what that call returned, and which citation in the narrative points at it; and who approved the resulting write, when, and against which version.
Tracing has to be present at every call site or the chain has gaps, and a chain with gaps is not an audit trail — it is a log. This is why instrumentation is not a phase-two concern: retrofitting it produces coverage everywhere except the places that were hard, which are the places that matter.
The honest cost
A gate on every write means a human is in the path of every write, and that is a throughput ceiling. It is the right ceiling in a regulated context — in the verification deployment this pattern came from, an unattended write into a test plan is itself a defect, so the system does not have that capability at all, and the count of unreviewed writes is zero by construction rather than by policy.
Where volume matters more than reversibility, this is the wrong design and a narrower blast radius with unattended execution is the better trade. The question to settle first is not how much you trust the model. It is what the worst single write could do before anyone noticed.
Axionalytics
Production agentic AI for enterprise engineering, data, and revenue teams.