Tool Authorization Policy for Multi-Agent Systems Prompt Template

This prompt is for AI platform engineers coordinating tool access across multiple specialized agents within a single system. Use it when you have a multi-agent architecture where each agent has a distinct role and tool scope, and you need a single, authoritative system prompt that defines per-agent tool scopes, prevents tool access leakage between agents, and handles inter-agent tool delegation with explicit authorization checks. The primary job-to-be-done is establishing a clear, machine-enforceable contract that the model can interpret to prevent Agent A from silently using a tool that only Agent B should access, or from delegating a sensitive operation without proper authorization context.

You should not use this prompt for single-agent assistants, simple chatbot tool calling, or systems where all agents share the same flat tool permissions. It assumes you already have stable agent role definitions, a tool catalog with unique identifiers, and an execution layer that can enforce the authorization decisions made by the prompt. The ideal user is an AI platform engineer who needs to define authorization logic in the prompt layer before it reaches the execution layer, and who understands that this prompt is a policy document, not a runtime enforcement mechanism. You will need to provide the agent role definitions, the tool catalog with per-tool risk levels, and the delegation rules as inputs to the template.

Before using this prompt, confirm that your execution layer can act on the authorization decisions the model produces. If your runtime cannot enforce a denial, this prompt alone is insufficient. The prompt works best when paired with structured output validation that checks for unauthorized tool calls in the model's response, and with logging that captures authorization decisions for audit. Do not use this prompt as a substitute for runtime access control; it is a policy specification layer that reduces ambiguity and guides model behavior, but it must be backed by deterministic enforcement in your application code. Proceed by gathering your agent role definitions, tool catalog, and delegation rules, then adapt the template in the next section.

This template encodes a tool authorization policy directly into the system prompt for a multi-agent coordinator or a specialized agent. It is designed to be the single source of truth for tool access boundaries before any execution-layer enforcement. The prompt uses square-bracket placeholders for all dynamic values—replace each one with your production configuration before deployment. The structure separates the agent's identity, its explicit tool allowlist, delegation rules, and strict output formatting requirements to make authorization decisions auditable and testable.

markdownCopy
# SYSTEM INSTRUCTION: Tool Authorization Policy

## Identity and Scope
You are [AGENT_NAME], a specialized agent within the [SYSTEM_NAME] multi-agent system. Your primary function is [AGENT_PURPOSE]. You operate under a strict tool authorization policy. You are prohibited from performing any action not explicitly granted below.

## Authorized Tools
You are permitted to call ONLY the following tools. Any attempt to call a tool not on this list must be refused.

| Tool Name | Permitted Arguments | Constraints |
|-----------|---------------------|-------------|
| [TOOL_NAME_1] | [ARG_1], [ARG_2] | [CONSTRAINT_1] |
| [TOOL_NAME_2] | [ARG_1] | [CONSTRAINT_2] |

## Tool Call Protocol
1. Before every tool call, verify the tool name is in your Authorized Tools table.
2. Verify all provided arguments match the Permitted Arguments column.
3. Verify the call context satisfies all Constraints.
4. If any check fails, do not call the tool. Instead, respond with the exact refusal format below.

## Inter-Agent Delegation
You may delegate a task to another agent ONLY if the target agent is listed below and the task falls within that agent's declared scope. When delegating, you must output a structured delegation message.

| Agent Name | Delegated Scope | Authorization Required |
|------------|-----------------|------------------------|
| [AGENT_B] | [SCOPE_DESCRIPTION] | [YES/NO] |
| [AGENT_C] | [SCOPE_DESCRIPTION] | [YES/NO] |

If Authorization Required is YES, you must request and receive explicit user confirmation before sending the delegation message. Output the confirmation request using the [CONFIRMATION_FORMAT] specified below.

## Output Formats

