When Agents Delegate, Authority Must Shrink

Disclosure: These views are my own and do not represent my current or any former employers. This paper uses only public sources and does not describe non-public product information.

Executive summary

An agent can be exactly who it claims to be and still do something nobody authorised.

A shopping agent presents a valid credential, is traceable to a real cardholder, has passed a certification programme, and is monitored continuously. It then buys something the user never asked for, because a web page it read during the task told it to. Every identity control worked, and the purchase was still unauthorised.

On 10 September 2026, Ant International, Mastercard and Visa announced that they have begun collaboration on a Know Your Agent interoperability framework, built on cross-network operator traceability, shared certification requirements and continuous transaction monitoring, while preserving each network's own verification and decisioning processes.[1] The announcement is a useful signal about where the industry is heading. It is an announcement rather than a published specification, and its own language is careful: the organisations will explore opportunities, and the framework could simplify agentic payment transactions.[1]

Payments are the opening stress case here because money makes the gap legible. The gap is general. The same structure appears when an agent calls a tool over Model Context Protocol, deletes a cloud resource, merges a release branch, queries a production database, sends mail on somebody's behalf, drives a browser session carrying a logged-in cookie, or passes work to an agent in another organisation. In each case something authenticated the caller, and something else, often nothing at all, decided whether the specific action was allowed.

This paper sets out a standards-neutral operating model for that second decision:

1. Authority has an explicit root. Every consequential action traces to a principal or institutional authority entitled to grant it.
2. Authority is typed. The enforceable grant is a machine-evaluable structure over actions, resources, arguments, purpose, time, budgets, depth, risk and obligations. Natural-language instruction is evidence of intent rather than the thing enforced.
3. Authority is stateful. Budgets, counts, reservations, approvals, revocations and policy versions change between issue and execution.
4. Authority is re-evaluated per consequential action. A standing grant is an input to a decision rather than the decision.
5. Enforcement sits outside model reasoning, at the component capable of causing the side effect.
6. Evidence links intent, delegation, proposal, decision, approval, execution and observed result.
7. Authority may stay the same or shrink along a delegation path. It must never expand through delegation, fan-out, fan-in, concurrency or translation between administrative domains. Combining authority from independent roots requires a new grant from a principal entitled to hold both.

None of the underlying ideas is new. The separation of identity from authorisation, least privilege, complete mediation, task-bound permissions, delegation chains, capability attenuation, policy decision and enforcement separation, and signed receipts are long established.[13][18][19][20][23] Several 2026 Internet-Drafts and preprints apply them specifically to AI agents.[24][25][26] This paper proposes no new token format and does not claim that existing standards are inadequate for every agent.

The contribution is an operating-model synthesis. Recent drafts and preprints already address attenuating chains, branch handling and capability budgets. Less settled questions remain around authority arriving through several roots, sequential combinations of individually permitted actions, concurrent consumable budgets, cross-domain translation, and conformance tests that demonstrate the properties instead of inferring them from token shape.

The rest of the paper is about what the title means when the delegation structure is a graph rather than a chain, when the grant is a set of typed constraints rather than a scope string, and when the proof of correct behaviour has to survive an audit six months later.

1. A known agent can still exceed its authority

1.1 The catalyst

The KYA collaboration announced on 10 September 2026 addresses a real problem. Agent commerce currently forces every merchant, wallet, marketplace and network to judge for itself whether an incoming automated request is a legitimate consumer agent, a scraper, or an attack, and duplicated onboarding is expensive, inconsistent and produces a weak signal.

The announcement names three workstreams: cross-network operator traceability, shared certification requirements and continuous transaction monitoring.[1] The work runs through the Monetary Authority of Singapore's BuildFin.ai programme and builds on Safeguards for Agentic Finance at Runtime.[1][2]

Three qualifiers belong with any use of this announcement. The parties have begun a collaboration rather than published a joint specification. They have said they will explore opportunities and that the framework could simplify agentic transactions. Each network retains its own verification and decisioning.[1] A shared trust signal that every network interprets independently is an input to an authorisation decision rather than the decision itself.

1.2 The example

A user asks an agent to book a hotel in Dublin for under EUR 300 a night for three nights next month. The agent is registered, certified, attested to a real cardholder, and monitored. During the task it reads a review page containing text addressed to automated shoppers, instructing it to secure the booking by first purchasing EUR 4,000 of prepaid gift cards through a linked merchant.

The agent attempts the purchase. Identity verification returns a valid result, because the identity is valid, the operator is real and the certification is current. Nothing in the identity layer has failed, and nothing in it is positioned to notice that the requested action bears no relation to the task the user described.

Detecting the injected instruction is worth doing and is not sufficient, because the detector is a probabilistic component reading adversarial text. The durable control is that the authority the agent holds does not cover prepaid gift cards, does not cover EUR 4,000, and does not cover a merchant outside accommodation. Under that arrangement the injection still happens and the purchase still fails.

1.3 The same structure without payments

The pattern is not about money. It is about an authenticated actor performing a consequential action outside the authority anyone actually granted.

EchoLeak, tracked as CVE-2025-32711, demonstrated that an assistant with broad access to a user's mail and documents could be induced by adversarial content to disclose that data.[27] The credential was legitimate, and the exposure came from the breadth of what it reached during a task that needed almost none of it. A published demonstration against a GitHub MCP deployment showed the same shape: content in a public issue influenced an agent that also held authority over the same user's private repositories, producing data movement across that boundary.[29] That is a research demonstration rather than a confirmed production breach, and its value here is structural, because the agent's authority was the union of everything the user could do, so the attacker only needed to steer the agent.

The Amazon Q Developer extension compromise is a different kind of case and should be labelled accordingly. AWS reported that an inappropriately scoped GitHub token allowed unauthorised code into a release build, where a syntax error prevented it from running.[28] That was a software supply-chain compromise rather than an autonomous delegation failure, and the root condition is the same: a credential whose reach exceeded the task it existed to perform, inside a pipeline with authority to publish.

The list generalises easily: a cloud role that can delete as well as read, a support agent that can refund any amount because the refund API has one permission, a data agent whose query authority is the analyst's, and a browser agent inside an authenticated session where every action inherits what that session can do.

1.4 The question this paper answers

Identity answers who is acting. Certification answers whether the operator met a standard. Monitoring answers what happened across a population over time. None of them answers the question that determines whether the gift card purchase completes:

May this actor, holding authority derived through this particular path from this particular root, perform this exact action with these exact arguments against this resource, right now, given current budgets, approvals, revocations and policy?

That question has to be answered per action, by a component the agent cannot talk its way past, and the answer has to leave a record that can later be checked against what actually happened.

2. What Know Your Agent establishes

2.1 The three workstreams

Cross-network operator traceability links an agent to a validated operator, cardholder, business or organisation.[1] It is an attribution mechanism, answering who is accountable for an agent's behaviour, which supports liability allocation, offboarding and fraud investigation. Shared certification requirements assess agents against common security and behavioural expectations,[1] which is a statement about a class of software at a point in time and supports a prior about how an agent is likely to behave. Continuous transaction monitoring uses identity and transaction signals to support ongoing assessment and certification,[1] which is a population-level and retrospective control that detects patterns, revokes trust and feeds risk models.

Together these give a network better information about who is calling, which is worth having. They share a property: each describes the agent rather than the action.

2.2 What the announcement does not yet specify

