Agent Action Boundary Violation Prompt

This prompt belongs in the pre-execution layer of an autonomous agent system. It evaluates a proposed action against a defined boundary policy and returns a structured violation assessment before the action reaches the execution engine. Use it when your agent has access to tools, APIs, or data stores where some operations are permitted and others are not, and where a single boundary violation could cause data loss, privilege escalation, or safety incidents. The prompt acts as a semantic safety net that catches actions the planner should not have proposed, including actions that are technically possible but out of policy scope.

Run this check after the planner produces a candidate action and before the executor invokes any tool or API call. The prompt requires a clearly defined boundary policy as input, typically expressed as a set of allowed and disallowed operations, resource scopes, and conditional constraints. It is not a replacement for application-level authorization or identity-based access control. Instead, it provides a defense-in-depth layer that validates the semantic intent of an action against organizational policy, catching misaligned plans that might slip through technical permission checks. For example, an agent with database write access might propose a schema migration that is technically permitted but violates a change management policy—this prompt would flag that violation before execution.

Do not use this prompt for real-time authorization decisions where latency is critical, or as the sole gatekeeper for actions with severe safety implications. It should be paired with deterministic policy enforcement, human approval workflows for high-risk actions, and comprehensive logging for auditability. Before deploying, test the prompt against a golden set of boundary-violating and boundary-compliant actions to calibrate its precision and recall. When a violation is detected, the output should be routed to a structured escalation path, not silently logged.

The prompt below is designed to be pasted into your agent's safety layer, typically as a guardrail that executes before any tool call or state mutation is committed. It expects a structured description of the proposed action, the agent's current context, and your boundary specification. The output is a machine-readable decision that your application can use to block, escalate, or allow the action. Replace every square-bracket placeholder with your own values before use.

textCopy
You are an agent safety boundary evaluator. Your job is to determine whether a proposed agent action violates any defined boundary and to return a structured decision.

## BOUNDARY SPECIFICATION
[BOUNDARY_SPECIFICATION]

## AGENT CONTEXT
[AGENT_CONTEXT]

## PROPOSED ACTION
[PROPOSED_ACTION]

## INSTRUCTIONS
1. Compare the proposed action against every rule in the boundary specification.
2. If the action violates any boundary, classify the violation severity as BLOCK, ESCALATE, or WARN.
3. If the action is within all boundaries, classify the decision as ALLOW.
4. For violations, cite the specific boundary rule that was violated.
5. For ESCALATE decisions, include the reason human judgment is required.
6. Do not execute the action. Only evaluate it.

## OUTPUT SCHEMA
Return a single JSON object with these fields:
- decision: "ALLOW" | "BLOCK" | "ESCALATE" | "WARN"
- violated_rules: [list of rule identifiers from the boundary specification that were violated, empty if ALLOW]
- reasoning: string explaining the decision, citing specific boundary rules
- escalation_reason: string (required if decision is ESCALATE, otherwise null)
- risk_level: "low" | "medium" | "high" | "critical"

## CONSTRAINTS
- Do not invent boundaries. Only use rules from the provided boundary specification.
- If the proposed action is ambiguous relative to a boundary, escalate.
- If the agent context is insufficient to evaluate a boundary, escalate and explain what context is missing.
- Never return ALLOW if any boundary rule is violated, even partially.

To adapt this prompt, start by defining your boundary specification as a set of explicit, referenceable rules. Each rule should have a unique identifier and a clear condition. For example, a rule might state: RULE-01: Agent must not delete production data without human approval. or RULE-03: Agent must not send external emails outside the allowed-recipients list. The agent context should include the current task, user identity, permissions scope, and any relevant session state. The proposed action should be a structured description of what the agent intends to do, including the target resource, the operation, and any parameters. In production, you should validate the output JSON against the schema before acting on the decision. For high-risk domains, log every evaluation result and require a second reviewer for any ESCALATE or BLOCK decision before the action is permanently blocked or routed to a human queue.

When wiring this into an application, treat the prompt output as a control signal, not as a final action. If the decision is BLOCK, your application should prevent the action and optionally notify the user with the reasoning. If the decision is ESCALATE, place the action into a human review queue with the full evaluation payload. If the decision is WARN, allow the action but log the warning for audit. Only ALLOW should proceed without interruption. Test this prompt against a golden set of known boundary violations and known safe actions to measure boundary precision and false positive rate before deployment. Common failure modes include ambiguous boundary rules that cause excessive escalation, missing context that forces unnecessary human review, and boundary specifications that drift out of sync with actual system capabilities.

The Agent Action Boundary Violation Prompt is not a standalone safety filter; it is a gating function that must sit directly in the agent's action-execution path. Before any tool call, API write, or state mutation is committed, the agent's proposed action and its context are passed through this prompt. The output is a structured verdict: allow, block, or escalate. This verdict must be enforced by the application harness, not by trusting the model to self-police. The harness should treat a block verdict as a hard stop and an escalate verdict as a pause that places the action into a human review queue with the full boundary-violation payload.

To implement this reliably, wrap the prompt call in a validation layer that checks the output schema before acting on the verdict. The expected output is a JSON object with at minimum verdict, violated_boundaries, and reasoning fields. If the model returns malformed JSON, a missing verdict, or an unrecognized boundary reference, the harness should default to block and log the raw output for diagnosis. A retry with a stricter schema reminder can be attempted once, but if the second attempt also fails validation, the action must be escalated to a human operator with the original proposed action, the failed validation output, and a VALIDATION_FAILURE error code. This prevents schema drift from silently allowing boundary violations.

For high-throughput agent systems, consider batching boundary checks where actions are independent and low-risk, but never batch checks for actions that modify shared state, external systems, or user data. Each boundary check should be logged with a unique check_id, the agent_id, the action_signature (a hash of the proposed tool name and arguments), the verdict, and the timestamp. This audit trail is essential for post-incident review and for tuning boundary definitions over time. When an escalate verdict is returned, the harness should package the full boundary-violation payload into a review item and push it to a human review queue with a TTL (time-to-live) that reflects the action's urgency. If the TTL expires without human response, the harness must default to block, never to allow.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, and set the temperature to 0 to minimize variance in boundary interpretation. Avoid using smaller or open-weight models for this gating function unless they have been specifically evaluated on your boundary definitions and action coverage. The prompt should be versioned alongside your boundary policy document, and any change to the boundary definitions must trigger a regression run against a golden set of known violation and non-violation action examples before the updated prompt is deployed to production.