How AI agents are given spending authority today

Session keys, spending limits, allowlists and signed attestations: what each protects against, where each fails, and who ships it

Research date: 2026-10-15. All pages were retrieved on that date unless marked otherwise.

How to read this report

Every substantive statement carries one of these labels:

• [F] Fact: stated in the cited source, which is primary (a spec, vendor documentation, source repository or official press release) unless noted otherwise.
• [F-sec] Secondary fact: reported by press or a third party and not confirmed against a primary source in this research.
• [I] Inference: my own analysis built from the cited facts. It is not stated by the source.
• [U] Uncertain: the evidence is incomplete, conflicting, or could not be retrieved.

Open questions are collected in §7. Sources are numbered in §8.

---

1. Summary

1. [I] Production systems no longer give an agent a full private key or an unrestricted card number. They give it a derived, bounded credential. On-chain, that is a session key or delegation enforced by a smart account. Off-chain, it is a scoped token or virtual card enforced by the issuer or the network. The four mechanisms in the question are layers, usually combined, not alternatives:
   • Session keys say who may sign and for how long.
   • Spending limits say how much.
   • Allowlists say to whom and for what.
   • Signed attestations or mandates record what the human actually authorised, so that others can check it later.
2. [F] The most explicit design premise comes from Google's AP2 specification: "AP2 assumes that preventing prompt injection attacks is infeasible" [S8]. [I] Every mechanism below follows the same logic. The model will sometimes be fooled, so the spend envelope must be enforced outside the model, by a contract, an enclave, an issuer or a network.
3. [I] The shared failure mode: these controls cap the size of the damage. They do not ensure the correctness of what is bought. A manipulated agent can still spend its whole budget on the wrong thing, and inside an allowlist an agent can still be steered among permitted counterparties. The Freysa incident [S14][S15] and the Princeton memory-injection study [S13] show that controls placed only in the prompt fail.

---

2. Session keys and delegated permissions

What it is

• [F] ERC-7715 defines wallet_requestExecutionPermissions, which lets a dApp ask a wallet "for permissions to execute transactions on the user's behalf". Each permission has a type, an isAdjustmentAllowed flag and data. Optional rules constrain it; the only rule defined is an expiry timestamp. The ERC has Draft status and requires EIP-4337 and EIP-7710 [S1].
• [F] In MetaMask's implementation ("Advanced Permissions"), a session account (a smart account or an EOA) requests the permission and later redeems it under ERC-7710. Supported types include ERC-20 periodic permissions and native-token permissions; the example given is "10 USDC per day for a month". Requirements are MetaMask v13.23.0 or later and a user upgraded to a MetaMask smart account [S2].
• [F] ZeroDev describes a permission as "1 signer + N policies + 1 action". Policy types are sudo (unrestricted), call policy (specific contracts, functions and parameters), gas policy, rate-limit policy and timestamp policy [S3].

What it protects against

• [I] The agent never holds the root key, so leaking the agent's key, its host or its logs exposes only what the session grants, and only until expiry.
• [I] Policies are checked on-chain by the account's validation logic. A prompt-injected agent therefore cannot sign its way past them.
• [F] MetaMask notes that unconstrained ("regular") delegations cannot be signed through the extension, because an unconstrained delegation "could expose the whole wallet". Advanced Permissions instead show the user a readable confirmation of start time, amount and period [S2].

Where it fails

• [F] ERC-7715's security section names the main risk: "Malicious DApps could pose as legitimate applications and trick users into granting broad permissions". It also says wallets "MUST clearly display the permissions" [S1]. [I] The standard defines only the request and response shapes. Enforcement quality depends on each wallet and each policy plugin.
• [I] A "sudo" policy [S3] makes the session key equal to a full key. Granting broad scopes for convenience defeats the mechanism.
• [I] Expiry and rate limits bound how long damage can last, but not what happens inside the window. A periodic allowance can be drained every period until someone revokes it.
• [U] Because ERC-7715 is still Draft [S1], permission types and rule semantics may change. Cross-wallet interoperability is not established.

Production use

• [F] MetaMask Smart Accounts Kit / Advanced Permissions [S2]; ZeroDev permissions [S3].
• [F-sec] Coinbase "Agentic Wallets" (launched Feb 2026) are reported to include "session duration restrictions" and to keep keys in trusted execution environments [S16].

---

3. Spending limits (amount, period and budget caps)

What it is and who ships it

