Authorization Decision Log Prompt for Policy Engines

Platform engineers integrating with policy engines like Open Policy Agent (OPA) need structured decision logs that capture every authorization evaluation. This prompt produces machine-parseable JSON records with input attributes, policy path, decision outcome, and evaluation duration. Use it when your authorization pipeline requires auditable, queryable decision logs that downstream systems can ingest without transformation.

The prompt is designed for post-decision logging, not real-time enforcement. It assumes a policy decision has already been rendered by the engine. You supply the raw evaluation context—the input attributes, the policy path evaluated, the boolean or multi-valued decision, and the evaluation latency—and the prompt normalizes these into a consistent JSON schema. This is critical for teams shipping audit evidence to SIEMs, compliance databases, or internal observability platforms where field-level consistency across thousands of decisions determines queryability.

Do not use this prompt as a substitute for the policy engine itself. It does not evaluate policies, resolve conflicts, or make access decisions. It also should not be used for real-time request interception where latency added by an LLM call is unacceptable. For high-throughput enforcement paths, log asynchronously or batch records. For regulated environments, ensure the log record includes a trace ID linking back to the engine's own decision event to maintain a verifiable chain of custody.

This prompt template is designed to be pasted directly into your system instructions or user message. It instructs the model to produce a single, valid JSON object representing an authorization decision log entry. The template uses square-bracket placeholders for all dynamic inputs, such as the request attributes, the policy being evaluated, and the expected output schema. Before using this prompt, you must replace every placeholder with concrete values from your application context. The prompt is structured to enforce a strict output contract: a decision enum, a valid policy path, and a numeric evaluation duration, making the output safe for direct ingestion by a policy decision log aggregator or SIEM.

textCopy
You are an authorization logging agent for a policy engine. Your only job is to output a single JSON object that conforms to the schema described below. Do not include any explanatory text, markdown fences, or additional keys.

Evaluate the following authorization request against the provided policy context and produce a structured decision log.

## INPUT
- Request Attributes: [REQUEST_ATTRIBUTES]
- Policy Context: [POLICY_CONTEXT]

## OUTPUT_SCHEMA
{
  "decision_id": "string, a unique UUID for this decision event",
  "timestamp": "string, ISO 8601 timestamp of the evaluation in UTC",
  "input": {
    "subject": "string, the principal making the request from [REQUEST_ATTRIBUTES]",
    "action": "string, the requested operation from [REQUEST_ATTRIBUTES]",
    "resource": "string, the target resource from [REQUEST_ATTRIBUTES]"
  },
  "policy": {
    "path": "string, the fully qualified policy path from [POLICY_CONTEXT], e.g., 'app.rbac.allow'",
    "version": "string, the policy version from [POLICY_CONTEXT]"
  },
  "decision": "string, must be one of: 'allow', 'deny', 'error'",
  "evaluation_duration_ms": "number, the evaluation time in milliseconds from [POLICY_CONTEXT]",
  "context": {
    "reason": "string, a concise, factual explanation for the decision based on the policy and input",
    "matched_rules": ["string, the specific rule names that matched from [POLICY_CONTEXT]"]
  }
}

## CONSTRAINTS
1. The `decision` field MUST be exactly one of the allowed enum values: 'allow', 'deny', 'error'.
2. The `policy.path` MUST start with the package name from [POLICY_CONTEXT] and use dot notation.
3. All fields in the output schema are required. Do not omit any field.
4. If the policy evaluation results in an error, set `decision` to 'error' and explain the error in `context.reason`.

To adapt this template, start by replacing [REQUEST_ATTRIBUTES] with a structured representation of the incoming request—typically a JSON object containing subject, action, and resource. Replace [POLICY_CONTEXT] with the relevant details from your policy engine's evaluation trace, including the policy path, version, matched rules, and evaluation duration. For high-risk environments, such as financial or healthcare systems, you should add a post-processing validation step in your application code that checks the decision enum and policy.path format before the log is written to an immutable store. If the model fails to produce a valid output, implement a retry with a simplified version of the prompt or escalate to a human operator for manual log entry.

This prompt is designed to sit between a policy engine's decision endpoint and your audit storage. The model receives raw evaluation context and produces a structured decision log that downstream systems can ingest without manual transformation. The harness must enforce that the model output matches the expected schema before any record is written to the audit log, because a malformed decision entry can break compliance reporting or mask an incorrect authorization outcome.

Wire the prompt into an application pipeline that performs three stages: pre-validation, generation, and post-validation. In pre-validation, confirm that required inputs—[POLICY_PATH], [INPUT_ATTRIBUTES], and [DECISION_OUTCOME]—are present and that [POLICY_PATH] matches a known policy namespace pattern (e.g., ^[a-z]+\.[a-z]+\.[a-z_]+$). After generation, validate the output JSON against a strict schema: decision must be one of allow, deny, or error; evaluation_duration_ms must be a non-negative number; timestamp must be ISO 8601. If validation fails, retry once with the validation error injected into the prompt as a correction hint. If the retry also fails, log the raw output and the validation error to a dead-letter queue for human review—never silently drop a failed authorization record. For high-risk environments, require a human to acknowledge any deny decision log before it is committed to the audit trail.

Choose a model that reliably follows JSON schema constraints. GPT-4o and Claude 3.5 Sonnet perform well on this structured output task, but always run schema validation regardless of model choice. Store the validated decision log in an append-only audit store with the model version, prompt version, and trace ID attached as metadata. Avoid using this prompt for real-time enforcement—the model's output documents a decision that has already been made by the policy engine; it does not make the authorization decision itself.