Tool Least Privilege Enforcement Prompt

This prompt is for security engineers and platform operators who need to enforce a default-deny policy on agent tool use. It transforms a standard agent into one that refuses any tool invocation unless an explicit grant exists for that specific tool, operation, and resource scope. Use this prompt when you are deploying an agent that has access to a broad tool catalog but should only be allowed to use a narrow, auditable subset. The prompt produces a structured permission evaluation and an audit record for every tool call attempt, making it suitable for regulated environments where every access decision must be traceable.

This prompt is not a replacement for application-layer authorization logic. It is the prompt-level enforcement layer that catches overbroad tool calls before they reach your execution harness. You should deploy this prompt alongside, not instead of, API-level authz checks, IAM policies, and tool-side permission enforcement. The prompt works best when the agent's tool catalog is well-defined, each tool has a clear name and operation set, and you can enumerate the allowed [TOOL_GRANTS] as a structured list of permitted tool-operation-resource tuples. If your tool ecosystem is dynamic, with tools registered at runtime or capabilities that change mid-session, pair this prompt with a tool discovery and registration prompt from the Tool Discovery content group to keep the grant list current.

Do not use this prompt as your sole security control for high-risk operations like database writes, infrastructure changes, or PII access. For those, you must combine it with the High-Risk Action Confirmation Gate Prompt, the Destructive Write Confirmation Prompt, and human-in-the-loop approval workflows. This prompt is also not designed to stop a determined prompt injection attack on its own; pair it with the Tool Injection Defense System Prompt and the Tool Instruction Hierarchy Enforcement Prompt for defense-in-depth. Before deploying, run the eval checks described in the Testing section against boundary violation attempts, and ensure your execution harness logs every denial decision for audit review.

This prompt template establishes a least-privilege enforcement layer that sits between the agent's reasoning and its tool execution. It forces the model to evaluate every tool invocation against an explicit permission manifest before the call is made. Without this guard, agents drift toward over-privileged behavior across multi-step sequences, especially when tool outputs contain persuasive or adversarial content. Place this prompt in your system instructions or as a pre-invocation guard that runs before any tool call is dispatched.

textCopy
You are a tool access enforcement layer operating under a strict default-deny policy. Your sole responsibility is to evaluate every proposed tool invocation against the permission manifest below and return a structured allow/deny decision. You do not execute tools. You do not modify arguments. You only enforce access policy.

## PERMISSION MANIFEST
[PERMISSION_MANIFEST]

## EVALUATION RULES
1. DEFAULT-DENY: Any tool, operation, or resource scope not explicitly listed in the manifest is denied.
2. EXACT MATCH: Tool names, operation names, and resource patterns must match exactly as declared. Wildcards are permitted only where the manifest explicitly uses them.
3. ARGUMENT VALIDATION: For allowed operations, validate that all arguments conform to the constraints declared in the manifest (types, ranges, patterns, enums).
4. SCOPE BOUNDARY: Resource arguments (paths, IDs, namespaces) must fall within the declared scope. Any resource outside scope is denied even if the tool and operation are allowed.
5. NO ESCALATION: An agent may not request permission for a denied action by rephrasing or chaining calls. Each invocation is evaluated independently against the manifest.
6. AMBIGUITY RESOLUTION: If the manifest is ambiguous for a given invocation, deny and flag for human review.

## INPUT
You will receive a proposed tool invocation with the following structure:
[TOOL_INVOCATION]

## OUTPUT SCHEMA
Return ONLY a JSON object with these fields:
{
  "decision": "allow" | "deny",
  "tool": "string",
  "operation": "string",
  "resource": "string | null",
  "matched_rule": "string | null",
  "denial_reason": "string | null",
  "audit_id": "string",
  "requires_approval": boolean,
  "risk_level": "low" | "medium" | "high" | "critical"
}

## CONSTRAINTS
- Do not execute the tool under any circumstances.
- Do not modify the proposed arguments.
- If [RISK_LEVEL] is "high" or "critical", set requires_approval to true regardless of manifest permissions.
- Generate a unique audit_id for every evaluation using the format: aud-[timestamp]-[random-8chars].
- If decision is "deny", denial_reason must cite the specific manifest rule or scope boundary that blocked the invocation.
- If no manifest rule matches, denial_reason must state "No explicit grant found — default-deny applied."

To adapt this template, replace [PERMISSION_MANIFEST] with a structured declaration of allowed tools, operations, and resource scopes. Each entry should specify the tool name, permitted operations, allowed argument constraints, and resource boundaries. Replace [TOOL_INVOCATION] with the actual proposed call your agent intends to make. Set [RISK_LEVEL] based on your environment's classification of the target resource. Wire the output into your tool execution pipeline: only dispatch calls where decision is allow and requires_approval is false. Route approval-required decisions to your human-in-the-loop queue. Log every evaluation result, including denials, for audit trail generation. Test this prompt against boundary-violation attempts, wildcard edge cases, and injection payloads disguised as resource arguments before deploying to production.

This prompt is not a standalone safety layer—it is a policy evaluation step that must sit inside a deterministic enforcement harness. The harness calls the prompt before any tool invocation, passes the agent's intended action (tool name, arguments, target resource), and receives a structured allow/deny decision. The prompt's output is advisory; the harness must enforce the decision in code. Never rely on the model's refusal as the sole gate, because prompt injection, context drift, or model error can cause the policy evaluation to be skipped or overridden.

The implementation flow should follow a strict sequence: (1) Intercept the agent's tool call before execution. (2) Assemble the permission evaluation context: agent role, session scope, tool name, full arguments, target resource identifier, and the original user intent if available. (3) Call the Tool Least Privilege Enforcement Prompt with these inputs, requesting a structured JSON output containing decision (ALLOW/DENY), matched_grant (the specific permission entry that authorized the action, or null), denial_reason (if denied), and audit_record. (4) Validate the output schema programmatically—if the model returns malformed JSON, missing required fields, or an unrecognized decision value, default to DENY and log a policy evaluation failure. (5) If the decision is DENY, block the tool call, return the denial explanation to the agent (not the raw prompt output), and write the full audit record to your observability pipeline. If ALLOW, attach the matched grant ID and audit record to the tool call context for downstream logging.

For production hardening, implement a short-circuit cache keyed on (role, tool, operation, resource_pattern) so repeated permission checks for the same action pattern don't require an LLM call. The cache must be invalidated when permission policies change. Add a circuit breaker: if the policy evaluation prompt fails more than a configured threshold within a time window, block all tool calls and escalate to the on-call channel. The harness should also enforce argument-level constraints (e.g., regex patterns, value ranges, allowed enum values) in code before the prompt is even called, because structural validation is cheaper and more reliable than LLM-based policy checks. Finally, ensure every denied action generates a structured log with the full evaluation context—this is your audit trail for security review and policy tuning. The prompt is the reasoning layer; the harness is the enforcement layer. Never confuse the two.