On the published evidence, no joint artifact currently defines a credential schema or API; how a user's detailed intent is represented or compiled into deterministic authority; how one exact purchase, API call or tool invocation is authorised; how a child agent receives a provable subset of its parent's authority; how a shared budget is conserved across several child agents; whether authority arriving through two paths may be combined; how one network must treat another network's signal; how revocation propagates; what a portable decision or execution receipt looks like; or how liability is allocated when an agent acts outside its mandate.[1]

That is not a criticism of an effort announced the previous day. The list matters because it marks where a deploying organisation still has to build, and because a KYA signal will arrive at systems whose operators may assume it carries more meaning than it does. If each network decides for itself, a shared trust signal is an input to a policy decision, and Sections 5 to 11 describe the layer in which that decision is made.[1]

2.3 SAFR is the closer relative

Safeguards for Agentic Finance at Runtime is the more directly relevant piece of the same programme. SAFR describes a runtime governance layer with four components: agent identity, a controls repository, a disposition engine and a tamper-evident audit log. Its disposition engine returns deny, escalate, auto-execute or observe, and it is designed to verify and record proposed agent actions before execution.[2]

SAFR states its own boundary in a line worth quoting: payment schemes and settlement rails move money, and SAFR governs the decision to move it.[2] That is the separation between decision and execution, stated by an industry framework from within the payments sector, and it is the same line this paper draws in Section 8. SAFR also states that it is not regulatory guidance or a statement of supervisory expectations and remains under development, while BuildFin.ai is a collaborative initiative involving financial institutions, technology providers and research institutes rather than a standards body, certification authority or central agent registry.[2]

KYA improves what a network knows about the caller. SAFR governs whether a proposed action proceeds. The industry is drawing the same line this paper draws, in its own vocabulary, in one sector.

3. Nine different questions

Discussion of agent security tends to collapse several questions into one word. The nine below are distinct, are answered by different components, fail in different ways, and produce different evidence. Drift between them is the most common source of confusion in design reviews.

Evidence subdivides further, and conflating its kinds weakens audits. Credential evidence shows what was issued, approval evidence what a human agreed to, decision evidence what a policy engine concluded and on what inputs, enforcement evidence that a component applied that conclusion, execution evidence what the target system did, and provenance evidence where the data an agent relied on came from.

A system can satisfy several of these and still fail. Strong authentication with no authorisation gives a well-identified actor doing whatever it likes. Strong authorisation with weak enforcement gives a correct decision that nothing applies. Strong enforcement with weak evidence gives a system that behaved correctly and cannot prove it.

4. What current commerce protocols contribute

The agentic commerce protocols published in 2025 and 2026 matter here for one reason: they show several different layers being built by serious organisations, and they show that the layers are not interchangeable. The purpose of this section is to place them rather than to compare or recommend them.

4.1 Visa Trusted Agent Protocol

TAP addresses a merchant encountering an agent it does not know. It defines three linked forms of signed information: an agent-recognition signature, a consumer or device identity object, and a payment container. The signature builds on HTTP Message Signatures and covers the merchant authority and path, timestamps, key identifier, algorithm, nonce and an interaction tag, and the two currently defined tags express browsing and paying.[3]

Verification establishes that the agent participates in the relevant payment-scheme programme.[3] It does not establish that the agent is safe, that its model interpreted the user correctly, or that a transaction is authorised. Visa states that the initial specifications apply to the Visa network in this phase, so TAP is not a universal, scheme-neutral identity layer, and the public reference implementation is a sample rather than a conformance-complete implementation.[3] Other Visa Intelligent Commerce components can record consumer approval, restrictions and spending limits, and those should not be attributed to the agent-recognition signature.

Visa's TAP announcement cites a rise of more than 4,700 percent in AI-driven traffic to US retail sites.[3] The underlying Adobe measurement covers referral traffic from generative AI sources in July 2025 against July 2024. It does not measure autonomous purchases, payment volume, sales, deployed agents or protocol adoption.[4]

4.2 Mastercard Verifiable Intent

Mastercard announced Verifiable Intent on 5 March 2026 as an open trust layer co-developed with Google, aligned with Google's Agent Payments Protocol and with Universal Commerce Protocol, and described as protocol agnostic.[5] The public specification and reference SDK are available, with a draft version dated 18 February 2026.[6]

The mechanism is layered credentials. An issuer signs a first-layer credential carrying the user's public key, the user signs a second layer including a hash of that credential, autonomous mandates bind the delegation to an agent public key, open payment mandates can reference an exact checkout disclosure through a conditional transaction hash, and final checkout and payment credentials are linked by a hash that must match the payment transaction identifier.[6]

This can establish that the credential layers and the referenced checkout are linked, that the expected keys signed them, and that disclosed constraints were not altered. It does not establish that the human was authenticated to any particular assurance level, that instructions were correctly translated, that merchant-supplied data is truthful, that a credential was used once, or that execution produced the claimed external result. The specification is explicit that transaction-count and budget enforcement cannot be performed cryptographically by the credential scheme alone.[6] Some properties of bounded authority are inherently stateful and cannot be pushed into a signature, which Section 8 builds on.

4.3 Ant International Agentic Mobile Protocol

AMP is an application-layer framework for agentic payments involving wallets, super-apps and mobile interfaces, positioned above existing payment and identity systems rather than replacing them.[7] Its KYA process includes due diligence, agent verification and applicable anti-money-laundering or sanctions checks, current applicability is limited to platform agents, and the Alipay+ credential provider governs the downstream agent lifecycle, while merchant discovery, pricing, fulfilment, settlement rules, institutional fraud models and model inference are out of scope.[7] AMP spans more of the identity, delegation and payment workflow than TAP, within one payment ecosystem, and does not supply a general cross-domain authorisation model.

4.4 AP2 and UCP

AP2 separates mandate delegation from action authorisation. Open mandates bind authority to an agent proof-of-possession key, and closed mandates bind a concrete checkout and payment.[8] That is the same separation this paper makes between a standing grant and a per-action decision. UCP provides commerce capability negotiation, checkout state, account linking and transport, and its AP2 extension carries signed mandate evidence, while base UCP context carrying an intent field is descriptive context about a shopping session rather than purchase authority.[8]

4.5 Four things called intent

Across these specifications, the word intent refers to at least four different objects.

A design that treats a field named intent in one layer as if it carried the meaning of another will grant more authority than anyone agreed. The rest of this paper uses intent in the fourth sense and, where stated, the first, and reserves authorisation for the fifth.

5. From natural-language intent to an enforceable grant

5.1 Instructions are evidence

A user's instruction is a statement of desired outcome, written in a language that tolerates ambiguity, under assumptions the user did not write down. Book me a hotel in Dublin under EUR 300 carries unstated conditions about dates, cancellation terms and the fact that only accommodation was ever in question.

That instruction should be retained, hashed and referenced as evidence of intent. It should not be the thing an enforcement point evaluates, because an enforcement point evaluating free text is a language model, which returns us to the position where adversarial text can change what is permitted.

The translation step is therefore a compiler from instruction to typed grant, and the compiler is a policy-relevant artifact in its own right. It should be versioned, its output should be shown to the user in the cases that matter, and it should fail towards narrowness: when the instruction underdetermines a constraint, choose the narrower interpretation, ask, or escalate for approval. Guessing wide is how a request to book a hotel becomes authority to buy anything from anyone. The recommendation to translate natural-language intent into deterministic policy appears in the OpenID Foundation community work on agent identity.[11]

5.2 A typed authority grant

The enforceable object is a structure of the following shape. Field names are illustrative; the structure matters more than the spelling.

