Tool-Use Restriction Guardrail Prompt Template

This prompt is for platform engineers and AI safety architects who need to enforce hard, pre-execution restrictions on which tools an agent can invoke and with what arguments. The job-to-be-done is preventing an LLM agent from calling a dangerous or unauthorized function, even if the user or the model's own reasoning chain tries to route around the policy. Use this when you are building a tool-augmented agent and you cannot rely on the model's general safety training alone—you need an explicit, auditable guardrail that sits between the model's tool-call decision and the actual execution environment.

The ideal user is an engineer wiring a function-calling or tool-use loop into a production application. They have a defined set of tools with known risk profiles, and they need a system-level instruction that acts as a pre-flight check. Required context includes a complete list of allowed tools, per-tool argument schemas, and a clear definition of which tools or argument patterns are disallowed. This prompt is not a substitute for runtime validation in your application code; it is a defense-in-depth layer that reduces the probability of a dangerous call reaching your execution layer. It is also not designed for dynamic, user-defined tool sets that change mid-session without a corresponding guardrail update.

Do not use this prompt when you need a conversational refusal or a user-facing explanation. This guardrail is designed to produce a structured blocking decision, not a polite decline. If your goal is to explain to a user why an action is unavailable, pair this with a Safe-Decline prompt in the user-facing layer. Also, avoid this prompt if your primary risk is data exfiltration through the content of a tool's response rather than the invocation itself—that requires output filtering, not tool-call blocking. Before deploying, you must test this guardrail against adversarial rewordings, multi-turn tool-call sequences, and edge cases where the model attempts to chain allowed tools to achieve a disallowed outcome.

This template is designed to be placed in the system prompt or a dedicated guardrail layer of an agent that has access to external tools. It defines a strict policy that the model must evaluate before emitting any tool call. The policy checks the requested tool name, the caller context, and the proposed arguments against a set of allow/deny rules. The model is instructed to output a structured POLICY_CHECK block instead of the tool call if the request is disallowed. This prevents the execution environment from ever receiving an unauthorized action.

textCopy
You are a tool-use guardrail. Before you output any tool call, you must evaluate it against the following policy. Do not output the tool call if it violates the policy. Instead, output a structured POLICY_CHECK block explaining the violation.

[POLICY_RULES]

TOOL_CALL_REQUEST:
Tool Name: [TOOL_NAME]
Arguments: [TOOL_ARGUMENTS]
Caller Context: [CALLER_CONTEXT]

POLICY EVALUATION INSTRUCTIONS:
1. Check if [TOOL_NAME] is in the list of allowed tools for the [CALLER_CONTEXT].
2. If allowed, validate that [TOOL_ARGUMENTS] conform to the argument constraints defined for [TOOL_NAME].
3. If the tool is not allowed or arguments are invalid, output a POLICY_CHECK block and STOP. Do not output the tool call.
4. If the tool and arguments are allowed, output the tool call exactly as requested.

OUTPUT FORMAT FOR DISALLOWED CALLS:
POLICY_CHECK:
  status: DENIED
  tool_requested: [TOOL_NAME]
  reason: [DENIAL_REASON]
  policy_ref: [POLICY_REFERENCE]

OUTPUT FORMAT FOR ALLOWED CALLS:
[ORIGINAL_TOOL_CALL]

To adapt this template, replace the [POLICY_RULES] placeholder with your actual allow/deny lists and argument constraints. The [CALLER_CONTEXT] should be populated dynamically by your application harness with the user's role, session ID, or tenant ID before the prompt is assembled. The [TOOL_NAME] and [TOOL_ARGUMENTS] are typically injected by the agent's planning step, but this guardrail prompt should be evaluated as a final gate. For high-risk deployments, do not rely solely on this prompt; implement a hard-coded pre-execution check in your application code that also parses the POLICY_CHECK block and refuses to execute the tool if the status is DENIED. Test this guardrail with adversarial inputs where the model attempts to call a disallowed tool directly, bypass the check by omitting the POLICY_CHECK format, or manipulate the [CALLER_CONTEXT] to escalate privileges.

The Tool-Use Restriction Guardrail is not a standalone prompt—it is a pre-execution gate that must be inserted into the agent's tool-calling pipeline. The guardrail prompt evaluates every tool call the model proposes before the call is executed. In a typical implementation, the agent loop generates a function call, the application layer intercepts it, constructs a guardrail evaluation request using this prompt template, and only forwards the call to the tool executor if the guardrail returns allow. If the guardrail returns deny, the tool call is blocked, and the denial reason is injected back into the model's context as a synthetic tool response so the agent can recover or escalate.

The harness requires several components to be reliable in production. First, tool-call interception must happen synchronously before any side effects occur—this means the guardrail evaluation must complete before a database write, API call, or file operation executes. Second, argument validation should be performed both by the guardrail prompt (for semantic checks like 'is this user ID in the allowed tenant scope?') and by the application layer (for structural checks like 'is this a valid UUID?'). Third, structured output parsing is mandatory: the guardrail prompt must return a machine-readable decision (allow, deny, needs_clarification) plus a reason string. Use a strict JSON schema with response_format or equivalent constrained decoding to prevent the model from producing free-text decisions that break downstream logic. Fourth, retry logic should be minimal—if the guardrail fails to produce valid JSON, log the raw output and default to deny for safety. Do not retry guardrail evaluations more than once without human review.

For logging and audit, capture the full guardrail evaluation payload: the proposed tool name, arguments, the guardrail's decision, the reason, the model and prompt version used, and a timestamp. This log is essential for debugging false positives (legitimate calls blocked) and false negatives (disallowed calls that slipped through). In high-risk deployments, route all deny decisions to a human review queue with a short SLA. For model choice, use a fast, instruction-following model for the guardrail—latency is critical because the guardrail sits on the critical path of every tool call. A smaller model fine-tuned on your tool policy may outperform a large general-purpose model on both speed and accuracy. Finally, test the harness end-to-end with tool-call interception tests that simulate allowed calls, disallowed calls, edge-case arguments, and adversarial rephrasing of tool names or parameters. The guardrail prompt is only as strong as the interception harness that enforces its decisions.