Delegated Spend, Token Allowance and Session-Key Governance requires that every AI agent interacting with ERC-20 approve/transferFrom flows, EIP-2612 permit signatures, ERC-7715/ERC-7710 session keys, account abstraction delegations (ERC-4337 paymasters and session validators), or any equivalent delegated-spend mechanism operates under structural controls that limit the scope, duration, and value of delegated spending authority. The dimension addresses the pervasive risk that an AI agent — optimising for convenience or operational efficiency — grants unlimited token approvals, creates long-lived session keys with broad permissions, or accumulates delegated spending authority across multiple protocols until the agent's compromise would expose all approved assets to immediate, irrecoverable theft. In the ERC-20 model, a single approve(spender, type(uint256).max) call grants the spender permanent, unlimited authority to transfer the owner's entire token balance. As of 2025, over USD 2.8 billion in token value has been lost through exploited approvals on compromised or malicious contracts. For AI agents, the risk is amplified: an agent managing 200 client wallets that sets MAX_UINT256 approvals on each creates a single point of failure where one key compromise drains all 200 wallets instantly.
Scenario A — Unlimited Approval on Compromised DEX Router: An AI trading agent executes swaps across 15 DEX aggregators. For each new token pair, the agent calls approve(router, type(uint256).max) to avoid per-transaction approval gas costs. Over 3 months, the agent accumulates 847 unlimited approvals across the 15 routers for 63 different tokens, representing USD 42 million in exposed value. One aggregator's router contract (v2.3.1) is discovered to have a vulnerability in its swap() function that allows an attacker to call transferFrom() on any approved token using a crafted calldata payload. An attacker exploits the vulnerability and drains USD 18.7 million from wallets that had approved the vulnerable router before the protocol can deploy a fix.
What went wrong: The agent granted unlimited, perpetual approvals instead of per-transaction or bounded approvals. No structural control limited the approval amount to the transaction's actual need. No expiry mechanism revoked stale approvals. No monitoring tracked the aggregate exposure through outstanding approvals. Consequence: USD 18.7 million loss, incident response requires revoking 847 approvals across 63 tokens (costing approximately 0.4 ETH in gas per revocation — USD 1,200 at ETH = USD 3,000), and remaining exposure persists until every approval is revoked.
Scenario B — Session Key Over-Permissioning: An AI agent operating on a smart account (ERC-4337) is granted a session key to execute trades on behalf of a user. The session key is configured with: no value cap, 30-day expiry, and permission to call any function on any contract. The agent uses this session key to execute 50 trades per day. On day 14, the agent's session key is compromised through a supply chain attack on the agent's runtime dependency. The attacker uses the session key to transfer all assets from the smart account — ETH, ERC-20 tokens, and NFTs — because the session key's permissions are unbounded.
What went wrong: The session key was over-permissioned. It should have been scoped to specific contract addresses (the DEX routers), specific functions (swap() only), a maximum value per transaction (e.g., USD 50,000), a maximum daily aggregate (e.g., USD 500,000), and a shorter duration (e.g., 24 hours with auto-renewal upon re-authentication). Consequence: Complete wallet drain, estimated USD 3.2 million in assets lost, unrecoverable on-chain.
Scenario C — Cumulative Allowance Exposure Across Protocols: An AI yield-farming agent manages positions across 8 DeFi protocols. For each protocol, the agent approves the protocol's contract to spend specific tokens. Individually, each approval seems reasonable: USD 500,000 in USDC to Aave, USD 300,000 in DAI to Compound, and so on. But the aggregate exposure — the total value that could be drained if any approved contract is compromised — reaches USD 8.4 million across all protocols. No single dashboard or monitoring system tracks this aggregate. When a governance attack on one protocol replaces its contract with a malicious version, the agent's existing approval allows the attacker to drain USD 500,000 immediately. The organisation then discovers the full scope of outstanding approvals and spends 72 hours identifying and revoking them.
What went wrong: No cumulative allowance tracking existed. Each approval was evaluated in isolation. No aggregate exposure limit was enforced. No automated revocation mechanism existed for stale or over-scoped approvals. Consequence: USD 500,000 immediate loss, 72-hour exposure window for remaining USD 7.9 million, operational disruption during revocation campaign.
Scope: This dimension applies to any AI agent that can grant, modify, or utilise delegated spending authority over digital assets. This includes ERC-20 approve() and increaseAllowance() calls, EIP-2612 permit() signatures, ERC-7715/ERC-7710 session key configurations, ERC-4337 session validator setups, and any equivalent mechanism on any chain that permits one address to spend another address's assets or execute actions on behalf of another account. The scope extends to agents that manage approval revocations, as failure to revoke creates persistent exposure. An agent that only reads allowance state without modifying it is excluded.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
4.1. A conforming system MUST NOT permit an AI agent to grant unlimited token approvals (type(uint256).max or equivalent). Every approval MUST be bounded to the specific amount required for the immediate operation, plus a configurable tolerance not exceeding 10% to account for slippage or price movement.
4.2. A conforming system MUST enforce a maximum approval duration, automatically revoking or expiring any approval that has not been consumed or renewed within the configured period (default: 24 hours for approvals exceeding USD 10,000; 7 days for approvals under USD 10,000).
4.3. A conforming system MUST maintain a real-time allowance registry tracking all outstanding approvals granted by wallets under the agent's control, including: spender address, token address, approved amount, remaining amount, grant timestamp, and expiry.
4.4. A conforming system MUST enforce an aggregate exposure limit across all outstanding approvals, blocking new approvals when the total outstanding approved value (across all tokens, protocols, and chains) exceeds a configured ceiling.
4.5. A conforming system MUST scope session keys to the minimum required permissions: specific contract addresses, specific function selectors, maximum value per call, maximum aggregate value per session, and maximum session duration not exceeding 24 hours without re-authentication.
4.6. A conforming system MUST automatically revoke all approvals and session keys associated with a wallet or account when a security event is detected (e.g., key compromise, anomalous transaction, agent shutdown).
4.7. A conforming system SHOULD implement EIP-2612 permit() with deadlines rather than on-chain approve() where supported, reducing the window of exposure from perpetual to the permit deadline.
4.8. A conforming system SHOULD use ERC-7715/ERC-7710 or equivalent granular delegation standards that support per-function, per-contract, per-value, and time-bounded permission scoping, rather than blanket address-level approvals.
4.9. A conforming system SHOULD maintain a whitelist of approved spender contracts, blocking approvals to contracts not on the whitelist.
4.10. A conforming system MAY implement a "just-in-time approval" pattern where the approval is granted, the operation is executed, and the remaining allowance is revoked to zero in a single atomic transaction (using a multicall or batch transaction pattern).
The ERC-20 approval model was designed in 2015 (EIP-20, finalised 2017) for a world of human users manually approving specific transactions. The approve(spender, amount) function was intended to allow a user to authorise a specific contract to spend a specific amount — the user would review the approval in their wallet, confirm the amount, and proceed. In practice, the model has devolved: nearly every DeFi protocol requests unlimited approval (type(uint256).max) to avoid repeated approval transactions, users rubber-stamp these requests, and the result is a massive, invisible surface of outstanding approvals that persist indefinitely.
For AI agents, this problem is dramatically worse. An agent does not "rubber-stamp" — it programmatically grants approvals as part of its operational flow. Without structural constraints, an agent optimising for gas efficiency will always choose unlimited approval (one transaction) over per-operation approval (two transactions per operation). Without structural constraints, an agent managing multiple wallets will grant approvals on all of them, multiplying the exposure. Without structural constraints, an agent will never revoke stale approvals because revocation costs gas and provides no immediate operational benefit.
Session keys (ERC-7715, ERC-7710, and ERC-4337 session validators) represent the next generation of delegated authority, designed specifically for agent-like use cases. They are more granular than ERC-20 approvals — they can restrict not just value but function calls, contract addresses, and duration. However, they introduce their own governance challenges: a mis-configured session key with broad permissions effectively becomes an unlimited approval, and the composability of session key permissions can create unexpected authority combinations.
The core principle is the same as AG-001 (Operational Boundary Enforcement) applied to the token allowance layer: the agent should have the minimum authority required for its immediate operation, that authority should expire automatically, and the total outstanding authority should be tracked and capped.
Recommended patterns:
approve(spender, exactAmount), (2) the operation (e.g., swap()), (3) approve(spender, 0) in a single atomic transaction. This eliminates persistent approvals entirely. Gas cost is approximately 25,000-35,000 gas higher than a persistent approval but eliminates all ongoing exposure. For an agent executing 100 trades per day at 30,000 gas overhead and a gas price of 20 gwei on Ethereum (ETH at USD 3,000), the daily cost is approximately USD 180 — a negligible price for eliminating approval-based theft risk.permit() with a tight deadline (e.g., current block timestamp + 300 seconds) instead of on-chain approve(). The permit is a signed message that expires, reducing the exposure window from perpetual to 5 minutes. The permit can be submitted by the spender contract, eliminating the need for a separate approval transaction. Approximately 60% of major ERC-20 tokens now support EIP-2612.Approval events) and aggregates the total exposed value. Display this as a real-time metric. Set alerts when aggregate exposure exceeds defined thresholds (e.g., 50% of AUM, absolute dollar threshold). This does not replace structural controls but provides visibility.approve(spender, 0)). Prioritise revocations by exposure value (highest first) and by spender risk (unverified contracts first).Anti-patterns to avoid:
approve(spender, type(uint256).max).** The single most common anti-pattern in DeFi. Grants permanent, unlimited spending authority. Every AI agent framework must structurally prevent this call from being submitted, regardless of the agent's instructions or optimisation objectives.DeFi Trading. Trading agents should use the just-in-time approval pattern for every swap. The gas overhead is minimal compared to the value at risk. For high-frequency trading agents (>1,000 trades/day), consider batch approvals for the next N trades using a bounded amount, with automatic revocation of unused allowance.
Wallet-as-a-Service Providers. Providers managing wallets on behalf of users must treat approvals as a first-class governance concern. Every approval granted by an agent on a user's wallet should be logged, time-bounded, and subject to the aggregate exposure limit. Users should be able to view and revoke all outstanding approvals through a self-service interface.
Account Abstraction (ERC-4337) Deployments. Session validators in smart accounts provide the most granular delegation mechanism available. Implementations should use session validators that enforce per-call value limits, contract allowlists, and function selector allowlists. The session validator's configuration is itself a governance artefact subject to AG-007 (Governance Configuration Control).
Basic Implementation — The agent grants bounded approvals (specific amounts, not type(uint256).max) and maintains a log of all outstanding approvals. Session keys have defined expiry periods. No automated revocation exists — stale approvals persist until manually revoked. Aggregate exposure is tracked in a dashboard but not enforced as a hard limit. This level prevents the worst case (unlimited approvals) but still creates persistent exposure through unrevoked approvals.
Intermediate Implementation — Just-in-time approvals eliminate persistent exposure for most operations. Session keys are scoped to specific contracts, functions, and value limits with maximum 24-hour duration. An automated hygiene process revokes stale approvals every 6 hours. Aggregate exposure limits are enforced structurally — new approvals are blocked when the ceiling is reached. A whitelist of approved spender contracts prevents approvals to unknown contracts.
Advanced Implementation — All intermediate capabilities plus: formal verification of session key permission boundaries. Cross-chain aggregate exposure tracking with unified dashboard. Automated emergency revocation triggered by security events (agent compromise, anomalous transactions). Integration with threat intelligence feeds that flag compromised contracts for immediate approval revocation. Independent adversarial testing confirms that the agent cannot bypass approval limits through any known vector including meta-transaction relaying, delegatecall injection, or permit deadline manipulation.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Unlimited Approval Prevention
type(uint256).max (or any amount exceeding 110% of the required operation value) for any spender.type(uint256).max or any amount exceeding the bounded limit is submitted.Test 8.2: Approval Expiry
Test 8.3: Aggregate Exposure Limit
Test 8.4: Session Key Scope Enforcement
Test 8.5: Session Key Duration Enforcement
Test 8.6: Emergency Revocation
Test 8.7: Spender Whitelist Enforcement
type(uint256).max) and session keys have expiry periods, but no automated revocation, no aggregate limits, and no whitelist — basic bounds without lifecycle management.| Regulation | Provision | Relationship Type |
|---|---|---|
| MiCA | Article 70 (Safeguarding of Clients' Crypto-Assets) | Direct requirement |
| MiCA | Article 68 (Obligations for Crypto-Asset Service Providers) | Supports compliance |
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| DORA | Article 9 (ICT Risk Management Framework) | Supports compliance |
| PSD2 | Article 66-67 (Payment Initiation and Account Information Services) | Supports compliance |
| NIST AI RMF | GOVERN 1.1, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1, Clause 8.2 | Supports compliance |
Article 70's requirement that client crypto-assets be safeguarded extends to the approval and delegation layer. An unlimited approval on a client's wallet is a safeguarding failure — it creates a path through which client assets can be drained without further authorisation. AG-212 implements safeguarding at the delegation layer by ensuring approvals are bounded, time-limited, and subject to aggregate exposure controls. The automated revocation requirement (4.6) ensures that safeguarding is maintained even during security events.
SYSC 6.1.1R requires "adequate policies and procedures sufficient to ensure compliance." For AI agents managing digital asset wallets, the approval and delegation layer is a critical control surface. An agent that grants unlimited approvals does not have adequate policies and procedures — the control gap is structural. AG-212 provides the specific controls that satisfy SYSC 6.1.1R for the delegation layer: bounded approvals, expiry, aggregate limits, and emergency revocation.
PSD2's framework for third-party access to payment accounts establishes the principle that delegated access must be scoped, time-limited, and revocable. While PSD2 applies to fiat payment accounts, the same principles apply to crypto asset accounts accessed through delegated spending mechanisms. AG-212's session key requirements (4.5) map to PSD2's concept of "explicit consent" with defined scope and duration. The emergency revocation requirement (4.6) maps to PSD2's requirement that payment service users can revoke consent at any time.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | All wallets and accounts with outstanding approvals or active session keys under the agent's control — potentially all client assets managed by the agent |
Consequence chain: Failure of delegated spend governance creates a latent vulnerability that may remain unexploited for months before a triggering event (contract compromise, key theft, governance attack) converts it into an immediate, irrecoverable asset loss. The failure mode is particularly insidious because unlimited approvals create no visible symptom until they are exploited — the assets appear safe in the wallet, and the outstanding approval is invisible to standard balance checks. When exploitation occurs, it is typically automated: an attacker discovering a compromised contract with outstanding approvals will script transferFrom() calls across all approved wallets within minutes. The financial impact equals the total outstanding approved value, which for an agent managing institutional portfolios can reach hundreds of millions of dollars. The operational impact includes emergency revocation across all wallets (time-critical, gas-intensive, and error-prone under pressure), client notification, regulatory reporting, and forensic investigation. The regulatory consequence includes enforcement for inadequate safeguarding (MiCA Article 70), inadequate systems and controls (FCA SYSC 6.1.1R), and potential personal liability for senior managers.
Cross-references: AG-001 (Operational Boundary Enforcement) provides the mandate framework within which approval limits are defined as a specific type of operational boundary. AG-007 (Governance Configuration Control) governs the versioning of approval policies, whitelist configurations, and session key templates. AG-009 (Delegated Authority Governance) is the general framework for delegation that AG-212 specialises for the token allowance and session key context. AG-013 (Data Sensitivity and Exfiltration Prevention) protects the session key material and approval signing keys from exfiltration. AG-035 (Cumulative Privilege Acquisition Detection) detects the pattern described in Scenario C where aggregate approval exposure escalates incrementally. AG-210 depends on AG-212 because rehypothecation requires approvals to lending protocols — controlling the approval layer is a prerequisite for controlling rehypothecation. AG-214 addresses the risk that approval revocation transactions may themselves be subject to censorship or delayed inclusion.