Agent Handoff Permission Transfer Prompt

This prompt is for multi-agent system architects who need to transfer context and authority between specialized agents without silently escalating privileges or losing critical constraints. The core job is generating a handoff protocol that explicitly declares which permissions transfer, which require re-validation, and how the receiving agent confirms its scope before acting. Use this when you have two or more agents with distinct permission sets—such as a research agent handing off to an execution agent—and you need the handoff to be auditable, reversible, and resistant to scope creep. The ideal user is an engineering lead or platform architect who already has agent roles defined and needs the glue that makes handoffs safe.

Do not use this prompt when agents share identical permission scopes, when there is no actual authority transfer (simple message passing), or when you lack a defined permission model for each agent. This prompt assumes you have already completed the hard work of defining per-agent tool allowlists, data access boundaries, and refusal policies. Without those inputs, the handoff protocol will be hollow. The prompt is also inappropriate for single-agent workflows or for systems where all agents operate under a single monolithic permission set—those scenarios don't require permission transfer logic, only context passing. For high-risk domains such as healthcare, finance, or infrastructure control, pair this prompt's output with human review checkpoints and audit logging before any transferred permission is exercised.

The output is a structured handoff specification, not a runtime execution script. You will receive a declaration of transferred permissions, a list of permissions that require re-validation, confirmation steps the receiving agent must perform, and explicit denial rules for permissions that must never transfer. Wire this into your agent orchestration layer as a pre-action validation step: before the receiving agent executes any tool call, it must confirm the call falls within its post-handoff scope. Store the handoff record for audit trails. Common failure modes include permission leakage through vague transfer language, missing re-validation steps that let stale authorizations persist, and receiving agents that fail to confirm scope before acting. Test with adversarial handoff scenarios where the sending agent attempts to transfer permissions it doesn't hold or where the handoff payload is malformed.

Next step: after generating the handoff protocol, run it through your permission scope regression test suite to verify that transferred permissions don't create unintended escalation paths. Then implement the confirmation step in your agent harness—this is the most commonly skipped step and the most common source of production incidents in multi-agent systems.

This template is designed for multi-agent system architects who need to produce a reliable, machine-readable handoff specification. The core challenge is ensuring that when Agent A delegates work to Agent B, the receiving agent understands exactly which permissions it has inherited, which require fresh validation, and what actions it must take to confirm its operational scope before executing any task. The prompt forces explicit declaration of transfer rules, reducing the risk of privilege escalation or unauthorized action during handoff.

textCopy
You are a permission transfer protocol designer for a multi-agent system. Your task is to generate a structured handoff specification based on the provided context. The specification must be unambiguous and executable by a receiving agent's permission validator.

## INPUTS
- [SOURCE_AGENT_ROLE]: Description of the originating agent's role and current task.
- [TARGET_AGENT_ROLE]: Description of the receiving agent's intended role.
- [SOURCE_PERMISSION_MANIFEST]: The complete list of permissions, tool access, and data scopes currently held by the source agent.
- [TASK_CONTEXT]: The specific task or subtask being delegated.
- [ORGANIZATIONAL_POLICY]: Any overarching security or compliance policies that govern permission transfer.

## CONSTRAINTS
- [CONSTRAINTS]: Additional constraints such as 'Deny-by-default for all write operations' or 'Require human approval for data access outside the [DATA_SCOPE] boundary.'

## OUTPUT_SCHEMA
Produce a JSON object conforming to this exact schema:
{
  "handoff_id": "unique string",
  "source_agent": "string",
  "target_agent": "string",
  "permission_transfer_list": [
    {
      "permission_name": "string",
      "transfer_decision": "GRANTED | DENIED | REVALIDATE_REQUIRED",
      "rationale": "string explaining decision based on policy and task context",
      "constraints_inherited": ["string constraints from source"]
    }
  ],
  "target_agent_startup_checklist": [
    "Actionable step the target agent must execute to confirm its scope before acting, e.g., 'Run self-capability check against active permission set.'"
  ],
  "escalation_rule": "string describing what to do if the target agent cannot confirm its scope or encounters a denied permission during execution."
}

To adapt this template, replace the square-bracket placeholders with concrete data from your agent orchestration layer. The SOURCE_PERMISSION_MANIFEST should be a structured object your system already maintains; do not ask the model to invent permissions. For high-risk deployments, the generated permission_transfer_list should be programmatically validated against a master policy before being injected into the target agent's context. Always pair this prompt with an evaluation step that checks for permission leakage—specifically, that no GRANTED permission exceeds the intersection of the source agent's scope and the target agent's least-privilege requirements for the task.

This prompt is not a standalone chat instruction; it is a structured generation step inside a multi-agent orchestrator. When Agent A prepares to hand off to Agent B, the orchestrator should call this prompt with the current session context, Agent A's active permission manifest, and the intended task for Agent B. The output is a machine-readable handoff payload—not a user-facing message—that the orchestrator parses, validates, and attaches to Agent B's system instructions before Agent B receives any user or tool context. Treat the handoff as a privilege-bracketing event: Agent B starts with zero trust until the handoff payload is validated and its permission scope is explicitly activated.

Wire this prompt into your agent framework as a pre-handoff hook. Before invoking Agent B, the orchestrator must: (1) extract Agent A's current permission set from a trusted source of truth (not from the conversation history), (2) populate the [SOURCE_AGENT_PERMISSIONS] and [TARGET_AGENT_DEFAULT_PERMISSIONS] fields from that source, (3) call the prompt with a unique handoff_id for traceability, and (4) validate the output against a JSON schema that enforces the transferred_permissions, revoked_permissions, requires_revalidation, and scope_confirmation_required fields. Reject any handoff payload where transferred_permissions contains entries not present in the source agent's manifest, or where requires_revalidation is empty for high-risk action categories such as write, delete, or external API access. Log the full handoff payload, validation result, and any rejection reason to an audit store before proceeding.

For production reliability, implement a retry-and-escalate pattern. If the prompt produces invalid JSON, missing required fields, or a permission set that fails validation, retry once with a stricter [CONSTRAINTS] block that includes the validation error message. If the second attempt fails, escalate to a human operator via a predefined escalation channel and block the handoff. Never default to granting full permissions on failure. For model choice, use a model with strong structured output and instruction-following capability (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize determinism in permission transfer decisions. If your orchestrator supports tool use, consider implementing a validate_handoff_permissions tool that performs the schema and scope checks programmatically, keeping the model focused on the transfer logic rather than output formatting. The next step after a successful handoff is to inject the scope_confirmation_prompt into Agent B's system instructions and require Agent B to emit a confirmation receipt before executing any tool calls.