Mandate, presence and a circuit breaker for agents

Honest label: this line is target architecture. It exists in code and in a test environment. It is not a commercial offering, and nothing here is available for purchase.

The problem, without exaggeration

A software agent that acts in the world, that pays, transfers, cancels or signs, needs some form of authorisation. The usual answers are two, and both share one defect: the instruction in the prompt (“do not pay without approval”) and the if inside the very process that acts. Both are advice. They work while whoever receives them chooses to follow, and whoever does not need not be malicious. A badly written retry, a forgotten error path, or an old service nobody updated will do.

What we propose is not a better lock inside the agent. It is moving the lock.

The whole sentence

The system that performs the action only performs it with the receipt that a specific, living, present person saw and authorised it; anyone verifies that receipt without trusting anyone.

Both halves matter. The first puts the decision with whoever executes, not whoever asks. The second says verification is offline, with a public key: not even we need to be in the path for the receipt to hold.

Two steps, never one

If every action requires a person, the person approves on autopilot within a week and the gate becomes theatre. Hence two steps.

Routine under mandate. A person grants, once only, with live presence: a mandate with a written scope, saying which actions, with what limits, until when, revocable or not. After that the agent acts alone inside that scope, and each action produces a level 0 delegated act, with no new human and a signed receipt. What sustains the action is not its content, but the mandate.

Exception with presence. Anything outside the scope is not negotiated with the agent. It requires a fresh level 2 proof, with the person present, through the same verification journey that already exists.

The context recipe, and why it is the centre

The receipt does not carry what the agent did. We do not see the action, and we do not want to. What the receipt carries is the hash of the context the client declared, plus the names of the declared keys:

context.hash = "sha256:" + hex(SHA-256(JCS(context)))

JCS is RFC 8785 canonicalisation, the same as the rest of the format. Whoever holds the original context recomputes the hash alone and checks it, with nothing from us. That is what binds a receipt to one specific request.

Inside that context go two things the executor chooses: a nonce it issued itself, and its own identifier. No new field entered the receipt for this. Nonce, executor and freshness are declared keys in the context, plus a window over the completion instant. That is what stops a legitimate proof of another request, or of the same request a second time, from serving the action at hand.

Stopping: authority, not computation

Nobody stops the computation of an agent they do not host, and promising that would be a lie. There is no infrastructure kill switch in this design.

What is stopped is authority, in the systems that require it:

revoke the agent’s authority in every system that requires it, with a human act, and only give it back with another

In practice, four layers. Revoking the mandate, itself a human act with its own receipt. Propagating, because a webhook event warns executors and a state endpoint answers for whoever missed the warning. Stopping everything, with bulk revocation by mandate holder or by client, a mandatory target and no default, and one receipt per mandate brought down. And resuming, which is not a button: it is a new mandate, with live presence again.

A detail that is not a detail. The receipt of a delegated act performed before the revocation stays valid and true, because it proves what it proved. What ceased to exist is the authority for the next one.

What we measured

We compared, on a deterministic test bench, a gate that warns and executes anyway against the executor that requires the receipt. Seven shapes of call, from correct to wrong, with no language model in any of them, because what is measured is the mechanism and not a model’s behaviour.

The advisory gate let six of seven through. The requiring one, a single one, the correct one. The reading that matters is not the ratio: the advisory gate stopped exactly one caller, and it was the only one that was going to stop anyway.

Method and data are in the note A gate that warns and a gate that requires.

Limits, declared

• This does not decide what is risky. The client chooses what requires proof, in their own policy. There is no score, threshold or risk heuristic in the design, and there will not be.
• It does not replace access control. Proof of human presence does not answer who may do what. It answers whether a living person was there and authorised it.
• Live presence today goes through a certified AWS component, outside the country. A national source is target architecture.
• We do not prove the facial reference the client sent is legitimate. We prove that whoever is on camera is the same person as the reference they gave us.
• Short lived delegated credentials do not exist today, for executors without network at the moment of the action.
• None of this is a commercial offering. While it is target architecture, it will be called that.