Grant = {
  grant_id,
  issuer,
  root_principal,
  actor,
  holder_key,
  audience,
  permitted_actions,
  resource_constraints,
  argument_constraints,
  purpose_or_task,
  budgets,
  valid_from,
  valid_until,
  delegation_depth,
  redelegation_allowed,
  risk_tier,
  obligations,
  parent_reference,
  policy_epoch,
  intent_evidence_reference
}

Three fields carry more weight than their size suggests. Purpose binds the grant to a task rather than to a period of time, which is the model set out in the workflow authorisation literature of the 1990s, where authority activates for the execution of a task and expires with it.[23] A grant that says accommodation booking for trip 4471 is narrower than the same constraints without a purpose, because purpose lets a decision point reject an action that satisfies every numeric bound while having nothing to do with the task. Obligations are conditions the enforcement point must discharge, such as notifying the principal, writing a receipt to a named ledger, requiring two-person approval above a threshold, or applying a data-minimising transform; they travel with authority and may only be strengthened by delegation. Policy epoch records the policy version under which the grant was issued, which is what makes the stale-authority detection in Section 8 possible.

5.3 What determinism buys

The model decides which hotel, and the authorisation system decides what may be done at all. Allowing probabilistic reasoning to determine its own limits removes the only component that behaves predictably under attack. This is also why the grant must be evaluable without the model: if checking a constraint requires interpreting free text, the constraint is advisory.

6. Authority is a partial order

6.1 The invariant

For every delegation edge in the system:

Authority(child) <= Authority(parent)

Read as: the child's authority must be contained within the parent's, along every dimension, at the moment of issue and at the moment of use. Delegation may preserve authority or reduce it, and may not add anything.

This is the capability-security property, stated for agents.[18][19][20] Several 2026 agent-specific proposals state it again.[25] It is worth stating explicitly in an operating model because handing a child agent a general-purpose credential from a secret store gives it whatever authority that credential carries, regardless of the nominal task.

The title states the direction of travel. The enforceable rule permits equality where a task requires it and prohibits expansion on every delegation edge.

6.2 The dimensions

Containment has to hold on each dimension below, and a system that checks some and ignores others is not attenuating.

6.3 Why subset comparison of JSON is insufficient

A common implementation compares the child's permission document with the parent's and accepts it if every key and value appears in the parent. This fails in predictable ways. Absence is not restriction, so a child that omits a constraint the parent set is broader unless omission inherits the parent's value. Wildcards and ranges are not string comparisons: a child asking for region eu-star is broader than a parent limited to eu-west-1, and textually neither contains the other. Taxonomies need semantics, because whether a merchant category or a clinical data class is narrower than another requires the type's own rules. Numeric comparison needs units and direction, since a limit of 500 is narrower than 1,000 on spending and broader on retry counts. Obligation sets invert, so subset logic would accept a child with fewer obligations. Action verbs carry implicit power, and a grant to update a policy document may confer more real authority than a grant to delete one record.

RFC 9396 makes this explicit for structured authorisation details. It provides the representation and deliberately does not provide a generic algorithm for comparing arbitrary authorisation detail types.[15] Each type must define its own containment rule, which in practice means a registry: every authority type needs a declared containment function, an owner, tests, and a default, and the default for an unknown type must be that containment cannot be established, so delegation of that type fails. Macaroons make added restrictions cryptographically cumulative through append-only caveats while leaving the meaning of each caveat to the application.[18] SPKI formalised delegation and the intersection of authorisation and validity across certificate chains three decades ago, and left permission semantics application-defined for the same reason.[19] The semantics are the work.

7. Graphs are harder than chains

Chain attenuation is well understood. A linear sequence of grants, each narrower than the last, with a verifier that walks the chain, is a solved problem in several credential systems.[18][19][25] Agent systems do not produce chains. They produce directed graphs that change during execution: a planner spawns several workers, workers call shared services, services call other agents, results converge, and some participants belong to other organisations.[10][12]

Recent preprints address capability budgets, branch handling and monotonic authority across agent chains.[26] The less settled operational questions concern how those mechanisms compose at graph forks and joins, under concurrent use, and across administrative domains with different policy vocabularies.

7.1 Fan-out and budget conservation

A parent holding a cumulative budget of GBP 2,000 delegates to two children. If each child receives a grant carrying GBP 2,000, the system now contains GBP 4,000 of executable authority, and each child grant individually satisfies the containment test in Section 6. Per-edge attenuation is insufficient for consumable dimensions, meaning those where use reduces what remains: spend, message counts, rows exported, API calls, compute quota, records modified. Permitted actions and resource scopes can be duplicated across branches without expanding total authority. Consumable dimensions cannot.

Four approaches work, and a system should state which it uses. Accountable partition divides the budget into non-overlapping portions at issue time. Shared reservation has child grants reference a common budget identifier and reserve before acting. Serialisable admission routes all actions against a budget through one admission point. Lease-based allocation gives children short renewable leases on portions of the budget, paired with a hard ceiling and reconciliation. The first is verifiable offline and wasteful when demand is uneven; the middle two are correct under concurrency and introduce a coordination dependency; the last suits high-volume low-value actions.

The property to test is conservation: the sum of authority executable across all live descendants of a grant, at any instant, must not exceed the parent's remaining budget. ChainCaps addresses capability-budget intersection across composed tool flows, Bounded Agents models multidimensional budgets and accumulated state, and CAPMAS applies Macaroon-style attenuation to branches in multi-agent delegation.[26] This paper treats conservation as an implementation-neutral property that each allocation method must demonstrate.

7.2 Fan-in and the union problem

An agent that receives authority through two paths creates two distinct hazards.

The first is static combination, where one proposed action requires authority from several roots. Three resolutions are acceptable. Path selection has the action nominate exactly one authority path, and the decision is made against that path alone; this is the default. Nominated intersection lets an action name several paths and receive the intersection of their authority. Explicit combination has a principal entitled to hold both authorities issue a new grant covering the combined action, making the combination visible, attributable and revocable.

The second is sequential combination. Suppose an agent holds a finance grant permitting payment initiation up to GBP 5,000 and a procurement grant permitting vendor-record modification. It changes a vendor's bank details under the procurement path, then pays the vendor under the finance path. Each action is individually authorised against one path, so path selection alone permits the sequence.

Sequential combination requires task-level separation of duties. The set of independent roots available to a task is fixed when the task starts. The decision point evaluates the task's action history as well as the proposed action and denies a sequence that combines authorities the roots did not permit to operate together. Proceeding requires a new combined grant from a principal entitled to hold both authorities, or a separate approved task whose purpose and evidence make the combination explicit.

Combination must never be implicit. Relationship-based authorisation systems show that union, intersection and exclusion can all be evaluated efficiently at scale, which removes the performance excuse for taking the union by default.[21] For delegated authority arriving from independent roots, union is the wrong default, whether it occurs in one action or across a sequence.

A related hazard is the shared worker. An agent process serving many tasks concurrently must not let authority from one task leak into another, so authority binds to a task context rather than to a process, and the enforcement point sees the task's authority path rather than the worker's accumulated set.

7.3 Cycles and repeated delegation

Graphs contain loops. Agent A delegates to B, which calls a shared service, which routes work back to A, and without care each traversal can re-issue authority and reset counters.

