Session & Scope for Agentic AI¶
Control Domain: Agentic — Containment Controls
Purpose: Isolate agent sessions, limit blast radius, and prevent scope creep in autonomous AI operations.
Extends: IAM-06 (session-scoped credentials) and NET-01 (network zones) with agentic-specific depth.
The Problem¶
An agent operating within a session accumulates context, credentials, data access, and decision history. Over time, a long-running agent session becomes a high-value target: it holds data from multiple tool calls, has active credentials, and has built a context window containing potentially sensitive information from across the session.
The longer a session runs, the greater the blast radius if compromised. Session isolation limits what an attacker can reach through any single compromised session.
Control Objectives¶
| ID | Objective | Risk Tiers |
|---|---|---|
| SESS-01 | Define and enforce session boundaries with automatic expiry | Tier 2+ (agentic) |
| SESS-02 | Isolate sessions from each other (no cross-session data leakage) | Tier 2+ (agentic) |
| SESS-03 | Limit the scope of each session to a declared task | Tier 2+ (agentic) |
| SESS-04 | Implement progressive trust within sessions | Tier 3+ (agentic) |
| SESS-05 | Clean up session state on termination | Tier 2+ (agentic) |
SESS-01: Session Boundaries¶
Every agent session must have defined boundaries:
| Boundary | Enforcement |
|---|---|
| Time limit | Maximum session duration (e.g., 30 minutes for Tier 3, 4 hours for Tier 2). Hard cutoff, not advisory. |
| Token limit | Maximum total tokens consumed across all model calls in the session. Prevents denial-of-wallet and runaway context accumulation. |
| Action limit | Maximum number of tool invocations per session. Prevents infinite loops and excessive automation. |
| Scope boundary | Session is scoped to a declared task. The agent cannot "pivot" to unrelated tasks within the same session. |
| Credential expiry | All session credentials expire with the session (IAM-06). No credential carry-over. |
When any boundary is reached, the session terminates gracefully: pending actions are cancelled (not auto-approved), the user is notified, and all session state is cleaned up (SESS-05).
SESS-02: Session Isolation¶
Sessions must be isolated from each other. No data, credentials, context, or state from one session should be accessible to another.
Isolation Requirements¶
- Context isolation: Agent A's session context (conversation history, tool results, intermediate reasoning) is not accessible to Agent B's session, even if they serve the same user.
- Credential isolation: Credentials issued for Session A cannot be used in Session B.
- Memory isolation: If the agent has persistent memory, session-specific data must be clearly separated from cross-session memory, and cross-session memory must not contain sensitive data from individual sessions.
- Resource isolation: For Tier 3+ systems, sessions run in separate compute contexts (containers, sandboxes) to prevent side-channel information leakage.
What This Prevents¶
- A compromised session cannot pivot to access data from other sessions.
- An attacker who extracts context from one session cannot use it to authenticate in another.
- Cross-session data correlation attacks (where an attacker uses multiple sessions to reconstruct information that no single session should reveal).
SESS-03: Scope Constraints¶
Each session should have a declared scope — the task it is permitted to accomplish.
Scope Definition¶
| Element | Description |
|---|---|
| Task type | What the session is doing (e.g., "answer customer query", "process expense report") |
| Data domain | What data the session can access (e.g., "customer record for user X only") |
| Tool set | Which tools are available in this session (subset of the agent's full manifest) |
| Output type | What the session can produce (e.g., "text response only", "response + database update") |
| User context | Who initiated the session and what permissions they carry |
Scope Enforcement¶
The authorization gateway (IAM-04) enforces scope by:
- Restricting tool invocations to those relevant to the declared task.
- Filtering data queries to the declared data domain.
- Monitoring agent reasoning for scope drift (e.g., the agent starts discussing topics unrelated to the declared task).
- Terminating sessions that persistently attempt out-of-scope actions.
SESS-04: Progressive Trust¶
For Tier 3+ systems, sessions should not start with full permissions. Instead, permissions increase as the session demonstrates expected behaviour.
Trust Levels¶
| Level | Permissions | Triggers to Advance |
|---|---|---|
| Initial | Read-only tool access, text response only | N successful interactions without guardrail flags |
| Standard | Full read access, reversible writes | No Judge flags, confirmed user identity |
| Elevated | Irreversible writes (with approval), external communications | Human reviewer approves elevation, explicit user request |
Why Progressive Trust¶
- Limits the damage from injection attacks early in a session (before the agent has accumulated data or context).
- Forces attackers to maintain consistent benign behaviour before gaining access to destructive capabilities.
- Provides natural checkpoints where human oversight can intervene.
SESS-05: Session Cleanup¶
When a session terminates (normally or abnormally), all session state must be cleaned up:
- Credentials: All session-scoped tokens revoked immediately.
- Context: Session context purged from memory (not just dereferenced — actively cleared).
- Temporary data: Any temporary files, cache entries, or intermediate results created during the session are deleted.
- Tool connections: Any open connections to backend tools are closed.
- Audit record: A session termination event is logged with: session duration, token consumption, tool invocation count, guardrail/Judge flags, and termination reason.
For abnormal termination (crash, timeout, forced kill), cleanup must still occur — design for crash-safe cleanup.
Platform-Neutral Implementation Checklist¶
- Session boundaries defined (time, token, action, scope, credential expiry)
- Hard session termination on boundary breach (not advisory)
- Sessions isolated from each other (context, credentials, memory, resources)
- Session scope declared and enforced via authorization gateway
- Progressive trust implemented for Tier 3+ systems
- Session cleanup verified for normal and abnormal termination
- Session metadata logged for forensics and drift detection
- Cross-session data correlation attacks considered in threat model
Customer-to-Agent Session Binding¶
The controls above address agent sessions — how an autonomous AI system manages its own context, credentials, and scope. But in customer-facing deployments (chatbots, self-service portals, AI-assisted commerce), there is an additional trust boundary: the authenticated customer whose intent the agent is executing.
This is not the same as agent identity. Agent identity answers "which AI component is acting?" Customer session binding answers "on whose behalf, and how do we know?"
The Problem¶
When a customer authenticates to your application and interacts with an AI agent, the agent acts as a proxy for that customer — reading their data, modifying their cart, processing their payment. If the binding between customer identity and agent session is weak, an attacker can:
- Session hijack: Take over another customer's agent session and issue commands on their behalf
- Session fixation: Pre-set a session that a customer later authenticates into, giving the attacker a parallel path
- Cross-customer contamination: In concurrent sessions, context from Customer A bleeds into Customer B's agent responses
- Scope escape: The agent holds credentials scoped to "customer cart access" but the scope isn't bound to which customer's cart
What You Must Design¶
The framework gives you the agent-side controls (SESS-01 through SESS-05). For customer-facing systems, you must additionally answer:
| Question | Why It Matters |
|---|---|
| How is the customer's identity propagated into the agent session? | The agent needs to know whose data it can access — not just what kind of data |
| Is customer identity verified per-session or per-request? | Per-session is simpler but vulnerable to mid-session takeover. Per-request is safer for CRITICAL-tier |
| Are the agent's write permissions scoped to this specific customer? | "Can write to shopping carts" is insufficient. "Can write to customer-12345's cart" is the control |
| What happens if the customer's account is compromised mid-session? | You need a revocation path from your identity provider to active agent sessions |
| How do you prevent cross-customer context contamination in concurrent sessions? | SESS-02 covers agent isolation. You also need to verify that shared resources (connection pools, caches) don't leak between customers |
Design Pattern: Customer Context Injection¶
Customer authenticates → Your application verifies identity
→ Application creates agent session with:
- Customer ID (verified, not user-supplied to the agent)
- Scoped permissions (this customer's resources only)
- Session binding token (ties agent session to customer session)
→ Agent receives customer context via system prompt or secure context injection
→ Agent CANNOT modify its own customer binding
→ All agent actions logged with both agent ID and customer ID
The critical principle: customer identity is injected by your infrastructure, not extracted from the conversation. If the agent determines which customer it's serving by reading the chat, an attacker can inject a different identity through the conversation.
Offramps — Go Here Next¶
This framework gives you the AI-specific session controls. For customer authentication, session management, and identity propagation, these are the domain-specific resources:
| Topic | Resource | Why |
|---|---|---|
| Session management fundamentals | OWASP Session Management Cheat Sheet | Token generation, session lifecycle, fixation prevention — the upstream controls your AI session inherits |
| Authentication architecture | Your identity platform documentation (Entra ID, Cognito, Auth0, Okta, Keycloak) | How customer identity tokens are issued, validated, and revoked. Your agent session must consume these, not reinvent them |
| Payment authentication | PCI-DSS Requirement 8 (your QSA or PCI SSC Document Library) | If your agent handles payment data, PCI-DSS defines authentication requirements that apply through the agent, not just around it |
| Customer data scoping | Your data platform's row-level security or tenant isolation documentation | How your backend ensures the agent can only read/write this customer's data — the enforcement point beneath the agent |
| Session revocation | Your identity provider's real-time revocation documentation (token introspection, webhook-based revocation) | How to kill an active agent session when a customer reports account compromise |
The framework's role: Define the agent session controls (SESS-01–05), require customer identity binding, and mandate that write permissions are scoped to the authenticated customer — not just to a resource type.
Your platform's role: Implement the authentication, issue the scoped tokens, enforce row-level data access, and provide the revocation path.
AI Runtime Behaviour Security, 2026 (Jonathan Gill).