Session Binding Governance

2. Summary

Session Binding Governance requires that every sensitive governance session is cryptographically bound to the authenticated identity, the specific device, and the approval context that established it. A session that can be detached from these bindings — stolen via cookie theft, replayed from another device, or hijacked through a man-in-the-middle attack — allows an attacker to inherit the authenticated user's governance authority without re-authenticating. AG-285 ensures that governance sessions are non-transferable, non-replayable, and continuously validated against the original authentication context throughout their lifetime.

3. Example

Scenario A — Session Token Theft Enables Governance Takeover: A governance administrator authenticates to the agent management platform with MFA from a managed laptop. A browser extension (installed for personal use) exfiltrates the session cookie. The attacker imports the cookie into a browser on their own machine and gains full access to the governance platform — they can view agent configurations, modify mandates, and approve overrides. The session remains valid for 8 hours (the default timeout). During this window the attacker modifies the mandate of a financial agent, raising its per-transaction limit from £50,000 to £2,000,000.

What went wrong: The session token was a bearer token — whoever holds it has the session. No binding to the device, TLS channel, or IP address existed. The token was extractable by JavaScript (no HttpOnly flag, or the extension had sufficient permissions). The session lifetime of 8 hours provided a long exploitation window. Consequence: £1,950,000 increase in per-transaction risk exposure, potential for fraudulent transactions during the 8-hour window, mandatory incident response.

Scenario B — Man-in-the-Middle Hijacks Approval Session: A mandate approver connects to the agent governance platform over a public Wi-Fi network. An attacker on the same network performs an SSL stripping attack, downgrading the HTTPS connection. The attacker intercepts the session establishment and inserts themselves between the approver and the platform. The approver believes they are approving a mandate change for Agent-47 with a £100,000 limit, but the attacker modifies the request in transit to approve a £5,000,000 limit for Agent-12. The platform records the approval as coming from the legitimate approver.

What went wrong: The session was not bound to a specific TLS channel. The approval was not signed by the approver's device. The platform relied on the transport layer for integrity but the transport layer was compromised. Channel binding (tying the session token to the TLS session's unique channel ID) would have detected the interception. Consequence: Fraudulent mandate approval attributed to a legitimate approver, £5,000,000 in unauthorised agent authority, forensic difficulty distinguishing the legitimate from the fraudulent approval.

Scenario C — Session Persistence After Context Change: An agent governance administrator authenticates from the corporate office network on a managed device. During the session, the administrator disconnects from the corporate VPN and connects through a personal hotspot (changing network context), then transfers the browser session to a personal tablet (changing device context). The session remains valid throughout because no re-validation of the authentication context occurs. On the personal tablet (which has no MDM, no endpoint protection, and a rooted OS), the administrator makes a governance change that is later found to be erroneous. The audit log shows the action was performed by a legitimate administrator but cannot confirm the device or network context at the time of the action.

What went wrong: The session was established with a specific device and network context, but those bindings were not re-validated when the context changed. The session migrated across devices and networks without triggering re-authentication or session invalidation. Consequence: Governance action from an uncontrolled device, incomplete audit trail, inability to confirm the security posture at the time of the action.

4. Requirement Statement

Scope: This dimension applies to every session in which a human or service interacts with an AI agent governance system to perform actions that can affect agent behaviour, configuration, or authority. This includes: administrative sessions for agent configuration, approval sessions for mandate changes, override sessions for emergency actions, and monitoring sessions with write access. It extends to both web-based sessions (browser) and API sessions (programmatic access). The scope is determined by the sensitivity of the actions available within the session — read-only monitoring sessions may apply a lighter binding, but any session with write or approve capability is fully in scope.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

4.1. A conforming system MUST bind governance session tokens to the TLS channel in which they were issued, using Token Binding (RFC 8471) or equivalent channel-binding mechanism, so that tokens intercepted or extracted cannot be used in a different TLS session.

