Delegated authority glossary

Agent identity#

Cryptographic proof of which software, run by which operator, is making a request.

Agent identity answers 'who is calling'. It is established by signing requests with a key whose public half is published — the mechanism in Web Bot Auth — or by registering an agent with a network, as in Mastercard Agent Pay and Visa's trusted agent model.

It is necessary and insufficient. A verified agent can still propose an unauthorised payment, because identity and authority are different properties. Every deployment that has treated a verified identity as an authorisation has re-learned this.

Agentic token#

A tokenised payment credential registered to a specific agent and user and constrained by rules the user set.

Mastercard's term, introduced with Agent Pay in April 2025, extending existing network tokenisation. The token is tied to a user, registered to an agent, and carries constraints — merchant, category, amount, timeframe, usage — enforceable by the network at authorisation.

The design puts the constraint inside the credential, which makes it enforceable regardless of the agent's own behaviour, and bounds how expressive the constraint can be to what the token format holds.

Audit trail#

The chain of records establishing what was authorised, what was decided, and what was executed.

For agent payments a sufficient trail answers five questions: who delegated, under what policy version, what did the agent propose, what was decided and why, and what was actually executed. Most systems can answer the last one and struggle with the middle three.

The recurring failure is a gap between the decision and the execution. If the record shows an approval and the ledger shows a payment, but nothing binds one to the other, the trail proves less than it appears to.

Authorisation artifact#

A one-time, signed object issued when an action is approved, presented at execution and consumed on use.

The bridge between deciding and doing. An artifact binds a specific approved action to a specific execution attempt: it is verified before execution, claimed exactly once, and cannot be replayed for a second payment.

Its value is in closing the gap between an approval and what was actually done with it. Without one, an approval is an assertion in a log that a payment was allowed, with nothing preventing the same approval being used twice.

Autonomous limit#

The threshold below which an agent may act alone and above which a human must approve.

Distinct from the maximum limit. A mandate typically has both: a ceiling above which nothing is permitted at all, and a lower threshold above which a person is asked. The gap between them is where most useful agent work happens.

Setting it is an empirical exercise. Run in shadow mode, look at the distribution of proposals, and place the threshold where escalation volume is tolerable and unattended exposure is acceptable.

Confused deputy#

An authorised system tricked into misusing its authority on behalf of someone who lacks it.

A 1988 term that describes the central security problem of agent payments exactly. The agent has legitimate authority. The attacker does not. The attack is to get the agent to use its authority on the attacker's behalf — through a poisoned document, a malicious web page, a crafted invoice, an injected instruction in a tool result.

Identity does not help, because the deputy is genuinely who it says it is. What helps is bounding the deputy's authority so tightly that misuse is contained, and requiring a human for the cases where the bound cannot be tight enough.

Delegated authority#

The permission a principal grants an agent to act on their behalf, bounded in scope, amount, time and purpose.

Delegated authority is older than software. A power of attorney, a corporate signing limit, a purchase order threshold and a parent's instruction to a shop are all the same construct: someone with authority grants a bounded subset of it to someone else, and remains accountable for the result.

What changes with autonomous agents is the rate and the reviewability. A human delegate exercises authority a few times a day and can be asked afterwards what they were thinking. An agent may exercise it hundreds of times an hour and cannot be meaningfully asked anything — its reasoning is not stable, not reproducible, and not admissible. So the bound has to be external to the agent, and the record has to be produced at the time rather than reconstructed later.

Every serious construct in this field — mandates, agentic tokens, scoped payment credentials, verifiable intent — is an attempt to express delegated authority in a form a machine can check and a human can audit.

Deterministic evaluation#

The property that the same proposal against the same policy version always yields the same decision.

Determinism is what makes a decision defensible. It means the decision can be replayed, tested before deployment, diffed across policy versions, and explained in terms of rules rather than outputs.

It also has a practical consequence for architecture: the policy version must be pinned to the decision. A decision that references 'the current mandate' is not reproducible, because the mandate will change.

Escalation#

Referring a proposed action to a person because the policy says this case should not be decided alone.

The third outcome, and the one that makes the other two usable. A binary allow/deny forces a choice between an agent that is too constrained to be useful and one that is too free to be safe; escalation lets the policy be tight and the agent still get its work done.

Designing it well is mostly about latency and context: an approver needs to see what is being asked, what rule triggered, and what happens if they do nothing, and needs to decide in seconds on a phone. An escalation that takes an hour to reach someone is a rejection with extra steps.

Evidence receipt#

