Boundary Violation Logging Prompt Template

This prompt is designed for governance, AI safety, and security operations teams who need a structured, machine-readable audit trail whenever an AI model steps outside its assigned role boundary. The primary job-to-be-done is post-detection logging: capturing a violation event after it has been identified by a separate detection system, not preventing the violation in real-time. The ideal user is an engineer or compliance analyst integrating this prompt into a Security Information and Event Management (SIEM) pipeline, a compliance dashboard, or an on-call alerting system. You need this prompt when you must answer the question, 'What boundary was violated, by which component, under which governing instruction, and what was the immediate resolution?' for every single boundary event in a production multi-agent or customer-facing system.

You should use this prompt when you have a pre-existing detection mechanism—such as a rule-based guardrail, an output classifier, or a Role Overreach Detection Prompt—that has already flagged a violation. The prompt's value is in transforming that detection signal into a consistent, queryable log entry. For example, if a customer-support agent attempts to access a billing database outside its Tool Access Scope Limitation Prompt policy, the detection system triggers this logging prompt to create a structured record with fields like violated_boundary, attempted_action, governing_instruction_layer, and resolution. This record can then be forwarded to a log aggregator. Do not use this prompt as an inline refusal or blocking mechanism; it is a forensic and audit tool, not an enforcement point. It assumes the violation has already occurred or been attempted and focuses on creating the evidence of that event.

To implement this effectively, you must wire the prompt's output into a downstream system. The generated JSON log entry should be validated against a strict schema before being written to an append-only log or sent to an alerting webhook. A critical next step is to ensure that the [RESOLUTION] field is populated by a deterministic system action (e.g., 'BLOCKED_BY_GUARDRAIL', 'ESCALATED_TO_HUMAN') rather than generated by the model, to maintain a reliable audit trail. Avoid using this prompt for real-time user-facing interactions; its purpose is to create a durable, structured record for internal review, compliance, and operational monitoring.

This prompt is designed to be placed in a dedicated logging step within your agent's orchestration layer, not in the main system prompt. It receives the details of a detected boundary violation as context and outputs a single, strictly-typed JSON object. The goal is to create a machine-readable audit trail that can be ingested by your SIEM, alerting platform, or compliance database without requiring a human to interpret a narrative summary.

textCopy
You are a boundary violation logging function. Your only job is to output a single JSON object that conforms to the provided schema. Do not include any text outside the JSON object.

## Context
[VIOLATION_DETAILS]

## Output Schema
You must output a JSON object with the following fields. Do not omit any fields. Use `null` for unknown or inapplicable values.

- `log_id`: A unique identifier for this log entry, prefixed with `bvlog-`.
- `timestamp`: The ISO 8601 timestamp of the violation event, provided in the context.
- `agent_id`: The identifier of the agent or role that committed the violation.
- `session_id`: The identifier of the conversation or workflow session.
- `violated_boundary`: The specific boundary that was crossed (e.g., `tool_access`, `data_access`, `capability_claim`, `out_of_scope_request`).
- `action_attempted`: A concise, factual description of the action the agent attempted to take.
- `governing_instruction_layer`: The instruction layer that defined the violated boundary (e.g., `system_prompt`, `tool_policy`, `data_access_policy`).
- `resolution`: The immediate action taken by the system (e.g., `blocked`, `escalated_to_human`, `refused_with_message`, `logged_only`).
- `severity`: A classification of the violation's potential impact: `low`, `medium`, `high`, or `critical`.
- `raw_event`: A copy of the exact agent output or tool call that triggered the violation.
- `notes`: Any additional context for auditors, or `null`.

## Constraints
- Output ONLY the JSON object. No markdown fences, no explanatory text.
- Do not hallucinate details. Use only the information provided in the [VIOLATION_DETAILS] context.
- Ensure all strings are properly escaped for JSON.

To adapt this template, replace [VIOLATION_DETAILS] with a structured summary of the event from your detection system. This summary should include the timestamp, agent ID, session ID, the boundary that was crossed, the raw output, and the resolution taken. For high-risk domains, ensure the severity field is mapped to an alerting rule in your downstream system. A common failure mode is the model adding conversational padding like 'Here is the log entry:' before the JSON; the constraint to output only the JSON object is critical. Always validate the output against the schema before writing it to your audit store.

The Boundary Violation Logging prompt is designed to be called as a secondary, non-blocking step after a primary agent or assistant has attempted an action that triggered a boundary check. It should not be placed in the critical path of user-facing responses. Instead, wire it into an asynchronous logging pipeline: when your boundary enforcement layer detects a violation (e.g., a tool call outside the role's scope, an attempt to access restricted data, or a refusal override), capture the raw event context and invoke this prompt in a fire-and-forget logging worker. The prompt expects structured input describing the violated boundary, the action attempted, the governing instruction layer, and the resolution applied. Its output is a structured log entry ready for ingestion into your audit system.

For implementation, wrap the prompt call in a thin service that validates the output against the expected log schema before writing to your audit store. The schema should include fields such as violation_id, timestamp, role_id, boundary_rule_id, attempted_action, instruction_layer, resolution, and severity. Use a JSON schema validator on the model's response and implement a single retry with a repair prompt if validation fails. If the retry also fails, fall back to a structured error log entry with the raw model output attached for manual review. This ensures you never lose a violation record due to a malformed generation. Choose a model with strong structured output support (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize schema adherence.

Downstream, route log entries by severity. High-severity violations (e.g., attempted PII access, tool calls outside declared scope) should trigger near-real-time alerts to the security or AI ops channel via webhook. Lower-severity events can be batched and written to your data warehouse for periodic governance review. Do not use this prompt to decide whether to block an action—that decision must happen in the enforcement layer before the action executes. The logging prompt's job is to produce an auditable record, not to serve as a runtime policy engine. Avoid wiring it into synchronous user-facing flows, as the added latency and non-determinism will degrade the user experience and create a coupling between audit logging and request success.