Tool Session Scope Isolation Prompt

This playbook is for multi-tenant platform engineers who need to prevent cross-session data leakage in tool-bearing agents. When an agent orchestrates tool calls across different user sessions, the risk of data from one session contaminating another is high. This prompt enforces strict session-scope isolation by binding every tool interaction to a specific session, user, and task context. Use this prompt as a system-level instruction that wraps every tool call in a validated session boundary. It is not a replacement for application-level access control, but a defense-in-depth layer that makes scope violation explicit and auditable before execution.

The ideal user is an AI platform engineer or security engineer deploying agents in a multi-tenant environment where a single agent process serves multiple users, accounts, or organizations. The prompt is most effective when the agent has access to tools that read or write tenant-scoped data—databases, file stores, APIs, knowledge bases, or internal services. Before adopting this prompt, you must already have session identifiers, user context, and tool definitions that can accept a scope parameter. The prompt adds a mandatory validation step: before any tool call, the agent must confirm that the target resource, query, or operation belongs to the active session's tenant boundary. If the agent cannot confirm this, it must refuse the call and log the violation.

Do not use this prompt as your sole isolation mechanism. Application-level controls—row-level security, API-level tenant filters, database connection scoping—must still enforce isolation at the infrastructure layer. This prompt is a defense-in-depth layer that catches logic errors, prompt injection attempts, and agent planning failures before they reach your tools. It is also not a replacement for tool input sanitization or output filtering. Pair this prompt with a tool argument sanitization prompt and a tool output filtering prompt for a complete security posture. If your agent operates in a single-tenant environment with no cross-user tool access, this prompt adds unnecessary latency and token overhead. Skip it and rely on your application's native isolation.

This prompt template enforces session-scoped tool isolation at the system-instruction level. It establishes a hard boundary around the current session's context—including session ID, user identity, and authorized resource scope—and instructs the model to reject any tool invocation that would access data or resources outside that boundary. The prompt is designed to be inserted as a system-level instruction that executes before every tool call, making it suitable for multi-tenant platforms where a single agent process serves multiple users or sessions and cross-session data leakage is a critical failure mode.

textCopy
You are an agent operating within a strictly isolated session context. Your tool access is bound to the following session scope, and you must enforce this scope on every tool invocation without exception.

## Session Scope
- Session ID: [SESSION_ID]
- User ID: [USER_ID]
- Tenant ID: [TENANT_ID]
- Authorized Resource Scope: [RESOURCE_SCOPE]
- Session Start Time: [SESSION_START_TIME]
- Session Expiry: [SESSION_EXPIRY_TIME]

## Scope Enforcement Rules
1. Before invoking any tool, verify that the target resource, record, or data object belongs to the current session scope defined above.
2. If a tool argument references a resource ID, user ID, tenant ID, or session ID that does not match the current scope, DO NOT invoke the tool. Instead, respond with a scope violation error.
3. If a tool returns data that contains references to resources, users, or sessions outside the current scope, DO NOT include that data in your response. Flag it as a cross-scope data leak and report it.
4. Never use cached, stored, or remembered data from previous sessions or conversations. Each session is isolated.
5. If you are uncertain whether a resource falls within the current scope, DO NOT proceed. Request explicit scope clarification before invoking any tool.

## Tool Invocation Pre-Flight Check
For every tool call, perform this check before invocation:
- Does the tool target a resource within [RESOURCE_SCOPE]?
- Do all resource identifiers in the arguments match [TENANT_ID] and [USER_ID] constraints?
- Is the current time within [SESSION_START_TIME] to [SESSION_EXPIRY_TIME]?
- Would this tool call access or modify data from another session, user, or tenant?

If any check fails, output a structured scope violation:
```json
{
  "violation": true,
  "session_id": "[SESSION_ID]",
  "tool_name": "<tool_name>",
  "blocked_reason": "<reason>",
  "offending_argument": "<argument_name>",
  "offending_value": "<value>",
  "timestamp": "<current_timestamp>"
}

Scope Violation Response Format

When blocking a tool invocation, respond ONLY with the violation JSON above. Do not invoke the tool. Do not attempt to work around the scope restriction. Do not explain what the tool would have done.

Allowed Cross-Scope Actions

• Logging scope violations to the audit system for session [SESSION_ID]
• Reporting potential security events to the monitoring system
• Requesting human review for ambiguous scope determinations

No other cross-scope actions are permitted.

To adapt this template, replace each square-bracket placeholder with values from your session management system. The [RESOURCE_SCOPE] placeholder should contain a machine-parseable scope definition—such as a resource path prefix, a list of allowed resource IDs, or a scope expression your tool layer can evaluate. For production deployments, pair this prompt with a server-side enforcement layer that independently validates scope before executing any tool call; the prompt provides defense-in-depth but should not be the sole enforcement mechanism. Test the prompt against cross-session access attempts, including direct resource ID injection, tenant ID manipulation in arguments, and attempts to access data from expired sessions. The structured violation output format enables automated monitoring and alerting on scope violation attempts.

The Tool Session Scope Isolation Prompt is not a standalone safety measure—it must be embedded in an application harness that enforces its output. The prompt produces a scope binding declaration and session boundary validation checks, but the harness is responsible for injecting the correct session context, parsing the model's scope assessment, and blocking tool invocations that violate declared boundaries. Without this harness, the prompt becomes advisory text that a determined attacker or a drifting agent can ignore.

Implement the harness as a pre-invocation middleware layer that runs before every tool call in a multi-tenant agent loop. The harness must: (1) extract the active [SESSION_ID], [USER_ID], and [TENANT_ID] from the authenticated request context—never from the model's output; (2) inject these values into the prompt's [SESSION_CONTEXT] placeholder along with the current tool's name, arguments, and target resource identifiers; (3) parse the model's response for the structured scope assessment fields (session_match, user_authorization, resource_ownership, cross_session_risk); and (4) enforce a hard block if any field returns false or high, logging the denial with the full context for audit. Use a strict JSON output schema with required fields so parse failures trigger a safe default of denial rather than silent allowance.

Add a retry-and-escalation path for ambiguous cases. If the model returns session_match: uncertain or the output fails schema validation after one retry, the harness must route the request to a human review queue rather than guessing. For latency-sensitive applications, implement a short-circuit path: cache scope approvals for the duration of a session so repeated tool calls to the same resource within the same session don't re-invoke the isolation prompt on every step. Invalidate the cache immediately if the agent attempts to access a new resource, change scope, or if the session context is updated. Wire structured logs—including session ID, tool name, resource target, scope decision, and any denial reason—to your observability pipeline so that cross-session leakage attempts are detectable in production before they become incidents.

Model choice matters here. Use a model with strong instruction-following and structured output support (such as GPT-4o, Claude 3.5 Sonnet, or Gemini 2.0 Flash with JSON mode enabled) because scope isolation decisions require precise boolean logic and schema adherence. Avoid models that are prone to hallucinating session identifiers or inventing authorization justifications. Test the harness with adversarial inputs: a prompt injection payload in a tool argument that claims to belong to a different session, a tool output from a prior tenant that leaks into the current context window, and a legitimate cross-tenant admin override that should pass. Each test case must produce the expected block or allow decision, and your eval suite should measure both false-positive blocks (breaking legitimate work) and false-negative allowances (leaking data across sessions).