A signed record of a decision — the proposal, the policy version, the outcome and the reasons — verifiable without trusting the issuer.

A receipt differs from a log in three ways: it is signed, so it cannot be edited afterwards; it is self-contained, so it can be verified by someone with no access to the issuing system; and it names the exact policy version the decision was made under.

The test of a receipt scheme is whether a third party — an auditor, a counterparty, a court — can verify one using only a published key. If verification requires the issuer's cooperation, the receipt is a log with extra steps.

Execution boundary#

The line between the system that decides whether a payment is permitted and the system that actually moves money.

Keeping decision and execution in different systems, under different credentials, is a deliberate control. The deciding system never holds funds or payment credentials, so compromising it does not directly move money; the executing system will not move money without a valid artifact, so compromising it does not silently widen authority.

It also has a regulatory consequence: a system that never holds or transmits funds is not performing a regulated payment service, which materially changes what it must be licensed to do.

Human-not-present#

A transaction the agent completes alone, on authority granted in advance.

AP2's term for the flow that actually needs new machinery. Where a human is present at the moment of purchase, existing authentication mostly works. Where the agent acts alone — the overnight top-up, the automatic renewal, the reorder — nothing in the traditional flow captures consent, because consent was given earlier and in general terms.

This is where mandates, evidence and escalation stop being nice properties and start being the only way to answer what happened.

Idempotency#

The property that repeating a request produces the same single effect rather than repeated effects.

Mundane, and the single most common cause of duplicate agent payments. Agents retry: on timeout, on ambiguity, on a plan being re-run. Without an idempotency key on the decision and on the execution, a retried payment is a second payment.

It belongs at both layers. An idempotent decision prevents a duplicate approval; an idempotent execution prevents a duplicate transfer against a single approval.

Kill switch#

A single control that stops an agent spending immediately, without redeploying anything.

Every deployment needs one, and it should be exercised in a drill rather than discovered during an incident. The design question is where it lives: at the policy layer (fastest, and only effective if the agent must consult the policy), at the credential layer (deactivate the token or card, effective regardless of the agent), or both.

The honest answer is both, because the reason you are reaching for it may be that the agent has stopped behaving as designed.

Know Your Agent (KYA)#

Extending customer due diligence to the software acting for a customer.

A coinage by analogy with Know Your Customer, used by several infrastructure providers to describe registering an agent, attesting its operator, and binding it to an accountable party.

It is not a regulatory term of art. No supervisor has defined a KYA obligation; what exists is a set of vendor practices and a reasonable expectation that existing obligations will be read to cover agents acting for customers.

Least privilege#

Granting the minimum authority sufficient for the task, for the shortest time that works.

Well understood in access control, routinely abandoned in agent deployments, where the path of least resistance is a card on file and a broad limit because narrowing it takes work.

For payments least privilege has a specific shape: scope to counterparties actually needed, amounts actually required, purposes actually assigned, and windows the work actually occupies — and re-grant rather than extend.

Liability shift#

Who bears the loss when an agent-initiated payment turns out to be unauthorised or wrong.

In card payments liability allocation is a settled, if complicated, matter of scheme rules and law. Agent-initiated payments unsettle it, because the categories — authorised, unauthorised, disputed — assume a person who either did or did not consent to a specific transaction.

The open question is whether a person who granted broad standing authority to an agent has authorised what the agent later did. Both the FCA and HM Treasury have signalled that consent and liability need revisiting; nobody has answered it yet. Firms deploying now should assume that whatever the answer, they will have to evidence what was authorised.

Mandate#

An explicit, machine-checkable statement of what an agent may do on a principal's behalf.

The word is used in at least three ways, and conflating them causes real confusion.

In AP2, a mandate is a verifiable digital credential — a signed object carrying the user's constraints, presented to a merchant or a payment provider. It travels.

In UK Open Banking and in direct debit schemes, a mandate is a standing authorisation held by a payment provider that permits future collections. It sits with the institution.

In a policy engine, a mandate is a versioned document that a proposed action is evaluated against: counterparties, limits, budgets, purposes, hours, escalation rules. It does not travel and it is not a credential; it is the thing decisions are made from.

The three are not competitors. A policy mandate can produce a credential mandate as an output; a credential mandate can be honoured by a scheme mandate at settlement. When reading anything in this space, establish which sense is meant before comparing.

Merchant category code (MCC)#

A four-digit code classifying a merchant's business, used to allow or block categories of spend.

The blunt instrument of spend control, and a useful one: blocking whole categories is cheap and enforced at authorisation.

