Session Resumption Integrity Governance

2. Summary

Session Resumption Integrity Governance requires that when an AI agent resumes a previously established connector session — reconnecting to an MCP server, A2A endpoint, or equivalent after interruption, timeout, or planned restart — the resumed session is verified for integrity, freshness, and continuity before any operational actions are executed. Session resumption is a uniquely dangerous moment in agent-connector interactions because the agent inherits state from the prior session (accumulated permissions, transaction context, partially completed workflows) without re-establishing that state from scratch. An attacker who can forge, replay, or manipulate session resumption tokens can inject the agent into a fabricated session state — one where permissions have been escalated, transaction limits have been exhausted, safety constraints have been removed, or partially completed workflows have been altered. This dimension mandates structural controls that ensure resumed sessions are authentic, current, and consistent with the governance state that existed when the session was last active.

3. Example

Scenario A — Replayed Session Token Bypasses Re-Authentication: An enterprise procurement agent maintains persistent sessions with three supplier MCP servers. The agent's session with Supplier B expires after 4 hours of inactivity. An attacker who previously intercepted a valid session token (captured during a network monitoring window) replays this token to the MCP server. The server accepts the replayed token because it validates the token's cryptographic signature without checking a server-side session registry or verifying token freshness. The attacker now holds an active session with Supplier B under the agent's identity. Over the next 6 hours, the attacker uses the session to place 23 fraudulent purchase orders totalling £1.74 million. The organisation discovers the breach when Supplier B invoices for goods never ordered by the legitimate agent.

What went wrong: The session token was a bearer token — possession was sufficient for access. No server-side session state was maintained to detect that the original session had expired. No freshness mechanism (nonce, sequence counter, or timestamp binding) prevented replay of the captured token. The session resumption accepted a stale token as valid. Consequence: £1.74 million in fraudulent procurement, credential revocation across all three supplier connections, FCA investigation into systems and controls, procurement process suspended for 3 weeks during remediation.

Scenario B — Stale Session State Causes Double Execution: A financial settlement agent maintains a session with a clearing house endpoint. During an overnight batch settlement run, the agent processes 1,247 settlement instructions. At instruction 891, the network connection drops for 45 seconds. The agent's session resumption logic reconnects and resumes the session. However, the session state cached on the agent side indicates that instruction 891 was "submitted but unconfirmed." The clearing house's session state shows instruction 891 as "received and executed." The agent resubmits instruction 891. The clearing house processes it as a new instruction because the session resumption did not synchronise state. The duplicated settlement instruction moves £4.2 million to a counterparty that has already received the payment, creating a £4.2 million reconciliation break that takes 11 business days to resolve and incurs £89,000 in financing costs.

What went wrong: The session resumption did not synchronise the agent's local session state with the remote endpoint's session state. Each side had a different view of which operations had completed. The resumption logic assumed that the agent's cached state was authoritative, but the network interruption occurred after the endpoint received the instruction but before the agent received the confirmation. No state reconciliation protocol existed. Consequence: £4.2 million reconciliation break, £89,000 financing costs, regulatory reporting under FCA SUP 15.3 for settlement failures, counterparty relationship damage.

Scenario C — Session State Injection Escalates Agent Permissions: A customer-facing agent connects to a multi-tool MCP server that provides both read-only data tools and write-capable action tools. The agent's session state includes a permission set: during the initial session, the trust bootstrap (AG-373) verified the agent's credentials and granted read-only permissions. The session is interrupted. An attacker intercepts the session resumption handshake and injects a modified session state object that includes write permissions for the "transfer_funds" tool. The MCP server's resumption logic deserialises the session state without verifying it against the original permission grant. The agent resumes with escalated permissions and subsequently uses the "transfer_funds" tool to process a customer request that should have been routed to human review. The transfer of £67,000 to a fraudulent payee account completes before the discrepancy is detected.

What went wrong: The session state was transmitted from the client side during resumption, and the server trusted it without verifying against its own authoritative session record. The session state was not signed or integrity-protected, allowing the attacker to modify the permission set. The server did not re-verify permissions during resumption. Consequence: £67,000 fraudulent transfer, customer compensation claim, FCA complaint investigation, mandatory security incident report to ICO under UK GDPR Article 33 (personal data involved in the transaction).