Depth counters alone do not prevent this, because a loop that decrements depth still permits repeated execution until depth is exhausted, and a loop that re-roots authority does not decrement at all. Three controls are needed together: a monotonically decreasing depth; a path identifier recording the ordered sequence of delegation edges, so a cycle is detectable as a repeat; and a per-path budget so that traversal consumes something. Actions should also carry an idempotency key derived from the task and the action digest. Repeated delegation to the same actor needs its own rule: the same grant received twice must not double a budget, and a narrower grant must not silently replace a broader one held for a different task.

7.4 Concurrency

Budgets, counts and approvals are mutable state under concurrent access, so the familiar failure modes apply: two branches read a remaining budget of GBP 500 and each approves GBP 400; a revocation lands while actions are in flight; an approval granted for one proposal is consumed by another.

The controls are ordinary transactional engineering: reservations rather than read-then-write, serialisable isolation on the counter, idempotency keys so retries do not double-spend, explicit compensation for actions that cannot be rolled back, and defined behaviour for in-flight work when revocation arrives, which should default to abort. Reservations need a lifecycle of their own: reserve, confirm on successful execution, release on failure, expire after a bounded period, and reconcile against the executing system's records. Unreconciled reservations are a leak, and the reconciliation job is part of the control rather than an operational nicety.

7.5 Multiple administrative domains

When a path crosses an organisational boundary, a second policy engine is involved and both have legitimate authority over the outcome. The default should be conjunctive: an action proceeds when the delegating domain permits it and the executing domain permits it, each evaluating against its own policy, its own view of the authority path, and its own state.

Translation between vocabularies is where authority expands accidentally, because mappings between permission sets are rarely exact. Translation may narrow and may not widen: if a source constraint has no target equivalent, the mapping must deny or fall back to the narrowest target constraint that is certainly implied. A mapping that turns an unmatched constraint into an unconstrained target is an expansion, and it will be invisible because both sides can show a valid grant.

Cross-domain designs also need agreement on how a resource verifies which path was used, which signals are accepted from the other domain and at what weight, how revocation propagates and within what period, how evidence is exchanged without disclosing more than necessary, and what happens when the domains disagree. A KYA-style shared signal fits precisely here: an input, weighted by the receiving domain, into a decision that the receiving domain still makes.[1]

7.6 Graph hazards and the invariant each requires

8. Every consequential action needs a current decision

8.1 Standing grants and per-action decisions

A grant issued at the start of a task describes authority as it was understood then. By the time an action executes, the budget may be partly consumed, an ancestor grant may have been revoked, the policy may have changed, or the user may have withdrawn consent. A standing grant is therefore an input to a decision rather than the decision, and for each consequential action the decision point evaluates the actor and its authentication, the complete authority path from root to actor, the canonical action and its exact arguments, the target resource, current policy and its version, current budgets and outstanding reservations, approval state, revocation state, and environmental context.

Consequential should be defined by the deploying organisation rather than assumed. A workable definition covers actions that move value, change state outside the agent's workspace, disclose data beyond an established boundary, are irreversible or expensive to reverse, affect other people, or change authority itself. Reading a document the agent already has authority to read, inside a task, is not consequential. Emailing that document to an external address is.

Verifiable Intent's security model makes the supporting argument from the credential side: transaction counts and aggregate budgets cannot be enforced cryptographically by the credential scheme alone.[6] Stateful properties require a stateful decision.

8.2 Component placement

The established access-control architecture applies without modification.[13] The policy decision point evaluates and returns a decision. Policy information points supply attributes: budgets, reservations, revocation status, risk scores, certification status, KYA signals. The policy administration point manages policy and its versions. The policy enforcement point applies the decision where the side effect occurs.

Two placement rules matter for agents. The decision point must not sit inside the agent process, because an agent that can rewrite its own decision is not being authorised. The enforcement point must sit at the resource or its gateway, because an enforcement point in the agent's own client library is a suggestion.

SAFR's disposition engine is a worked example of this architecture in a sector framework.[2] The Agent Action Decision Protocol Internet-Draft describes the same separation between standing capability and stateful authorisation of an exact action at a particular time, including budgets, reservations, approval lifecycle, idempotency and obligations; it is an individual draft and a work in progress rather than an endorsed IETF standard.[24]

8.3 Fail-closed, and what to do about availability

The default on an indeterminate answer must be denial. If the decision point is unreachable, the state authority is unavailable, revocation status is unknown, an authority type has no containment function, or the policy version cannot be established, the action does not proceed.

The practical objection is availability, since a decision point that is down stops all work. Three mitigations bound the damage when that invariant is suspended, and each requires the exception to be declared in advance. Tier by risk, so that low-risk, reversible, non-consumable actions may proceed on a cached decision with a bounded staleness window and a hard ceiling, while high-risk and irreversible actions never do. Pre-authorise narrow envelopes, so that a bounded set of low-value actions can proceed during an outage and be reconciled afterwards; the envelope is itself a grant and obeys the same containment rules. Degrade to escalation, routing to human approval the subset of work that justifies the cost and queueing the rest. Each of these decides how much unreviewed authority an organisation is willing to hold during an outage, and making that explicit is the point.

9. Bind the permit to the action

A decision that is not bound to a specific action can be reused for a different one. The requirements below are the difference between a permit and a bearer token with a short life.

Canonical action and argument digest. The permit carries a hash of the canonical serialisation of the operation and its arguments. Canonicalisation rules are defined once and shared by the decision point and the enforcement point, covering field ordering, encoding, numeric representation, defaulting and normalisation. The enforcement point recomputes the digest from the request it is about to execute and rejects any mismatch.

Audience. The permit names the resource server, tool or rail entitled to accept it. Resource indicators provide this mechanism in the OAuth setting, preventing a permit obtained for one service being replayed at another.[16]

Holder binding. The permit is usable only by the party holding a specific key, and DPoP provides sender-constrained tokens through proof of possession.[17] Its boundary matters: it does not normally bind the request body, so it does not by itself prevent a holder presenting a valid proof alongside different arguments, and subverted code can still use the legitimate key. Payload-level binding through the argument digest is the complement.

Short lifetime, nonce and idempotency. Lifetimes measured in seconds for high-value actions. A nonce prevents replay, and an idempotency key lets the executing system recognise a retry rather than perform the operation twice. The permit also states how many times it may be presented and under what failure conditions, so that a network timeout does not become two payments.

Material-change reauthorisation. Any change to a material parameter invalidates the permit. Material is declared per action type: amount, recipient, resource identifier, destination, quantity, data classification, irreversibility. A change to a request identifier is not material; a change to a destination account is.

What the existing OAuth mechanisms contribute and do not contribute is worth stating plainly, because they are often cited as if they closed the gap.

Together they provide much of the transport-level machinery. The action binding, the semantic containment, the stateful budget and the execution evidence sit above them.

The Agent Operation Authorization Internet-Draft defines structured action proposals, confirmed operation tokens, intent evidence and agent-to-agent delegation.[25] It is individual work in progress without IETF endorsement, and it further demonstrates that action binding and delegation lineage are active areas rather than missing concepts.

10. Enforcement must sit outside model reasoning

An instruction in a system prompt is not a control. An agent that checks its own plan against its own understanding of its limits is one persuasive paragraph away from a different understanding. Complete mediation means the check happens where the effect occurs, in code the agent cannot modify, on inputs it cannot forge.[20]

