Agent Action Allowlist Enforcement Prompt

This prompt functions as a deterministic policy enforcement gate for autonomous agents, designed to be embedded directly into an agent's pre-execution hook or a CI/CD pipeline stage. The primary job-to-be-done is to prevent an agent from executing an action that falls outside an explicitly defined set of allowed operations. The ideal user is a platform engineer or AI infrastructure lead who needs a structured, machine-readable ALLOW or DENY verdict before an API call, database query, or system command is dispatched. It assumes you already have two structured inputs available: a formal representation of the agent's intended action (including the target service, operation, and parameters) and the organization's allowlist policy, which defines the complete set of permitted operations.

Use this prompt when the cost of an unauthorized action is high and you need a programmatic gate that can be logged for audit purposes. For example, wire it into an agent runtime to block a DROP_TABLE command against a production database, prevent a DELETE API call on a restricted customer resource, or stop an agent from accessing a disallowed internal service. The prompt is designed to be part of a defense-in-depth strategy, not the sole security control. It is most effective when the allowlist policy is machine-generated from an infrastructure-as-code specification, ensuring the prompt's [POLICY] input stays synchronized with your actual deployment topology. The output is a strict JSON verdict containing an action, a decision, and a list of violations with policy references, making it trivial to integrate with alerting and logging systems.

Do not use this prompt as a replacement for proper Identity and Access Management (IAM) at the API or database layer. It is a pre-flight check, not a runtime security enforcement point. It is also not suitable for evaluating complex, context-dependent business logic where an action's validity depends on dynamic state rather than a static allowlist. For those scenarios, use a Custom Business Rule Validator Prompt or a multi-step agent planning check. If the agent's action is ambiguous or the allowlist is too large to fit in a single context window, you should decompose the check into multiple narrower validation calls or use a retrieval-augmented generation (RAG) approach to fetch only the relevant policy subset before invoking this prompt.

This prompt template is designed to be dropped into an agent control loop before a tool is dispatched. It takes a planned action and an allowlist policy as input, then returns a deterministic JSON verdict that your application code can use to block, log, or escalate the action. The template uses square-bracket placeholders for all variable inputs so you can wire it directly into your prompt assembly pipeline without manual editing.

textCopy
You are an action policy enforcement agent. Your only job is to check whether a planned agent action is permitted by the provided allowlist policy.

## POLICY
[ALLOWLIST_POLICY]

## PLANNED ACTION
Action Name: [ACTION_NAME]
Action Arguments: [ACTION_ARGUMENTS]
Target Resource: [TARGET_RESOURCE]

## INSTRUCTIONS
1. Compare the planned action against every rule in the policy.
2. If the action matches an explicit ALLOW rule, it is permitted.
3. If the action matches an explicit DENY rule, it is blocked.
4. If the action does not match any rule, apply the default policy stance specified in [DEFAULT_STANCE].
5. Return ONLY a valid JSON object with no additional text, markdown, or commentary.

## OUTPUT SCHEMA
{
  "verdict": "ALLOW" | "DENY",
  "blocking": true | false,
  "matched_rule_id": "string | null",
  "matched_rule_text": "string | null",
  "reason": "string",
  "policy_reference": "string"
}

## CONSTRAINTS
- Never allow an action that matches a DENY rule, even if it also matches an ALLOW rule. DENY takes precedence.
- If the action arguments contain placeholders or unresolved variables, treat the action as DENY with reason "unresolved arguments".
- If the policy is empty or unparseable, return DENY with reason "invalid policy".
- The `policy_reference` field must contain the exact policy section identifier, not a paraphrase.

Adapt this template by replacing the placeholders with your actual policy document, action metadata, and default stance. The [ALLOWLIST_POLICY] placeholder should receive your full policy text, not a summary. For high-risk agent environments, add a [RISK_LEVEL] placeholder that gates whether the verdict requires human co-approval before the action executes. Wire the JSON output into a post-processing validator that confirms the schema is respected before your agent dispatches the tool—never trust the raw model output to gate a destructive action without a structural schema check.

This prompt is designed to act as a synchronous gate within an agent execution loop, not as a standalone chat interaction. The ideal integration point is immediately before a tool dispatcher or action executor commits to a side effect. The application should capture the agent's planned action—including the tool name, arguments, and any justification the agent provides—and pass it to this prompt as the [ACTION] input. The [ALLOWLIST] should be injected from a secure configuration source, not from the agent's own context, to prevent an agent from modifying its own policy. The [POLICY_REFERENCE] is a human-readable identifier (e.g., ops-policy-v2.3) that ties the enforcement decision back to a specific, auditable governance document.

The output of this prompt must be parsed as structured JSON and used to control program flow. A decision of ALLOW should proceed to tool execution. A decision of DENY must block the action and trigger a structured error response back to the agent, including the violating_action and policy_reference fields so the agent can self-correct or escalate. Implement a strict JSON schema validator on the response before acting on it; if the model returns malformed JSON, retry once with a simplified error message. If the retry also fails, default to DENY and log the raw output for inspection. For high-risk environments, route all DENY decisions and any validator failures to a human approval queue before the agent receives the rejection, ensuring a human can override a false positive without the agent proceeding autonomously.

Log every enforcement decision—including the full action payload, the allowlist version, the model's decision, and the final system action—to an immutable audit log. This trace is critical for post-incident review and for proving to compliance teams that the allowlist was enforced correctly. When deploying changes to the [ALLOWLIST] or the prompt itself, run a regression suite of known allowed and disallowed actions through the full harness to confirm that the gate behaves as expected before releasing the change. Avoid the temptation to let the agent see the full allowlist; the policy should remain opaque to the agent to prevent social-engineering attacks against the enforcement prompt.