Scenario D — Governance Policy Changed During Session Gap: A compliance-checking agent has an active session with a regulatory data endpoint. The agent's session establishes that certain transaction types are permitted under the current regulatory regime. During a 3-hour session interruption (maintenance window), the organisation updates its compliance policy to restrict a transaction category due to a new sanctions designation. The agent resumes its session with the pre-update governance state and processes 14 transactions in the newly restricted category before the policy change propagates to the agent's runtime. The transactions violate sanctions requirements. Total transaction value: £2.1 million across 14 counterparties.

What went wrong: The session resumption restored the agent to the governance state that existed before the interruption, without checking whether governance policies had changed during the gap. The session state effectively froze the agent's compliance posture at the point of interruption. No mechanism required the agent to re-validate its governance context before resuming operations. Consequence: £2.1 million in sanctions-violating transactions, OFSI investigation, potential civil monetary penalty of up to £1 million or 50% of the estimated value of the breach, reputational damage, correspondent banking relationship review.

4. Requirement Statement

Scope: This dimension applies to any AI agent that resumes a previously established connector session rather than establishing a new session from scratch. A "session" is defined as a stateful interaction context between an agent and a remote endpoint that persists across multiple individual requests and maintains accumulated state (permissions, transaction context, workflow progress, negotiated parameters). The dimension applies regardless of the resumption mechanism: session tokens, TLS session tickets, session IDs, persistent connection handles, or any equivalent. If the agent's reconnection to a remote endpoint relies on previously established state rather than re-bootstrapping trust and permissions from zero, this dimension applies. Stateless interactions — where each request is independently authenticated and carries no accumulated state — are out of scope, though organisations should verify that interactions claimed to be stateless are genuinely stateless and do not carry implicit session state through cookies, cached tokens, or connection pooling.

4.1. A conforming system MUST verify the integrity of session state during resumption by comparing the client-side session state against an authoritative server-side session record, rejecting resumption if the states are inconsistent.

4.2. A conforming system MUST implement session freshness verification, ensuring that session tokens or resumption credentials include a freshness signal (timestamp, nonce, or monotonic sequence counter) that prevents replay of expired or previously used session material.

4.3. A conforming system MUST enforce a maximum session resumption window — a defined time period after which a session cannot be resumed and a full re-bootstrap (per AG-373) is required. The recommended maximum resumption window is 1 hour for high-risk sessions and 8 hours for standard sessions.

4.4. A conforming system MUST re-validate the agent's governance context during session resumption, confirming that mandate limits (AG-001), permission grants, capability whitelists (AG-369), and compliance policies have not changed during the session gap. If governance context has changed, the resumed session MUST operate under the updated governance context, not the stale pre-interruption context.

4.5. A conforming system MUST implement session state reconciliation during resumption, synchronising the agent's view of completed operations with the remote endpoint's view, to prevent duplicate execution of operations that were in-flight at the time of interruption.

4.6. A conforming system MUST cryptographically sign session state objects, ensuring that any tampering with session state (permission escalation, workflow modification, parameter alteration) is detected during resumption.

4.7. A conforming system MUST log every session resumption event with: the session identifier, the time of original session creation, the time of interruption, the time of resumption, the freshness verification result, the governance re-validation result, and the state reconciliation outcome.

4.8. A conforming system SHOULD implement session binding to the original trust bootstrap, such that a resumed session is cryptographically linked to the specific bootstrap event (AG-373) that established the original trust relationship, preventing session tokens from being used with different endpoints or different bootstrap contexts.

4.9. A conforming system SHOULD implement idempotency mechanisms for all operations that may be in-flight during session interruption, ensuring that resubmission of an in-flight operation produces the same result as the original submission rather than creating a duplicate.

4.10. A conforming system SHOULD maintain a real-time session registry that tracks all active sessions, their current state, and their governance context, enabling the organisation to invalidate any session immediately when a security event or governance change requires it.

4.11. A conforming system MAY implement progressive session degradation, where resumed sessions operate under tighter constraints (lower transaction limits, reduced capability sets) than freshly bootstrapped sessions, with full capabilities restored only after successful re-verification.

5. Rationale

