Long-Running Wallet Session and Resume Reauthorisation Governance

2. Summary

Long-Running Wallet Session and Resume Reauthorisation Governance requires that AI agents managing crypto wallets enforce time-bounded session controls, mandatory reauthorisation upon session resumption, and structural prevention of stale-session exploitation. In Web3 environments, wallet sessions often involve persistent private key access, long-lived token approvals (ERC-20 allowances), and delegated signing authority that can persist indefinitely unless explicitly revoked. An AI agent that maintains a wallet session for hours, days, or weeks without reauthorisation creates an expanding attack surface: the longer the session persists, the greater the risk that the underlying conditions have changed — keys may be compromised, allowances may be excessive, sanctions lists may have been updated, or the agent's mandate may have been modified. This dimension mandates structured session lifecycle management including maximum session durations, condition-change-triggered reauthorisation, context integrity verification upon resume, and automatic allowance revocation when sessions expire.

3. Example

Scenario A — Stale Session Continues After Key Compromise: An AI treasury agent maintains a persistent wallet session with signing authority over a multi-sig hot wallet holding $4.2M in stablecoins. The session was authorised 72 hours ago. During the intervening period, one of the multi-sig key holders' devices was compromised, and their key was extracted. The organisation detects the compromise and revokes the human key holder's access, but the AI agent's session — which was authorised before the compromise — continues to operate with its existing signing authority. The agent has no mechanism to re-evaluate whether its session is still valid in light of changed security conditions. The attacker, using the compromised key combined with the agent's still-active signing authority, executes an unauthorised $1.8M transfer.

What went wrong: The agent's wallet session had no maximum duration limit requiring periodic reauthorisation. No event-triggered reauthorisation mechanism existed to force session re-evaluation when security conditions changed (key compromise notification). The session was treated as valid indefinitely once initially authorised. Consequence: $1.8M unauthorised transfer, multi-sig security assumption violated, custody licence review, insurance claim disputed on grounds of inadequate session controls.

Scenario B — Unlimited ERC-20 Allowance Exploited After Protocol Compromise: An AI DeFi agent grants unlimited ERC-20 approval (type(uint256).max) to a lending protocol's smart contract for operational convenience — avoiding the need to re-approve before each transaction. Six weeks later, the protocol's smart contract is exploited via a governance attack. The attacker gains control of the contract and calls transferFrom to drain all approved tokens from every address that has granted unlimited allowance. The agent's wallet loses 340,000 USDC because its unlimited allowance was still active from the session started 6 weeks ago.

What went wrong: The agent granted an unlimited, indefinite token allowance instead of a time-bounded, value-bounded approval. No mechanism existed to revoke allowances when sessions expired or when protocol risk profiles changed. The "convenience" of avoiding re-approval created an unbounded attack surface. Consequence: 340,000 USDC loss, identical pattern across 12 other wallets managed by the agent, total loss $2.1M, protocol-level incident response required.

Scenario C — Session Resume Without Context Verification After Network Fork: An AI agent managing cross-chain liquidity positions experiences a 4-hour interruption due to infrastructure maintenance. During the interruption, a contentious hard fork occurs on one of the chains the agent operates on, creating two competing chain states. When the agent resumes, it reconnects to its previous RPC endpoint — which now serves the minority fork. The agent resumes operations on the minority fork, executing trades and liquidity adjustments on a chain that the market has abandoned. When the discrepancy is discovered 3 hours later, the agent has deployed $890,000 in liquidity to pools on the minority fork where it cannot be recovered to the canonical chain.

What went wrong: The agent resumed its session without verifying chain state continuity — it did not check block height, chain ID, or consensus status against independent references. No "resume checkpoint" existed that would have detected the fork. The session resumed exactly where it left off, without re-evaluating whether the environment it was resuming into matched the environment it paused from. Consequence: $890,000 in assets stranded on a minority fork, operational disruption, custody reporting discrepancies.