4.2. A conforming system MUST bind governance session tokens to the device that established the session, using device-bound keys (e.g., FIDO2 platform authenticator, TPM-bound key) so that tokens cannot be used from a different device.

4.3. A conforming system MUST invalidate governance sessions when a significant context change is detected — including device change, network change (e.g., corporate to public), geographic location change exceeding a defined threshold, or user-agent change — requiring re-authentication.

4.4. A conforming system MUST enforce maximum session lifetimes appropriate to the risk: no more than 1 hour for sessions with mandate approval authority, no more than 4 hours for sessions with configuration modification authority, and no more than 8 hours for sessions with monitoring-only authority.

4.5. A conforming system MUST implement idle timeout that terminates sessions after 15 minutes of inactivity for sessions with approval authority and 30 minutes for sessions with configuration authority.

4.6. A conforming system SHOULD implement continuous session validation that periodically re-verifies the session's binding to the device, channel, and authentication context (at least every 5 minutes for high-risk sessions).

4.7. A conforming system SHOULD require step-up re-authentication (e.g., biometric re-verification, FIDO2 re-assertion) at the point of high-risk governance actions within an existing session, even if the session is otherwise valid.

4.8. A conforming system SHOULD implement session-specific signing for governance actions — each mandate approval or configuration change is signed with a session-bound key that proves the action occurred within the authenticated session on the bound device.

4.9. A conforming system MAY implement mutual session attestation where both the governance platform and the client continuously verify each other's session integrity, detecting middleware injection or proxy interception.

5. Rationale

Authentication happens once, at session start. Governance actions happen throughout the session lifetime. If the session can be detached from the authenticated identity — through token theft, session hijacking, or context migration — then the governance actions are no longer bound to the authenticated person. The session becomes a bearer instrument: whoever holds it wields the authority.

Traditional session management relies on session cookies or tokens that are, by design, bearer tokens. The server issues a token at authentication; the client presents it with each request; the server grants access based on the token alone. This model was designed for web applications where the primary risk was session fixation or cross-site scripting. For AI agent governance, where a single session may authorise actions with millions of pounds in financial impact, bearer-token sessions are structurally insufficient.

Session binding addresses this by tying the session token to something the attacker cannot replicate: the TLS channel (Token Binding), the device's hardware (TPM-bound keys), and the authentication context (network, location, device posture). Even if the attacker obtains the session token, they cannot use it because it is bound to a TLS session they are not party to, a device they do not possess, and a context they cannot replicate.

The session lifetime and idle timeout requirements reflect the principle that governance authority should be time-bounded and actively maintained. A session that remains valid for 8 hours provides an 8-hour exploitation window if the token is stolen. A session that requires re-authentication every hour limits the window to 1 hour. An idle timeout of 15 minutes ensures that an unattended workstation does not provide open access to governance functions.

Step-up re-authentication at the point of high-risk actions adds a further layer: even within a valid session, the most sensitive actions (mandate approval, emergency override) require fresh authentication proof. This defeats attacks where the session was legitimately established but the user steps away and an attacker takes over the physical workstation.

6. Implementation Guidance

Session binding should be implemented at multiple layers: transport (TLS channel binding), application (device-bound tokens), and behavioural (context validation). Each layer addresses a different attack vector.

Recommended patterns:

• Token Binding with DPoP. Implement Demonstrating Proof-of-Possession (DPoP, RFC 9449) for OAuth 2.0 access tokens. The client generates an asymmetric key pair at session start, proves possession of the private key with each request, and the server validates that the token is used by the same client that obtained it. Combined with device-bound key storage (FIDO2 platform authenticator), the session token becomes non-transferable. Example: a governance administrator's session token is bound to a DPoP key stored in the laptop's TPM. Extracting the session cookie alone does not grant access because the attacker cannot produce the DPoP proof without the TPM-bound private key.
• Continuous context validation engine. Deploy a session context engine that captures the authentication context at session start (device fingerprint, network IP range, geolocation, user-agent, TLS session ID) and re-validates every 5 minutes. Context changes exceeding defined thresholds trigger session invalidation or step-up authentication. Example thresholds: IP change outside the corporate range → require re-authentication; geolocation change exceeding 100 km within 5 minutes (impossible travel) → terminate session immediately; user-agent change → terminate session.
• Session-scoped signing keys. At session start, generate an ephemeral signing key pair bound to the session and the device's TPM. Each governance action within the session is signed with the session key. The signature proves that the action occurred within the authenticated session, on the bound device, and at the recorded time. The session key is destroyed at session end. Example: a mandate approval is signed with the session-scoped key, producing a signature that the audit log records alongside the approval. Replaying the approval in a different session or from a different device is cryptographically impossible.
• Progressive session degradation. As a session ages or as context confidence decreases, progressively reduce the session's authority rather than maintaining full authority until an abrupt termination. Example: a fresh session (0-15 minutes after authentication) allows mandate approval; an aging session (15-60 minutes) allows configuration viewing but not approval; an aged session (60+ minutes) allows monitoring only. Any approval action triggers step-up re-authentication regardless of session age.

Anti-patterns to avoid:

• Bearer session tokens without channel or device binding. Standard session cookies are bearer tokens — whoever presents them gets the session. For agent governance, this is equivalent to an unsigned cheque. Any exfiltration (XSS, malicious extension, network interception) gives the attacker full governance access.
• Long session lifetimes without re-validation. 8-hour or 24-hour session lifetimes provide wide exploitation windows. Even with device binding, long sessions increase the risk of context drift (user walks away from workstation, device compliance changes).
• Session binding only at token issuance. Checking device binding at login but not on subsequent requests. Token Binding and DPoP provide per-request proof-of-possession, ensuring binding is validated continuously, not just at session start.
• Idle timeout only, no absolute timeout. An idle timeout of 15 minutes is defeated by an attacker who sends periodic keep-alive requests. Absolute session lifetimes ensure that re-authentication occurs regardless of activity.
• Allowing session transfer for convenience. Permitting users to transfer governance sessions across devices (e.g., "continue on mobile") for convenience. Each device change must require new authentication and new session establishment.

Industry Considerations

Financial Services. PSD2 SCA requirements include session security provisions. Financial agent governance sessions must implement session binding consistent with EBA technical standards. Trading system session management standards (e.g., FIX session management) provide models for binding and timeout.

Healthcare. HIPAA requires automatic logoff after inactivity for systems accessing PHI. AG-285's idle timeout requirements meet this, with recommended tighter timeouts (10 minutes) for sessions governing clinical AI agents.

Critical Infrastructure. IEC 62443 requires session management controls including timeout and re-authentication for industrial control systems. Agent governance sessions for critical infrastructure agents should implement the shortest practical timeout values.

Maturity Model

Basic Implementation — Session tokens are issued with HttpOnly, Secure, and SameSite attributes. Absolute session lifetime is enforced (1 hour for approval sessions, 4 hours for configuration sessions). Idle timeout is enforced (15 minutes for approval sessions). Session tokens are invalidated on logout. This meets minimum mandatory requirements but relies on transport-layer security alone for token protection.

Intermediate Implementation — DPoP or equivalent proof-of-possession is implemented, binding tokens to client-held keys. Device-bound key storage (TPM, Secure Enclave) prevents key extraction. Continuous context validation detects device, network, and location changes, triggering re-authentication. Step-up authentication is required for mandate approval and emergency override actions. Session events (establishment, actions, termination) are logged with full context.

Advanced Implementation — All intermediate capabilities plus: session-scoped signing keys bound to TPM for per-action cryptographic proof. Progressive session degradation reduces authority over time. Mutual session attestation detects middleware injection. Independent adversarial testing confirms that token theft, session hijacking, context migration, and man-in-the-middle attacks are all blocked. The organisation can demonstrate cryptographic proof that each governance action occurred within an authenticated, device-bound, context-validated session.