Session resumption is an optimisation — it exists to avoid the overhead of full trust bootstrap on every reconnection. In traditional web applications, session resumption trades security for performance: rather than re-authenticating on every request, the server issues a session token that serves as proof of prior authentication. This trade-off is well-understood and generally acceptable for human-interactive web applications where sessions are short-lived, the user can re-authenticate easily, and the consequence of session compromise is limited to the user's own account.

For AI agents operating autonomous workflows, the trade-off calculus is fundamentally different. First, agent sessions carry richer state than web sessions. A web session typically tracks authentication status and user preferences. An agent session may track: accumulated permissions negotiated during bootstrap, partially completed multi-step workflows with intermediate state, transaction counters approaching mandate limits, compliance context including applicable regulations and risk parameters, and tool-specific state such as API rate limit budgets. Compromising this state has far broader consequences than compromising a web session cookie.

Second, agent sessions operate without human oversight of the resumption. When a human user's web session expires, the user is presented with a login screen — a natural checkpoint that provides an opportunity to verify identity and context. When an agent's session expires and resumes, no human is involved. The resumption happens automatically, and any compromise of the resumption process proceeds without human observation. The attacker's window of opportunity is not limited by human attention; it extends for as long as the resumed session is active.

Third, agent sessions may resume into a different governance context than the one that existed when the session was created. Governance policies change: mandate limits are adjusted, sanctions lists are updated, compliance rules are revised, capability whitelists are modified. A session that resumes with stale governance context is a session that operates under rules that no longer apply. For a financial agent, this can mean executing transactions that were permitted yesterday but are prohibited today. For a compliance agent, this can mean approving activities that violate newly imposed restrictions. The gap between session creation and session resumption is a governance blind spot that must be structurally addressed.

The double-execution problem (Scenario B) represents a particularly insidious failure mode. When a session interruption occurs during an in-flight operation, the agent and the endpoint may have inconsistent views of whether the operation completed. Without explicit state reconciliation, the agent's default behaviour is to retry — which may duplicate a financial transaction, resubmit a regulatory filing, or re-execute a physical control action. Idempotency at the protocol level is the established solution, but it must be implemented deliberately rather than assumed. Many connector protocols do not provide idempotency guarantees by default.

The session state injection attack (Scenario C) exploits a common architectural weakness: serialised session state that is transmitted from the client side and trusted by the server. This pattern, familiar from web application security (where session data stored in cookies has been a recurring vulnerability), carries into agent connector protocols. If the session state includes permission grants, capability lists, or workflow progress, and this state is not cryptographically signed and verified against server-side records, any party that can intercept and modify the session state can escalate the agent's permissions.

6. Implementation Guidance

Session Resumption Integrity Governance requires mechanisms that ensure resumed sessions are authentic, fresh, consistent, and operating under current governance context. The core principle is that session resumption must provide security guarantees equivalent to fresh session establishment, minus the computational overhead of full trust bootstrap.

Recommended patterns:

• Server-authoritative session state. Store all session state on the server side (or in an encrypted, signed session store that only the server can read). The client holds only an opaque session identifier. During resumption, the server loads the authoritative session state from its own store and compares it against any state the client presents. If the client's state diverges from the server's state, the server's state is authoritative, and the divergence triggers an investigation. This pattern eliminates client-side session state injection attacks entirely.
• Signed session tokens with embedded freshness. If session state must be transmitted (e.g., in stateless architectures), sign the entire session state object with a key held only by the issuing server. Include in the signed state: the session creation timestamp, the last-activity timestamp, a monotonic sequence counter, the original bootstrap event identifier (linking to AG-373), and a hash of the governance context at the time of last activity. During resumption, verify the signature, check the freshness constraints (maximum resumption window), and re-validate the governance context hash against the current governance state. If the governance context has changed, issue a new session with updated governance parameters.
• State reconciliation protocol. Implement an explicit reconciliation step during session resumption. Before resuming normal operations, the agent and the endpoint exchange their views of the session's operation history — specifically, the last N completed operations and any in-flight operations at the time of interruption. The reconciliation identifies operations that one side considers complete and the other considers in-flight. In-flight operations are resolved through idempotency checks (querying whether the operation was actually executed) before being retried.
• Governance checkpoint on resumption. Before resuming any operational activity, query the governance layer (mandate service, compliance policy store, capability whitelist) for the current governance context. Compare against the governance context embedded in the session state. If any governance parameter has changed — mandate limits adjusted, capabilities modified, compliance rules updated — apply the new governance context to the resumed session. This may mean that operations the agent planned to execute are no longer permitted.
• Session invalidation broadcast. Implement a mechanism to invalidate sessions in real time across all endpoints. When a security event occurs (credential compromise, governance policy change, anomaly detection), a broadcast message invalidates all affected sessions, forcing agents to re-bootstrap. This requires a session registry that tracks all active sessions and their associated endpoints.

