AI agent authority landscape
Three questions are routinely treated as one: who is this agent, what is it allowed to do, and who answers when it does the wrong thing. They have different answers, built by different organisations, with different failure modes. This is a map of who is answering which.
Inclusion is descriptive, not an endorsement. mnd8t appears in the first group with the same one-line treatment as everyone else. The infrastructure map covers the commerce and settlement layers, and is organised by what you would integrate rather than by what question is being answered.
Authority and policy
The thinnest layer by headcount and the one every other layer defers to. A credential can carry a constraint, and a network can enforce one at authorisation, but something has to decide what the constraint should be for this action, right now, against a budget that has been partly consumed and a counterparty with a history.
Two designs are visible. Constraints embedded in a credential at issuance, enforced by whoever is in the payment path — the network model. And constraints held as a versioned policy on the delegator's side, evaluated per proposal before anything is presented to a payment system — the policy engine model. They fail differently: the first is unavoidable but inexpressive, the second is expressive but can be bypassed by an agent that simply does not call it.
Verifiable digital credentials carrying a user's checkout and payment constraints, now under FIDO governance.
A framework binding identity, instruction and outcome into one tamper-resistant record, contributed to FIDO.
Spend rules — merchant, category, amount, timeframe, usage — carried inside a network token and enforced at authorisation.
Per-card limits, merchant locks, category blocklists and velocity rules exposed by issuing platforms and spend-management providers.
A deterministic policy engine and evidence layer: proposals evaluated against a versioned mandate, answered approve, reject or escalate, with a signed receipt and no model in the decision path.
Agent identity and admission
This layer matured fastest, because the pain arrived first: sites were being crawled and probed by software that would not identify itself, and the defences built against that were also blocking agents doing legitimate work for real customers.
The settled pattern is cryptographic. An agent signs its requests, its operator publishes verification keys, and a verifier checks the signature rather than trusting a header. What remains unsettled is the harder half — carrying who the agent is acting for, and on what authority, through the same channel.
IETF drafts applying HTTP Message Signatures to automated traffic, with keys published at a well-known location.
Merchant-facing signals distinguishing a trusted commerce agent from a malicious bot, with merchant-bound, time-bound signatures.
Verification of signed agent traffic at the edge, with a public directory of verified agents.
The standards process now holding AP2 and Verifiable Intent, chaired by CVS Health, Google and OpenAI.
Commercial agent registration and attestation, typically issuing a signed credential that carries identity and spend claims together. No common standard governs them; FIDO's agent-authentication work is the nearest thing to one in progress.
Governance, liability and supervision
The least resolved layer, and the one that will determine how fast the rest can be deployed in regulated firms. Whether a person who granted broad standing authority to an agent has authorised what the agent later did is a question regulators have opened and not yet answered.
What has changed in 2026 is that supervisors stopped saying existing rules simply apply. The FCA said it would consider whether regulation needs to change for agentic payments; HM Treasury opened a consultation asking how authentication, consent and liability should adapt. In the EU, agent-initiated payments remain under PSD2 and its technical standards as written, with no special regime.
Two working groups standardising agentic authentication and agentic payments, holding AP2 and Verifiable Intent.
Signalled in its 2026 payments priorities that it would consider whether rules need to change for agentic AI payments.
July 2026 consultation on modernising payment services regulation, including authentication, consent and liability.
PSD2 and its regulatory technical standards apply as written; no separate agentic regime, with PSD3 and the payment services regulation in train.
The two structural positions
Strip away the branding and there are two ways to bound an agent, distinguished by where the rule lives.
In the credential. The constraint is written into the instrument at issuance and enforced by whoever is in the payment path — an issuer, a network, a payment provider. Its great virtue is that it does not depend on the agent's cooperation: a compromised or malfunctioning agent still cannot exceed it. Its limit is expressiveness. A token can say “up to £750, at this merchant, this month”. It cannot say “up to £750, unless this supplier's bank details changed in the last thirty days, in which case ask a person”.
In a policy. The constraint is held as a versioned document on the delegator's side and evaluated per proposal, before anything is presented to a payment system. It can express anything computable, including state the credential cannot see — budget consumed today, counterparty history, whether this is the fourth attempt at the same payment. Its limit is reachability: an agent that never calls the policy is not bound by it.
These fail in opposite directions, which is the argument for both. The credential is the floor that holds when the software misbehaves. The policy is the layer that can express what the business actually meant, and produce a record of it. Anyone choosing between them is answering the wrong question; the real one is which rules belong in which place.
What is not yet settled
It would be wrong to say nobody is working on these. FIDO's agentic working groups are chartered on exactly this ground: verifiable user instructions, so an agent performs only approved actions; agent authentication, so a service can check an agent is acting for an authenticated user and within defined parameters; and trusted delegation, so agent-initiated transactions run within user-controlled boundaries with verifiable authorisation. Mastercard's Verifiable Intent and Google's AP2 were contributed into that process.
The accurate claim is narrower and more interesting: no broadly adopted architecture yet provides the complete lifecycle of dynamic, stateful delegated authority across agents and financial systems. Chartered is not delivered, and four things in particular remain open.
- Revocation, and the lifecycle after issuance. Issuing is well described everywhere. Withdrawing a mandate an agent already holds, and proving it was withdrawn before a given transaction, is not — FIDO's April 2026 announcement sets out delegation boundaries without yet specifying revocation or audit mechanisms. Most designs substitute short lifetimes.
- State that changes between issuance and use. A credential fixed at issuance cannot see the budget consumed since, the counterparty's history, or the fourth attempt at the same payment. Something has to evaluate those at the moment of the action, and no widely adopted standard says what.
- Carrying the principal through the chain. Identity protocols attest the operator. Nothing widely deployed carries who the agent is acting for, verifiably, across several hops of delegation without the scope widening on the way.
- Liability. Whether standing authority granted in general terms constitutes authorisation of a specific later payment is an open question in both the UK and the EU, and both HM Treasury and the FCA have it under active consideration. Firms deploying now should assume they will have to evidence what was authorised, whichever way it is resolved.
The legitimate agent doing the wrong thing sits underneath all four. Prompt injection does not forge a signature — it persuades a correctly identified agent to propose something its principal never wanted. No identity layer addresses that; only a bound on authority does.
Last reviewed 8 September 2026. Corrections: hello@mnd8t.com.