Tool-Use Authorization Boundary Prompt

This prompt is for platform engineers and AI safety engineers who need to enforce a strict authorization boundary around tool use. It is designed to be injected as a system-level instruction that evaluates every proposed tool call against a defined policy before execution. Use this when your AI assistant has access to multiple tools with different risk profiles, data access levels, or cost implications, and you need the model itself to act as the first line of authorization enforcement. The ideal user is someone integrating LLMs into a product backend where tool calls can trigger state changes, spend money, access PII, or modify production resources. You must have a clearly defined tool-use policy—a document that specifies which tools are allowed under which conditions, what confirmation is required, and what is categorically denied. Without this policy, the prompt has nothing to enforce.

This prompt is not a replacement for runtime authorization checks in your execution layer. It is a prompt-level gate that reduces the likelihood of unauthorized tool calls reaching your backend. The model can be confused, jailbroken, or simply wrong. Therefore, you must still validate every tool call in your execution environment against the same policy. Treat the prompt as a defense-in-depth layer: it catches obvious violations early, provides auditable reasoning, and reduces the load on your runtime authorization system. The prompt produces structured authorization decisions with explicit approvals, denials, or confirmation requirements, making the model's reasoning auditable. This is especially valuable when you need to log why a tool call was blocked or escalated, not just that it was blocked.

Do not use this prompt when you have only one or two low-risk tools with no meaningful authorization distinctions. In that case, a simple allow-list in your execution layer is more reliable and easier to maintain. Do not use this prompt as your sole authorization mechanism for high-risk operations such as financial transactions, medical record modifications, or safety-critical system commands—those require deterministic, tested, runtime enforcement with no model in the loop. Do not use this prompt when your tool-use policy is vague or unwritten; the model will hallucinate a policy that may be dangerously permissive or overly restrictive. Before deploying this prompt, write down your policy, test it against at least 20 tool-call scenarios including edge cases, and verify that your runtime authorization layer independently enforces the same rules.

This template defines a strict authorization boundary for tool-use decisions. It forces the model to classify every tool call against a defined policy before execution, returning one of three outcomes: approved, denied, or requires_confirmation. The prompt is designed to be injected as a system instruction before any tool-call decision point in your agent loop. It does not execute tools itself—it gates them. Use this when you need auditable, consistent authorization decisions that can be logged, reviewed, and tested independently from the tool execution layer.

textCopy
You are a tool-use authorization gatekeeper. Your only job is to decide whether a proposed tool call is permitted under the current policy. You do not execute tools. You do not answer user questions. You only authorize, deny, or flag tool calls for human confirmation.

## POLICY
[POLICY_RULES]

## CURRENT CONTEXT
User role: [USER_ROLE]
Session risk level: [RISK_LEVEL]
Previous authorizations this session: [PRIOR_AUTHORIZATIONS]

## PROPOSED TOOL CALL
Tool name: [TOOL_NAME]
Arguments: [TOOL_ARGUMENTS]
Justification provided by calling agent: [AGENT_JUSTIFICATION]

## DECISION RULES
1. If the tool call matches an explicitly permitted action in POLICY for this USER_ROLE and RISK_LEVEL, return "approved".
2. If the tool call matches an explicitly prohibited action in POLICY, return "denied" with the specific policy rule violated.
3. If the tool call is not explicitly covered by POLICY, or if RISK_LEVEL is "high" and the action is not pre-authorized, return "requires_confirmation".
4. If AGENT_JUSTIFICATION is missing, insufficient, or inconsistent with the proposed arguments, return "denied" with reason "insufficient_justification".
5. If the tool call would access, modify, or transmit data classified above the current USER_ROLE clearance, return "denied" with reason "data_classification_boundary".

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "decision": "approved" | "denied" | "requires_confirmation",
  "reason": "string explaining the decision with policy reference",
  "policy_rule_cited": "string identifier of the specific policy rule applied",
  "risk_factors": ["list of risk factors considered"],
  "confirmation_prompt": "string to show the human reviewer if requires_confirmation, otherwise null"
}