Its limits show up quickly with agents. MCCs describe the merchant, not the purchase — a marketplace has one code for everything it sells — and they carry no notion of purpose, so a control built on them cannot distinguish a legitimate purchase from an illegitimate one at the same merchant.

Non-repudiation#

The property that a party cannot credibly deny having authorised or issued something.

In agent payments, non-repudiation is wanted in both directions: the principal should not be able to deny an authorisation they genuinely gave, and the operator should not be able to deny a decision their system genuinely made.

It requires signatures over canonical content with published verification keys, and it requires key management good enough that 'the key was compromised' is not an easy answer.

On-behalf-of (OBO)#

A claim asserting that an agent is acting for a named principal, rather than for itself.

Borrowed from OAuth token exchange, where a service acts for a user rather than under its own identity. In agent payments the same claim has to survive several hops — user to orchestrator, orchestrator to sub-agent, sub-agent to merchant — and each hop is an opportunity for the chain to be broken or forged.

The unsolved part is not expressing the claim; it is establishing that the principal actually made it, and that the scope did not widen along the way.

Policy engine#

A deterministic evaluator that answers whether a specific proposed action is permitted by a specific mandate.

A policy engine takes a proposed action and a version of a mandate and returns a decision — permitted, refused, or requires a human — with the reasons. The properties that make one trustworthy are determinism (the same inputs against the same mandate version always return the same answer), explainability (a rule-by-rule trace, not a score), and no model in the decision path.

That last property is the one people argue about. An LLM can be excellent at drafting a policy and is unsuitable for enforcing one: enforcement needs to be reproducible in front of an auditor a year later, and a probabilistic system cannot offer that.

Policy versioning#

Treating each published state of a mandate as an immutable version that decisions are bound to.

Without versioning, an audit question — 'what authorised this payment?' — has no stable answer, because the policy has been edited since. With versioning, the decision names the exact version, and the version cannot be altered after publication.

This is the same discipline that applies to any control document. The novelty is only the rate of change: mandates for agents get tuned weekly in early deployments, so version churn is high and the immutability guarantee matters more.

Principal#

The person or organisation whose authority the agent is exercising, and who bears the consequence.

In agent systems the word is doing double duty and it is worth separating the senses. The principal in the legal sense is whoever is accountable for the payment — usually the account holder or the company. The principal in the authentication sense is whichever identity a token was issued to, which may be a service account, an agent registration, or a human's session.

Most incident post-mortems in this field turn on a gap between the two: the token identified something, but not the party who would have to answer for the transaction.

Prompt injection#

Content the agent reads being crafted to change what the agent does.

The practical delivery mechanism for the confused deputy problem in agent systems. Instructions arrive in a web page, an email, a PDF invoice, a tool result — anywhere the agent takes in text it did not author.

For payments the mitigation is architectural rather than linguistic. Do not attempt to make the model immune; assume a proportion of proposals will be adversarial, and put a deterministic check between the proposal and the money. A policy engine does not read the injected text; it reads the amount, the counterparty, the purpose and the budget.

Purpose binding#

Restricting a delegation to a stated purpose, so an otherwise-in-limit payment can still be refused.

Purpose is the axis that separates a policy from a limit. 'Up to £750' permits any £700 payment; 'up to £750 for cloud infrastructure' does not permit £700 of advertising. Purpose is also the axis that maps most directly onto how organisations already delegate: budget lines have purposes, cost centres have purposes, approvals are granted for purposes.

It is under-represented in credential formats because it is hard to enforce at a network: a card authorisation carries a merchant category, not an intention. Purpose therefore tends to be evaluated before the payment, on the delegator's side, and recorded in the evidence.

Regulated execution#

The part of a payment flow that requires authorisation as a payment service, as distinct from the parts that do not.

Deciding whether a payment is permitted is not a regulated payment service. Holding client funds, transmitting them, or issuing payment instruments is. The distinction is why several agent-payment designs keep execution with a regulated institution or with the customer's own treasury systems.

For anyone architecting in this space it is the first question, not the last: what the system touches determines what it must be licensed to do.

Revocation#

Withdrawing an authority already granted, and being able to prove when it was withdrawn.

The most under-specified part of every credential-based scheme. Issuing a mandate is straightforward; withdrawing one already in flight, and later proving it was withdrawn before a particular transaction, is not.

There are two designs. Short-lived authority, re-issued continuously, so revocation is achieved by not re-issuing — simple, and it makes availability a hard dependency. Or an explicit revocation record that relying parties must check — stronger, and it needs a distribution mechanism everyone actually consults.

Scope of authority#