• [F] Coinbase Spend Permissions. A SpendPermissionManager singleton is added as an owner of the user's Coinbase Smart Wallet. A spender calls spend, and the manager checks that the amount fits the approved recurring-period allowance. Only native and ERC-20 tokens are supported, and "arbitrary external calls" are not allowed. Users can revoke at any time via SpendPermissionManager.revoke. The contract was audited by Spearbit/Cantina (Oct to Dec 2024, plus a public competition) and is deployed at 0xf85210B21cC50302F477BA56686d2019dC9b67Ad on Base, Ethereum, Optimism, Arbitrum, Polygon and other chains [S4].
• [F] Coinbase Agentic Wallet (MCP). The human sets "Max per call" (example $0.05) and "Max per session" (example $5.00) in the wallet UI: "Your agent can't change these—only you can" [S5].
• [F] Safe Allowance module. Allowances are scoped per Safe, token and delegate, and can be one-time or recurring (reset period up to 2^16 minutes, about 45 days). The delegate authorises transfers with an EIP-712 signature [S6].
• [F] Stripe Shared Payment Tokens (SPTs). An agent creates a token for a specific seller profile with usage_limits[currency], usage_limits[max_amount] and usage_limits[expires_at]. The token can be revoked at any time. Its states are active, requires_action and deactivated, and deactivated is terminal. The API is currently a preview (Stripe-Version: 2026-09-30.preview) [S7].
• [F-sec] Card networks. Visa Intelligent Commerce reportedly lets users set "purchase limits and conditions" that Visa enforces with real-time transaction data [S17].

What it protects against

• [I] A hard cap on loss from any cause: prompt injection, model error, runaway loops, or theft of the agent's credential. This is the one control that gives a known worst case.
• [I] Because the limit sits in a contract [S4][S6], an enclave or wallet backend [S5], or the payment processor [S7], it holds even when the agent is fully compromised.

Where it fails

• [I] It does not judge intent. An agent fooled into overpaying, or into buying the wrong item, stays within the cap. AP2's threat model says this directly: constraint enforcement "bounds the worst-case impact" of manipulated discovery but does not prevent bad choices [S8].
• [I] Recurring allowances renew. Without monitoring, an attacker who controls the spender drains the cap every period.
• [F] Safe's own docs warn of front-running once a transfer reaches the mempool, and of delegate-key collisions, because delegates are keyed by only 6 address bytes [S6].
• [I] Splitting purchases across sessions, tokens or agents can evade per-call or per-session caps unless an aggregate limit exists at the account level.

---

4. Allowlists (recipient, merchant and contract scope)

What it is and who ships it

• [F] Turnkey policy engine. Policies are JSON with an allow or deny effect, consensus and condition. The example eth.tx.to == '<ALLOWED_ADDRESS>' is a recipient allowlist. "Almost all actions on Turnkey are implicitly denied by default", and "EFFECT_DENY always wins" [S9]. Turnkey lists "AI agent wallets with policy-scoped signing" as a target use [S9].
• [F] ZeroDev call policies restrict which contracts and functions, and which parameters, a session key may call [S3].
• [F] Coinbase Spend Permissions fix the token and disallow arbitrary calls [S4]. Stripe SPTs bind to one seller profile via seller_details[network_business_profile] [S7].
• [F-sec] Coinbase's CDP Wallets policy engine reportedly supports recipient allowlists and denylists, amount limits and contract-invocation controls, with enforcement "at the enclave layer". The primary page returned HTTP 403 during this research, so this is [U] as to exact current features. A search summary of Coinbase's Agentic Wallet docs reports that agents "can only pay for x402 services, not send to arbitrary addresses"; I did not retrieve that sentence from the primary page [S5 search context].
• [F-sec] Stripe Issuing spending controls (merchant categories, countries, amounts, and real-time authorization webhooks) are widely described as the card-based way to scope agent purchases [S18]. I did not re-verify the current agent-specific Issuing preview status on Stripe's own pages [U].

What it protects against

• [I] The "send everything to the attacker" outcome. Freysa's single transfer tool sent the whole pool to the message sender [S15]. A recipient allowlist enforced outside the model would have blocked that transfer, unless the attacker's address was itself on the list.
• [I] Calls to malicious contracts, unlimited approve() calls, and spending at unexpected merchant categories.

Where it fails

• [I] Allowlists suit closed-world tasks (pay these vendors) and fit poorly with open-world agents (shopping, x402 pay-per-call APIs). The list either grows too broad to protect or too narrow to be useful.
• [I] Allowlisted counterparties can themselves be compromised or impersonated. A permitted DEX router or marketplace can still be used to route value to an attacker, for example through slippage or an attacker-listed item.
• [F] In the Princeton work, injected "memories" caused unauthorized asset transfers in ElizaOS agents [S13]. [I] Allowlists limit where such transfers can go. They do not stop the agent from choosing a harmful but permitted action.

---

5. Signed attestations, mandates and agent identity

What it is and who ships it

