Governed Tool Use
Governed Actions · Part I
Your agent can install the tool you revoked.
Across 540 trap evaluations built from 143 unique PyPI yank scenarios, three frontier models installed a yanked version 539 times when it looked like the newest release. Governed Tool Use held that to zero by reading the registry's own record, which the model never sees, and recorded every decision in a verifiable packet.
Installed without governance
539/540
full tool context picks the revoked newest, on every model and seed
Prompt instruction, clean log
0/540
ties the gate when the authority log is current (published)
Prompt instruction, stale log
540/540
a one-step-old log breaks it completely
Revoked versions installed (gate)
0/540
removed before the model sees it; across 3 models and 3 seeds
The outcome: an agent that cannot act on a revoked record it was never shown, and a FieldHash Ledger packet that proves what it did. This is enforcement of configured authority: not a model-intelligence benchmark, and not a claim about any other product.
A faithful agent, a convincing tool.
Maintainers pull releases after the fact. When requests, a widely used Python library, pulled a release over a security advisory, and when aiohttp pulled one over a regression, the version number and its description did not change at all. Only the registry's record marked the yank. So a coding agent told to install the latest version sees a release that looks current and reads clean, with nothing in its text to say it was withdrawn.
We built 540 of these traps from real PyPI yank flags, ground truth anyone can re-fetch from the public API. In each, the withdrawn version is the newest one shown. A model cannot reliably enforce a revocation signal that is absent from its inputs, which is why all three frontier models failed within one case of each other.
This is tail risk, not a constant failure. It does not fire on every install, but when a withdrawn version looks newest it is hard to spot, a more capable model does not catch it, and the cost is shipping code that was pulled for a reason.
Remove the revoked version before the model sees it.
Governed Tool Use reads the operations log and takes the revoked version out of the candidate set the model is given. The model cannot install what it is never shown. Across three frontier models and three seeds, the gate installed a revoked version zero times in 540 trap cases, against 539 of 540 without governance.
0/540
Revoked versions installed under the gate, on the trap cases.
539/540
Installed without governance, on every model and every seed. The gap is not subtle.
0/538
Valid-control cases falsely blocked. The gate does not over-block.
Capability does not close the gap
| Model | Without governance | With the gate |
|---|---|---|
| Gemini 3.5 Flash | 180/180 | 0/180 |
| GPT-5.5 | 180/180 | 0/180 |
| Claude Opus 4.7 | 179/180 | 0/180 |
Revoked versions installed on the trap cases, by model (180 trap evaluations each). The three frontier models fail within one case of each other; the gate holds every one at zero.
Could you just tell the model? On a clean log, yes.
We tested the obvious cheaper alternative: state the revoked versions in the prompt and instruct the model not to install them. With a complete, current log pasted into every call, the models complied perfectly. Prompt instruction installed zero revoked versions, tied with the gate.
We publish that tie rather than hide it. Instruction works when the telling is perfect. The question is whether the telling is ever perfect in production, and the next act measures what happens when it is not.
Instruction is only as good as the log that reaches the model. Production logs can become stale, truncated, delayed, or inconsistent across systems.
A prompt instruction depends on a complete, current authority log reaching the model intact, on every call. In production that assumption breaks: logs go stale, get truncated, or fall out of sync. When the log is even one step out of date, the model is never told the version was revoked, so it installs it. The gate does not depend on the prompt's copy of the log at all. It reads the live operations log directly and removes the revoked version from the candidate set, so a stale or missing log in the prompt changes nothing.
Clean, current log
instruction ties the gate
Log one step out of date
one-step-stale log breaks instruction
Instruction and enforcement also separate on a second axis the count does not show. Instruction alone does not create a verifier-bound enforcement record proving the revoked option was excluded before selection. The gate removes it and writes a hash-chained evidence packet for the action. Refreshing the prompt's log on every call can close the count gap only when the log is complete, current, and intact; it still leaves authority inside the prompt as a soft instruction the model can override, rather than enforcing it structurally.
We make no claim that the gate defends against prompt injection. On this benchmark, an adversarial instruction breaks prompting only when it stands in for the authority record (535/540) — the same absent-authority failure in another form. The gate's value is independence from a stale or absent log, plus a provable record, not hardening the model.
Stable, not cherry-picked
The result held on every run.
Nine runs: three frontier models (Gemini 3.5 Flash, GPT-5.5, Claude Opus 4.7) across three seeds, pooled to 1,078 paired cases (540 trap evaluations over 143 unique PyPI yank scenarios, and 538 valid-version controls; two control cases were dropped where a model response did not parse to a candidate). The gate installed a revoked version zero times on every single run. The tie held on every run, and its break under a stale or absent authority log held on every run. Every unauthorized-install figure on this page is recomputed from the raw rows by a stdlib verifier that fails on drift.
What this does not claim
The boundary, stated plainly.
- Not an accuracy claim. The gate prevents unauthorized influence; it does not make the model smarter.
- Not an injection-defense claim. The gate's value is independence from a stale or absent authority log, plus a provable record — not hardening the model against adversarial prompts.
- The gate is only as trustworthy as the authority source it reads. FieldHash enforces from your systems of record, not the model's context, and records every decision in a reviewer-verifiable evidence packet. Stronger tamper evidence depends on deployment configuration. The authority record must live in a channel the agent itself cannot write to: a poisoned source fails with the same lack of protection as instruction.
- Not a claim about any other product. The comparison is enforcement against instruction, both FieldHash's own arms.
- The trap cases are constructed to place the revoked version as the newest shown. The yank itself is real and re-fetchable; the framing is disclosed.
- FieldHash enforces configured authority. It does not infer which version is authoritative from prompt text.
Local-model addendum
The gate does not ask the local model to remember the registry.
+
Local-model addendum
The gate does not ask the local model to remember the registry.
We reran the same PyPI authority arms through two local open-weight routes, Qwen 2.5 1.5B 4-bit and SmolLM2 360M 6-bit. The addendum is post-hoc portability evidence, not part of the pre-registered frontier run. It shows the same boundary: when the revoked candidate remains in the model's candidate set, local models can still pick it. When the gate removes it first, the paired trap rows produce zero revoked installs.
The verifier counts only cases where all six arms parsed to a candidate. Qwen produced 120 paired cases; SmolLM2 produced 80 paired cases from the 120-case request. That is a disclosed local-model quality boundary, not hidden sample loss.
| Local route | Paired traps | Full context | Prompt, clean log | Stale log | Gate |
|---|---|---|---|---|---|
| Qwen 2.5 1.5B local | 60 | 49/60 | 2/60 | 48/60 | 0/60 |
| SmolLM2 360M local | 38 | 26/38 | 17/38 | 20/38 | 0/38 |
Counts are unauthorized installs on latest-yank trap rows, recomputed from the local addendum bundle. Across both local routes, full context picked revoked versions in 75/98 paired traps, stale-log prompting in 68/98, and the gate in 0/98.
Reproduce the figures
Download the public verification bundle.
The bundle includes decision rows, public PyPI ground-truth references, the disclosed task harness, checksums, and a stdlib verifier. It excludes raw model responses, provider routing, keys, and internal enforcement code.
The other half of governed actions
Part II: whether a consequential action runs at all.
This study governs which tools an agent is allowed to trust. Its companion governs the action itself — delete, deploy, revoke, transfer. On 90 decision points authored by the most cautious model we tested, agents took the unreviewed consequential action in 84% of evaluations; a prompt to ask first helps but still leaks, and the gate holds at zero with a tamper-evident approval bound to the exact action.
Govern what your agents are allowed to do.
Bring one agent workflow with real tool or action risk. We will show what it would have been allowed to do, what we would have blocked, and the evidence packet your reviewers can inspect.
Bring one workflow