7. Evidence Requirements

Required artefacts:

• Session management policy. Documented policy specifying session lifetimes, idle timeouts, context validation rules, step-up authentication triggers, and binding mechanisms for each governance session type.
• Token binding configuration. Evidence that DPoP, Token Binding, or equivalent proof-of-possession is implemented and enforced. Format: configuration export or automated test results.
• Context validation rules. The complete set of context change thresholds that trigger re-authentication or session termination, with justification for each threshold.
• Session event log. Timestamped records of session lifecycle events: establishment (with context), governance actions (with session binding proof), context changes (with validation outcome), and termination (with reason). Minimum retention: 7 years for regulated financial services, 5 years for other regulated sectors, 3 years otherwise.
• Adversarial test results. Results from testing session binding resistance to: token theft and replay, session hijacking, man-in-the-middle, context migration, and idle session exploitation.

Retention requirements:

• Session event logs: 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.

8. Test Specification

Test 8.1: Token Theft and Replay

• Stimulus: Extract a valid governance session token (cookie or access token) from an authenticated session. Attempt to use the token from a different device/browser.
• Expected behaviour: The replayed token is rejected because it fails proof-of-possession validation (DPoP) or channel binding. The governance platform returns an authentication error.
• Pass criteria: No governance action can be performed with a stolen token from a different device.
• Fail criteria: A stolen token grants governance access from a different device.

Test 8.2: Man-in-the-Middle Session Hijacking

• Stimulus: Interpose a proxy between the client and the governance platform during an authenticated session. Attempt to modify a governance action request in transit (e.g., change the mandate limit value).
• Expected behaviour: Channel binding or session-scoped signing detects the interposition. The modified request is rejected because the signature or channel binding check fails.
• Pass criteria: Modified requests are detected and rejected. The session is terminated upon detection.
• Fail criteria: A modified request is accepted as genuine.

Test 8.3: Context Change Detection

• Stimulus: Establish an authenticated governance session from a corporate network. During the session, change the client's IP address to a different range (simulating network change). Attempt to continue the session.
• Expected behaviour: The context validation engine detects the network change and either requires re-authentication or terminates the session.
• Pass criteria: The session does not continue with full authority after a context change.
• Fail criteria: The session continues unchanged despite a significant context change.

Test 8.4: Absolute Session Lifetime Enforcement

• Stimulus: Establish an authenticated governance session with approval authority. Maintain continuous activity. Attempt to perform an approval action after the maximum session lifetime (1 hour) has elapsed.
• Expected behaviour: The session is terminated at the 1-hour mark regardless of activity. The approval action is rejected with a re-authentication requirement.
• Pass criteria: No governance action succeeds beyond the maximum session lifetime.
• Fail criteria: The session remains valid beyond the maximum lifetime.

Test 8.5: Idle Timeout Enforcement

• Stimulus: Establish an authenticated governance session with approval authority. Leave the session idle (no requests) for 16 minutes. Attempt to perform an approval action.
• Expected behaviour: The idle timeout (15 minutes for approval sessions) has elapsed. The session is terminated. The action requires re-authentication.
• Pass criteria: The session is terminated after 15 minutes of inactivity.
• Fail criteria: The session remains active after the idle timeout period.

Test 8.6: Step-Up Re-Authentication for High-Risk Actions

• Stimulus: Within a valid governance session with configuration authority, attempt to perform a high-risk action (mandate approval) without step-up re-authentication.
• Expected behaviour: The governance platform requires step-up authentication (biometric re-verification or FIDO2 re-assertion) before processing the high-risk action.
• Pass criteria: High-risk actions cannot be performed without step-up re-authentication, even within a valid session.
• Fail criteria: A high-risk action proceeds without step-up authentication.

Test 8.7: Session-Scoped Signing Verification

