Role Transition Validation Prompt

This prompt is for multi-agent system architects and platform engineers who need to validate that context, permissions, and data are correctly sanitized when work moves from one AI role to another. The job-to-be-done is preventing privilege escalation, data leakage, and boundary violations during agent handoffs. Use this prompt when you have a defined handoff point between two specialized agents—for example, when a triage agent passes a user to a support agent, or when a code-review agent hands findings to a remediation agent. The ideal user is someone who already has role definitions and needs a programmatic, auditable gate between them.

Do not use this prompt for simple single-agent workflows, for defining the roles themselves, or for real-time user-facing interactions. This is a backend validation step that should run as part of your agent orchestration logic, not as a conversational prompt. It assumes you have structured context from the originating role and a target role definition to validate against. The prompt is designed to produce a machine-readable validation result—pass, fail with violations, or uncertain with a request for human review—not a natural language explanation for end users.

The prompt requires several structured inputs to function correctly: the originating role's definition and permissions, the target role's definition and permissions, the full context payload being transferred, and a transition audit log schema. Without these, the validation will be incomplete. You should also define a risk level for the transition, which controls whether the prompt demands strict field-level sanitization or allows broader context sharing. In high-risk domains like healthcare, finance, or legal, always route uncertain results to a human reviewer before completing the handoff.

Before deploying this prompt, ensure you have a mechanism to capture and store the transition audit log it produces. The log should include the timestamp, originating and target roles, the specific violations found, and the resolution (allowed, blocked, or escalated). This audit trail is essential for debugging agent behavior, demonstrating compliance, and iterating on your role boundary definitions. Wire the prompt into your agent framework so that no handoff proceeds without a passing validation result or an explicit human override.

This prompt template is designed to be inserted at every handoff point in a multi-agent system. It acts as a gate that inspects the originating role, the target role, the context being transferred, and the requested action. The model's job is not to perform the action but to validate whether the transition is safe according to a predefined policy. Use this template when you have a defined set of roles with explicit permissions and need an auditable, programmatic check before context or control moves between agents.

textCopy
You are a Role Transition Validator. Your sole responsibility is to inspect a proposed transition between two roles in a multi-agent system and determine whether it is safe to proceed.

You will receive:
- [ORIGINATING_ROLE]: The role that currently holds context and control.
- [TARGET_ROLE]: The role that will receive context and control.
- [TRANSITION_CONTEXT]: The data, instructions, or state being handed off.
- [REQUESTED_ACTION]: The action the target role is expected to perform.
- [ROLE_PERMISSION_MAP]: A JSON object mapping each role to its allowed actions, accessible data categories, and delegation rights.
- [DATA_CLASSIFICATION_POLICY]: Rules governing how data classified as [PUBLIC], [INTERNAL], [CONFIDENTIAL], or [RESTRICTED] may be shared between roles.

Perform the following validation steps in order. Stop and report a violation immediately if any check fails.

1. **Role Existence Check**: Verify that both [ORIGINATING_ROLE] and [TARGET_ROLE] exist in the [ROLE_PERMISSION_MAP].
2. **Action Authorization Check**: Confirm that [REQUESTED_ACTION] is listed in the [TARGET_ROLE]'s allowed actions.
3. **Delegation Right Check**: If the [ORIGINATING_ROLE] is delegating an action, confirm that its delegation rights include delegating to the [TARGET_ROLE].
4. **Data Containment Check**: Inspect every field in [TRANSITION_CONTEXT]. For each field, determine its data classification based on [DATA_CLASSIFICATION_POLICY]. Confirm that the [TARGET_ROLE] is authorized to access data of that classification.
5. **Privilege Escalation Check**: Compare the privilege level of [ORIGINATING_ROLE] and [TARGET_ROLE]. If [TARGET_ROLE] has a higher privilege level, flag this for audit but do not block unless the [ROLE_PERMISSION_MAP] explicitly prohibits escalation.
6. **Context Sanitization Check**: Scan [TRANSITION_CONTEXT] for any residual artifacts from the [ORIGINATING_ROLE]'s tools, memory, or permissions that could grant the [TARGET_ROLE] unauthorized access (e.g., API keys, session tokens, internal tool names).

Output a JSON object with the following schema:
{
  "transition_allowed": boolean,
  "violations": [
    {
      "check_name": string,
      "severity": "BLOCKER" | "WARNING",
      "description": string,
      "offending_field_or_action": string
    }
  ],
  "audit_log": {
    "timestamp": string,
    "originating_role": string,
    "target_role": string,
    "requested_action": string,
    "data_fields_shared": [string],
    "decision": "APPROVED" | "DENIED" | "APPROVED_WITH_WARNINGS"
  }
}

If any check fails with a BLOCKER severity, set transition_allowed to false and do not include the audit_log. If only WARNING violations exist, set transition_allowed to true and include all warnings in the violations array alongside the audit_log.

Adaptation Guidance: Replace the bracketed placeholders with your system's actual role definitions, permission maps, and data classification policies. The [ROLE_PERMISSION_MAP] should be a static JSON object injected at runtime, not generated by the model. For high-risk domains such as healthcare or finance, add a seventh check for regulatory compliance that references a [REGULATORY_POLICY] placeholder. The output schema is designed to be parsed by an orchestration framework; if a violation is detected, the framework should halt the handoff, log the violation, and optionally route to a human reviewer. Do not rely on this prompt alone for security; it is a defense-in-depth layer that should sit alongside application-level authorization logic.

The Role Transition Validation Prompt is not a standalone chat prompt. It is a programmatic checkpoint that sits inside a multi-agent orchestration framework. Every time context moves from one agent role to another—whether via handoff, escalation, or delegation—the orchestrator calls this prompt with the source role definition, the target role definition, and the transition payload. The prompt returns a structured validation result that the orchestrator must evaluate before allowing the transition to proceed. Treat the output as a gate, not a suggestion. If the validation result is blocked or requires_review, the orchestrator must halt the transition and either route to a human reviewer or log the event for audit.

Wire the prompt into your application with a thin harness function: validate_role_transition(source_role, target_role, transition_context). This function should construct the prompt by injecting the role definitions, the transition payload, and any relevant policy constraints into the template placeholders. Call the model with temperature=0 and a structured output format (JSON schema enforcement if your model provider supports it, otherwise a strict parse-and-validate step). The expected output schema includes fields for transition_allowed (boolean), violations (array of objects with boundary, severity, and description), privilege_escalation_detected (boolean), data_leakage_risk (enum: none/low/medium/high/critical), and recommended_action (enum: allow/block/flag_for_review). Validate the response against this schema before acting on it. If the model returns malformed JSON or missing required fields, retry once with a repair prompt that includes the raw output and the schema. If the retry also fails, block the transition and log the failure.

For production deployments, add a lightweight audit log entry for every transition validation. Capture the source role ID, target role ID, timestamp, validation result, violation details, and the model version used. This log serves two purposes: it provides traceability for compliance and governance reviews, and it becomes the dataset you need to tune the prompt over time. When you observe patterns—such as repeated false-positive blocks for a specific role pair or missed privilege escalations—use those logs to update the role boundary definitions or the validation prompt itself. Do not rely on this prompt as the sole defense in high-risk systems. Pair it with deterministic application-layer checks: verify that the target role's tool access list does not include tools the source role was denied, and confirm that the transition payload does not contain fields marked as source-role-only. The prompt catches semantic and contextual boundary violations; the application layer catches structural ones.