• [F] Google AP2. AP2 uses Verifiable Digital Credentials, which it describes as "tamper-evident, cryptographically signed digital objects", chained into an audit trail. The current site describes a Checkout Mandate and a Payment Mandate, each with an open stage (constraints such as budget and allowed instruments) and a closed stage (authorization of a finalized checkout or amount). AP2 v0.2 was donated to the FIDO Alliance, and initial support covers "pull" methods such as cards [S10]. Open mandates bind the agent's key through a cnf claim [S8].
• [U] Launch-era coverage (Sept 2025) instead describes Intent, Cart and Payment mandates [S19]. [I] This most likely reflects a spec revision between launch and v0.2. Readers should use the current site [S10].
• [F] Visa Trusted Agent Protocol (14 Oct 2025, built with Cloudflare). It uses "agent-specific cryptographic signatures" to convey agent intent, consumer recognition and optional payment information to merchants. It is initially limited to the Visa network [S11]. [F-sec] It is built on HTTP Message Signatures (RFC 9421), per partner Nuvei [S20].
• [F] Mastercard Agent Pay (announced 29 Apr 2025). It introduces "Agentic Tokens" that build on Mastercard tokenization. The primary page returned 403 here; facts come from search snippets of the official release and a Business Wire copy [S12]. [F-sec] These tokens are described as embedding usage rules, permissions and traceability [S17].
• [F] Stripe can use network-issued agent tokens (Mastercard Agent Pay, Visa Intelligent Commerce) when processing SPTs, according to a footnote in Stripe's docs [S7].

What it protects against

• [F] AP2's threat model lists the attacks mandates address: reusing a signed Payment Mandate with an unrelated checkout, an agent requesting payment that differs from the user's approved mandate, and double spending of one open mandate [S8].
• [I] Non-repudiation and dispute evidence. Issuers and merchants can tell whether a human approved this cart or these constraints, and which agent acted. Merchants can tell a registered agent from an anonymous bot [S11].

Where it fails

• [F] AP2 itself makes overlap rejection optional: Credential Providers, Networks or processors "MAY" reject overlapping mandates [S8]. It requires that receipts used for double-spend detection be protected from the shopping agent's LLM, and it puts mandate-sharing "outside the scope of AP2" [S8].
• [I] An attestation proves that a key signed, not that the human understood. If the trusted surface shows a misleading summary, or the user approves an over-broad open mandate, the signature faithfully records a bad authorization.
• [I] Agent-identity signatures (Trusted Agent Protocol, Agentic Tokens) prove which agent platform sent a request. They say nothing about whether that agent's model was manipulated by the content it read.
• [U] Liability allocation, key-compromise handling and dispute resolution are not defined in the AP2 security considerations I reviewed [S8].

---

6. Comparison table

Mechanism	Main threat bounded	Main failure	Enforcement point	Production examples (evidence level)
Session keys / delegations	Theft of the agent's key; unlimited signing	Over-broad grants (sudo), phishing for permissions, draft standard	Smart-account validation	MetaMask Advanced Permissions [F], ZeroDev [F], Coinbase Agentic Wallets [F-sec]
Spending limits	Size of any loss	Wrong but in-budget purchases; renewing allowances; split purchases	Contract, wallet backend, processor	Coinbase Spend Permissions [F], Coinbase Agentic Wallet caps [F], Safe Allowance [F], Stripe SPT [F (preview)]
Allowlists	Funds sent to arbitrary attacker addresses	Open-world tasks; compromised permitted counterparties	Policy engine / enclave, call policy, issuer	Turnkey [F], ZeroDev call policy [F], Stripe SPT seller binding [F], CDP policy engine [F-sec/U]
Signed mandates / attestations	Cart or amount substitution, replay, bot impersonation; dispute evidence	Proves signature, not understanding; optional overlap checks; liability undefined	Credential provider, network, merchant	AP2 v0.2 [F; production scale U], Visa TAP [F], Mastercard Agent Pay [F-sec]

[I] Recommended composition, based on the above:

1. A short-lived session key.
2. Hard per-transaction and per-period caps, enforced outside the model.
3. A default-deny allowlist wherever the task allows one.
4. A signed, human-approved mandate for anything open-ended.
5. Monitoring and fast revocation (SPT revoke [S7], SpendPermissionManager.revoke [S4], Safe removeDelegate [S6]).

---

7. Uncertainty and unanswered questions