Anti-patterns to avoid:

• Client-authoritative session state. Never trust session state transmitted by the client without cryptographic verification against server-side records. The client may be compromised, and the session state may be tampered with.
• Resuming without freshness checks. A session token that was valid yesterday may have been intercepted and is being replayed today. Without freshness verification (timestamp validation, nonce checking, sequence counter verification), replay attacks are trivially easy.
• Assuming governance continuity. The governance context at session resumption may differ from the context at session creation. Resuming under stale governance is operationally equivalent to operating without governance during the period between the policy change and the next full re-bootstrap.
• Retry-without-reconcile. Automatically retrying in-flight operations after session resumption without first confirming whether those operations already completed at the endpoint. This is the root cause of double-execution failures.
• Infinite session lifetime. Sessions that never expire and can always be resumed are sessions that can be replayed indefinitely. Maximum resumption windows must be enforced, with full re-bootstrap required after expiry.
• Treating session resumption as a lesser event than session creation. Session resumption inherits all the authority of the original session. A compromised resumption is as dangerous as a compromised bootstrap. Logging, monitoring, and verification should be equivalent.

Industry Considerations

Financial Services. Session resumption in settlement, clearing, and payment systems must include explicit state reconciliation to prevent double settlements. CPMI-IOSCO Principles for Financial Market Infrastructures (PFMI) Principle 8 (Settlement Finality) requires that settlement is "final and irrevocable" — a double settlement caused by session resumption failure violates this principle. The maximum resumption window for payment and settlement sessions should not exceed 15 minutes without full re-bootstrap. FCA PS21/3 (Operational Resilience) requires firms to test their ability to resume critical business services within impact tolerances, which must include agent session resumption scenarios.

Healthcare. Resumed sessions that access patient records must re-verify the agent's authorisation under the current access control policy. A session interrupted during a patient encounter may resume after the patient's consent status has changed (e.g., the patient revoked consent for data sharing during the interruption). HIPAA's minimum necessary standard (45 CFR 164.502(b)) requires that access be limited to what is necessary at the time of access — not at the time of original session creation.

Critical Infrastructure / CPS. Session resumption for agents controlling physical systems must include actuator state verification. If a session is interrupted while a control action is in progress, resumption must verify the current physical state before issuing further commands. Blindly resuming a control sequence based on stale session state can cause physical damage. IEC 61508 requires that safety-related systems verify their state after any interruption before resuming safety functions.

Crypto / Web3. Session resumption involving blockchain transaction signing must verify that nonces have not been consumed during the interruption. Replaying a session with a stale nonce can cause transaction failure or, worse, transaction reordering that enables front-running. The irreversibility of on-chain transactions makes double-execution catastrophic.

Maturity Model

Basic Implementation — Sessions have a defined maximum lifetime and a maximum resumption window. Session tokens include a timestamp that is verified during resumption. Expired sessions require full re-bootstrap per AG-373. Session resumption events are logged with basic details (session ID, resumption time, outcome). In-flight operations are retried after resumption without explicit reconciliation, relying on endpoint-side idempotency where available. This level addresses the most common failure mode (stale session replay) but does not address governance continuity, state injection, or double-execution in the absence of endpoint idempotency.

Intermediate Implementation — All basic capabilities plus: session state is stored server-side or is cryptographically signed with freshness signals. Session resumption includes explicit state reconciliation that synchronises the agent's and endpoint's view of completed operations. Governance context is re-validated on resumption, and sessions are updated to reflect any governance changes during the gap. A session registry tracks all active sessions and supports real-time invalidation. Bootstrap binding links resumed sessions to their original trust bootstrap event.

