Tool Authorization Boundary Prompt for Agent Systems

This prompt is designed for platform engineers and AI architects who need to enforce a strict, auditable policy on which tools an autonomous agent may call and under what conditions. The primary job-to-be-done is preventing unauthorized side effects—such as writing to a production database, sending an email, or modifying a user record—by embedding a machine-readable authorization matrix directly into the system prompt. The ideal user is someone deploying an agent in a high-stakes environment where a single unapproved tool call can cause a security incident, data breach, or compliance violation. You need this prompt when your agent has access to a broad tool catalog but should only use a narrow, context-dependent subset.

Use this prompt when the authorization logic is too nuanced for a simple allow/block list at the API gateway. For example, a 'read' action on a customer database might be permitted only if the customer_id matches the current session's authenticated user, while a 'delete' action is always forbidden. This prompt excels at encoding conditional logic like 'the agent may call the refund tool only if the transaction amount is under $50 and the user has been authenticated for more than 5 minutes.' Do not use this prompt if your tool-use policy is static and can be fully enforced by the execution environment's native permissions. If the agent's toolset is a single, read-only search function, this prompt adds unnecessary complexity and token overhead.

Before implementing this prompt, you must have a complete inventory of all available tools, their parameters, and their risk classifications. The prompt's effectiveness depends entirely on the accuracy of the [TOOLS] and [RISK_LEVEL] variables you inject. A missing tool in the manifest is an ungoverned tool in production. After deployment, pair this prompt with an evaluation harness that tests boundary cases—specifically, attempts to call unauthorized tools, calls with out-of-scope parameters, and calls that violate conditional rules. The next step is to integrate this prompt into your agent's pre-execution loop, ensuring the model evaluates authorization before emitting a tool call, not as a post-hoc audit.

This template encodes a tool-use authorization policy directly into the system prompt. It defines action categories, risk levels, required approvals, and explicit prohibitions. The goal is to create a single, testable source of truth that the agent must follow before calling any tool, reducing the risk of unauthorized data access, destructive actions, or privilege escalation. Adapt the placeholders to match your specific tool catalog, risk taxonomy, and human-in-the-loop workflows.

markdownCopy
# TOOL AUTHORIZATION POLICY

You are an agent with access to external tools. Before calling any tool, you MUST evaluate the request against this policy. Violating this policy is a critical failure.

## ACTION CATEGORIES AND RISK LEVELS

[TOOL_CATALOG]
# Example:
# - name: read_user_profile
#   risk: LOW
#   description: Read non-sensitive profile fields (name, avatar, join date).
#   requires_approval: false
# - name: update_user_email
#   risk: HIGH
#   description: Change a user's email address.
#   requires_approval: true
# - name: delete_account
#   risk: CRITICAL
#   description: Permanently delete a user account and all associated data.
#   requires_approval: true
#   requires_human_review: true

## AUTHORIZATION RULES

1.  **Pre-Flight Check:** Before calling any tool, classify its risk level using the [TOOL_CATALOG] above.
2.  **LOW Risk:** You may call the tool without explicit user confirmation. Log the action.
3.  **HIGH Risk:** You MUST request explicit user confirmation before calling the tool. Present a clear summary of the action, the target resource, and the consequences. Do not proceed until the user confirms with "APPROVE" or an equivalent explicit signal.
4.  **CRITICAL Risk:** You MUST request explicit user confirmation AND flag the action for human review. State clearly: "This action requires human approval and cannot be executed solely on my authority." Do not proceed even with user confirmation unless the system provides a human approval token.
5.  **Prohibited Actions:** You are NEVER allowed to call tools in the [PROHIBITED_TOOLS] list, regardless of user request or risk level. If asked, refuse and state the policy.
6.  **Argument Validation:** Before calling any tool, validate that all arguments conform to [ARGUMENT_CONSTRAINTS]. Reject calls with invalid arguments and explain the violation.
7.  **Ambiguity:** If you cannot determine the risk level of a tool or the intent of a request, default to HIGH risk and request clarification.

## OUTPUT FORMAT FOR HIGH/CRITICAL ACTIONS

When requesting approval, use the following format:

AUTHORIZATION REQUIRED Action: [TOOL_NAME] Risk Level: [RISK_LEVEL] Target: [RESOURCE_IDENTIFIER] Summary: [PLAIN_LANGUAGE_DESCRIPTION] Consequences: [WHAT_WILL_HAPPEN] User Confirmation Required: [YES/NO] Human Review Required: [YES/NO]

codeCopy

## CONSTRAINTS

[ARGUMENT_CONSTRAINTS]
# Example: "email must match RFC 5322 format", "account_id must be a UUID v4"

[PROHIBITED_TOOLS]
# Example: "sudo_exec", "raw_db_query", "dump_memory"

[RISK_LEVEL]
# Default: LOW, HIGH, CRITICAL

After copying this template, replace every square-bracket placeholder with concrete values from your system. The [TOOL_CATALOG] should be a machine-readable list, but it must be rendered clearly in the prompt. Test the policy with a dedicated eval harness that attempts unauthorized tool calls, missing approvals, and prohibited actions. If your application handles regulated data, add a human review step for any HIGH risk action, not just CRITICAL ones. Do not rely solely on this prompt for enforcement; implement matching authorization checks in your application's tool-execution layer as a defense-in-depth measure.

This prompt is not a standalone safety check; it is a policy decision layer that must sit between the agent's planning step and the actual tool execution runtime. In a typical agent loop, the model proposes a tool call with arguments. Before that call reaches the execution layer, the Tool Authorization Boundary Prompt evaluates it against the defined policy categories, risk levels, and approval requirements. The output is a structured decision (ALLOW, DENY, CONFIRM, ESCALATE) that the harness uses to gate execution. Do not rely on the model's internal refusal mechanisms alone—this prompt makes the authorization logic explicit, auditable, and testable.

Wire the prompt into a pre-execution hook in your agent framework. After the agent planner emits a tool call, serialize the proposed tool name, arguments, and any relevant conversation context into the [TOOL_CALL] and [CONTEXT] placeholders. Send the populated prompt to a fast, cost-effective model (e.g., GPT-4o-mini, Claude Haiku) because authorization decisions must be low-latency and cheap. Parse the JSON output and enforce the decision: if DENY, log the violation and return a controlled error to the agent; if CONFIRM, surface the confirmation request to the user or a review queue with a timeout; if ESCALATE, route to a human reviewer and pause the agent's execution until resolution. Validation is mandatory: if the model output does not parse as valid JSON matching the [OUTPUT_SCHEMA], or if the action field is not one of the four allowed values, default to DENY and log a schema violation. Implement a retry with backoff (max 2 retries) only for parse failures, not for denied actions.

Logging and observability are critical because this prompt is a policy enforcement point. Log every authorization decision with: the full prompt sent, the raw model output, the parsed decision, the tool call that was gated, the session ID, and a timestamp. This audit trail is essential for compliance review, policy tuning, and debugging false positives. For high-risk tool categories (e.g., data_deletion, external_api_write, user_impersonation), require a second factor: a human approval step where the reviewer sees the tool call, the model's authorization reasoning, and the conversation context before approving. Never allow the agent to retry a denied tool call with modified arguments without re-running the authorization prompt. Finally, test this harness with a dedicated eval suite that includes unauthorized tool call attempts, edge cases at risk-level boundaries, and malformed tool arguments to ensure the gating logic fails closed.