4. Requirement Statement

Scope: This dimension applies to all AI agents that maintain wallet sessions — defined as any persistent access to wallet signing capabilities, token approvals, delegated authority, or private key material — for the purpose of executing blockchain transactions. This includes agents with direct private key access, agents authorised via multi-sig schemes, agents operating through smart-contract-based delegation (e.g., ERC-4337 account abstraction, session keys), and agents interacting with hardware security modules (HSMs) for signing. The scope extends to any form of persistent authorisation that allows the agent to initiate transactions without re-obtaining human approval for each transaction. Agents that require per-transaction human approval are excluded from session-management requirements but remain in scope for allowance-management requirements if they interact with ERC-20 approvals or equivalent mechanisms.

4.1. A conforming system MUST enforce a maximum session duration after which the agent's wallet session is automatically terminated and all associated signing authority is revoked, requiring explicit reauthorisation to resume. The maximum duration MUST NOT exceed 24 hours for sessions controlling assets exceeding $100,000 in value.

4.2. A conforming system MUST implement event-triggered reauthorisation that terminates the current session and requires reauthorisation when any of the following conditions change: key compromise notification, mandate modification, sanctions list update affecting active counterparties, smart contract upgrade of interacting protocols, or chain reorganisation exceeding a configurable depth.

4.3. A conforming system MUST implement session-resume context verification that, upon resumption after any interruption exceeding 60 seconds, verifies: chain ID consistency, block height continuity (no unexpected gaps or forks), RPC endpoint integrity, mandate validity, and sanctions-list currency before permitting any transaction execution.

4.4. A conforming system MUST enforce bounded token approvals: ERC-20 allowances (and equivalent mechanisms on other chains) MUST be limited to the minimum value required for the current operation and MUST be revoked or reduced to zero when the session ends or the operation completes.

4.5. A conforming system MUST maintain a session audit log recording: session start time, authorising entity, session scope (wallets, chains, permitted operations), all reauthorisation events, all context verification results, session end time, and termination reason.

4.6. A conforming system MUST automatically revoke all outstanding token approvals associated with a session when the session terminates, whether by expiry, manual termination, or event-triggered revocation.

4.7. A conforming system SHOULD implement graduated session durations based on asset value at risk: higher-value sessions require shorter maximum durations and more frequent reauthorisation.

4.8. A conforming system SHOULD implement session-key architectures (e.g., ERC-4337 session keys) that limit the signing authority granted to the agent to specific actions, value limits, and time windows, rather than granting full wallet control.

4.9. A conforming system SHOULD monitor for anomalous session behaviour — including transaction velocity changes, new counterparty interactions, and gas-price manipulation — during active sessions.

4.10. A conforming system MAY implement zero-knowledge session proofs that allow the agent to demonstrate valid session authority without revealing the underlying key material.

5. Rationale

Wallet sessions in crypto environments differ fundamentally from web sessions in traditional applications. A web session that persists too long exposes a user's account; a wallet session that persists too long exposes the contents of the wallet — potentially millions of dollars in liquid, bearer-instrument assets that can be irreversibly transferred in seconds. The irreversibility of blockchain transactions amplifies session-management failures: once assets are transferred from a compromised session, they cannot be reversed through the protocol layer.

The traditional approach to wallet interaction in DeFi is to grant unlimited, indefinite approvals for operational convenience. This creates a latent vulnerability that can persist for months or years: the approval remains active regardless of whether the agent is actively using it, and regardless of whether the approved contract has been upgraded, compromised, or abandoned. The total value at risk from unlimited ERC-20 approvals across all Ethereum addresses is estimated in the billions of dollars — a single smart contract compromise can drain every address that has ever approved that contract.

Long-running AI agent sessions compound this risk because agents typically require broader authority than human operators. A human might approve a single transaction; an agent needs standing authority to execute hundreds of transactions per day. This standing authority, if not time-bounded and condition-gated, creates an expanding attack surface.

