Tool Access Scope Limitation Prompt Template

This prompt is for security-conscious platform and AI engineering teams building tool-augmented agents. Its job is to produce a machine-readable tool access policy that maps each available tool to specific roles, rate limits, and argument constraints. Use it when you need to enforce least-privilege access at the agent level, prevent one agent role from calling tools assigned to another, or generate a policy artifact that your agent harness can validate before every tool call. This prompt belongs in the design phase of multi-agent systems, before you wire tools into a production agent loop. It is not a runtime guard itself; it generates the policy that your runtime guard enforces.

The ideal user is an AI architect or platform engineer who already has a defined set of agent roles and a catalog of available tools. You should have a clear understanding of which roles need access to which tools, what argument constraints apply, and what rate limits are acceptable. The prompt requires you to provide a list of roles, a list of tools with their schemas, and any organizational policies governing tool use. Without this context, the generated policy will be generic and require significant manual revision before it can be enforced in a production harness.

Do not use this prompt when you need a runtime enforcement mechanism—this prompt generates a static policy artifact, not an active guard. Do not use it when your tool catalog is unstable or undefined, as the output will be incomplete and misleading. Do not use it as a substitute for infrastructure-level controls like IAM roles, network policies, or API gateway rules; the policy it produces should complement those controls, not replace them. If you need a prompt that actively intercepts and blocks out-of-scope tool calls at runtime, use the Tool Output Contamination Guard Prompt or the Action Authorization Check Prompt instead. After generating the policy, you must validate it against your actual tool schemas, test it with both authorized and unauthorized role-tool pairings, and integrate it into your agent harness with logging for every policy decision.

The following prompt template defines a tool access policy for a security-conscious agent. It maps each available tool to specific roles, rate limits, and argument constraints, and instructs the model to refuse any tool call that falls outside the declared scope. Use this template when you need a single, auditable source of truth for tool permissions that the model can reference before every action.

codeCopy
You are an agent with access to external tools. Before calling any tool, you must verify that the call is permitted by the Tool Access Policy below. If a tool call violates this policy, respond with a refusal that cites the specific policy rule broken.

## TOOL ACCESS POLICY

For each tool, the policy defines:
- **Allowed Roles**: Which roles may invoke this tool.
- **Rate Limit**: Maximum calls per [TIME_WINDOW].
- **Argument Constraints**: Required, forbidden, or restricted parameter values.
- **Data Scope**: What data the tool may access or return.

[TOOL_POLICY_TABLE]

## CURRENT CONTEXT
- **Active Role**: [ACTIVE_ROLE]
- **Session Tool Call Count**: [CALL_COUNT]
- **User Request**: [USER_REQUEST]

## INSTRUCTIONS
1. Parse the user request and identify the required tool and arguments.
2. Check the Active Role against the tool's Allowed Roles. If not listed, refuse and state: "Role [ACTIVE_ROLE] is not authorized to use [TOOL_NAME]."
3. Check the Session Tool Call Count against the tool's Rate Limit. If exceeded, refuse and state: "Rate limit of [LIMIT] calls per [TIME_WINDOW] exceeded for [TOOL_NAME]."
4. Validate all arguments against the tool's Argument Constraints. If any argument violates a constraint, refuse and state the specific violation.
5. If all checks pass, proceed with the tool call.

## OUTPUT FORMAT
If the call is permitted, output the tool call in the standard function-calling format. If refused, output a JSON refusal object:
{
  "status": "refused",
  "tool": "[TOOL_NAME]",
  "reason": "[POLICY_RULE_BROKEN]",
  "detail": "[SPECIFIC_VIOLATION]"
}

To adapt this template, replace [TOOL_POLICY_TABLE] with a structured description of each tool and its constraints. The table can be a markdown table, a JSON block, or a YAML snippet—whatever your model parses most reliably. [ACTIVE_ROLE] and [CALL_COUNT] should be injected by your application harness at runtime. [USER_REQUEST] is the current user input. For high-risk deployments, add a final instruction that requires human approval before any tool call that modifies external state, and log every refusal to your audit system for later review.

The Tool Access Scope Limitation prompt template is designed to be evaluated before the model's tool-calling step, not as a one-time system instruction that can drift over long sessions. In practice, you inject the populated policy block into the system prompt or a dedicated tool-selection preamble every time the model is about to choose a tool. This ensures that role-to-tool mappings, rate limits, and argument constraints are fresh in the attention window when the model decides which function to call and with what parameters.

The implementation harness should wrap the model's tool-call output in a pre-execution validation layer. After the model emits a tool call, extract the tool_name and arguments, then check them against the policy map produced by the prompt. Reject any call where the tool is not in the role's allowlist, the arguments violate declared constraints (e.g., max_records, forbidden fields, disallowed date ranges), or the rate limit for that [ROLE]–[TOOL] pair has been exceeded in the current session window. Log every rejection with the role, attempted tool, violating argument, timestamp, and session ID. For high-risk actions—such as DELETE, UPDATE, or any tool tagged with [RISK_LEVEL] = "high"—route the call to a human approval queue instead of executing it automatically. The approval payload should include the original user request, the model's proposed tool call, and the policy rule that requires review.

Model choice matters here. Smaller or older models may ignore complex policy constraints embedded in the system prompt, especially when the tool schema itself is large. If you observe policy violations in production, escalate to a model with stronger instruction-following behavior, or move the policy check entirely into the harness code rather than relying on the model to self-enforce. The prompt template is a declaration of intent; the harness is the enforcement mechanism. Never trust the model's tool-call output without a code-level gate that can block, log, and escalate out-of-scope attempts before execution.