Six questions for anything that says your agent is authorised

Payment rails for agents are arriving quickly. They are also, without exception, rails: they answer how value moves once a decision exists, and they say nothing about the decision. That is the correct scope for a payment protocol. It just leaves the interesting half to whoever is above it, which is increasingly everyone.

We built the layer above for a case with no money in it — a club where a member's agent asks another member's agent questions under terms both sides set. Nothing is spent. The authorisation problem turned out to be identical, which is what makes it worth writing down as questions rather than as an architecture.

Here are the six we would ask of anything claiming an agent is authorised, including of ourselves.

1. Where is the record, and can you produce it afterwards?

Not a settings screen. A record: what this person agreed to, attached to this agent, versioned, retrievable later by someone who was not there.

The test is temporal. Everything looks authorised in advance — that is why the agent acted. The moment that matters is after somebody is surprised, and then the only thing that settles it is the terms that applied at the time of the call. If the terms have been edited since and there is no version, you have a current setting and no history, which proves nothing about what was permitted then.

2. Is it checked by the system, or carried in the agent?

A rule in the agent's prompt is advisory. The agent reads text as part of its work, some of that text was written by someone with an interest in the outcome, and instructions hold only until something more convincing arrives mid-task.

A rule the server checks holds regardless of what the agent has been persuaded of.

This is the question that most designs fail quietly, because the prompt version demos identically. The difference only shows up under an adversary, and by then the difference is the whole thing.

3. If the principal narrows the terms today, do last month's credentials get narrower?

Almost everything says yes and means no.

If permissions are stamped into a credential when it is issued, then narrowing your terms changes nothing already in circulation. The remedy on offer is enumeration: find every credential you have handed out and revoke each one, including the ones you have forgotten, which are the ones that matter.

The alternative costs one lookup. Compute effective permissions as the intersection of the credential's scopes and the principal's current terms, on every request. Narrowing then reaches everything by construction, and "you can revoke it" stops meaning "you can revoke what you can find".

4. Can the agent change its own terms?

If yes, there are no terms. This sounds too obvious to ask, and it is worth asking because of where the answer usually comes from: the agent is the thing making the calls, and the convenient place to put the tool that updates settings is next to all the other tools.

We have a scope for changing a mandate. It exists because principals need to change their minds. It is never granted to an agent.

5. What happens to a request that falls just outside?

The answer "it fails" is a design that has not met its users yet. The marginal request — slightly outside the terms, plausibly fine — is the single case a person most wanted to see, and a system with only allow and deny turns it into a guess performed by a model.

What should happen is that it routes. The request becomes a decision for the principal, carrying the thing that raised it, so the person answers with the context already in front of them instead of reconstructing it from a notification. The refusal is not the product. The handover is.

6. Is every call recorded against the agent, the principal and the credential?

All three, because each one answers a different question later: what did this agent do, what was done in this person's name, and which credential — possibly one they had forgotten about, possibly one that should have been revoked — was used to do it.

This is the cheapest item on the list and the one most often deferred, on the grounds that it is observability rather than control. It is control. "Who allowed this" is not a question you can only ask in advance.

What a passing score means

Not that the agent is safe. An agent operating strictly within terms somebody chose can still do something they regret, and no list prevents a model from being wrong.

What it means is narrower and more useful: the worst case is bounded by something a person decided, rather than by something a model concluded while reading a page written by a stranger. That is the property worth insisting on before agents start spending, because it is much harder to add to a system afterwards than to build in now — and because the rails are not going to wait.