Advanced Implementation — All intermediate capabilities plus: progressive session degradation restricts resumed sessions until re-verification is complete. Anomaly detection identifies unusual resumption patterns (e.g., sessions resuming from different IP addresses, sessions resuming after unusually long gaps, or sessions resuming with state that diverges from server records). Automated session invalidation triggers on governance policy changes, security events, or anomaly detection. Red-team exercises specifically target session resumption, including token replay, state injection, and race conditions during reconciliation. Hardware-bound session tokens (tied to TPM or HSM) prevent token exfiltration and replay from different devices.

7. Evidence Requirements

Required artefacts:

• Session management policy. Documented policy specifying: maximum session lifetime, maximum resumption window, freshness verification mechanism, governance re-validation procedures, and state reconciliation protocol. Format: structured policy document with specific parameter values, not general principles.
• Session resumption logs. Timestamped records of every session resumption event, including: session identifier, original creation time, interruption time, resumption time, freshness verification result, governance context comparison (changed/unchanged), state reconciliation outcome (consistent/divergent with resolution), and final resumption decision (resumed/rejected). Minimum 12 months of continuous records.
• Session state integrity evidence. Cryptographic mechanism documentation showing how session state is signed, how signatures are verified during resumption, and how server-side session records are maintained. Architecture diagram showing the session state flow during resumption.
• Double-execution prevention evidence. Documentation of idempotency mechanisms for in-flight operations, including: how in-flight operations are identified, how their completion status is verified during reconciliation, and test results demonstrating that interrupted operations are not duplicated on resumption.
• Governance re-validation evidence. Records demonstrating that governance context changes during session gaps were detected and applied on resumption. At least 3 examples from production or realistic test scenarios showing: a governance change occurred during a session gap, the change was detected during resumption, and the resumed session operated under the updated governance context.

Retention requirements:

• Session resumption logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Session management policy versions: minimum 5 years or the life of the system, whichever is longer.
• Double-execution prevention test results: minimum 3 years or until superseded.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-374 compliance requires verification that session resumption is secure against replay, state injection, stale governance, and double-execution across a range of failure scenarios.

Test 8.1: Session Token Replay Prevention

• Stimulus: Capture a valid session token from an active session. Allow the session to expire (exceed the maximum resumption window). Attempt to resume the session using the captured token.
• Expected behaviour: The system rejects the resumption because the token has exceeded the maximum resumption window. A full re-bootstrap per AG-373 is required.
• Pass criteria: The expired token is rejected. No operational actions are executed under the expired session. A log entry records the rejected resumption attempt with the reason (expired resumption window).
• Fail criteria: The expired token is accepted and the session resumes, or the system falls back to a permissive mode that allows partial operation.

Test 8.2: Session State Integrity Verification

• Stimulus: Intercept a session resumption handshake and modify the session state object — specifically, escalate the permission set to include a capability not granted during the original bootstrap (e.g., adding write permission to a read-only session).
• Expected behaviour: The system detects the modification through cryptographic signature verification or server-side state comparison. The resumption is rejected.
• Pass criteria: The modified session state is rejected. An alert is generated indicating session state tampering. No operations execute under the escalated permissions.
• Fail criteria: The modified session state is accepted and the agent operates with escalated permissions.

Test 8.3: Governance Context Re-Validation

