Account Abstraction Paymaster Policy Governance

2. Summary

Account Abstraction Paymaster Policy Governance requires that any AI agent operating through smart-account architectures — including but not limited to ERC-4337 smart accounts, ERC-7579 modular accounts, session-key frameworks, and equivalent constructs on non-EVM chains — implements formal governance over paymasters, session keys, execution delegates, and permission scoping to prevent unauthorised privilege escalation, uncontrolled delegation chains, and exploitation of the programmable transaction validation layer. Account abstraction decouples transaction authorisation from the externally owned account (EOA) model, enabling programmable validation logic, delegated execution authority, and third-party gas payment. For AI agents, this is transformative — it allows agents to operate with scoped, time-bounded, revocable permissions rather than holding raw private keys. But the same programmability that enables fine-grained permission control also creates a complex attack surface: misconfigured session keys can grant unbounded authority, paymasters can be exploited to subsidise malicious operations, and recursive delegation chains can obscure the actual authority being exercised. This dimension mandates structural controls that ensure account abstraction components are governed with the same rigour as traditional key management, preventing the flexibility of smart accounts from becoming a governance liability.

3. Example

Scenario A — Overbroad Session Key Grants Full Account Control: An organisation deploys an AI rebalancing agent that operates through an ERC-4337 smart account. To avoid requiring the account owner's signature for every transaction, the team creates a session key granting the agent permission to call any function on any contract, with a value limit of 10 ETH per transaction and a 30-day expiry. The intention is for the agent to execute swaps on three approved DEX contracts. However, the session key's target contract field is set to the wildcard (any contract) rather than scoped to the three DEX addresses. A vulnerability in the agent's strategy logic causes it to interact with a malicious contract disguised as a DEX aggregator. The malicious contract calls back into the smart account using the session key's broad permissions, executing an approve(MAX_UINT256) on the account's USDC holdings — approving $2.4 million in USDC to be spent by the attacker's address. The per-transaction value limit of 10 ETH is not triggered because the approve function transfers no value; it merely sets a spending allowance. The attacker drains $2.4 million in USDC in a single transferFrom call executed moments later.

What went wrong: The session key was scoped by value but not by target contract, function selector, or parameter constraints. The wildcard target contract field transformed a limited rebalancing permission into full account control for any zero-value function call. The per-transaction value limit was ineffective against approval-based attacks because token approvals transfer no native value. No validation checked whether the session key's permissions were the minimum necessary for the agent's stated purpose. The 30-day expiry meant the overbroad permission persisted for an entire month rather than being scoped to individual sessions. Total loss: $2.4 million in USDC.

Scenario B — Paymaster Subsidises Attacker Operations Through Agent Misdirection: A DeFi protocol operates a paymaster contract that sponsors gas for its AI yield-farming agents. The paymaster validates that the sender is a registered agent smart account and that the target contract is on the protocol's allowlist. An attacker discovers that the paymaster's validation checks the to field of the UserOperation but not the calldata content. The attacker crafts a UserOperation where the to field points to an allowlisted contract (a legitimate DEX router) but the calldata encodes a swap that routes through a malicious intermediate pool controlled by the attacker. The swap extracts value through an inflated swap fee embedded in the malicious pool — the agent receives 30% less output than fair market value. The paymaster sponsors the gas for this exploitative transaction because its validation only checks the outer to address. Over 72 hours, the attacker manipulates the agent into routing 140 transactions through the malicious pool, extracting $89,000 in value while the protocol's paymaster sponsors $420 in gas for the exploitative transactions.

What went wrong: The paymaster's validation policy was insufficient — it verified the target contract but not the full execution path. The allowlist check (per AG-469) was applied at the UserOperation level but not at the internal call trace level. The paymaster effectively subsidised the attacker's exploitation because its policy did not evaluate whether the sponsored operation was economically rational for the agent. No validation compared expected swap output against actual output to detect value extraction. The $420 in gas cost was trivial, but the $89,000 in extracted value was not.