MCP servers and gateways. The specification profiles OAuth for HTTP transports, treats the server as a resource server, requires protected-resource and authorisation-server discovery, requires resource indicators and audience validation, and prohibits forwarding an inbound token to an upstream API.[9] That prohibition is the confused-deputy defence stated normatively. The specification does not standardise recursive delegation, task-bound authority, exact argument approval, semantic containment, signed receipts or an audit schema, and authorisation is optional with local transports outside its scope.[9] Those gaps are where a deployment adds its own decision point.

A2A systems. The protocol defines agent discovery, messaging, task lifecycle, advertised authentication schemes and an AUTH_REQUIRED state that can pause work for credentials or human approval.[10] It does not define the delegated credential, attenuation, expiry, revocation, exact operation constraints, or a binding between an approval and later messages. A deployment still has to carry and enforce those semantics across the task graph.

API gateways and service meshes. For plain HTTP APIs, the gateway holds the permit check, the digest comparison and the obligation discharge. The failure mode to avoid is a gateway that authenticates the agent and then forwards the user's own credential unchanged, which reproduces ambient authority with extra steps.

Databases. A proxy or policy-aware access layer enforces table, column, row, row-count and export constraints, because a connection string is an unbounded grant.

Cloud control planes. Admission controllers, service control policies and resource policies enforce infrastructure actions, evaluating the request as submitted, independent of whatever plan produced it.

Operating systems and runtimes. Sandboxes, syscall filters, filesystem scoping and capability-secure runtimes bound what an agent process can do regardless of what it decides to do.[20] This layer catches the actions nobody modelled.

Two anti-patterns are common enough to name. The first is the agent that holds a broad credential and calls a policy library in its own process before using it, so the check and the authority share a trust domain and compromise removes both. The second is human confirmation inside the agent's own interface, where the text shown to the user is generated by the component that wants approval. Confirmation belongs in a channel the agent does not control, showing the canonical action as the enforcement point will receive it.

11. Evidence must connect intent to outcome

11.1 The chain

A governed action should leave linked records covering:

intent -> delegation path -> proposal -> decision
      -> obligations and approval -> execution -> observed result

Each record references the previous by stable identifier or hash, so the set can be verified as a whole. A useful record set contains a reference to the intent evidence and its hash; the ordered authority path with each grant's identifier and issuer; the canonical action and argument digest; the policy version and the decision, including the constraints evaluated and state values read; the reservation identifier and amount; the approval, its method, assurance level and expiry; the obligations and their discharge; the enforcing component; the external execution identifier; and the observed result.

11.2 Why the observed result matters

The gap most audit systems leave is between the decision and the world. A log line saying allowed proves that a decision point returned a permit. It does not prove that the executed operation matched the permit, that it succeeded, or that its effect was the intended one.

Reconciliation closes it. The evidence chain carries the identifier the executing system produced: the payment reference, the commit identifier, the message identifier, the resource identifier, the row count, the ticket number. A reconciliation process compares permits issued against operations recorded by the executing system and surfaces three discrepancy classes: permits with no matching execution, executions with no matching permit, and executions whose parameters differ from the permit. The third indicates a real control failure, and it is invisible to any system that stops at the decision.

Verifiable credential mechanisms provide much of the machinery for issuing, verifying, checking status and expressing evidence.[22] Credential verification establishes that a statement was made by the expected issuer. It does not make the statement true, and it is not an authorisation decision.[22]

11.3 Privacy minimisation

A complete delegation and intent record is sensitive. It exposes what a user asked for, which organisations were involved, what limits they set, what an agent proposed, and what was declined. Cross-domain exchange amplifies this, because the counterparty needs enough to make its own decision and should not receive the user's original prompt, the full delegation topology, or unrelated parts of a budget.

Four practices keep evidence proportionate. Store hashes and references in preference to content. Use selective disclosure so a verifier receives only the predicates it needs, which is the pattern the layered credential schemes already use.[6][22] Set retention limits per record class. Apply access control and logging to the evidence store itself, since it is a map of who authorised what. The goal is independent verifiability: a third party should be able to confirm that a decision was consistent with a grant and a policy version without reading the conversation that produced the task.

12. Applying the model beyond commerce

The same grant structure applies across domains. What changes is which dimensions carry the weight and where the enforcement point sits.

MCP tool invocation. The grant names permitted tools, argument constraints per tool, and the servers in scope, enforced at the MCP server or a gateway in front of it, with audience validation and no forwarding of inbound tokens upstream.[9] Dominant dimensions: actions, arguments, audience. The common failure is a server that lets any authenticated client call any tool with any arguments.

Software delivery and release authority. The grant distinguishes reading a repository, opening a pull request, merging, tagging, publishing a package and deploying to an environment. Dominant dimensions: actions, resources, obligations, reversibility. Publishing and deployment are irreversible in practice, so they carry approval obligations that reading does not, and the Amazon Q case shows the cost of a token whose reach exceeded its task inside a pipeline with publishing authority.[28]

Cloud resource management. The grant names accounts, regions, resource types, tags, and limits on instance counts and spend, enforced in the control plane. Dominant dimensions: resources, budgets, reversibility, risk tier. Deleting a stateful resource and creating a public network path warrant escalation rather than automatic approval.

Email and communication. The grant names permitted recipients or recipient classes, internal against external, attachment and data classification rules, and volume limits. Dominant dimensions: arguments, budgets, obligations. External recipients and classified attachments are the escalation triggers, because an outbound message is irreversible.

Database access. The grant names tables, columns, row predicates, maximum result rows, permitted statement classes and export destinations. Dominant dimensions: resources, arguments, budgets. A read-only credential is a weak control when the risk is bulk extraction rather than mutation.

Browser automation. The grant names permitted origins, permitted form submissions, whether authenticated sessions may be used, and which interactions are allowed. Dominant dimensions: resources, actions, purpose. This is the hardest environment, because the session carries the user's full ambient authority at every origin it reaches and page content is adversarial input by default.

Healthcare workflows. The grant names patient cohorts, encounter identifiers, data categories, permitted purpose under the applicable legal basis, and whether results may leave a jurisdiction. Dominant dimensions: purpose, resources, obligations, time. Purpose binding does most of the work, since the same read is permitted for direct care and prohibited for secondary analysis.

Cross-agent work. When one organisation's agent delegates to another's, both domains evaluate, translation may only narrow, and evidence crosses the boundary in minimised form.[7][10] Dominant dimensions: delegation depth, audience, obligations, translation fidelity.

13. A practical operating model and conformance tests

13.1 Nine implementation steps

1. Define authority types. Enumerate the consequential actions. For each, declare the argument constraints, containment function, reversibility class, material parameters, canonicalisation rule and owner. Register unknown types as non-delegable.

2. Issue roots. Establish which principals may issue root grants, how they authenticate, what assurance each risk tier requires, and how issue is recorded. Compile instructions into typed grants, retain the instruction as intent evidence, and show the compiled grant to the user for anything irreversible or above a threshold.

3. Delegate. Issue child grants by containment check rather than by copying a credential, recording the parent reference, path identifier and remaining depth. Refuse delegation of any type without a containment function.

4. Decide. Run a decision point outside every agent process, evaluating actor, path, canonical action, arguments, resource, policy version, budgets, reservations, approvals, revocations and context. Return a permit, denial or escalation, and record the inputs.

5. Reserve. For consumable dimensions, reserve against a state authority that serialises the counter. Confirm on success, release on failure, expire on timeout, and reconcile on a schedule.

6. Enforce. Place the enforcement point at the tool, gateway, database proxy, control plane or kernel. Verify audience, holder binding, lifetime, nonce and argument digest against the request as it will be executed. Discharge obligations. Fail closed.