• Stimulus: Perform a governance action (mandate approval) within an authenticated session. Extract the session-scoped signature from the audit log. Attempt to verify the signature with a key from a different session.
• Expected behaviour: The signature verifies only with the session-scoped key from the original session. Verification with any other key fails.
• Pass criteria: Each governance action is cryptographically bound to its specific session. Cross-session signature reuse is impossible.
• Fail criteria: A governance action's signature verifies with keys from a different session.

Conformance Scoring

• Score 0: No session binding — bearer tokens are used without proof-of-possession, device binding, or channel binding.
• Score 1: Basic session management (HttpOnly cookies, absolute timeout, idle timeout) is implemented but tokens remain bearer tokens without cryptographic binding.
• Score 2: Proof-of-possession (DPoP or equivalent) binds tokens to client-held keys. Device-bound key storage is required. Context validation triggers re-authentication on significant changes. Step-up authentication is required for high-risk actions.
• Score 3: All Score 2 capabilities plus: session-scoped signing keys for per-action cryptographic proof, progressive session degradation, mutual session attestation, and independent adversarial testing confirming resistance to all known session attack vectors.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
PSD2/EBA RTS	Article 4 (Authentication Code — Dynamic Linking)	Direct requirement
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST SP 800-63B	Section 7 (Session Management)	Direct requirement
ISO 27001	A.8.5 (Secure Authentication)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Supports compliance
HIPAA	Section 164.312(a)(2)(iii) (Automatic Logoff)	Direct requirement
OWASP ASVS	V3 (Session Management)	Supports compliance

PSD2/EBA RTS — Article 4 (Authentication Code — Dynamic Linking)

PSD2's dynamic linking requirement mandates that the authentication code for a payment transaction is dynamically linked to the amount and payee. For AI agent governance, this maps to session-scoped signing: each governance approval must be cryptographically linked to the specific action approved. A session token that grants blanket approval authority does not satisfy dynamic linking. AG-285's session-scoped signing directly implements this principle.

NIST SP 800-63B — Section 7 (Session Management)

NIST SP 800-63B Section 7 specifies requirements for session management including: session binding to the subscriber, reauthentication requirements, and session timeout. AG-285's requirements align with AAL2 and AAL3 session management requirements, adapted for the specific risk context of AI agent governance.

HIPAA — Section 164.312(a)(2)(iii) (Automatic Logoff)

HIPAA requires automatic logoff for systems accessing PHI after a period of inactivity. AG-285's idle timeout requirements satisfy this requirement, with tighter timeouts for higher-risk governance sessions.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Session-scoped — affects every governance action possible within the hijacked session, which may span all agents the session holder has authority over

Consequence chain: Session binding failure allows an attacker to inherit a legitimate user's governance authority by stealing, hijacking, or replaying their session. The attacker operates with the victim's identity and permissions for the remaining session lifetime. Every governance action the attacker performs is attributed to the victim in the audit log. The attacker can modify mandates, approve overrides, change configurations, and access sensitive governance data. Detection is difficult because the actions appear to come from an authenticated, authorised user. The damage potential equals the victim's governance authority multiplied by the remaining session lifetime. For a mandate approver with a 4-hour session, this could mean 4 hours of unchecked access to approve any mandate change.

Cross-references: AG-281 (Device Identity Binding Governance) provides the device identity that AG-285 binds sessions to. AG-279 (Human Identity Proofing Governance) provides the authenticated identity behind the session. AG-286 (Attested Login Context Governance) records the context at session establishment that AG-285 uses for continuous validation. AG-016 (Cryptographic Action Attribution) leverages session-scoped signatures for attributing governance actions. AG-287 (Non-Repudiation Evidence Governance) depends on session integrity to ensure non-repudiation evidence is genuine. AG-115 (Strong Authentication for Agent-Initiated Value Transfer) requires session-bound approval for high-value transfers. AG-161 (Requester Authentication and Anti-Impersonation) establishes the authentication that AG-285 maintains throughout the session.