Scenario C — Recursive Session Key Delegation Creates Ungovernable Authority Chain: An organisation configures a smart account with modular permissions (ERC-7579 style). The primary agent holds a session key with full rebalancing authority. A sub-agent (a specialised gas-optimisation module) is granted a delegated session key derived from the primary agent's key, scoped to gas-related operations. Due to a misconfiguration in the delegation module, the sub-agent's session key inherits the delegation capability itself — meaning it can create further delegated keys. An automated process in the sub-agent creates 47 additional session keys for ephemeral worker processes, each inheriting delegation capability. The result is a tree of 49 active session keys, most with broader permissions than intended, none individually tracked by the organisation's key management system. When the organisation attempts to revoke the primary agent's session key in response to an anomaly, 47 child keys remain active because revocation is not recursive. One child key is used to execute an unauthorised $340,000 withdrawal 6 hours after the primary key was ostensibly revoked.

What went wrong: The delegation module permitted recursive delegation without depth limits, violating AG-396. Session key creation was not logged or tracked in the organisation's key management system, violating AG-012. Revocation was not recursive — revoking a parent key did not automatically revoke child keys. The organisation believed the primary key revocation had neutralised the threat, but 47 untracked child keys remained active. No inventory of active session keys existed. The $340,000 unauthorised withdrawal occurred because the organisation's revocation was incomplete.

4. Requirement Statement

Scope: This dimension applies to any AI agent that operates through a smart-account architecture where transaction validation, execution authority, or gas payment is programmable rather than derived solely from a single private key signature. This includes but is not limited to: ERC-4337 smart accounts with UserOperation validation, modular smart accounts (ERC-7579, ERC-6900), session key frameworks, delegated execution modules, social recovery wallets with agent access, multi-signature wallets where the agent holds one or more signing keys, and equivalent constructs on non-EVM chains (Cosmos authz module, Solana session tokens, NEAR function-call access keys). The scope covers three components: (1) paymasters — contracts that pay gas on behalf of the smart account, governed for sponsorship abuse by AG-475 but requiring additional governance here for validation policy and allowlist compliance; (2) session keys — scoped, time-bounded signing authorities granted to agents for autonomous operation; and (3) delegation mechanisms — processes by which one authorised entity grants a subset of its authority to another. An AI agent operating solely through a traditional EOA with a single private key is excluded from session-key and delegation requirements but remains subject to paymaster requirements if a paymaster sponsors its transactions.

4.1. A conforming system MUST scope every session key granted to an AI agent to the minimum necessary permissions, specifying at minimum: the allowed target contracts (by address), the allowed function selectors, the maximum value per transaction, the maximum cumulative value per session, and the expiry time — with no field left as a wildcard unless explicitly justified and approved by a governance authority.

4.2. A conforming system MUST enforce that paymaster validation policies verify not only the target contract address but also the function selector, critical calldata parameters, and — where technically feasible — the full execution path of sponsored UserOperations, preventing paymasters from subsidising operations that do not conform to the agent's approved mandate.

4.3. A conforming system MUST maintain a real-time inventory of all active session keys, delegation grants, and paymaster authorisations associated with each smart account, including the permissions, expiry times, issuer identity, and delegation depth of each credential.

4.4. A conforming system MUST implement recursive revocation such that revoking a session key or delegation grant automatically revokes all child keys and sub-delegations derived from it, with confirmation that revocation has propagated to all descendants before reporting revocation as complete.

4.5. A conforming system MUST enforce a maximum delegation depth (recommended: 2 levels — primary key delegates to agent key, agent key may delegate to one sub-agent key, no further delegation permitted), consistent with AG-396, and block any delegation attempt that would exceed the configured depth.

4.6. A conforming system MUST log every session key creation, delegation grant, permission modification, key usage, and revocation event with timestamps, the granting authority, the granted permissions, and the recipient identity, retaining logs for the period specified in Section 7.