7. Report. Emit linked evidence for intent, delegation path, proposal, decision, approval, obligations, execution and observed result, with external identifiers from the executing system.

8. Revoke. Support revocation of a grant, subtree, actor, task or root. Define propagation time, cache staleness bounds, in-flight behaviour and a kill switch that stops a task family. Test propagation rather than assuming it.

9. Audit. Run reconciliation, review denials for brittleness, review escalations for missing constraints, and re-run the conformance tests after every change to policy, types or topology.

13.2 Conformance tests

Each test states a setup and the required outcome. A system that cannot demonstrate these has an operating model on paper only.

Useful indicators for a programme review: the share of consequential actions passing a decision point outside the agent process; the share of authority types with a containment function and tests; reservation reconciliation discrepancy rate; median revocation propagation time measured rather than configured; and the share of executions with a complete evidence chain.

14. The strongest counterargument

The strongest case against this model is that it buys a small reduction in risk with a large increase in complexity, and that the complexity itself creates outages, delays and cost.

Complexity. A decision point, a state authority, a type registry with containment functions, reservations, evidence storage and reconciliation is a substantial control plane. Every component is a dependency that can fail, and a failure in the authorisation layer stops legitimate work. An organisation running a summarisation assistant over public documents would be building infrastructure disproportionate to its risk.

Latency. A round trip to a decision point before every consequential action adds delay, and a reservation against a serialised counter adds more. In interactive workflows that is visible to users, and in high-volume automation it can be the dominant cost.

Policy brittleness. Narrow authority produces false denials. An agent blocked from a legitimate action is a support ticket, and enough of them produce pressure to widen grants until the control is decorative. Over-restriction can be worse than moderate authority with strong monitoring, because it drives users towards unmanaged tools.

Intent-translation ambiguity. A user who says book me somewhere nice near the conference has not specified a budget, a neighbourhood or a cancellation policy. Compiling narrowly creates friction, and compiling widely defeats the purpose. This is a genuine limit rather than an engineering gap.

Existing standards suffice for bounded cases. The OpenID Foundation community work on agent identity says directly that existing standards can secure many simpler, bounded agents.[11] A single-purpose agent with a fixed tool set, a scoped OAuth client, audience-restricted tokens and no ability to delegate does not need any of this. Building an elaborate authority system before the product exists is also a familiar way to spend a year and ship nothing, encoding guesses about actions and risks the product does not turn out to have.

The proportionate answers are these. Tier by consequence, so the full model applies to irreversible, high-value, externally visible or privacy-sensitive actions while reversible, low-value, internal actions run on standing grants with monitoring and periodic review. Spend additional decision latency where consequence justifies it, while high-volume low-value actions use leases and local ceilings with asynchronous reconciliation. Treat denials as a product signal, routing each to an escalation path a human can resolve quickly and feeding denial patterns back into grant design, because a control with no escalation path becomes a control that is switched off. Accept the ambiguity and bound it, narrowing and confirming where the instruction underdetermines the grant, which also produces the approval evidence the model needs.

Adopt incrementally. The ordering that produces value earliest is evidence first, because it makes current behaviour visible; then one enforcement point in front of the highest-consequence action class; then typed grants for that class; then delegation containment; then graph invariants when the topology actually becomes a graph. An organisation with a single agent and no agent-to-agent delegation should stop once it has typed grants for its highest-consequence action class.

15. What this paper does not claim

It does not claim that Know Your Agent is useless. Attribution to a validated operator, common certification and continuous monitoring are valuable, and they address problems that authorisation does not.[1] They answer questions about the agent rather than about the action.

It does not claim that existing OAuth and enterprise identity infrastructure is universally insufficient. For bounded, single-purpose agents without delegation, current standards are adequate, as the OpenID Foundation community work states.[11]

It does not claim novelty for capability security, least privilege, complete mediation, task-bound authority, delegation chains, scope intersection, attenuation, proof of possession, policy decision and enforcement separation, or signed receipts. These are established in SPKI, Macaroons, object-capability systems, workflow authorisation and access-control architecture.[13][18][19][20][23] Recent agent-specific work also addresses action permits, attenuation and branch handling.[24][25][26] The contribution here is an operating model that joins those controls across graph forks, static and sequential joins, concurrency, administrative boundaries and testable conformance.

It does not claim that every agent deployment needs per-action authorisation infrastructure. A low-risk assistant with reversible actions and a narrow tool set does not, and building it anyway is a poor use of engineering time.

It does not claim that natural language can always be compiled unambiguously into a grant. Some instructions underdetermine the constraints, and the correct response is to narrow, ask or escalate.

It does not claim that payment industry activity proves general adoption. TAP applies to the Visa network in its current phase, AMP currently applies to platform agents in one ecosystem, and Verifiable Intent is a draft specification with a reference implementation.[3][6][7] Publication of a protocol is not deployment, interoperation or evidence of effectiveness.

It does not treat Internet-Drafts or preprints as standards or as proven deployments. The drafts cited are individual submissions, works in progress without IETF endorsement, and they may be replaced or expire.[24][25] The academic work cited for graph budgets and capability propagation consists of preprints whose claimed proofs and benchmarks should not be taken as peer-reviewed results.[12][26]

It does not claim that monotonic attenuation alone establishes safety. A perfectly attenuating system can still authorise a harmful action that was inside the root grant, and a root grant that is too broad makes every downstream check irrelevant.

It does not claim that identity, reputation and fraud controls become unnecessary. A decision is better when it can consider who the operator is, how the agent has behaved, and what current risk signals say.[1][2]

It does not claim any industry-wide failure rate. The incidents and demonstrations referenced illustrate failure modes.[27][28][29] They do not support a base rate, and one of them is a research demonstration rather than a production breach.[29]

Conclusion

The question that determines whether the gift card purchase completes is not whether the agent is genuine. It is whether anything between the user's instruction and the payment rail was in a position to say no, on the basis of something more durable than a model's reading of a web page.

The payments industry is converging on that question from one direction. KYA improves what a network knows about the caller, SAFR governs the decision to act, and the commerce protocols are building mandate structures that separate a standing delegation from a specific transaction.[1][2][6][8] The same question arrives in software delivery, cloud operations, data access, communications, browser automation and clinical workflows, where no card network is convening a framework and the deploying organisation has to answer it alone.

The operating model here is a synthesis of established components: a typed grant with an explicit root, semantic containment on every delegation edge, stateful per-action decisions, enforcement at the point of effect, and evidence that reaches the observed result. Recent work addresses parts of the graph problem, especially attenuation and branch budgets.[25][26] The remaining operational questions concern how these controls compose. Budgets have to be conserved when work fans out. Authority from independent roots must not silently merge in one action or across a sequence. Cycles must consume something. Concurrency must reserve rather than read and hope. Translation across administrative boundaries may narrow and may never widen.

Those properties are testable, which is the reason for Section 13. An organisation that can demonstrate C1 to C13 on its own system has something better than an architecture diagram. An organisation that cannot has agents whose real authority is whatever their credentials can reach.

When agents delegate, authority must shrink. Everything else is the engineering required to make that true under load, under attack, and across organisations that do not trust each other.

Appendix A: Delegated authority record template

# Delegated authority record

Record ID:
Task ID:
Date:
Issuing organisation:
Executing organisation (if different):

## Root and principals

Root principal:                       [person | organisation | institutional authority]
Root authentication method:
Assurance level:
Root grant ID:
Root issue timestamp:
Entitlement basis for root issue:

## Actor

Agent or workload identity:
Agent instance ID:
Operator:
Operator attribution or certification signal:  [source, status, date]
Holder key (thumbprint):
Key custody:                          [HSM | KMS | software | delegated]

## Grant

Grant ID:
Parent grant ID:
Issuer:
Audience:
Permitted actions:
Resource constraints:
Argument constraints (per action):
Purpose or task binding:
Risk tier:                            [reversible | costly to reverse | irreversible]
Budgets:
  Per action:
  Cumulative:
  Consumable dimensions:
  Budget identifier (shared state):
Validity:
  Valid from:
  Valid until:
  Task-bound expiry:                  [yes | no]
Delegation:
  Remaining depth:
  Redelegation allowed:               [yes | no]
  Permitted delegates:
Obligations:
  Notification:
  Approval thresholds:
  Data minimisation:
  Receipt destination:
Policy epoch at issue:

## Authority path

Ordered edges (root to actor):
Path identifier:
Authority paths available to this task:
Path nominated for this action:
Combination basis:                    [single path | nominated intersection |
                                       explicit combined grant ID | none required]
Path verified by:                     [component]
Containment checked per dimension:    [actions | resources | arguments | purpose |
                                       time | budgets | depth | risk | obligations]
Containment function versions used:
Cross-domain translation applied:      [yes | no]
Translation mapping version:
Unmapped constraints and disposition:

## State and reservations

State authority:
Budget remaining at decision:
Reservation ID:
Reserved amount or count:
Reservation status:                   [reserved | confirmed | released | expired]
Reservation expiry:
Concurrency control:                  [partition | shared reservation |
                                       serialisable admission | lease]
Reconciliation run ID and date:

## Proposed action

Proposal ID:
Canonical action:
Canonicalisation rule version:
Arguments (canonical form):
Argument digest:
Target resource:
Material parameters declared:
Intent evidence reference and hash:
Intent compiler version:
Proposal timestamp:

## Decision

Decision point:
Decision:                             [permit | deny | escalate | observe]
Policy version:
Constraints evaluated:
State values read:
Context signals used:
Reason codes:
Decision timestamp:
Decision record hash:

## Approval

Required:                             [yes | no]
Approver identity:
Approval method and assurance level:
Approved operation and parameters:
Approval channel:                     [out of band | agent interface | ticketed]
Approval expiry:
Permitted retries:
Approval record hash:

## Permit binding

Permit ID:
Audience:
Holder binding method:
Bound argument digest:
Issued at:
Expires at:
Nonce:
Idempotency key:
Maximum presentations:
Obligations to discharge at enforcement:

## Enforcement and execution

Enforcement point:
Digest verification result:           [match | mismatch]
Obligations discharged:
Execution system:
External execution identifier:
Execution timestamp:
Execution status:                     [succeeded | failed | partial | unknown]
Observed result:
Reconciled against executing system:  [yes | no] Date:
Discrepancy class if any:             [permit without execution |
                                       execution without permit |
                                       parameter mismatch]

## Revocation

Revocation events affecting this path:
Revoked by:
Scope:                                [grant | subtree | actor | task | root]
Propagation target time:
Measured propagation time:
In-flight action behaviour:           [abort | complete | quarantine]
Kill switch invoked:                  [yes | no]

## Evidence and retention

Evidence chain complete:              [yes | no]
Records linked: intent, delegation, proposal, decision, approval,
enforcement, execution, result
Selective disclosure applied:         [yes | no] Method:
Fields shared across domain boundary:
Retention period per record class:
Access restrictions on evidence store:
Independent verification possible:    [yes | no] Method:

Appendix B: Delegation and action-authorisation review checklist

Authority types

• Is every consequential action enumerated with an owner?
• Does every authority type declare a containment function, and is it tested?
• Are unknown or unregistered types non-delegable by default?
• Is canonicalisation of actions and arguments defined once and shared by the decision and enforcement points?
• Are material parameters declared per action type?
• Is reversibility classified per action type?

Roots and intent

• Can every consequential action be traced to a root grant and an entitled issuer?
• Is the authentication assurance required for root issue matched to the risk tier?
• Is the user instruction retained and hashed as intent evidence?
• Does the compiler from instruction to grant narrow, ask or escalate when the instruction is underdetermined?
• Is the compiled grant shown to the user before irreversible or high-value actions?
• Is the compiler versioned and reviewed as a policy artifact?

Delegation

• Are child grants issued by containment check rather than by credential copying?
• Is containment checked on all nine dimensions, including obligations and reversibility?
• Does delegation depth decrease, and is redelegation explicitly permitted?
• Is purpose carried and narrowed, rather than dropped?
• Are the parent reference and path identifier recorded on every grant?

Graph properties

• Are consumable dimensions identified and conserved across fan-out?
• Which conservation method is in use: partition, shared reservation, serialisable admission or lease?
• Is implicit union across multiple authority paths prevented?
• Does each action nominate the path it relies on?
• Is the set of independent roots available to a task fixed when the task starts?
• Does the decision point detect sequences that combine authorities across roots?
• Does combining independent roots require a new grant from an entitled principal?
• Are cycles detectable through path identity, and does traversal consume budget?
• Is repeated delegation to the same actor idempotent?
• Is authority bound to task context rather than to a worker process?
• Does cross-domain translation narrow only, and does an unmapped constraint deny?

Decisions

• Does every consequential action receive a current decision from a point outside the agent process?
• Does the decision consider path, action, arguments, resource, policy version, budgets, reservations, approvals, revocation and context?
• Is the definition of consequential written down and reviewed?
• Is the behaviour on indeterminate answers denial?
• Are cached decisions bounded by staleness, risk tier and count?
• Are decision inputs recorded well enough to re-derive the decision?

Permits and enforcement

• Is the permit bound to a canonical argument digest, an audience and a holder key?
• Is its lifetime proportionate to the action's value?
• Does it carry a nonce and an idempotency key, with a stated presentation limit?
• Does a material parameter change invalidate it?
• Does the enforcement point sit at the component that causes the side effect?
• Does any component forward an inbound token to an upstream service?
• Are human confirmations rendered outside the agent's control, showing the canonical action?

State and revocation

• Are reservations used rather than read-then-write?
• Do reservations confirm, release, expire and reconcile?
• Can a grant, a subtree, an actor, a task and a root all be revoked?
• Is revocation propagation time measured rather than configured?
• Is in-flight behaviour on revocation defined and tested?
• Is there a tested kill switch for a task family?

Evidence

• Is there a linked record from intent through to observed result?
• Does execution evidence carry the external identifier from the executing system?
• Does reconciliation surface permits without executions, executions without permits and parameter mismatches?
• Is evidence tamper-evident and stored outside the agent's reach?
• Is selective disclosure used for cross-domain evidence?
• Are retention periods set per record class, and is access to the evidence store controlled and logged?

Assurance

• Have tests C1 to C13 been run against the live system?
• Are they re-run after changes to policy, authority types or delegation topology?
• Are denials reviewed and classified as correct, brittle or missing-constraint?
• Is the proportionality of the control set reviewed against actual product risk?

About the author

Jason Doyle writes about reliable software, observability, incident leadership, applied AI, and practical controls for systems that influence human and organisational decisions. He publishes at jasondoyle.ie and can be contacted at [email protected].

References

