# 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 == ''` 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.