### Refusal (Unauthorized Tool Call)
```json
{
  "decision": "REFUSED",
  "reason": "Tool [REQUESTED_TOOL] is not in the authorized tool list for [AGENT_NAME].",
  "suggested_action": "[SUGGESTION_OR_NULL]"
}

Delegation Message

jsonCopy
{
  "decision": "DELEGATE",
  "target_agent": "[AGENT_NAME]",
  "task_summary": "[SUMMARY]",
  "payload": { }
}

Confirmation Request

jsonCopy
{
  "decision": "CONFIRMATION_REQUIRED",
  "target_agent": "[AGENT_NAME]",
  "action_description": "[DESCRIPTION]",
  "risk_level": "[RISK_LEVEL]"
}

Override Policy

Tool authorization overrides are permitted only under the following conditions: [OVERRIDE_CONDITIONS]. When an override is executed, you must log the justification and the authorizing entity in the audit trail.

Audit Requirement

For every tool call, delegation, or refusal, append a structured audit record to your final response under the key audit_trail.

To adapt this template for production, start by replacing all placeholders with concrete values from your agent specification and tool registry. The [CONSTRAINTS] column is critical—use it to encode rate limits, data sensitivity checks, or user-role requirements. The delegation table should mirror your actual agent topology. If your system does not support inter-agent delegation, remove that section entirely to reduce prompt length and prevent the model from hallucinating delegation capabilities. The structured output formats (Refusal, Delegation, Confirmation Request) are designed to be parsed by an upstream orchestrator, so coordinate the JSON schemas with your application's state machine. Before deployment, run the evaluation criteria defined in the full playbook to verify that the prompt prevents tool access leakage and correctly handles delegation authorization checks.

This prompt is not a standalone artifact; it is the policy layer of a multi-agent authorization system. The prompt template defines per-agent tool scopes and delegation rules, but the application harness must enforce these rules at runtime. The harness acts as a gate between the model's output and the actual tool execution layer. When an agent generates a tool call, the harness validates it against the policy defined in the prompt before the tool is invoked. This prevents prompt injection, model error, or context drift from bypassing authorization boundaries. The implementation pattern is: model proposes, harness validates, system executes, harness logs.

To implement this, build a Tool Authorization Middleware that sits between the agent's model response and your tool execution engine. The middleware must: (1) Parse the agent's proposed tool call and extract the agent_id, tool_name, and arguments. (2) Retrieve the active policy for that agent from a policy store (which should be derived from the system prompt's [AGENT_TOOL_SCOPES] variable). (3) Validate that the tool is in the agent's allowed scope and that the arguments conform to the [CONSTRAINTS] schema. (4) If the call is a delegation request to another agent, validate that the target agent's scope permits the delegated tool and that the delegation chain depth does not exceed [MAX_DELEGATION_DEPTH]. (5) If validation fails, inject a structured error message back into the agent's context window as a tool response, forcing it to correct its behavior without executing the unauthorized call. This closed-loop correction is critical for maintaining policy adherence across multi-turn sessions.

Logging and audit must be built into the middleware, not left to the model. For every tool call, log: the requesting agent, the proposed tool, the full arguments, the policy decision (allowed/denied), the justification from the policy rule that matched, a timestamp, and the session ID. This audit trail serves two purposes: it provides compliance evidence for [AUDIT_REQUIREMENTS] and it feeds your evaluation pipeline. For retry logic, implement a circuit breaker: if an agent receives three consecutive authorization denials in a single turn, the harness should escalate to a human reviewer or terminate the agent's tool-use capability for the remainder of the session, depending on the [RISK_LEVEL] configuration. Do not allow infinite retry loops on authorization failures.

Model choice matters here. This prompt requires strong instruction-following and structured output capabilities. Use a model that reliably produces tool calls in your defined schema (e.g., OpenAI's parallel tool calling or Anthropic's tool use format). For high-risk deployments, run a secondary, smaller classification model as a pre-validation step to flag potentially dangerous tool calls before they reach the primary authorization middleware. This adds a defense-in-depth layer. Testing must include adversarial scenarios: prompt the agent to call a tool outside its scope, attempt to delegate to an unauthorized agent, or craft arguments that bypass schema constraints. Your eval suite should measure the Authorization Enforcement Rate (AER)—the percentage of unauthorized tool calls that are correctly blocked by the harness before execution. A passing threshold for production should be 100% on known attack vectors; anything less indicates a bypass in your middleware or an ambiguity in your policy prompt that needs tightening.