1. Ant International, Ant International, Mastercard, and Visa Initiate Collaboration on Know-Your-Agent Interoperability to Scale Agentic Commerce, 10 September 2026, https://www.ant-intl.com/en/news/detail/?id=ant-international-mastercard-and-visa-initiate-collaboration-on-know-your-agent-interoperability-to-scale-agentic-commerce and https://www.businesswire.com/news/home/20260909003891/en/.
2. Monetary Authority of Singapore and industry contributors, Safeguards for Agentic Finance at Runtime, July 2026, with the MAS media release MAS Partners Industry to develop Safeguards for AI Agents in Finance, 3 July 2026, and the BuildFin.ai programme page, accessed 11 September 2026, https://www.mas.gov.sg/-/media/mas-media-library/development/fintech/ai-safr/safr.pdf and https://www.mas.gov.sg/schemes-and-initiatives/buildfinai.
3. Visa, Visa unveils Trusted Agent Protocol for AI commerce, 14 October 2025, with the Trusted Agent Protocol merchant specification and its reference implementation, accessed 11 September 2026, https://corporate.visa.com/en/sites/visa-perspectives/newsroom/visa-unveils-trusted-agent-protocol-for-ai-commerce.html, https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications and https://github.com/visa/trusted-agent-protocol.
4. Adobe, Generative AI-powered shopping rises with traffic to US retail sites, 2025, measuring July 2025 against July 2024, https://business.adobe.com/blog/generative-ai-powered-shopping-rises-with-traffic-to-retail-sites.
5. Mastercard, How Verifiable Intent builds trust in agentic AI commerce, 5 March 2026, https://www.mastercard.com/us/en/news-and-trends/stories/2026/verifiable-intent.html.
6. Verifiable Intent Working Group, Verifiable Intent specification and reference SDK, draft 0.1, 18 February 2026, https://github.com/agent-intent/verifiable-intent.
7. Ant International, Ant International launches open-sourced Agentic Mobile Protocol to drive AI commerce, 28 April 2026, with the protocol repository, https://www.ant-intl.com/en/news/detail/?id=ant-international-launches-open-sourced-agentic-mobile-protocol-to-drive-ai-commerce and https://github.com/ant-intl/AMP.
8. Google, Agent Payments Protocol, and Universal Commerce Protocol, including its AP2 mandate extension, accessed 11 September 2026, https://github.com/google-agentic-commerce/AP2 and https://github.com/Universal-Commerce-Protocol/ucp.
9. Model Context Protocol, Authorization, specification version 2026-07-28, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization.
10. A2A Project, Agent2Agent Protocol Specification, v1.0.0, May 2026, https://a2a-protocol.org/latest/specification/.
11. Tobin South et al., Identity Management for Agentic AI, OpenID Foundation Community Group whitepaper and preprint, arXiv:2510.25819, October 2025, https://arxiv.org/abs/2510.25819.
12. Krti Tallam, Authorization Propagation in Multi-Agent AI Systems, preprint, arXiv:2605.05440, 6 May 2026, https://arxiv.org/abs/2605.05440.
13. Vincent C. Hu et al., Guide to Attribute Based Access Control (ABAC) Definition and Considerations, NIST SP 800-162, January 2014, updated August 2019, https://doi.org/10.6028/NIST.SP.800-162.
14. Michael B. Jones, Anthony Nadalin, Brian Campbell, John Bradley and Chuck Mortimore, RFC 8693: OAuth 2.0 Token Exchange, IETF, January 2020, https://www.rfc-editor.org/rfc/rfc8693.html.
15. Torsten Lodderstedt, Justin Richer and Brian Campbell, RFC 9396: OAuth 2.0 Rich Authorization Requests, IETF, May 2023, https://www.rfc-editor.org/rfc/rfc9396.html.
16. Brian Campbell, John Bradley and Hannes Tschofenig, RFC 8707: Resource Indicators for OAuth 2.0, IETF, February 2020, https://www.rfc-editor.org/rfc/rfc8707.html.
17. Daniel Fett, Brian Campbell, John Bradley, Torsten Lodderstedt, Michael Jones and David Waite, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), IETF, September 2023, https://www.rfc-editor.org/rfc/rfc9449.html.
18. Arnar Birgisson, Joe Gibbs Politz, Ulfar Erlingsson, Ankur Taly, Michael Vrable and Mark Lentczner, Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud, NDSS, 22 February 2014, https://doi.org/10.14722/ndss.2014.23212.
19. Carl M. Ellison, Bill Frantz, Butler Lampson, Ron Rivest, Brian Thomas and Tatu Ylonen, RFC 2693: SPKI Certificate Theory, IETF, September 1999, https://www.rfc-editor.org/rfc/rfc2693.html.
20. Mark S. Miller, Ka-Ping Yee and Jonathan Shapiro, Capability Myths Demolished, technical report SRL2003-02, 2003, https://papers.agoric.com/papers/capability-myths-demolished/.
21. Ruoming Pang et al., Zanzibar: Google's Consistent, Global Authorization System, USENIX ATC, July 2019, https://www.usenix.org/conference/atc19/presentation/pang.
22. World Wide Web Consortium, Verifiable Credentials Data Model v2.0, W3C Recommendation, 15 May 2025, https://www.w3.org/TR/2025/REC-vc-data-model-2.0-20250515/.
23. Vijayalakshmi Atluri and Wei-Kuang Huang, An Authorization Model for Workflows, ESORICS, 1996, and Roshan K. Thomas and Ravi S. Sandhu, Task-Based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-Oriented Authorization Management, IFIP WG11.3, 1997, https://doi.org/10.1007/3-540-61770-1_27 and https://doi.org/10.1007/978-0-387-35285-5_10.
24. Agent Action Decision Protocol, draft-saha-aadp-02, individual Internet-Draft, work in progress, September 2026, https://datatracker.ietf.org/doc/draft-saha-aadp/.
25. Agent Passport System, draft-pidlisnyi-aps-03, 18 July 2026; Agent Operation Authorization, draft-liu-agent-operation-authorization-02, 16 March 2026; Attenuating Authorization Tokens for Agentic Delegation Chains, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026; and Verifiable Attenuated Delegation for AI Agent Chains, draft-asor-wimse-agent-delegation-chain-01, 3 September 2026. All are individual Internet-Drafts and works in progress without IETF endorsement, https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/, https://datatracker.ietf.org/doc/draft-liu-agent-operation-authorization/, https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/ and https://datatracker.ietf.org/doc/draft-asor-wimse-agent-delegation-chain/.
26. ChainCaps, capability budget propagation by intersection across composed tool flows, preprint, arXiv:2605.26542; Bounded Agents, principal chains, multidimensional budgets and blast-radius monotonicity, preprint, arXiv:2608.15888; and CAPMAS, Macaroon-style monotonic privilege intersection and branch handling for multi-agent delegation, preprint, arXiv:2609.06500, https://arxiv.org/abs/2605.26542 and https://arxiv.org/abs/2608.15888 and https://arxiv.org/abs/2609.06500.
27. Microsoft Security Response Center, CVE-2025-32711, the vulnerability publicly described as EchoLeak, 2025, https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32711.
28. Amazon Web Services, security advisory GHSA-7g7f-ff96-5gcw for the Amazon Q Developer extension for Visual Studio Code, 2025, https://github.com/aws/aws-toolkit-vscode/security/advisories/GHSA-7g7f-ff96-5gcw.
29. GitHub MCP Server, issue 844, a public research demonstration of prompt injection from public repository content leading to private repository data exposure, 2025, https://github.com/github/github-mcp-server/issues/844.