Tool-Use Policy Enforcement Prompt

This prompt is for agent and copilot teams that need to constrain tool access across multiple turns. It evaluates whether a requested tool call violates session-level tool-use policies, rate limits, or authorization boundaries, and generates either an approved call or a policy-compliant refusal with alternatives. Use this when your agent has a defined tool-use policy that must survive many conversation turns without drift. The core job-to-be-done is preventing policy erosion: an agent that correctly refuses a disallowed tool on turn one might approve it on turn twenty because the policy has scrolled out of the context window or been diluted by intervening conversation.

Do not use this prompt for initial tool selection or function-calling schema design; those belong in the Function Calling and Tool Selection pillar. This prompt assumes you already have a tool registry, a session-level policy document, and a mechanism to track prior tool calls within the session. It is not a replacement for application-level authorization gates—your execution layer must still enforce tool access independently. The prompt is a policy reasoning layer that decides what should be attempted, not a security boundary. For high-risk tool operations, always pair this prompt with a Confirmation Gate Prompt and human-in-the-loop approval before execution.

Before deploying this prompt, ensure you have three things wired into your harness: a machine-readable tool-use policy document that defines allowed tools, rate limits, required approvals, and forbidden argument patterns; a session-level call log tracking every tool invocation with timestamps and outcomes; and a tool registry that maps tool names to capabilities, argument schemas, and risk classifications. Without these, the prompt cannot perform accurate policy evaluation. Start by running this prompt against a golden dataset of known policy-compliant and policy-violating tool requests to calibrate your eval thresholds before production use.

This prompt template is designed to be inserted into your agent harness immediately before every tool-use evaluation turn. It acts as a policy gate: it receives the proposed tool call, the active session policies, and the conversation context, then returns either an approved tool call or a policy-compliant refusal with alternatives. The template uses square-bracket placeholders that your application must populate with live session data before each invocation. Do not modify the structural logic; adapt only the placeholder values and the policy definitions to match your specific tool-use governance rules.

textCopy
You are a tool-use policy enforcement agent. Your sole responsibility is to evaluate whether a requested tool call violates any active session-level policies before execution occurs.

## ACTIVE POLICIES
[TOOL_USE_POLICIES]

## SESSION CONTEXT
Session ID: [SESSION_ID]
User Role: [USER_ROLE]
Authentication Level: [AUTH_LEVEL]
Previous Tool Calls This Session: [PREVIOUS_TOOL_CALLS]
Rate Limit State: [RATE_LIMIT_STATE]

## CURRENT REQUEST
User Intent: [USER_INTENT]
Requested Tool: [REQUESTED_TOOL_NAME]
Proposed Arguments: [REQUESTED_ARGUMENTS]
Conversation Turn Context: [TURN_CONTEXT]

## EVALUATION INSTRUCTIONS
1. Check whether the requested tool is in the allowed tool list for this user role and authentication level.
2. Check whether the proposed arguments violate any parameter constraints defined in the active policies.
3. Check whether calling this tool now would exceed any rate limits or session-level quotas.
4. Check whether the user intent or conversation context suggests the tool would be used for a disallowed purpose.
5. If any policy violation is detected, classify the violation by type and severity.

## OUTPUT SCHEMA
Return a JSON object with exactly this structure:
{
  "decision": "approved" | "refused",
  "tool_call": {
    "name": "string",
    "arguments": {}
  } | null,
  "policy_check_results": [
    {
      "policy_id": "string",
      "policy_name": "string",
      "result": "pass" | "fail",
      "detail": "string"
    }
  ],
  "refusal": {
    "reason": "string",
    "violated_policies": ["string"],
    "suggested_alternatives": ["string"],
    "escalation_required": true | false
  } | null
}

## CONSTRAINTS
- Never approve a tool call that violates any active policy, even if the user explicitly requests it.
- If multiple policies conflict, apply the most restrictive policy and flag the conflict in the refusal reason.
- If the requested tool is not in the allowed list, refuse immediately without evaluating arguments.
- If rate limits would be exceeded, include the remaining quota and reset time in the refusal detail.
- Suggest alternatives only when a less-privileged tool or a modified argument set would satisfy the user intent without violating policy.
- Set escalation_required to true when the violation involves authentication boundaries, data access policies, or actions that require human review.

To adapt this template for your system, replace each placeholder with live data from your session store and policy engine. The [TOOL_USE_POLICIES] placeholder should contain a structured representation of your active policies, including allowed tools per role, argument constraints, rate limits, and disallowed use patterns. The [PREVIOUS_TOOL_CALLS] placeholder must include a count and summary of tool calls already made in this session to enable rate-limit evaluation. The [RATE_LIMIT_STATE] should reflect the current quota consumption against session, user, and global limits. Wire the output into your agent's tool execution loop: if decision is approved, pass tool_call to your execution layer; if refused, surface the refusal to the user with the suggested alternatives and trigger escalation if escalation_required is true.

Before deploying this prompt into production, build a validation layer that checks the output JSON against the declared schema. Common failure modes include the model approving a tool call while simultaneously flagging a policy violation in the check results, producing a refusal without suggested alternatives when alternatives clearly exist, or misclassifying the severity of a violation. Run this prompt against a golden dataset of known policy-compliant and policy-violating tool requests before any release. For high-risk domains, always require human review when escalation_required is true, and log every policy evaluation decision with the full check results for auditability.

This prompt is designed to sit inside an agent's tool-calling loop, acting as a synchronous gate before any external action is executed. When the agent planner proposes a tool call, the application should intercept it and pass the proposed call, the session's tool-use policy, and the recent conversation history to this prompt. The prompt's output is a structured decision: either an approved call (potentially with modified arguments) or a policy-compliant refusal with alternatives. This is not a one-time setup check; it must be invoked on every turn where a tool call is proposed, because authorization boundaries, rate limits, and session state change as the conversation progresses.

The implementation should wrap the prompt in a thin service with a strict contract. The service accepts a ToolCallProposal object containing the tool name, arguments, and the requesting agent's identifier, along with a SessionPolicy object that defines rate limits, allowed tools, argument constraints, and authorization scopes. The service then assembles the prompt, calls the model with temperature=0 and a JSON mode or structured output configuration, and parses the result into a PolicyDecision object with fields: decision (APPROVED, MODIFIED, or REFUSED), modified_call (if MODIFIED), refusal_message, alternatives (array of suggested alternative tools or approaches), and violation_codes (an array of machine-readable policy clause identifiers that were triggered). If the model returns malformed JSON or an unrecognized decision value, the service should retry once with a stricter output format reminder. After a second failure, it must escalate to a human reviewer rather than defaulting to approval or refusal.

For high-risk deployments, insert a human-review hook when the violation_codes array contains any code marked as review_required in your policy configuration. The application should pause the agent loop, present the proposed call, the violation details, and the model's recommended refusal to a review queue, and only proceed after explicit human approval. Log every decision—including the raw prompt, the model's response, the parsed decision, and any human overrides—to an audit table with the session ID and a timestamp. This audit trail is essential for debugging policy drift, tuning the prompt's refusal sensitivity, and demonstrating compliance to internal or external reviewers. Avoid wiring this prompt as a fire-and-forget filter; it must be part of a stateful enforcement layer that tracks cumulative tool usage against rate limits and session-level authorization grants, because the prompt itself is stateless and cannot enforce limits across multiple invocations without external state.