For platform operators and orchestration teams
The question is not whether an agent can act. It is whether it should have.
Written for teams running agents against real tools and real money, rather than for the agents themselves. It argues a case; it does not offer a service, and there is no channel on this page.
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.
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
Free, MIT, available today. Makes the mandate explicit, checks a proposed action against it, and records the decision. Advisory — this is the distribution and integration layer, not the security product.
The runtime
In development. Holds the credentials and tools exclusively, so it is the only layer that can actually refuse. Mechanisms implemented and tested in a private source tree you cannot inspect from here — source presence is not acceptance, integration, deployment, durability, or release: fail-closed admission, a closed task lifecycle, an append-only event chain, epoch-monotonic revocation, one-shot replay refusal, and privileged operation classes that cannot proceed without a named human decision.
Beyond
Fleet administration, evidence retention, and managed operation are design directions with nothing implemented and nothing offered.
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 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 released runtime. Everything in the enforcement layer is source and tests, not a product you can deploy.
- There is no published record format and no independent verifier, so nothing produced today is evidence to a counterparty. Until that exists, 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.
What exists is a working free skill, a tested enforcement core, and a specific thesis about which layer has to hold the credentials. That is an early-stage position honestly described, not a product.
Where this goes.
The skill is free and works today; installing it costs one command and commits you to nothing. Start there → · Present boundaries → · Source →