Cross-Role Context Sanitization Prompt

This prompt is for platform engineers and AI architects who manage multi-role or multi-agent sessions where context must move between roles with different trust levels, tool access, or data permissions. The job-to-be-done is stripping role-specific state—tool outputs, permission grants, internal reasoning, and sensitive data—before handing off to a different role, so the receiving role cannot exploit residual access or leak information across boundaries. Use this when your system has at least two distinct roles (e.g., a customer-facing assistant and an internal escalation agent) and context passes between them programmatically.

Do not use this prompt when all roles share identical permissions and data access, or when the handoff is purely cosmetic (same role, different prompt variant). It is also unnecessary for single-role systems where context never crosses a trust boundary. The prompt assumes you already have defined role boundaries and tool access policies; it does not create those policies—it enforces them during context transfer. For high-risk domains (healthcare, finance, legal), pair this prompt with a human review step and audit logging of what was stripped before the sanitized context reaches the next role.

Before implementing, inventory every piece of state your roles accumulate: tool call results, retrieved documents, user PII, internal monologue, permission tokens, and session metadata. The sanitization prompt must know what to strip, not just what to keep. Start by running this prompt against a set of known contaminated contexts and verify that residual access—such as a downstream role attempting to call a tool it shouldn't have—is blocked. If your system uses tool-augmented agents, combine this with the Tool Output Contamination Guard Prompt to catch injection attempts before they reach the sanitization step.

This template provides the core instruction set for stripping role-specific context, tool access, and permissions before passing state to a different role. Use it as the sanitization step in your handoff pipeline. The prompt is designed to be wrapped in your application's validation harness, not used as a standalone chat. Every placeholder must be resolved before the prompt is sent to the model.

textCopy
You are a context sanitization engine. Your job is to prepare a safe, minimal context payload for a downstream role. You do not execute the downstream role's task. You only produce the sanitized context.

## Input
- Current role: [CURRENT_ROLE]
- Target role: [TARGET_ROLE]
- Current role's full context: [CURRENT_CONTEXT]
- Target role's allowed data scope: [TARGET_DATA_SCOPE]
- Target role's allowed tool scope: [TARGET_TOOL_SCOPE]
- Target role's forbidden actions: [TARGET_FORBIDDEN_ACTIONS]
- Target role's required output schema: [TARGET_OUTPUT_SCHEMA]

## Sanitization Rules
1. Remove all tool call results, API keys, internal identifiers, and system prompts from the current role.
2. Remove any data fields not explicitly listed in the target role's allowed data scope.
3. Remove any references to tools, capabilities, or permissions not in the target role's allowed tool scope.
4. Remove any instructions, policy statements, or behavioral constraints that belong to the current role.
5. Preserve only user-facing conversation turns, factual findings, and data explicitly shareable with the target role.
6. If the current context contains actions or decisions that the target role is forbidden from performing, redact those entirely.
7. Do not summarize, interpret, or transform the remaining content unless the target role's output schema requires a specific format.

## Output Format
Return a JSON object with exactly these fields:
{
  "sanitized_context": "<cleaned context string>",
  "redacted_items": ["<list of what was removed and why>"],
  "residual_risk_flags": ["<any data or capability that could still leak across roles>"],
  "target_role_ready": true | false
}

## Verification Steps
Before returning, verify:
- No current-role system instructions remain in sanitized_context.
- No tool names, tool outputs, or API responses from the current role remain.
- No data fields outside the target role's allowed data scope remain.
- All redacted_items have a corresponding reason.
- If residual_risk_flags is non-empty, target_role_ready must be false.

## Constraints
- Do not add information not present in the original context.
- Do not guess what the target role needs. Use only the provided scopes.
- If the entire context must be redacted, return an empty sanitized_context with target_role_ready set to false.

Adapt this template by replacing each square-bracket placeholder with concrete values from your role registry. The [TARGET_DATA_SCOPE] should be a machine-readable list of allowed field paths or data categories. The [TARGET_TOOL_SCOPE] should enumerate permitted tool names and argument constraints. If your system uses dynamic role resolution, populate these from your role definition store at runtime. For high-risk domains such as healthcare or finance, add a human review step before the sanitized context is forwarded to the target role. Wire the residual_risk_flags output into your alerting system so that non-empty flags trigger an operator review queue.

After copying this template, test it against known contamination scenarios: a current role context containing system prompts, tool outputs with embedded instructions, and data fields outside the target scope. Verify that the model correctly redacts all three categories. Common failure modes include the model summarizing instead of redacting, preserving tool output content while removing only the tool name, and failing to detect instructions embedded in user-facing text. Build eval assertions for each of these before deploying to production.

The Cross-Role Context Sanitization Prompt is not a standalone chat instruction; it is a middleware operation that must execute between role transitions in a multi-agent system. In practice, this means the prompt should be called programmatically whenever a handoff event occurs—such as when a triage agent passes a case to a specialist agent, or when a customer-facing assistant escalates to a human operator. The harness should intercept the outgoing context payload, invoke the sanitization prompt with the source role's full state and the target role's boundary definition, and replace the raw context with the sanitized output before forwarding it to the next role. This prevents privilege escalation, tool access leakage, and data exposure that would otherwise compound across handoffs.

To implement this reliably, wrap the prompt call in a sanitization function that accepts three arguments: source_context (the full conversation state, tool outputs, and internal notes from the originating role), target_role_spec (the boundary contract for the receiving role, including allowed tools, data access scope, and output constraints), and handoff_metadata (transition reason, timestamp, and session ID). The function should construct the prompt by injecting these into the [SOURCE_CONTEXT], [TARGET_ROLE_BOUNDARY], and [HANDOFF_METADATA] placeholders, then call the model with temperature=0 and a structured output schema that includes sanitized_context, removed_items (with reasons), and residual_risk_flags. After receiving the response, validate that no removed tool names, internal identifiers, or source-role-only data appear in the sanitized output using a deterministic post-check—regex for known sensitive patterns, plus a secondary LLM call with the Residual Access Detection variant of this prompt if the risk level is high. If validation fails, retry once with an explicit error message injected into [PREVIOUS_FAILURE]; if it fails again, block the handoff and log an incident.

Model choice matters here. Use a model with strong instruction-following and long-context reliability, such as Claude 3.5 Sonnet or GPT-4o, because the prompt must reason over potentially thousands of tokens of conversation state without missing embedded role markers or tool call signatures. For high-throughput systems, consider caching the target role boundary definitions as reusable prompt prefixes. Logging is non-negotiable: persist the pre-sanitization context, the sanitized output, the removed items list, and the validation result to an audit store keyed by session ID and handoff sequence number. This creates the traceability required for compliance reviews and debugging handoff failures. Do not skip sanitization for same-session role transitions, even if the roles seem similar—tool access creep and context contamination accumulate silently across handoffs. Finally, integrate the sanitization function into your agent orchestration framework (LangGraph, custom executor, or event-driven mesh) as a required gate between every role transition, not an optional cleanup step.