Trace every payment through a non-expanding grant path to a principal.
Giving two agents access to the same wallet does not create accountable delegation. It creates two execution paths with indistinguishable authority. If one agent buys an unapproved service, the system may know which key signed the payment and still be unable to prove which principal allowed the purchase.
AI agent delegated payments need an authority graph. Each edge states who delegated to whom, what may be purchased, how much may be spent, when authority expires, whether it can be delegated again, and how usage or revocation changes the remaining grant. Every payment must trace through an unbroken path to a principal, and every child edge must be equal to or narrower than its parent.
Model Five Roles Before Issuing a Grant
The principal owns the economic authority. It may be a person, organization, treasury policy, or governed account. The delegating agent acts under a grant and may pass a subset of its authority onward. The spending agent selects a service and requests payment. The wallet signer controls the key or account that executes an approved instruction. The merchant receives value and delivers the resource.
One component can fill several roles, but the records should keep them distinct. A coordinator agent may be both delegate and spending agent. A smart account may combine policy enforcement and signing. That does not eliminate the need to identify the principal, policy, and purchase that made the signature legitimate.
Represent the system as directed edges:
The graph answers a question that wallet ownership cannot: which chain of authority made this exact purchase permissible?
Treat a Delegation Grant as a Capability Edge
A minimum grant records issuer, subject, grant ID, parent grant, purpose, allowed merchants or service classes, allowed actions, per-payment ceiling, cumulative budget, assets, networks, start time, expiry, maximum delegation depth, re-delegation flag, approval requirements, and revocation reference.
It also needs usage state. The total authority is not the original ceiling forever. Available authority equals the grant budget minus settled spend, active reservations, pending ambiguous payments, and budgets assigned to live child grants. If a parent gives $0.08 to a child, it cannot simultaneously spend that $0.08 itself unless the system explicitly models a shared nonexclusive limit and prevents aggregate overrun.
Bind the grant to an immutable digest and a principal decision record. Natural-language rationale can accompany it, but enforcement should rely on structured fields. A prompt such as “let the verifier buy anything necessary” is not a safe capability.
The grant should name the policy version used at issuance. Later policy changes may invalidate new use without rewriting historical evidence. That distinction supports both revocation and audit.
Follow a $0.30 Nested Procurement Chain
A principal gives coordinator A a $0.30 budget for one research task. Grant G1 allows search, document extraction, and verification services; caps each payment at $0.12; permits two networks; expires in 20 minutes; and allows one level of re-delegation.
Coordinator A spends $0.06 on search. Its remaining uncommitted budget becomes $0.24. It then creates G2 for verification agent B with an $0.08 cumulative limit, a $0.05 per-payment limit, verification-only services, the same task ID, a ten-minute expiry, and no further delegation.
While G2 is active, A has at most $0.16 of uncommitted purchasing power under G1: $0.30 original, minus $0.06 settled, minus $0.08 assigned to B. If B spends $0.05, G2 retains $0.03. When G2 closes and all payments are terminal, the unused $0.03 can return to G1, subject to the parent expiry.
B cannot buy a $0.06 dataset because its per-payment ceiling is $0.05. It cannot classify a translation service as “verification” merely by changing a label; merchant or service identity and capability evidence should support the category. It cannot create G3 because delegation depth is exhausted.
The task can finish with several merchants and signatures. Each payment still retains one explainable path to P.
Enforce Monotonic Attenuation
For every constrained dimension, child authority must be a subset of parent authority:
Amount is not the only dimension. A child with a lower budget and access to a riskier action is broader in an important way. A child that expires later can act after the parent is supposed to stop. A child that permits unrestricted merchants can turn a narrow service grant into general purchasing power.
Validate attenuation when the child grant is issued and again when it is used. Parent state may change between those events. A merchant can leave an allowlist, the parent can be revoked, or another child can consume the available budget.
Policy composition should use intersection. If the principal permits networks A and B, the coordinator permits only A, and the wallet permits A and C, the executable set is A. A downstream agent cannot union permissions from unrelated policies to create broader authority.
Revocation Stops New Authority, Not Settled History
Revocation needs an effective time, issuer, reason, target, and propagation rule. Revoking G1 should normally invalidate G1 and all descendants. Revoking G2 leaves A’s unrelated authority under G1 intact.
Check revocation at grant use, payment preparation, and immediately before signing when feasible. Long-running operations need short-lived execution tokens or another revalidation point; validating only at task start leaves a large exposure window.
An in-flight payment creates a boundary. If it has not been signed or submitted, revocation can stop it. If it is submitted and outcome is unknown, mark its budget reconciling and block replacement spend. If it settled, revocation cannot erase ledger history. The service may still be delivered or refunded according to terms.
Offline delegation trades availability for revocation freshness. A short-lived grant can continue during a control-plane outage and may miss an urgent revoke. High-risk payments may require online policy confirmation. Low-risk actions can accept bounded offline authority.
Compromised keys require separate treatment. Revoking an agent identity or grant prevents future authorized use in systems that consult the registry. It does not rotate a wallet key or recover funds by itself. Wallet controls and incident response remain necessary.
Bind Usage, Retry, and Payment Proof to the Grant Path
Every purchase intent should reference the leaf grant and include the ancestor path or resolvable path digest. The policy service verifies signatures, status, attenuation, remaining budget, expiry, and merchant scope before reserving capacity.
Use a grant-scoped usage ledger. Concurrent agents must not read the same remaining amount and both spend it. Reserve the requested ceiling atomically, then capture, release, expire, or reconcile it. Child-grant budgets count as reserved authority at the parent.
Retries reuse the purchase intent and grant reservation. A timeout is not permission to allocate a second budget. Payment attempts receive child IDs and idempotency keys. Duplicate proofs should map to one entitlement or to duplicate-payment handling.
The final evidence envelope includes principal decision, grant chain, policy evaluation, intent, reservation, wallet signature, payment proof, merchant order, and delivery result. This is more useful than recording “agent B paid” because it explains why B was allowed to pay.
FAQ
Is delegated payment the same as sharing a wallet private key?
No. Key sharing grants broad execution capability and weakens attribution. Delegation should grant structured, revocable authority that a policy or account enforces without exposing an unrestricted key.
Can an agent delegate more budget than it has spent?
It can delegate up to its uncommitted authority. Budgets assigned to active child grants must reduce what the parent can allocate elsewhere, even before the child spends them.
Does revocation reverse a payment already settled?
No. It blocks future authorized use according to the implementation. Settled value requires delivery, refund, dispute, or recovery rules on the relevant payment rail.
Does an ERC-8004 identity prove purchasing authority?
No. Identity can help resolve who an agent is and connect reputation or validation signals. A separate grant or policy must state what that agent may buy and spend.
Should subdelegation be enabled by default?
No. Enable it only when the workflow requires it, cap delegation depth, force constraint attenuation, and record the complete authority chain.
Separate Identity, Authority, and Wallet Proof
Identity proof answers which agent or service controls an identifier. Reputation summarizes historical signals. Delegation proof answers what an identified actor may do under a principal’s grant. Wallet proof shows that a key authorized a transaction. Payment proof establishes facts about value movement.
None of these proofs automatically supplies the others. ERC-8004 is relevant to portable agent identity, reputation, and validation. It should not be described as a wallet permission system. x402 can carry payment requirements and proof flows; it does not define the principal’s complete delegation graph.
GOAT Network is relevant because AgentKit runtime policies can gate networks, actions, write capability, and risk, while GOAT’s agent stack includes identity and payment components. An application still needs to issue delegation grants, enforce amount and merchant constraints, propagate revocation, and maintain the usage ledger.
Fault-Test the Authority Graph
Attempt to issue a child grant with a later expiry, larger merchant set, higher per-payment ceiling, extra network, or another delegation level. Use a valid child after revoking its parent. Submit two concurrent payments against one remaining budget. Replay an old policy decision. Rotate an agent key during a pending payment. Let a payment settle after revocation.
The system should reject every expanding edge, preserve ambiguous exposure until reconciliation, and retain historical evidence after revocation. Monitor orphan grants, depth violations, revoked-grant attempts, child budgets exceeding parent availability, payments without a complete path, and authority that never expires.
The deployment invariant is an authorization equation: for every payment, there exists one valid path from a principal to the signer, and the payment is inside the intersection of every grant and policy on that path. If the path cannot be reproduced, the system delegated keys, not purchasing authority.