• Stimulus: Establish an agent session with a remote endpoint. During an active session, update a governance parameter (e.g., reduce the agent's transaction limit from £50,000 to £25,000). Interrupt the session. Resume the session. Attempt to execute a transaction of £35,000 (within the old limit, exceeding the new limit).
• Expected behaviour: During resumption, the system detects that the governance context has changed (transaction limit reduced). The resumed session operates under the new £25,000 limit. The £35,000 transaction is blocked.
• Pass criteria: The governance change is detected during resumption. The resumed session enforces the new limit. The £35,000 transaction is blocked with a structured rejection citing the updated mandate.
• Fail criteria: The resumed session operates under the stale £50,000 limit and the £35,000 transaction executes.

Test 8.4: Double-Execution Prevention (State Reconciliation)

• Stimulus: Initiate a financial transaction through the agent-endpoint session. Interrupt the network connection after the endpoint has received and executed the transaction but before the agent receives confirmation. Resume the session. Observe whether the agent resubmits the transaction.
• Expected behaviour: During session resumption, the state reconciliation protocol identifies the transaction as "in-flight from agent perspective, completed from endpoint perspective." The agent updates its local state to reflect the completed transaction without resubmitting it.
• Pass criteria: The transaction is executed exactly once. The reconciliation correctly identifies the asymmetric completion state. No duplicate transaction is created.
• Fail criteria: The transaction is executed twice, creating a duplicate. The reconciliation fails to detect the asymmetric state.

Test 8.5: Maximum Resumption Window Enforcement

• Stimulus: Establish a session. Allow exactly the maximum resumption window to elapse (e.g., 1 hour for high-risk sessions). Attempt resumption at T+59 minutes (within window) and at T+61 minutes (outside window).
• Expected behaviour: Resumption at T+59 minutes succeeds (subject to all other verification checks). Resumption at T+61 minutes is rejected, requiring full re-bootstrap.
• Pass criteria: The boundary is precise. Resumption within the window succeeds; resumption outside the window is rejected. No grace period allows indefinite extension.
• Fail criteria: Resumption outside the maximum window succeeds, or the window boundary is not enforced precisely.

Test 8.6: Bootstrap Binding Verification

• Stimulus: Capture a valid session token from a session bootstrapped with Endpoint A. Attempt to use this token to resume a session with Endpoint B (a different remote endpoint).
• Expected behaviour: The system rejects the resumption because the session token is bound to the original bootstrap event with Endpoint A. The token cannot be used to establish or resume a session with a different endpoint.
• Pass criteria: The cross-endpoint resumption is rejected. A log entry records the attempt with the reason (bootstrap binding mismatch).
• Fail criteria: The session token is accepted by Endpoint B, allowing the agent to establish a session with an endpoint it did not bootstrap with.

Test 8.7: Resumption Under Registry Unavailability

• Stimulus: Make the session registry (or the governance context service) unavailable. Attempt to resume a session.
• Expected behaviour: The system cannot verify session state, governance context, or freshness because the required services are unavailable. Session resumption is blocked. The agent operates in a degraded mode without remote tool access until services are restored. Intersects with AG-008.
• Pass criteria: No session resumes while verification services are unavailable. The system fails closed rather than failing open.
• Fail criteria: Sessions resume without verification when the registry or governance service is unavailable, or the agent uses cached state without fresh verification.

Conformance Scoring

• Score 0: No session resumption governance — sessions resume without freshness checks, state verification, or governance re-validation; tokens can be replayed indefinitely.
• Score 1: Session lifetime and resumption windows are enforced, and session tokens include freshness signals — basic replay prevention is in place, but state integrity verification and governance re-validation are not implemented.
• Score 2: Full session resumption governance with signed state, server-side verification, governance re-validation, state reconciliation, and comprehensive logging — all MUST requirements are met through structural controls.
• Score 3: Verified by independent adversarial testing including token replay, state injection, governance bypass, double-execution exploitation, and cross-endpoint token reuse — an independent party has attempted to compromise session resumption and failed.

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)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Direct requirement
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.1, MANAGE 2.2	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment)	Supports compliance
DORA	Article 9 (ICT Risk Management), Article 11 (Response and Recovery)	Direct requirement

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

Article 15 requires high-risk AI systems to be resilient against "attempts by unauthorised third parties to alter their use or performance by exploiting system vulnerabilities." Session resumption is a system vulnerability when it lacks integrity verification — an attacker who can replay or inject session state can alter the AI system's performance by placing it in a fabricated operational context. AG-374 directly implements cybersecurity resilience for the session resumption attack surface. The requirement for robustness under "conditions of use that can reasonably be expected" explicitly includes network interruptions and reconnections, which are the normal triggers for session resumption.

EU AI Act — Article 9 (Risk Management System)

Session resumption failures — particularly double execution and stale governance — are foreseeable risks that must be identified, assessed, and mitigated under Article 9's risk management requirements. The scenarios in Section 3 represent risks that any competent risk assessment of agent-connector architectures would identify.

SOX — Section 404 (Internal Controls Over Financial Reporting)