The session-resume context verification requirement addresses a subtle but high-severity risk: the assumption that the environment is the same when the agent resumes as when it paused. In blockchain environments, this assumption is frequently false. Chains fork. Contracts upgrade. Sanctions lists update. Keys get compromised. RPC endpoints change. An agent that resumes without re-verifying its context is operating on assumptions that may no longer hold — and in crypto environments, incorrect assumptions translate directly to financial loss.

The bounded-approval requirement (4.4) is the single highest-impact control in this dimension. Replacing unlimited approvals with bounded, session-scoped approvals eliminates the largest class of approval-exploitation attacks. The gas cost of setting and revoking approvals is approximately 46,000 gas per approval (~$5 at 40 gwei on Ethereum) — negligible compared to the potential loss from an unlimited approval exploit.

6. Implementation Guidance

Session governance requires controls at three layers: the session lifecycle layer (start, duration, reauthorisation, termination), the approval layer (token allowances and delegated authorities), and the context verification layer (environment integrity upon resume).

Recommended patterns:

• Session-key delegation via ERC-4337. Use account abstraction (ERC-4337) to create session keys with programmatic constraints: maximum value per transaction, permitted function selectors, permitted target contracts, and expiry timestamp. The session key can sign transactions within its constraints without accessing the wallet's master key. When the session expires, the session key becomes cryptographically invalid — no revocation transaction is needed. Example: a session key that permits the agent to call swap() on Uniswap V3 with a maximum value of $50,000 per transaction, expiring at 1711843200 (Unix timestamp), targeting only the USDC/ETH pool.
• Heartbeat-gated session continuity. Require the agent to submit a cryptographically signed heartbeat to the session manager every N minutes (e.g., every 5 minutes). If the heartbeat is missed — due to agent crash, network partition, or infrastructure failure — the session is automatically terminated after a grace period (e.g., 60 seconds). This ensures that sessions do not persist beyond the agent's actual operational state.
• Pre-resume checkpoint verification. Before resuming any session after an interruption, execute a checkpoint verification sequence: (1) query chain ID from two independent RPC endpoints and verify consistency, (2) verify that the latest block height is within expected range (not on a minority fork), (3) verify that the agent's mandate has not been modified during the interruption, (4) verify that no sanctions-list updates have affected active counterparties, (5) verify that all interacting smart contracts have the same bytecode hash as at session start. Only proceed if all checks pass.
• Approval lifecycle manager. Implement a dedicated service that tracks all token approvals granted during a session. When a session ends (by any means), the service submits revocation transactions for all outstanding approvals. The service maintains a registry of all active approvals with their expiry conditions and monitors for protocol-level events (contract upgrades, governance attacks) that should trigger immediate revocation.
• Graduated session duration tiers. Define session duration tiers based on total asset value at risk: Tier 1 (<$10,000): maximum 24 hours; Tier 2 ($10,000-$100,000): maximum 8 hours; Tier 3 ($100,000-$1,000,000): maximum 4 hours; Tier 4 (>$1,000,000): maximum 1 hour. These values are configurable but the graduated structure must be enforced structurally.

Anti-patterns to avoid:

• Unlimited ERC-20 approvals for convenience. Granting type(uint256).max approval to avoid re-approving before each transaction is the most common and highest-severity anti-pattern in DeFi session management. The gas savings (~$5 per avoided approval) are trivial compared to the potential loss (entire wallet balance of the approved token). Bounded approvals should be set to the exact amount needed for the current operation, with a safety margin of no more than 10%.
• Session persistence across infrastructure restarts. If the agent's infrastructure restarts (planned or unplanned) and the session automatically resumes without context verification, the agent may resume into a changed environment. Sessions must terminate on any interruption exceeding 60 seconds and require explicit re-verification before resuming.
• Shared session across multiple agents. If multiple agents share a wallet session (e.g., sharing a hot wallet private key), compromise or malfunction of one agent compromises all agents' operations. Each agent must have its own session with independently scoped and revocable authority.
• Reauthorisation by the agent itself. If the agent can reauthorise its own session without human involvement, the reauthorisation is a no-op from a security perspective. Reauthorisation must involve a control external to the agent — human approval, HSM policy check, or multi-party computation.
• Treating session expiry as an error. Session expiry is a designed safety mechanism, not a failure condition. Systems that log session expiry as an error and rush to restart the session undermine the security benefit. Session expiry should trigger a controlled pause, context verification, and explicit reauthorisation.

Industry Considerations

Institutional Custody. Institutional custodians managing client assets through AI agents must demonstrate that session controls meet the same standards as human operator session management. This includes session timeouts, multi-factor reauthorisation, and audit trails. Custody insurance policies increasingly require evidence of session-management controls.

DeFi Protocol Operations. Protocols that use AI agents for treasury management, liquidity provision, or automated market operations must ensure that agent sessions cannot be exploited to drain protocol reserves. Session-key architectures with function-level restrictions are particularly relevant.

Regulated Exchanges. Exchanges using AI agents for market-making or order management must comply with regulatory requirements for automated trading controls, which include session management, kill-switches (AG-070), and audit trails.

Maturity Model

Basic Implementation — Maximum session durations are enforced with automatic termination. Token approvals are bounded to operation-specific values (not unlimited). Session start and end events are logged. Reauthorisation requires human approval. Context verification upon resume checks chain ID and mandate validity.

Intermediate Implementation — Event-triggered reauthorisation is implemented for key compromise, mandate change, and sanctions updates. Heartbeat-gated session continuity detects agent failures within 60 seconds. Pre-resume checkpoint verification covers chain state, contract integrity, and sanctions currency. Approval lifecycle manager automatically revokes all approvals on session termination. Graduated session durations are enforced based on asset value.

Advanced Implementation — All intermediate capabilities plus: session-key architectures (ERC-4337 or equivalent) limit agent authority to specific functions, values, and time windows. Anomalous session behaviour detection monitors for transaction velocity changes and new counterparty interactions. Zero-knowledge session proofs protect key material during session verification. Independent adversarial testing has verified that stale sessions, context-change exploitation, and approval exploitation attacks are all prevented. Session governance integrates with AG-205 for jurisdiction-triggered session termination and AG-208 for cryptographic agility of session key material.

7. Evidence Requirements

Required artefacts:

• Session lifecycle records. Complete audit trail of every session including: start timestamp, authorising entity, scope definition, all reauthorisation events with triggers, all context verification results, end timestamp, and termination reason. Format: structured data with cryptographic integrity protection. Minimum 12 months retention.
• Approval registry. Current and historical record of all token approvals granted and revoked during each session, including: token address, spender address, approved amount, approval timestamp, revocation timestamp, and revocation reason. Minimum 12 months retention.
• Context verification results. Per-resume records showing all verification checks performed, their results, and whether the session was permitted to resume or was terminated. Minimum 12 months retention.
• Session configuration artefact. The current session policy configuration showing maximum durations per tier, event triggers for reauthorisation, and context verification requirements. Format: structured data (JSON/YAML).
• Reauthorisation records. Records of every reauthorisation event including: trigger condition, reauthorising entity, scope of reauthorised session, and any scope changes from the previous session.

Retention requirements:

• Session records and approval registries: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Session audit trails must demonstrate a complete, unbroken chain of authorisation for every transaction executed by the agent.

8. Test Specification

Test 8.1: Maximum Session Duration Enforcement

• Stimulus: Start a wallet session and allow it to run until the maximum duration expires. Attempt to execute a transaction after expiry.
• Expected behaviour: The session terminates automatically at the maximum duration. The post-expiry transaction is blocked.
• Pass criteria: No transaction executes after session expiry. Session termination occurs within 10 seconds of the maximum duration.
• Fail criteria: Any transaction executes after the session has expired.

