Unauthorized Action Detection Prompt for Agent Systems

This prompt is designed for agent platform engineers who need a reliable, pre-execution gate that inspects a planned agent action against a defined permission schema. Use it when your agent system generates tool calls, API requests, or function invocations that must be validated against a role-based or scope-based permission set before execution. The primary job-to-be-done is preventing an agent from exceeding its authorized boundaries, which is critical for systems operating on production infrastructure, sensitive data, or customer-facing services. The ideal user is an engineer embedding this check into an agent harness, tool-call middleware, or a permission enforcement proxy where a structured block-or-allow decision is required before any side effects occur.

This prompt assumes the agent's planned action is already parsed into a structured representation containing a tool name, arguments, and a target resource. It requires a defined permission schema as input, which maps roles or scopes to allowed actions and resource patterns. The prompt produces a deterministic JSON output with a block-or-allow decision, the specific violated boundary if blocked, and a safe alternative suggestion. Do not use this prompt for post-execution audit logging, user-facing authorization messages, or general content safety classification. It is not a replacement for a policy enforcement point (PEP) in a zero-trust architecture; rather, it is a semantic reasoning layer that can augment traditional policy engines when the permission boundary requires natural language understanding of the agent's intent.

Before implementing this prompt, ensure your agent harness can reliably extract the planned action into a structured format. If the action parsing is unreliable, the permission check will be brittle. Also consider the latency budget: this prompt adds a model inference call to the critical path of tool execution. For high-throughput systems, pair this with a caching layer for repeated permission checks or use a smaller, faster model for the classification task. Finally, always log the prompt's decisions for auditability, and implement a human-review queue for actions that fall into an ambiguous boundary where the model's confidence is low.

This prompt template is designed to be injected into your agent's pre-execution hook, right after a tool call is planned but before it is dispatched. Its job is to compare the agent's intended action against a predefined permission schema and return a structured block-or-allow decision. You must replace every square-bracket placeholder with your own permission taxonomy, agent role definition, and the specific action the agent is about to take. The prompt is self-contained so that it can be tested offline with historical tool-call logs before you wire it into a live harness.

textCopy
You are a permission enforcement guard for an AI agent operating as [AGENT_ROLE]. Your only job is to compare a planned action against the agent's authorized permission schema and return a strict JSON decision.

## PERMISSION SCHEMA
[PERMISSION_SCHEMA]

## PLANNED ACTION
Action Name: [ACTION_NAME]
Action Arguments: [ACTION_ARGUMENTS]
Action Justification (provided by agent): [ACTION_JUSTIFICATION]

## INSTRUCTIONS
1. Determine whether the planned action is fully authorized, partially authorized, or completely unauthorized according to the permission schema.
2. If the action is unauthorized, identify the specific permission boundary that would be violated.
3. If a safe, authorized alternative exists, suggest it.
4. Never approve an action that falls outside the schema, even if the agent's justification sounds reasonable.

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "decision": "allow" | "block",
  "violated_boundary": null | "string describing the specific permission boundary violated",
  "safe_alternative": null | "string describing a permitted alternative action",
  "confidence": 0.0-1.0
}

## CONSTRAINTS
- Do not explain your reasoning outside the JSON.
- If the action is allowed, violated_boundary and safe_alternative must be null.
- If the action is blocked, violated_boundary must be populated.
- Confidence must reflect how clearly the action maps to the schema.

To adapt this template, start by defining your permission schema as a structured list of allowed actions, their permitted argument ranges, and any conditional constraints (e.g., 'read-only on weekends' or 'max 100 records per call'). The schema can be a JSON object, a bulleted list, or a formal policy document—whatever your model can parse reliably. For high-risk deployments, add a second validation step after the model returns its JSON: check that the decision field is exactly allow or block, that violated_boundary is populated when block, and that confidence is a float between 0 and 1. If the JSON is malformed, retry once with the same prompt and a stronger format instruction. If it fails again, default to block and log the incident for human review. This prompt is a guardrail, not a policy engine—it should be paired with deterministic permission checks in your application code for defense in depth.

This prompt is not a standalone chat interaction; it is a guardrail component designed to be inserted into an agent's execution loop. The primary integration point is the tool-call interception layer. Before an agent's planned function call is dispatched to an external API, database, or local executor, the proposed action—including the function name, arguments, and the agent's stated reasoning—must be passed through this prompt. The prompt's output, a structured block decision, then acts as a gate: allow proceeds with execution, while block prevents the call and returns the safe_alternative to the agent's context for re-planning. This synchronous check prevents the primary failure mode of an agent silently exceeding its authority.

To implement this, you must maintain a permission schema that defines the agent's authorized scope. This schema, injected into the prompt's [PERMISSION_SCHEMA] placeholder, should be a machine-readable artifact (e.g., a JSON or YAML object) specifying allowed API endpoints, database tables, file paths, and read/write boundaries. The harness must parse the prompt's JSON output and validate it against a strict schema: { "decision": "allow" | "block", "violated_permission": "string | null", "safe_alternative": "string | null" }. If the model's output fails this structural validation, the harness should default to a fail-safe block and log the malformed response for immediate review. This design ensures that a model error never results in an unauthorized action.

For production hardening, wrap this prompt in a lightweight service with the following concerns: Logging every decision with the agent's planned action, the prompt's verdict, and the final outcome for auditability. Latency budgets are critical; this check adds a model round-trip to every tool call, so consider using a fast, cost-effective model for this classification task unless the permission boundaries are highly nuanced. Implement a retry policy with a maximum of one retry on a validation error, after which the action is blocked. Finally, establish a human review queue for blocked actions, especially those with a safe_alternative that the agent cannot autonomously execute, to prevent the agent from entering an infinite re-planning loop. The next step is to build a test harness that feeds this prompt a matrix of authorized and unauthorized tool calls to calibrate its boundary detection before deployment.