## CONSTRAINTS
- Do not invent policy rules. Only use rules explicitly stated in POLICY.
- If multiple policy rules conflict, escalate to "requires_confirmation" and explain the conflict.
- Never authorize a tool call that accesses data outside the USER_ROLE scope.
- If RISK_LEVEL is "critical", all non-read-only tool calls require confirmation.

Adaptation notes: Replace [POLICY_RULES] with your actual policy document, structured as explicit allow/deny rules with clear identifiers. The [USER_ROLE] and [RISK_LEVEL] placeholders should be populated from your session context before each authorization check. [PRIOR_AUTHORIZATIONS] should carry a summary of previous decisions in the current session to prevent authorization drift. The output schema is deliberately flat and deterministic—avoid adding optional fields that could cause parsing ambiguity in your authorization harness. If your policy is long, consider moving it to a separate system message with higher priority rather than inline in this template.

The authorization boundary prompt is not a standalone decision-maker; it is a policy enforcement layer that sits between tool-call generation and tool-call execution. In a production harness, you intercept every tool call the model proposes, package it with the user's session context, the tool's declared risk level, and any prior authorization decisions in the conversation, then send that package through this prompt before the tool ever runs. The prompt returns a structured decision—approve, deny, or confirm—and your harness must enforce that decision without exception. If the prompt says deny, the tool call is blocked and the model receives a structured denial reason it can use to explain the outcome to the user. If the prompt says confirm, the harness pauses execution and routes the request to a human approval queue with the prompt's generated confirmation message and risk summary.

Validation is the first hard requirement. Parse the model's JSON output and validate that decision is exactly one of the three allowed enum values, that tool_name matches the intercepted tool call, that reason is a non-empty string, and that confirmation_message is present and non-empty when decision equals confirm. If validation fails, do not execute the tool. Log the validation failure with the raw output, the session ID, and the tool call payload, then retry the authorization prompt once with the validation error appended as a correction instruction. If the retry also fails validation, escalate to a human operator and block the tool call. This validation gate prevents malformed authorization outputs from silently defaulting to approval or denial.

Model choice matters for this prompt. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that may drift on enum constraints or hallucinate tool names. Set temperature=0 to maximize decision consistency across identical inputs. If your platform supports structured output modes (e.g., OpenAI's response_format with a JSON schema, or Anthropic's tool-use with a defined schema), use them to enforce the output shape at the API level rather than relying solely on prompt instructions. This reduces validation failures and makes the authorization boundary more predictable under load.

Logging and observability are non-negotiable. Every authorization decision—approve, deny, or confirm—must be logged with the session ID, user ID, tool name, tool arguments, risk level, decision, reason, timestamp, and model version. For confirm decisions, also log the human reviewer's eventual response and the time-to-review. These logs serve three purposes: audit trails for compliance, calibration data for tuning risk thresholds, and debugging material when the authorization boundary behaves unexpectedly. Feed a sample of denied and confirmed decisions into a periodic human review cycle to check for over-blocking (false denials that frustrate users) and under-blocking (approvals that should have been confirmations or denials).

The authorization prompt must run synchronously before tool execution, which means it adds latency to every tool call. For low-risk tools (e.g., read-only lookups, non-sensitive data retrieval), consider caching authorization decisions per (user, tool, argument_hash) tuple with a short TTL to avoid redundant prompt calls. For high-risk tools, never cache; always run the full authorization check. If your application uses an agent loop with multiple sequential tool calls, batch authorization checks where possible by sending multiple pending tool calls in a single prompt, but only if the tools are independent—dependent tool chains must be authorized step by step because each tool's output may change the risk profile of the next call.

The hardest failure mode to catch in production is authorization drift, where the prompt's decisions slowly become more permissive or more restrictive as the model version, context length, or conversation complexity changes. Build an eval harness that runs a fixed set of 50-100 tool-call scenarios through the authorization prompt on every model update, prompt change, or deployment. Each scenario should have a known expected decision and a tolerance of zero for unexpected approvals on high-risk tools. Run this eval suite in CI before any prompt or model change reaches production. If a change causes even one high-risk tool to flip from confirm to approve or from deny to approve, block the release and investigate.