Double execution of financial transactions through session resumption failure is a direct internal control deficiency. A SOX auditor assessing an AI agent that executes financial transactions will ask: "What prevents a duplicate transaction when a session is interrupted and resumed?" If the answer is "we rely on the endpoint to detect duplicates" without formal idempotency guarantees, the control is deficient. AG-374's state reconciliation and idempotency requirements directly address this control objective. The governance re-validation requirement also ensures that financial controls (transaction limits, approval thresholds) cannot be bypassed by resuming a session created before the controls were tightened — a scenario that would constitute a material weakness if it resulted in transactions exceeding authorised limits.

FCA SYSC — 6.1.1R (Systems and Controls)

SYSC 6.1.1R requires adequate systems and controls. For AI agents in financial services, "adequate" means controls that address the specific risks of the technology — including session resumption risks that do not exist for human operators. The FCA's supervisory approach, informed by SS1/23 on model risk management, expects firms to identify and mitigate technology-specific risks. Session state injection, stale governance, and double execution are technology-specific risks that require technology-specific controls. A firm that deploys AI agents without session resumption governance fails to meet the "adequate" standard for the risks its technology introduces.

NIST AI RMF — GOVERN 1.1, MANAGE 2.2

GOVERN 1.1 addresses legal and regulatory compliance expectations for AI systems. MANAGE 2.2 addresses mechanisms for tracking and managing identified AI risks. Session resumption integrity is a managed risk — identified through risk assessment, mitigated through structural controls, and monitored through session resumption logging and anomaly detection.

ISO 42001 — Clause 6.1, Clause 8.2

Clause 6.1 requires actions to address risks within the AI management system. Clause 8.2 requires AI risk assessment. Session resumption is an operational risk for AI agents that maintain stateful connections. ISO 42001 compliance requires that this risk is assessed, that controls are implemented, and that the effectiveness of controls is monitored — all of which AG-374 provides through its requirement, evidence, and test specifications.

DORA — Article 9, Article 11

Article 9 requires ICT risk management controls. Article 11 specifically addresses response and recovery, requiring financial entities to implement "ICT business continuity management" that includes "mechanisms to promptly detect anomalous activities." Session resumption is a recovery mechanism — the agent recovers from a connection interruption. DORA requires that this recovery maintains operational integrity and detects anomalous activities (such as state injection or governance bypass). AG-374's state reconciliation, governance re-validation, and anomaly detection capabilities directly implement DORA's response and recovery requirements for AI agent connector sessions. Article 11's requirement for "testing of ICT business continuity plans" maps to the adversarial testing requirement at Score 3.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Transaction-level to organisation-wide — depending on the session's scope and the nature of the resumption failure

Consequence chain: Session resumption integrity failure manifests through four primary paths, each with escalating consequences. Path 1 — Replay: an attacker replays a captured session token to impersonate the agent, gaining access to all capabilities the session carried; the immediate impact is unauthorised access to remote endpoints, escalating to fraudulent transactions, data exfiltration, or system manipulation depending on the session's capabilities; documented financial impact in session replay attacks against automated trading systems ranges from £200,000 to £8.5 million per incident. Path 2 — State injection: an attacker modifies session state to escalate permissions; the immediate impact is unauthorised capability access, escalating to execution of actions the agent was never authorised to perform; the blast radius extends to every system the escalated capabilities can reach. Path 3 — Double execution: a session resumes without state reconciliation, causing in-flight operations to be duplicated; the immediate impact is duplicate financial transactions, regulatory filings, or control actions; the blast radius depends on the operation duplicated — a duplicate £4.2 million settlement creates a reconciliation crisis, while a duplicate safety-critical control action can cause physical damage. Path 4 — Stale governance: a session resumes under pre-update governance context, allowing the agent to execute actions that current policies prohibit; the immediate impact is policy violations, escalating to regulatory enforcement for sanctions violations, mandate breaches, or compliance failures; the blast radius is organisation-wide when the stale governance affects compliance with sanctions regimes, where a single violation can trigger correspondent banking reviews, regulatory investigations, and civil monetary penalties. The compounding risk is that all four paths can be exploited simultaneously — an attacker who replays a session token with injected state during a governance gap can achieve maximum impact across all consequence chains.