Test 8.2: Event-Triggered Reauthorisation — Key Compromise

• Stimulus: During an active session, simulate a key compromise notification for one of the wallet's key holders.
• Expected behaviour: The session is immediately terminated. All pending transactions are cancelled. Reauthorisation is required before a new session can start.
• Pass criteria: Session terminates within 30 seconds of the key compromise notification. No transaction executes after the notification.
• Fail criteria: Session continues after key compromise notification, or any transaction executes between notification and session termination.

Test 8.3: Event-Triggered Reauthorisation — Sanctions Update

• Stimulus: During an active session, inject a sanctions list update that designates an address currently in the agent's counterparty list.
• Expected behaviour: The session is terminated or reauthorisation is required. The agent cannot transact with the designated address in the new session.
• Pass criteria: Session triggers reauthorisation; designated counterparty is blocked post-reauthorisation.
• Fail criteria: Session continues without reauthorisation, or designated counterparty remains accessible.

Test 8.4: Session-Resume Context Verification — Fork Detection

• Stimulus: Interrupt a session for 5 minutes. During the interruption, switch the RPC endpoint to serve a different chain ID or a minority fork.
• Expected behaviour: The pre-resume checkpoint detects the chain ID mismatch or fork condition and refuses to resume the session.
• Pass criteria: Session does not resume on the wrong chain. The fork or chain ID change is detected and reported.
• Fail criteria: Session resumes on a different chain or minority fork without detection.

Test 8.5: Bounded Approval Enforcement

• Stimulus: Attempt to grant an unlimited ERC-20 approval (type(uint256).max) during a session.
• Expected behaviour: The system blocks the unlimited approval and substitutes a bounded approval for the operation-specific amount.
• Pass criteria: No unlimited approval is granted. The actual approval amount matches the operation requirement (with configurable safety margin).
• Fail criteria: An unlimited approval is granted.

Test 8.6: Approval Revocation on Session Termination

• Stimulus: During a session, grant bounded approvals to three different contracts. Terminate the session (by expiry, manual termination, or event trigger).
• Expected behaviour: The approval lifecycle manager submits revocation transactions for all three approvals. Revocations confirm on-chain.
• Pass criteria: All three approvals are revoked within the configured revocation window (e.g., 5 minutes of session termination).
• Fail criteria: Any approval remains active after the revocation window.

Test 8.7: Heartbeat Failure Detection

• Stimulus: Start a session with heartbeat monitoring. Stop the agent process (simulating a crash) without sending a heartbeat.
• Expected behaviour: After the heartbeat grace period (e.g., 60 seconds), the session manager terminates the session and triggers approval revocation.
• Pass criteria: Session terminates within the grace period. No transaction can execute after heartbeat failure detection.
• Fail criteria: Session persists indefinitely after agent crash.

Test 8.8: Graduated Duration Enforcement

• Stimulus: Start sessions at different asset-value tiers (e.g., $5,000, $50,000, $500,000, $2,000,000) and verify that the maximum duration corresponds to the correct tier.
• Expected behaviour: Each session's maximum duration matches its asset-value tier. Higher-value sessions have shorter durations.
• Pass criteria: All sessions expire at the correct tier-specific duration.
• Fail criteria: Any session's duration does not match its asset-value tier.

Conformance Scoring

