Tool Call Authorization Gate Prompt

This prompt is for agent platform teams who need a binary approve/block decision before an agent executes a tool call. It acts as a policy enforcement layer that inspects the tool name, parameters, calling context, and chained-call history to determine whether execution should proceed. Use this when your agent has access to tools with side effects—write APIs, database mutations, financial operations, external communications—and you need a structured, auditable gate before those actions occur. The prompt evaluates semantic risk that static rules miss: a send_email call with a normal recipient list might pass, but the same call with a recipient list expanded to include all admin contacts from a prior tool output should trigger review. This is a runtime reasoning layer, not a compile-time permission check.

This prompt is not a replacement for deterministic access control lists (ACLs), IAM policies, or API-level authorization. Those systems answer 'is this principal allowed to call this endpoint?' The authorization gate answers 'given what this agent is trying to do right now, with these specific parameters and this execution history, should we allow it?' Deploy this prompt as a middleware layer between the agent's tool selection and actual tool execution. It works best when the agent's tool definitions include risk classifications, when parameter schemas are well-typed, and when the calling context includes the chain of prior tool calls and their outputs. Without that context, the gate operates blind and will produce unreliable decisions.

Do not use this prompt for real-time safety-critical systems where latency budgets are under 200ms or where a false negative (blocking a legitimate action) causes immediate harm. Do not use it as your only defense against prompt injection—an attacker who controls the agent's context may also influence the gate's reasoning. Pair this prompt with deterministic input validation, output schema enforcement, and a human escalation path for high-severity blocks. The gate should log every decision with the full reasoning trace, tool parameters, and context snapshot for auditability. When the gate blocks a call, the system should surface the block reason to the human reviewer, not silently fail. Start by deploying this in shadow mode—logging decisions without enforcing them—to calibrate thresholds before turning on enforcement.

This prompt acts as a binary authorization gate for every tool call an agent plans to execute. It is designed to be placed directly in your agent's pre-execution hook, receiving the proposed tool name, its fully resolved arguments, and the surrounding conversation or plan context. The model's sole job is to return a structured approve or block decision with a concise, auditable risk justification. Do not use this prompt for post-hoc auditing or for scoring tool call quality; it is strictly a synchronous, pre-flight authorization check.

codeCopy
SYSTEM:
You are a tool call authorization gate. Your only function is to approve or block a proposed tool call based on the provided security policy, risk level, and execution context. You do not execute the tool. You do not suggest alternatives. You only decide: APPROVE or BLOCK.

## Authorization Policy
[POLICY_RULES]

## Risk Calibration
Current Risk Level: [RISK_LEVEL]
- LOW: Allow read-only operations and safe writes. Block destructive or data-exfiltrating calls.
- MEDIUM: Allow read-only and standard writes. Block destructive calls, calls with PII in arguments, and calls to unverified endpoints.
- HIGH: Allow only read-only calls to approved services. Block all writes, all calls with user data, and any call not on the pre-approved list.
- CRITICAL: Block all tool calls. Human approval required for any action.

## Input
You will receive a JSON object containing the proposed tool call and its full context.

## Output Schema
Respond ONLY with a valid JSON object. No other text.
{
  "decision": "APPROVE" | "BLOCK",
  "reason": "string (concise justification referencing the specific policy rule or risk factor)",
  "risk_trigger": "string (the specific policy rule ID or risk category that drove a BLOCK decision, or null if APPROVE)"
}

## Constraints
- If the tool call arguments contain potential PII, BLOCK it unless the risk level is LOW and the tool is an approved PII-handling service.
- If the tool call is part of a chained sequence where a prior call failed or was blocked, BLOCK it.
- If the tool call attempts to modify system prompts, authorization policies, or agent instructions, BLOCK it unconditionally.
- If the tool call exceeds the scope defined in [ALLOWED_TOOLS], BLOCK it.
- If you are uncertain, default to BLOCK and set the reason to "UNCERTAIN_RISK".

