For the person answerable for what the agent does
Your scopes say which systems. They do not say which decisions.
Scopes and resource policies do their job well. What they do not carry is the whole business instruction: that this agent, for this purpose, may spend up to this much, may publish only here, and must escalate to a person there. The skill can read that instruction. It does not control the path that acts, so that path can skip or ignore the answer.
- Free
- MIT
- Makes no network calls
- Neither requires nor holds credentials
The problem
Four failure conditions, not one.
The accountability gap in autonomous execution is usually discussed as a single problem. It is better read as four, because each needs a different mechanism:
Attribution failure
Where contribution cannot be traced, fault cannot be assigned — and where fault cannot be assigned, no participant has an incentive to prevent it. Responsibility dissolves into composition.
Authority drift
The failure mode permission systems are least equipped to detect, because at every individual step the system behaves correctly. Each check passes. The aggregate is nonetheless outside what was authorized.
Evaluative capture
When the component that judges whether an action was acceptable is the same one that wanted to take it, the judgment carries no independent weight.
Recourse vacuum
An unauthorized outcome with no path to challenge, appeal, or remedy is not a governed system. It is an unbounded one that has not failed yet.
Why existing rails do not close it
Audience restriction is not designation of authority.
Current agent-authorization work concentrates on making sure a token is presented to the right service and is not passed on — the MCP authorization specification requires an explicit resource parameter and forbids token passthrough, which is real progress against a real class of confusion.
It is a different question from the one an operator has. Restricting where a credential may be used does not express what the holder may do with it, on whose grant, under what limits, or how the grant is taken back. That is designation of authority, and it is the older idea — the capability literature has argued since the 1980s that authority should travel with the reference to the object rather than with the identity of the caller.
Payment and settlement rails have the same shape of gap. They move value. They vary considerably in how much delegated authority, policy context, or software path they express behind an agent-initiated transaction.
What it looks like
One mandate, four proposed actions.
An operator writes a mandate in their own words and clauses: read the catalogue, post to our own catalogue API, nothing else — and refunds, or anything touching credentials, are the operator's decision rather than the agent's. Each proposed action is then checked against it.
| Proposed action | Answer | What it said |
|---|---|---|
Read /srv/catalog/2026-09/sku-4417.json |
permit | clause c2-read-catalog applies |
POST to https://partner-sync.example/ingest |
deny | no clause matched, so the mandate default applies; the closest were c3-post-to-our-api — target matches no permitted prefix |
| Refund $40 to a catalogue customer | escalate | clause c4-small-refunds permits this, but transaction always requires a person |
| Refund $250 to a catalogue customer | deny | the closest were c4-small-refunds — amount 250.00 exceeds the ceiling 50.00 USD |
This is the skill, which is advisory. Deny and escalate mean it declined to advise proceeding and appended that decision to a local log. Nothing here was prevented — the agent still held whatever access it had.
Two things in that table do most of the work. A ceiling narrows what may be asked for; it does not remove the person — the $40 refund is inside the ceiling and still comes back escalate, because transaction is in requires_human. And when nothing matches, the answer names the clause that came closest and why it missed, which is usually what you actually need to see.
What a mandate reaches
It bounds what is asked for, not what the agent holds.
A mandate states bounds against which a proposed action is checked. It cannot bound what the agent already has.
| Authority | What a mandate can express | What the skill does |
|---|---|---|
| Data access | which path prefixes may be read or listed | checked and recorded |
| Publication | which destinations may be posted to | checked and recorded |
| Spending | a ceiling, per clause, with a currency | checked and recorded |
| Third-party contact | counterparties named, destinations bounded by prefix | checked and recorded |
| Credentials | that credential use can never come back permit — and nothing more | escalate if a permitting clause matches, otherwise deny |
Every row is checked and recorded, because that is all the skill does. Nothing in the table is prevented. Prevention requires a runtime that holds the credentials and tools exclusively.
The last row is the honest one. A mandate can put credential use permanently out of reach of a permit, and the evaluator declines to advise proceeding on a request that appears to carry recognizable credential material — a heuristic that recognizes common shapes and cannot be complete. Neither stops an agent using a token it already holds.
The shape of the answer
Four layers, and only one of them can refuse.
The agent
Plans, negotiates, and proposes. It is not the place to put a control, because anything in its context can be overridden.
The skill
Makes the mandate explicit, checks a proposed action against it, and records the decision. It is advisory and does not hold credentials or control tools.
The runtime
Checks admission, lifecycle, revocation, replay, and privilege conditions and can return refusal results on those modeled paths. It could prevent an operation only by holding the protected credentials and tools exclusively.
Operational governance
Fleet administration, evidence retention, independent verification, challenge, appeal, and remedy govern the system around an execution boundary.
The governing principle, and the reason the free layer is deliberately the weak one: the skill requests authority; only the runtime can enforce it. A prompt or a Markdown skill cannot prevent bypass, and any vendor telling you otherwise is selling you a description of a control rather than a control.
What each mechanism does
Checks, refusals, and governance are different jobs.
The skill evaluates one described action. The runtime model evaluates conditions that an execution boundary would need. Operational governance covers records, independent verification, and recourse around that boundary.
| Mechanism | What it does |
|---|---|
| Mandate check | Evaluates one proposed action against structured clauses. |
| Decision answer | Returns permit, deny, or escalate with the governing clause and near-misses when nothing matches. |
| Decision log | Chains local entries and checks terminal truncation against a separately retained head. |
| Credential heuristic | Returns deny when a request or mandate appears to carry recognizable credential material. |
| Admission path | Fails closed when evaluating admission conditions. |
| Task lifecycle | Refuses undefined transitions. |
| Event chain | Appends events and exposes broken continuity. |
| Revocation | Advances epochs monotonically with no grace window. |
| Replay check | Refuses reuse of a one-shot nonce. |
| Privileged operations | Requires a named human decision before a privileged operation class can proceed. |
| Trusted time | Would have to be required before admission. |
| Human identity | Authenticating the named person and binding the decision to the plan remain requirements for the control boundary. |
| Action prevention | Requires exclusive credential and tool custody on the only execution path. |
| Runtime records | Need a published format and an independent verifier to support third-party verification. |
| Attack resistance | Must address confused-deputy and prompt-injection attacks at the control boundary. |
| Aggregate drift | Requires state across actions rather than one request at a time. |
| Recourse | Requires challenge, appeal, and remedy outside the action check. |
| Operations | Covers fleet administration, evidence retention, and managed operation. |
A model that returns a refusal does not prove that the operation was prevented. Prevention depends on exclusive control of the credential, tool, signing key, or worker process that can perform it.
What would have to be true
The case against, stated by us.
An operator evaluating this should weigh what is genuinely missing, so here it is without prompting:
- There is no credential or key-custody component and no exclusive tool boundary. The source can return refusal results for modeled calls; it cannot establish that an agent cannot bypass it or use a credential it already holds.
- There is no trusted-time requirement at admission. If time is never observed, split-path grants do not expire.
- There is no authenticated named-human approval record. The socket accepts the caller's privilege selection and one-to-one assertion; it does not authenticate or bind that decision to the plan.
- The modeled runtime paths do not hold protected credentials or tools, so their refusal results do not establish an exclusive execution boundary.
- There is no published record format and no independent verifier for the runtime's records, so nothing the runtime would produce is evidence to a counterparty yet. The hosted check's signed receipts show only what the check answered about one action under one mandate. Until runtime records can be verified, the evidence argument is a design intention.
- There is no confused-deputy or prompt-injection test suite. Those are the attacks a control boundary must survive, and they have not been demonstrated against.
- The recourse and remedy half of the accountability gap — challenge, appeal, restitution — is untouched. A system that records a bad outcome precisely has still not given anyone a way to undo it.
- There is no third-party audit, certification, or production deployment, and no customer using this in anger.
The skill provides an advisory check. The runtime model tests refusal logic. The governing thesis is that enforcement belongs only at the layer that holds the credentials and tools exclusively.
Start with the advisory check.
The free hosted check applies the evaluator to a mandate and a proposed action. It does not enforce the answer. Start there → · Present boundaries →
If you want to know whether this is relevant to you, re-read the case against. It is the same list either way, and it is what we would have to be able to strike out.