1. Adoption volumes. [U] I found no independent figures for how much value moves under any of these mechanisms. The x402 transaction counts in secondary sources conflict (e.g. 119M vs 165M transactions) and are self-reported, so I excluded them.
2. Deployment maturity. ERC-7715 is Draft [S1], Stripe SPTs are a preview API [S7], and Stripe's agent features are partly "private preview" [S7]. AP2's production deployments beyond samples are [U].
3. Card-network controls. [U] The exact consumer-facing controls of Visa Intelligent Commerce and Mastercard Agentic Tokens (per-merchant limits, categories, expiry) could not be confirmed from primary technical documentation in this research. Mastercard's newsroom returned 403.
4. Coinbase CDP policy engine. [U] The primary launch page returned 403. Its rule set and the claim of enclave enforcement come from search snippets.
5. Liability and disputes. [Open] Who bears the loss when an agent acts within a valid mandate but against the user's real wishes? None of the reviewed primary sources answers this.
6. Effectiveness evidence. [Open] I found no public incident data showing these controls stopping, or failing to stop, a real attack in production. Freysa [S14][S15] was a game with no out-of-model controls, and the Princeton study [S13] was a research benchmark.
7. Not covered. Privy, Biconomy, Crossmint, Nevermined, PayPal and other providers were not examined, for lack of time.

---

8. Sources

#	Source	Type
S1	ERC-7715: Grant Permissions from Wallets — https://eips.ethereum.org/EIPS/eip-7715	Primary (spec)
S2	MetaMask Smart Accounts Kit, Advanced Permissions — https://docs.metamask.io/smart-accounts-kit/concepts/advanced-permissions.md	Primary (docs)
S3	ZeroDev, Permissions intro — https://docs.zerodev.app/sdk/permissions/intro	Primary (docs)
S4	coinbase/spend-permissions repository — https://github.com/coinbase/spend-permissions	Primary (code/docs)
S5	Coinbase CDP Agentic Wallet MCP Quickstart — https://docs.cdp.coinbase.com/agentic-wallet/mcp/quickstart	Primary (docs)
S6	Safe Allowance module — https://github.com/safe-global/safe-modules/tree/main/modules/allowances	Primary (code/docs)
S7	Stripe, Shared Payment Tokens (agent variant) — https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=agent ; Stripe Agentic Commerce overview — https://docs.stripe.com/agentic-commerce.md	Primary (docs)
S8	AP2 Security and Privacy Considerations — https://ap2-protocol.org/ap2/security_and_privacy_considerations/	Primary (spec)
S9	Turnkey, Policies overview — https://docs.turnkey.com/concepts/policies/overview	Primary (docs)
S10	AP2 protocol site — https://ap2-protocol.org/ ; repo https://github.com/google-agentic-commerce/AP2	Primary (spec)
S11	Visa press release, Trusted Agent Protocol (14 Oct 2025) — https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21716.html	Primary (press release)
S12	Mastercard press release, Agent Pay (29 Apr 2025) — https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html (403 on fetch; snippet only); Business Wire copy — https://www.silicon.co.uk/press-release/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai	Primary (snippet) / copy
S13	Patlan et al., "Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents", arXiv:2503.16248 (v3, Jul 2025) — https://arxiv.org/abs/2503.16248	Primary (research)
S14	The Block, Freysa $47,000 challenge — https://www.theblock.co/amp/post/328747/human-player-outwits-freysa-ai-agent-in-47000-crypto-challenge	Secondary (press)
S15	Simon Willison, "0xfreysa agent" (29 Nov 2024) — https://simonwillison.net/2024/Nov/29/0xfreysaagent/	Secondary (expert analysis of public source)
S16	Decrypt, Coinbase agent wallets with guardrails — https://decrypt.co/357813/coinbase-launches-wallet-ai-agents-built-in-guardrails ; Coinbase launch post — https://www.coinbase.com/developer-platform/discover/launches/agentic-wallets (not fetched)	Secondary / primary (unfetched)
S17	Digital Commerce 360, Visa and Mastercard agentic commerce (6 May 2025) — https://www.digitalcommerce360.com/2025/05/06/visa-mastercard-ai-agentic-commerce/	Secondary (press)
S18	Stripe dev blog, Adding payments to your agentic workflows — https://stripe.dev/blog/adding-payments-to-your-agentic-workflows	Primary (vendor blog, 2025, not re-fetched)
S19	Vellum, Google's AP2 — https://www.vellum.ai/blog/googles-ap2-a-new-protocol-for-ai-agent-payments	Secondary
S20	Nuvei supports Visa Trusted Agent Protocol — https://marketplace.afponline.org/company/919146/news/3703004/nuvei-supports-visa-trusted-agent-protocol-to-advance-agentic-commerce	Secondary (partner release)

Method note. Pages were read through an automated fetch-and-summarise tool. Quoted strings are as returned by that tool, and a few pages (Stripe) were served in German and translated. Search-only items are marked [F-sec] or [U]. Nothing here was independently reviewed.