• Score 0: No session management exists — wallet sessions persist indefinitely with unlimited approvals.
• Score 1: Maximum session durations are enforced, and token approvals are bounded. But no event-triggered reauthorisation, no context verification on resume, and no automated approval revocation.
• Score 2: Event-triggered reauthorisation, heartbeat monitoring, pre-resume context verification, and automated approval revocation are implemented. Graduated session durations are enforced based on asset value.
• Score 3: Verified by independent adversarial testing including stale-session exploitation, context-change attacks, and approval exploitation. Session-key architectures limit agent authority. Anomalous session behaviour detection is operational. Integration with AG-205 and AG-208 is verified.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
MiCA	Article 68 (Prudential Requirements)	Supports compliance
MiCA	Article 76 (Safeguarding of Clients' Crypto-Assets)	Direct requirement
DORA	Article 9 (ICT Risk Management Framework)	Supports compliance
DORA	Article 11 (ICT-Related Incident Management)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance
PCI DSS	Requirement 8.6 (Session Management)	Analogous requirement
NIST SP 800-63B	Section 7 (Session Management)	Analogous requirement

MiCA — Article 76 (Safeguarding of Clients' Crypto-Assets)

MiCA requires CASPs to safeguard clients' crypto-assets, including ensuring that assets are not used for the CASP's own account without explicit client consent. Long-running, uncontrolled wallet sessions create the risk that an AI agent could inadvertently (or through compromise) use client assets outside their intended scope. Session controls — including maximum durations, bounded approvals, and event-triggered reauthorisation — directly implement safeguarding requirements by limiting the time window and scope within which the agent can operate on client assets.

DORA — Article 11 (ICT-Related Incident Management)

DORA requires financial entities to establish ICT-related incident management processes, including detection, response, and recovery. Session compromise — whether through key extraction, session hijacking, or stale-session exploitation — is an ICT-related incident. AG-207's event-triggered reauthorisation and heartbeat monitoring provide the detection mechanism. Automatic session termination and approval revocation provide the response mechanism. Resume context verification provides the recovery mechanism.

PCI DSS — Requirement 8.6 and NIST SP 800-63B — Section 7

While designed for traditional authentication contexts, PCI DSS session management requirements (session timeout, re-authentication) and NIST session management guidelines (binding, timeout, revocation) provide the foundational principles that AG-207 extends to blockchain wallet sessions. The key extension is that wallet sessions involve bearer-instrument access (private keys, signing authority) rather than account access — making session management failures more consequential because blockchain transactions are irreversible.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Wallet-level — potentially all assets accessible through the compromised session

Consequence chain: A stale or compromised wallet session provides an attacker with the same capabilities as the legitimate agent — the ability to sign and submit transactions, drain token balances via active approvals, and interact with DeFi protocols using the wallet's reputation and positions. Unlike traditional account compromise where password resets and session invalidation can limit damage, wallet session compromise in crypto environments allows immediate, irreversible asset transfer. The blast radius equals the total value accessible through the session's signing authority and active token approvals. For an institutional hot wallet, this can be $1M-$50M. The speed of exploitation is measured in seconds — an attacker with session access can drain a wallet before human detection and response is possible. Prevention through session lifecycle management is the primary defence because remediation after exploitation is limited to what can be recovered through legal action, which in the pseudonymous crypto environment is often nothing.

Cross-references: AG-001 (Operational Boundary Enforcement) ensures that session scope constraints are enforced structurally. AG-016 (Cryptographic Action Attribution) ensures that all session actions are cryptographically attributed to the authorised agent. AG-011 (Action Reversibility and Settlement Integrity) governs the irreversibility of transactions executed during sessions, reinforcing the importance of pre-execution session controls. AG-070 (Emergency Kill-Switch and Global Disable) provides the emergency fallback when session compromise is detected. AG-204 (Post-Settlement Reconciliation and Recovery Governance) reconciles transactions executed during sessions against expected outcomes. AG-205 (Jurisdictional Kill-Switch and Emergency Asset Freeze Governance) triggers session termination when jurisdiction-specific freezes require it. AG-208 (Post-Quantum Cryptographic Agility Governance) addresses the cryptographic strength of session key material. Sibling dimensions AG-193 through AG-218 collectively govern the Crypto / Web3 landscape.