4.7. A conforming system MUST validate that session key permissions do not exceed the permissions of the granting authority — no key may grant broader access than the key from which it is derived.

4.8. A conforming system SHOULD implement time-bounded session keys with automatic expiry not exceeding 24 hours for standard operations and not exceeding 1 hour for high-value operations (as defined by the organisation's risk classification), consistent with AG-010.

4.9. A conforming system SHOULD implement paymaster spending analytics that correlate sponsored gas expenditure with the economic outcome of the sponsored operation, detecting value-extracting transactions where the agent receives significantly less value than fair market rates.

4.10. A conforming system SHOULD conduct periodic permission audits (recommended: weekly) that compare each active session key's granted permissions against the agent's current operational requirements, identifying and revoking permissions that are no longer necessary.

4.11. A conforming system MAY implement session key rotation where long-lived agent operations use rotating session keys with overlapping validity periods, ensuring that compromise of a single key provides only a brief window of unauthorised access.

5. Rationale

Account abstraction is the most significant architectural shift in blockchain account management since the introduction of smart contracts. The traditional model — one private key controls one externally owned account, and every transaction requires that key's signature — is simple but poorly suited to AI agent operations. An AI agent that holds a raw private key has unlimited authority over the associated account: it can transfer any asset, approve any spender, interact with any contract, and spend any amount of gas. This is the antithesis of least-privilege governance.

Account abstraction replaces this monolithic authority model with programmable validation. A smart account can define arbitrary conditions for transaction authorisation: multi-signature requirements, spending limits, time windows, contract allowlists, function-level permissions, and delegated authority hierarchies. For AI agent governance, this is transformative. Instead of giving an agent a private key and hoping it behaves correctly, the organisation can give the agent a session key that permits only specific operations on specific contracts within specific value limits for a specific time period. If the agent is compromised or malfunctions, the damage is bounded by the session key's scope.

But the governance challenge is that this programmability creates a complex permission surface that must itself be governed. In the traditional EOA model, permission management is binary: the entity either has the private key (full access) or does not (no access). In the account abstraction model, permissions are multi-dimensional: target contracts, function selectors, value limits, time bounds, delegation depth, calldata constraints, and paymaster policies. Each dimension can be misconfigured. The combinatorial complexity of multi-dimensional permission scoping is orders of magnitude greater than binary key management.

Three specific risks emerge. First, permission scope creep: session keys that are initially well-scoped are broadened over time for operational convenience, gradually approaching the unlimited access of a raw private key. This is the blockchain equivalent of granting an employee temporary admin access that is never revoked. Second, paymaster policy gaps: paymasters that validate at the UserOperation level but not at the execution-trace level can be exploited to subsidise malicious operations that appear legitimate at the surface level. Third, delegation cascades: when session keys can create sub-delegations, and sub-delegations can create further sub-delegations, the result is a tree of active credentials that rapidly exceeds the organisation's ability to inventory, monitor, and revoke. Scenario C demonstrates this — 47 untracked child keys from a single misconfigured delegation.

The regulatory landscape reinforces the governance requirement. MiCA Article 67 requires that custody arrangements for crypto-assets include adequate access controls and key management procedures. Session keys and delegation grants are cryptographic credentials equivalent to custody keys — they control access to crypto-assets. FCA guidance on cryptoasset custody expects firms to maintain inventories of all credentials with access to client assets. DORA Article 9 requires ICT risk management that covers all digital access credentials. The principle is consistent across regulators: every credential that can access financial assets must be inventoried, scoped, monitored, and revocable. Account abstraction multiplies the number of such credentials by enabling programmatic creation — making governance more important, not less.

6. Implementation Guidance

Account Abstraction Paymaster Policy Governance requires that the programmable permission surface of smart accounts is treated as a first-class governance domain, with the same rigour applied to session key management as to traditional private key management — and additional rigour applied to the multi-dimensional permission scoping that account abstraction enables.

Recommended patterns:

• Permission template enforcement. Define a library of pre-approved session key templates for each agent role: a "DEX rebalancer" template specifying the 3-5 approved DEX router addresses, the allowed function selectors (e.g., swap, exactInputSingle, multicall), a per-transaction value ceiling (e.g., 5 ETH), a per-session cumulative ceiling (e.g., 50 ETH), and a 24-hour expiry. Agents receive session keys instantiated from templates, not ad hoc permission grants. Templates are version-controlled and require governance approval to modify. This prevents the ad hoc permission broadening that leads to overbroad keys (Scenario A). New operation types require new templates, not modifications to existing broad templates.
• Paymaster deep validation. Implement paymaster validation that inspects calldata beyond the target contract address. For swap operations, the paymaster should verify: the output token is on the approved token list, the minimum output amount is within a defined slippage tolerance of the fair market price (using an oracle), and the swap route does not include unapproved intermediate contracts. For approval operations, the paymaster should verify: the spender address is on the approved spender list, and the approval amount does not exceed a defined ceiling. For transfer operations, the paymaster should verify: the recipient is on the approved recipient list or is the smart account itself. This deep validation prevents the exploit in Scenario B where surface-level allowlist checks were bypassed through calldata manipulation.
• Session key lifecycle management. Integrate session key management with the organisation's credential lifecycle system per AG-012. Every session key creation triggers: (1) inventory registration with the key's full permission set, expiry, and issuer; (2) monitoring activation to track key usage against expected patterns; (3) scheduled expiry verification to confirm the key becomes invalid at its declared expiry time; and (4) revocation readiness — the ability to revoke the key within 60 seconds of a revocation decision. The lifecycle system should provide a dashboard showing all active session keys across all smart accounts, with permission summaries, time remaining until expiry, and usage statistics.
• Delegation depth enforcement at the contract level. Implement maximum delegation depth in the smart account's validation logic, not only in the off-chain agent orchestrator. The smart account should track the delegation depth of each key and reject any delegation attempt that would exceed the maximum. This ensures that even a compromised agent cannot create sub-delegations beyond the configured depth, regardless of off-chain governance state. The recommended implementation is a delegationDepth field in the session key metadata, incremented on each delegation and checked against a maxDelegationDepth parameter in the account's storage.
• Recursive revocation with confirmation. When a session key is revoked, the revocation system should: (1) identify all child keys derived from the revoked key using the delegation tree, (2) submit revocation transactions for each child key, (3) verify on-chain that each child key is invalidated (by attempting a test validation that should fail), and (4) report revocation as complete only after all descendants are confirmed revoked. If any child key revocation fails, the system should alert immediately and attempt re-revocation. This prevents the Scenario C failure where partial revocation left child keys active.

Anti-patterns to avoid:

• Wildcard session keys for operational convenience. Granting session keys with wildcard target contracts or wildcard function selectors because scoping is "too complex" or "too restrictive for the agent's needs." A wildcard session key on a smart account is functionally equivalent to giving the agent the account's private key — it can call any function on any contract. If the agent's needs are too complex for a well-scoped key, the correct response is to decompose the agent's authority into multiple narrowly scoped keys, not to grant a single broad key.
• **Paymaster validation limited to to address.** Validating only the target contract address in paymaster policy and ignoring function selectors, calldata, and execution paths. This is the Scenario B failure: an allowlisted contract address does not guarantee an allowlisted operation. A DEX router can be called with calldata that routes through malicious pools. A token contract can be called with approve(attacker, MAX_UINT256). Address-only validation provides a false sense of security.
• Off-chain-only delegation controls. Enforcing delegation depth limits and permission scoping only in the off-chain agent orchestrator, without corresponding on-chain validation. If the on-chain smart account accepts any properly signed delegation regardless of depth or scope, a compromised agent can bypass off-chain controls by submitting delegation transactions directly to the blockchain. Governance constraints must be enforced at the smart contract level.
• Non-recursive revocation. Revoking a parent session key without revoking its children. In a delegation tree, revoking only the parent creates a false sense of security — the operator believes the threat is neutralised, but child keys remain active. This is the Scenario C failure that led to a $340,000 unauthorised withdrawal.
• Static session keys with long expiry. Issuing session keys with 30-day or 90-day expiry for operational convenience. Long-lived keys accumulate risk: a key compromised on day 1 of a 90-day validity window provides 89 days of unauthorised access. Session keys should be time-bounded to the minimum period necessary, with automatic renewal processes for ongoing operations.

Industry Considerations

DeFi Protocols. Protocols offering smart-account-based agent services must govern the paymaster and session key infrastructure as a product security concern. The paymaster's validation policy is a security boundary — if it is insufficient, the protocol subsidises attacks on its own users. Session key templates should be defined and audited as part of the protocol's smart contract security review, not treated as off-chain configuration.

Institutional Custody. Institutions using smart accounts for agent-driven treasury management face custody regulatory requirements. Session keys are custody credentials — they control access to custodied assets. Regulatory frameworks (FCA, MiCA, SEC custody rule) require that all custody credentials are inventoried, access-controlled, and auditable. The session key inventory required by AG-476 directly satisfies these custody credential management requirements.

Multi-Chain Operations. Organisations operating smart accounts across multiple chains face interoperability challenges. ERC-4337 session keys on Ethereum do not translate directly to Cosmos authz grants or Solana function-call access keys. The session key lifecycle management system must abstract across chain-specific mechanisms while maintaining consistent permission scoping, inventory tracking, and revocation capabilities.

Maturity Model

Basic Implementation — Every session key is scoped to specific target contracts, function selectors, value limits, and expiry times. No wildcard permissions are granted without documented justification and governance approval. A real-time inventory of all active session keys exists. Revocation can be executed within 60 seconds. Paymaster validation checks target contract and function selector. Delegation depth is limited to 2 levels. All session key lifecycle events are logged. This level meets the minimum mandatory requirements.

Intermediate Implementation — All basic capabilities plus: permission templates are defined for each agent role and enforced through automated provisioning. Paymaster deep validation checks calldata parameters and swap routes. Recursive revocation is implemented with confirmation. Periodic permission audits (weekly) compare granted permissions against operational requirements. Session key time bounds follow risk-based classification (24 hours standard, 1 hour high-value). Delegation controls are enforced at the smart contract level.

Advanced Implementation — All intermediate capabilities plus: session key rotation provides continuous operation with minimal compromise windows. Paymaster spending analytics correlate gas sponsorship with economic outcomes, detecting value extraction. Machine learning identifies anomalous session key usage patterns. The permission template library is version-controlled with formal change management. Cross-chain session key governance provides unified inventory and policy enforcement across all chains. Independent adversarial testing confirms that no known attack can exploit the permission surface.

7. Evidence Requirements

Required artefacts:

• Session key permission inventory. Real-time registry of all active session keys across all smart accounts, documenting the target contracts, function selectors, value limits, expiry times, delegation depth, issuing authority, and associated agent identity for each key.
• Permission template library. The catalogue of approved session key templates for each agent role, with version history, approval records, and the governance authority that approved each template.
• Paymaster validation policy. Documented validation rules for each paymaster, specifying what checks are performed on UserOperations (target contract, function selector, calldata parameters, execution path) and the criteria for sponsorship approval or rejection.
• Session key lifecycle logs. Complete logs of all session key creation, delegation, modification, usage, and revocation events, with timestamps, granting authority, permissions granted, and recipient identity.
• Revocation confirmation records. Records of all revocation events, including recursive revocation traces showing the identification and confirmed invalidation of all child keys and sub-delegations.
• Permission audit reports. Periodic audit reports comparing active session key permissions against current operational requirements, documenting any over-permissioned keys identified and the remediation actions taken.
• Delegation depth enforcement records. Evidence that delegation depth limits are enforced at the smart contract level, including test results demonstrating that over-depth delegation attempts are rejected.

Retention requirements:

• Session key lifecycle logs and revocation records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Permission audit reports and paymaster validation policy: minimum 5 years for all deployments operating in regulated sectors.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.
• Session key inventory accessible to security operations in real time.

8. Test Specification

Test 8.1: Session Key Minimum Permission Scoping

• Stimulus: Attempt to create a session key with a wildcard target contract field (any contract) and no function selector restriction. Submit the creation request through the standard provisioning process.
• Expected behaviour: The provisioning system rejects the wildcard session key creation unless an explicit governance approval override is provided. The rejection is logged with the reason (wildcard target contract without governance justification).
• Pass criteria: Wildcard session key creation is blocked by default. The rejection event is logged. Only a documented governance override (with approver identity and justification) enables wildcard key creation.
• Fail criteria: A wildcard session key is created without governance override, or the rejection is not logged.

Test 8.2: Paymaster Deep Validation — Calldata Inspection

• Stimulus: Submit a UserOperation where the to field targets an allowlisted DEX router contract, but the calldata encodes a swap route through a non-allowlisted intermediate contract (simulating the Scenario B attack). Submit a second UserOperation where the to field targets an allowlisted token contract and the calldata encodes approve(non_allowlisted_address, MAX_UINT256).
• Expected behaviour: The paymaster rejects both UserOperations. The first is rejected because the swap route includes a non-allowlisted intermediate contract. The second is rejected because the approval spender is not on the approved spender list.
• Pass criteria: Both exploitative UserOperations are rejected by the paymaster. Rejection reasons are logged with the specific validation failure (non-allowlisted route, non-allowlisted approval spender). Legitimate UserOperations with allowlisted routes and spenders continue to be sponsored.
• Fail criteria: Either exploitative UserOperation is sponsored by the paymaster, or legitimate operations are incorrectly rejected (false positives exceeding 1%).

Test 8.3: Recursive Revocation Completeness

• Stimulus: Create a delegation chain: primary key delegates to agent key (depth 1), agent key delegates to sub-agent key (depth 2). Verify all three keys are active. Revoke the agent key (depth 1).
• Expected behaviour: Revoking the agent key triggers automatic revocation of the sub-agent key (depth 2). Both revocations are confirmed on-chain (validation attempts with both keys fail). The revocation system reports complete only after all descendants are confirmed invalidated.
• Pass criteria: All child keys are revoked within 120 seconds of the parent key revocation. On-chain validation confirms all revoked keys are invalid. The revocation report lists all revoked keys with confirmation status. No child key remains usable after parent revocation.
• Fail criteria: Any child key remains usable after parent revocation, or revocation takes longer than 120 seconds, or the revocation report does not include all child keys.

Test 8.4: Delegation Depth Enforcement

• Stimulus: Configure the maximum delegation depth to 2. Create a delegation chain at depth 2 (primary to agent to sub-agent). Attempt to create a further delegation from the sub-agent key (which would be depth 3).
• Expected behaviour: The depth-3 delegation attempt is rejected at the smart contract level. The rejection is logged with the reason (maximum delegation depth exceeded). The sub-agent key remains valid for its scoped operations but cannot delegate.
• Pass criteria: The depth-3 delegation is rejected on-chain (the smart account's validation logic rejects the transaction). The rejection is logged. No key at depth 3 or beyond is created.
• Fail criteria: A depth-3 delegation is created, or the rejection occurs only off-chain (byppassable by direct on-chain submission).

Test 8.5: Session Key Expiry Enforcement

• Stimulus: Create a session key with a 1-hour expiry. Execute transactions successfully during the validity period. Wait until 1 second after the expiry time. Attempt to execute a transaction with the expired key.
• Expected behaviour: Transactions execute normally during the validity period. The post-expiry transaction is rejected on-chain by the smart account's validation logic. No grace period permits post-expiry execution.
• Pass criteria: The expired key is rejected within the first attempted transaction after expiry. The rejection is on-chain (not merely off-chain). The rejection is logged as an expiry enforcement event.
• Fail criteria: Any transaction executes after the key's expiry time, or the rejection occurs only off-chain.

Test 8.6: Session Key Inventory Completeness

• Stimulus: Create 10 session keys across 3 smart accounts through the standard provisioning process. Create 2 additional delegated keys from existing session keys. Verify the inventory system reflects all 12 active keys.
• Expected behaviour: The session key inventory shows all 12 active keys within 60 seconds of creation. Each entry includes the full permission set, expiry time, delegation depth, issuing authority, and associated agent identity.
• Pass criteria: 100% of created keys appear in the inventory within 60 seconds. All required metadata fields are populated. Delegation relationships are accurately reflected (child keys reference their parent).
• Fail criteria: Any key is missing from the inventory, any required metadata field is unpopulated, or delegation relationships are inaccurate.

Test 8.7: Permission Non-Escalation Validation

• Stimulus: Create a session key (Key A) scoped to target contracts X and Y, with a value limit of 5 ETH per transaction. Attempt to delegate from Key A to create a child key (Key B) scoped to target contracts X, Y, and Z (adding a contract not in Key A's scope), with a value limit of 10 ETH per transaction (exceeding Key A's limit).
• Expected behaviour: The delegation is rejected because Key B's permissions exceed Key A's permissions on two dimensions: target contracts and value limit. The rejection specifies which dimensions exceed the parent key's scope.
• Pass criteria: The delegation creating Key B is rejected. The rejection identifies the specific permission escalation (additional target contract Z, increased value limit from 5 to 10 ETH). No child key is created with permissions exceeding its parent's scope.
• Fail criteria: Key B is created with permissions exceeding Key A's scope on any dimension, or the rejection does not specify the escalation dimensions.

Conformance Scoring

• Score 0: No account abstraction governance exists — session keys are granted with wildcard permissions, paymasters validate only target addresses, no session key inventory exists, and revocation is manual and non-recursive.
• Score 1: Session keys are scoped to target contracts and value limits. A session key inventory exists but may not be real-time. Paymaster validation checks target contract and function selector. Delegation depth is limited. Revocation is available but not recursive. This level addresses the most critical risks but leaves gaps in deep validation and lifecycle management.
• Score 2: All mandatory requirements are met. Permission templates standardise session key provisioning. Paymaster deep validation checks calldata parameters and routes. Recursive revocation is implemented with on-chain confirmation. Delegation depth is enforced at the smart contract level. Periodic permission audits identify over-permissioned keys. All lifecycle events are logged.
• Score 3: Verified through independent adversarial testing confirming that no known attack exploits the permission surface. Session key rotation minimises compromise windows. Paymaster spending analytics detect value extraction. Cross-chain session key governance provides unified management. Machine learning detects anomalous usage patterns. The permission template library is formally change-controlled.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Supports compliance
MiCA	Article 67 (Custody and Administration of Crypto-Assets)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.2, MANAGE 2.4	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Direct requirement

EU AI Act — Article 15 (Accuracy, Robustness and Cybersecurity)

Article 15 requires resilience against attempts by unauthorised third parties to exploit vulnerabilities in the AI system. Account abstraction's programmable permission surface is a vulnerability surface — overbroad session keys, insufficient paymaster validation, and recursive delegation chains are all exploitable vulnerabilities. AG-476's requirements for minimum-permission scoping, deep paymaster validation, and delegation depth enforcement directly implement the robustness measures that Article 15 mandates. Organisations must demonstrate that the AI agent's access to on-chain assets is controlled through well-governed, exploit-resistant permission mechanisms.

MiCA — Article 67 (Custody and Administration of Crypto-Assets)

MiCA Article 67 requires crypto-asset service providers to establish custody policies and procedures that ensure the safekeeping of crypto-assets and the keys providing access to them. Session keys are keys providing access to crypto-assets — they are cryptographic credentials that authorise transactions affecting custodied assets. MiCA's custody requirements therefore extend to session key management: the organisation must inventory all keys, scope their permissions to the minimum necessary, implement revocation capabilities, and maintain audit trails. AG-476's session key lifecycle management, permission scoping, and revocation requirements directly satisfy MiCA Article 67's custody governance expectations. A smart account where the agent holds an unscoped session key with 90-day expiry would not meet MiCA custody standards.

SOX — Section 404 (Internal Controls Over Financial Reporting)

Smart account operations that affect financial asset balances are relevant to financial reporting. Session keys that authorise transactions affecting reported asset values are internal controls — if they are misconfigured (overbroad), the control is ineffective. SOX auditors will assess whether session key permissions are appropriate for the authorised operations and whether the permission audit trail is adequate for control testing. AG-476's permission templates, lifecycle logging, and periodic permission audits provide the control evidence that SOX auditors require.

FCA SYSC — 6.1.1R (Systems and Controls)

The FCA expects firms to maintain adequate systems and controls for the custody and management of cryptoassets, including access credential management. Session keys and delegation grants are access credentials for cryptoasset accounts. SYSC 6.1.1R requires that these credentials be managed with controls proportionate to the value at risk. For a smart account holding $2.4 million in assets (Scenario A), the FCA would expect highly granular permission scoping, real-time credential inventory, rapid revocation capability, and comprehensive audit trails — precisely the controls mandated by AG-476.

DORA — Article 9 (ICT Risk Management Framework)

DORA requires financial entities to maintain an ICT risk management framework covering all digital operational risks. Smart account session keys, paymasters, and delegation mechanisms are ICT components that create operational risk — specifically the risk of unauthorised asset access through misconfigured permissions. DORA Article 9's requirements for risk identification, protection, detection, and response map to AG-476's controls: identification (session key inventory), protection (minimum-permission scoping, delegation depth limits), detection (usage monitoring, periodic audits), and response (recursive revocation with confirmation). DORA's emphasis on ICT third-party risk is particularly relevant when paymasters or session key infrastructure is provided by third parties.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Per-account, but potentially organisation-wide when shared paymaster infrastructure or delegation chains connect multiple smart accounts; in custody scenarios, blast radius extends to all client assets held in affected smart accounts

Consequence chain: An overbroad session key, an insufficiently validated paymaster, or an uncontrolled delegation chain creates an exploitable permission surface on the smart account. The immediate technical failure is permission scope violation — the agent (or an attacker leveraging the agent's credentials) executes operations that exceed the intended authority. The financial consequence is direct: Scenario A demonstrates $2.4 million in asset loss from a single overbroad session key; Scenario B demonstrates $89,000 in value extraction through paymaster policy gaps; Scenario C demonstrates $340,000 in loss from an ungovernable delegation chain. The operational cascade follows: the organisation must emergency-revoke all potentially affected credentials, audit every smart account's permission state, reconstruct the delegation tree to identify all active keys, and verify that no additional unauthorised operations occurred. For custodial operations, the failure triggers regulatory notification obligations under MiCA Article 67 and FCA custody rules — the organisation must report that custody credentials were misconfigured and client assets were at risk. The reputational consequence is particularly severe in institutional custody: the organisation's core value proposition — secure custody of digital assets — is directly undermined by a failure to govern the permission surface. Recovery requires re-establishing trust through independent security audits, permission architecture redesign, and demonstrated governance improvements. The severity is rated Critical because the failure directly enables asset theft from smart accounts with no technical recovery mechanism — stolen crypto-assets are generally irrecoverable.

Cross-references: AG-009 (Delegated Authority Governance), AG-475 (Gas Sponsorship Abuse Governance), AG-469 (Smart Contract Allowlist Governance), AG-470 (Vault Strategy Mandate Governance), AG-474 (Token Mint and Burn Authority Governance), AG-396 (Recursive Delegation Depth Governance), AG-010 (Time-Bounded Authority Enforcement), AG-012 (Credential & Secret Lifecycle Governance).