The race to standardise verifiable user instructions for AI agents
Standards bodies, card networks and agent-payment startups have all arrived at the same conclusion within about eighteen months: agents need a way to carry human authorisation. They have not arrived at the same answer about what the human authorises.
What are the standards bodies disagreeing about for agent authorisation?
Not the cryptography, which is settled. They disagree about what goes under the human's signature: a capability scope, a payment envelope, a policy the agent claims to follow, or the rendered effect of one specific action. That choice determines which attacks remain possible.
- The convergence is real: multiple independent efforts have concluded that agent actions need carried human authorisation.
- They diverge on the signed object — a capability, a payment envelope, a policy, or the rendered effect. That choice determines what attacks remain possible.
- Signing a scope authorises a class of actions. Signing a rendered effect authorises one. Most proposals do the first and are described as though they did the second.
Part of Agent tool-call gating
Why everyone arrived at once
Agent deployments hit the same wall in production. An agent holds credentials, takes actions, and produces no evidence of human authority behind any specific action. Every party downstream — a counterparty, a bank, an auditor, an insurer — eventually asks the same question, and there is no answer to give.
The convergence on "carry a signed authorisation" is genuine and welcome. The disagreement is about what goes inside it.
Four answers to one question
| Approach | Signed object | Authorises | What survives |
|---|---|---|---|
| Capability tokens | A scope and a set of constraints | A class of future actions | Replay within scope; unrendered detail |
| Payment mandates | A payment envelope: amount, merchant, window | A bounded payment | Non-payment actions; fields outside the envelope |
| Policy attestation | A policy the agent claims to follow | Compliance with a rule, asserted by the agent | Anything the agent misreports |
| Rendered effect | The canonical form of this specific action | Exactly this action, once | Nothing outside what was shown |
The first three are easier to deploy and compose better with existing infrastructure. The fourth is narrower and harder to retrofit.
The scope-versus-instance distinction
This is the whole argument, so it is worth stating carefully.
A scope signature says: this agent may do things of this kind, within these limits, until this time. It is a delegation. It is the right primitive for most agent operation, because requiring a human signature per action would make agents useless.
An instance signature says: I saw this exact effect and I authorise it. It is an approval, not a delegation, and it is only tolerable on a small number of actions.
Both are needed. The failure mode is describing a scope signature as though it carried the assurance of an instance signature — which happens routinely, because the marketing language for both is "the user authorised it".
What an attacker does against each
- Against a capability token: operate within scope. A compromised agent holding a valid scoped token produces valid signed actions. Every one of them verifies.
- Against a payment mandate: attack non-payment surfaces. Mandates bound the payment and say nothing about the account change, the address update, or the recipient added beforehand.
- Against policy attestation: misreport. The attestation is a claim by the component being asked to behave.
- Against an instance signature: there is no move inside the signed action. The attack shifts to what was rendered — which is a UI problem with known answers, rather than a cryptographic gap.
Where the standards effort actually matters
Not in the signing. Signing a digest with a hardware-backed credential is solved; WebAuthn has done it for years and the mechanism is not in dispute.
It matters in three places that are much less glamorous.
| Layer | Why it needs a standard |
|---|---|
| Canonicalisation | Two parties must derive the same digest from the same action. Without an agreed canonical form, verification fails on formatting. |
| Chain semantics | Depth limits, constraint expressions, revocation and expiry must mean the same thing to issuer and verifier. |
| Verification profile | A verifier must know which trust anchors, which algorithms and which failure modes are mandatory rather than optional. |
These are interoperability problems, and they are exactly what standards bodies are for. They are also where fragmentation causes real cost, because a receipt that only one vendor can check is not portable evidence.
What to build before the standard settles
Standards work takes years. Deployments are happening now. Three decisions are stable regardless of which proposal wins.
- Canonicalise with a published, deterministic scheme rather than a house format. RFC 8785 is the obvious choice and costs nothing to adopt early.
- Separate delegation from approval in your own architecture, with distinct types and distinct verification paths. Conflating them now makes migration painful later.
- Render from the canonical form. Whatever the standard settles on, the rule that a human signs what they were shown does not change.
An organisation that does those three things can adapt to any of the four approaches. One that has conflated delegation with approval will need to rebuild.
The likely outcome
Coexistence rather than a winner. Capability tokens for ordinary agent operation, payment mandates inside payment rails, instance signatures on the small set of actions where a dispute is expensive. That is a reasonable architecture and roughly what mature systems already do with human users.
The risk is not that the wrong standard wins. It is that enterprises deploy scope signatures, describe them as approvals, and discover the difference during a dispute.
Where the standards work actually matters
Not in the signing. Hardware-backed signing over a digest has been deployed for years and is not in dispute. The interoperability problems are duller and more consequential.
| Layer | Why a standard is required |
|---|---|
| Canonicalisation | Two parties must derive the same digest from the same action, or verification fails for formatting reasons unrelated to security |
| Chain semantics | Depth limits, constraint expressions, revocation and expiry must mean the same thing to issuer and verifier |
| Verification profile | A verifier must know which trust anchors, algorithms and failure modes are mandatory rather than optional |
Objections and honest limits
“We should wait for the standard.” Three decisions hold under any outcome: canonicalise with a published deterministic scheme, keep delegation and approval as distinct types, and render from the canonical form. An organisation that does those can adopt whichever proposal wins.
“Capability tokens are insecure.” They are not. They are the right primitive for bounded delegation, and requiring a human signature per action would make agents useless. They simply do not establish that a human saw a specific effect.
The likely outcome is coexistence rather than a winner: capability tokens for ordinary operation, payment mandates inside payment rails, instance signatures on the small set of actions where a dispute is expensive.
Three decisions that survive any standard
- Canonicalise with a published scheme. RFC 8785 costs nothing to adopt and makes your digests reproducible by anyone.
- Separate delegation from approval. Distinct types, distinct verification paths. Conflating them now makes migration painful later.
- Render from the canonical form. Whatever wins, the rule that a human signs what they were shown does not change.
- Record which tier was used. So a later reader knows whether an action carried a scope grant or an instance signature.
Terms used here
- Capability token
- A signed grant describing a class of permitted future actions, with constraints and an expiry. A delegation, not an approval.
- Instance signature
- A signature over one specific rendered effect, valid for one execution.
- Canonicalisation
- Reducing structured data to a single deterministic serialisation so that the same facts always produce the same digest.
Frequently asked questions
Is a capability token insecure? No. It is the right primitive for bounded delegation and works well for that. It does not establish that a human saw and intended a specific action, which is a different property.
Why does canonicalisation need standardising? Because issuer and verifier must derive the same digest from the same action. Different serialisation of the same data produces different digests and verification fails for no security reason.
Should we wait for the standard? No. Canonicalise deterministically, separate delegation from approval, and render from canonical form. Those three hold under any outcome.
Does this require WebAuthn specifically? It requires a credential under the human's sole control that can sign a supplied challenge with user verification. WebAuthn is the widely deployed way to get that.
Is this a criticism of FIDO's work? No. The signing mechanism is solved and the standards effort is needed precisely for the unglamorous parts: canonicalisation, chain semantics and verification profiles.
What is the practical risk of getting it wrong? Deploying scope signatures, describing them as approvals, and discovering the difference during a dispute.
Where this fits in Manav
Manav implements both tiers as distinct objects: a delegation carrying scope, expiry and depth, and a receipt carrying one rendered effect. Both canonicalise with RFC 8785 and verify offline, so neither is locked to a standards outcome.