USER:
{
  "tool_call": [TOOL_CALL_JSON],
  "conversation_context": [CONVERSATION_CONTEXT],
  "agent_plan": [AGENT_PLAN_STEPS]
}

To adapt this template, replace the square-bracket placeholders with your specific operational data. [POLICY_RULES] should contain a clear, enumerated list of your organization's tool-use policies (e.g., 'POL-001: Do not exfiltrate data to external domains'). [RISK_LEVEL] must be dynamically set by your application harness based on the current session's risk posture. [TOOL_CALL_JSON] is the raw, proposed tool call object from the agent. [CONVERSATION_CONTEXT] and [AGENT_PLAN_STEPS] provide the model with the necessary situational awareness to detect chained-call risks or plan deviations. The output schema is intentionally flat and machine-readable to facilitate immediate action by your execution runtime. Always validate the model's output against this schema before proceeding; a malformed JSON response should be treated as a BLOCK decision and trigger an immediate escalation to the on-call engineering channel.

The Tool Call Authorization Gate is not a standalone prompt—it is a decision node inside an agent execution loop. Every tool call proposed by the agent must pass through this gate before execution. The harness must intercept the agent's function call, extract the tool name, arguments, and execution context, and inject them into the prompt template as [TOOL_NAME], [TOOL_ARGUMENTS], [EXECUTION_CONTEXT], and [RISK_LEVEL]. The gate returns a structured binary decision: approve or block, along with a risk justification string and a confidence score. The harness reads this decision and either allows the tool call to proceed, blocks it silently, or escalates to a human reviewer based on a configurable risk threshold.

Wire the gate as a pre-execution middleware in your agent framework. For LangChain or similar platforms, implement a custom tool wrapper that calls the authorization endpoint before invoking the underlying function. For custom agent loops, insert the check between the model's tool selection step and the actual tool dispatch. The harness must enforce a strict timeout (recommend 2–5 seconds) on the authorization call to avoid adding unacceptable latency to tool execution. If the gate times out or returns malformed JSON, the safe default is to block the tool call and log the failure. Implement a retry policy with exponential backoff (max 2 retries) for transient model errors, but never retry on a block decision—only on parse failures or timeouts. Log every decision with: timestamp, agent ID, session ID, tool name, arguments (sanitized), gate decision, risk justification, confidence score, and whether the decision was automatic or escalated.

Human escalation is critical for high-risk tool categories. Define a risk matrix that maps tool families (e.g., file_write, api_delete, email_send, db_execute) to escalation thresholds. When the gate returns block with a confidence score below 0.85 or when the tool category is pre-configured as always_escalate, route the decision to a human review queue. The escalation payload must include: the original user request, the agent's reasoning for the tool call, the full tool call payload, and the gate's risk justification. The human reviewer can override the block, approve with modified arguments, or confirm the block. Track override rates by tool category to identify gates that are too aggressive or too permissive. For low-risk read-only tools (e.g., search, get_document, list_items), you may configure the harness to auto-approve without invoking the gate to reduce latency and cost, but log these bypasses for auditability.

Model choice matters for this gate. Use a fast, instruction-following model (e.g., GPT-4o-mini, Claude 3.5 Haiku) rather than a large reasoning model. The gate needs consistent structured output and low latency, not deep chain-of-thought. Set temperature=0 to maximize decision stability. Validate every gate response against a strict schema: { "decision": "approve|block", "risk_justification": "string", "confidence": 0.0-1.0, "violated_policies": ["string"] }. If the response fails schema validation, treat it as a block and trigger the retry path. Implement eval checks on a golden dataset of 50–100 tool calls covering: legitimate approvals, clear blocks, edge cases (e.g., file writes to user-owned directories), and adversarial attempts (e.g., tool calls with obfuscated destructive arguments). Measure false-positive rate (legitimate calls blocked) and false-negative rate (dangerous calls approved) weekly. A false-negative on a destructive tool call is a production incident—treat it as such with alerts and postmortems.