The dimensions along which a delegation is bounded: who, what, how much, how often, when, and why.

A useful scope has six axes. Counterparty (who may be paid), instrument (what may be spent), amount (per transaction and cumulative), frequency (velocity), time (windows and expiry), and purpose (what the spend is for).

Most implementations start with amount because it is the easiest to enforce, and discover in production that purpose and counterparty are where the losses actually occur. A per-transaction limit does not stop an agent paying the wrong supplier a plausible amount forty times.

Shadow mode#

Evaluating real traffic against a policy and recording what would have happened, without enforcing it.

The only responsible way to deploy a policy that will block payments. Replay real proposals, record the decisions, and compare against what actually happened. The output is a false-positive rate you can show to the people whose payments you are about to start refusing.

It is also the fastest way to discover that a mandate written in a meeting does not describe the business as it operates.

Shared payment token#

A credential minted by the buyer's payment provider for one merchant, one amount and a short window, given to an agent instead of a card.

The construct in the Agentic Commerce Protocol's delegated payment specification. Instead of exposing a card on file to an agent, the buyer's provider issues a token scoped to the transaction at hand.

It is a containment mechanism of real value and narrow scope: it says how much and to whom, and nothing about why, about cumulative budget, or about when a human should have been asked.

Spend control#

A constraint that caps or filters spending on an instrument: limits, merchant restrictions, category blocks.

Spend controls are the incumbent mechanism, and they work: per-card limits, per-merchant locks, merchant-category blocklists, velocity rules, single-use cards. Every issuing platform exposes them and they are enforced at authorisation whether or not the spender cooperates.

Their limitation is expressiveness, not effectiveness. A control lives on an instrument and can only see what the authorisation message carries. It cannot know that this supplier's bank details changed last night, that the invoice was for a purpose outside the budget line, or that a person would have wanted to be asked. Controls bound the damage; they do not encode the intent.

Strong Customer Authentication (SCA)#

The European requirement that electronic payments be authenticated with two independent factors, from knowledge, possession and inherence.

SCA was drafted around a present customer authenticating at the moment of payment. An agent transacting alone at 3am against authority granted a fortnight earlier does not fit that picture, and the exemptions were not designed with it in mind.

As of late 2026 there is no separate regime for agentic payments in the EU: PSD2 and its regulatory technical standards apply as written, and the question of how an agent-initiated payment is authenticated is being worked through by regulators, not resolved. The UK is consulting on the equivalent questions.

Tokenisation#

Replacing a payment credential with a surrogate value that is useless outside its intended context.

The mechanism underneath most agentic payment credentials. Its security property is contextual binding: a token restricted to a merchant, a channel or a device cannot be replayed elsewhere.

Tokenisation is about credential exposure, not about authority. It is why a leaked agentic credential is less damaging than a leaked card number, and it is not why an agent's spending is bounded.

Velocity limit#

A cap on the number or value of transactions in a rolling window.

The control that catches loops. A per-transaction limit does nothing about an agent that retries a payment two hundred times; a velocity limit does.

For agents the relevant windows are shorter than for humans. A person cannot make forty payments in a minute; an agent in a retry loop can, and will, and the first anyone hears about it is the balance.

Verifiable credential#

A signed, tamper-evident statement whose authenticity a third party can check without asking the issuer.

The format underpinning AP2's mandates. The useful properties are non-repudiation (the issuer cannot later deny it), tamper evidence (alteration invalidates the signature), and independent verification (a relying party checks the signature against a published key, offline).

The last property is what makes them appropriate for disputes. Evidence that can only be verified by asking the party with an interest in the outcome is weak evidence.

Verifiable intent#

A tamper-resistant record binding a person's identity, their instruction, and the resulting transaction together.

Mastercard's framework, published in March 2026 and contributed to the FIDO Alliance the following month, designed to work with AP2 and to be integrated into Agent Pay's intent APIs.

The idea is that a dispute is settled by a record showing what the person asked for and what actually happened, rather than by inference from logs. It is the clearest statement by an incumbent that the evidentiary problem is distinct from the credential problem.

Virtual card#

A card number issued programmatically and constrained to a vendor, amount or single use.

The default containment pattern for agent spending on card rails, and for good reason: it is available today from every issuing platform, needs no new standard, and caps exposure at the card's limit. The common shape is one card per vendor, with an approval flow for anything outside the approved list.

It contains a compromise rather than preventing a mistake. An agent that decides, wrongly but plausibly, to renew a subscription it should have cancelled will do so on a perfectly valid vendor-locked card.