Access Audit Record Prompt for IAM Systems

This prompt is for IAM engineers and security platform teams who need to convert raw access events, policy evaluation outputs, or authorization requests into structured, machine-readable audit records. Use it when you must produce JSON log entries with consistent fields for principal, action, resource, decision, and policy binding, and when downstream systems such as SIEMs, compliance databases, or access review dashboards require controlled vocabularies for decision outcomes. The primary job-to-be-done is structuring an existing authorization event for observability, not making the authorization decision itself.

This prompt assumes you already have the raw event data or policy context. It does not replace a policy decision engine like Open Policy Agent (OPA) or AWS IAM, nor does it evaluate whether an access decision was correct. It structures the record for audit and observability pipelines. Do not use this prompt to adjudicate access in real time or to bypass a policy engine; its output is a historical record, not an enforcement point. The prompt enforces controlled vocabularies for fields like decision (e.g., Allow, Deny, Error) and policy_binding to ensure downstream systems can query and alert on these records without normalization scripts.

Before using this prompt, ensure you have the principal identifier, the action attempted, the target resource ARN or URI, the raw decision from your policy engine, and the policy or rule that produced the decision. If any of these inputs are missing, the prompt may produce an incomplete record that fails validation in your SIEM or compliance pipeline. After generation, validate the output against your audit schema, confirm that the decision field matches one of your approved enum values, and verify that the timestamp is in RFC 3339 format. For high-compliance environments, route a sample of generated records through human review before ingestion.

This prompt template generates a structured access audit record suitable for ingestion into IAM monitoring systems, SIEM platforms, or compliance databases. It enforces a strict JSON schema with controlled vocabularies for access decisions, policy references, and principal identifiers. Replace every square-bracket placeholder with real values from your identity provider, policy engine, or application context before sending. The template is designed to produce outputs that survive automated schema validation without post-processing.

textCopy
You are an IAM audit record generator. Your task is to produce a single, valid JSON object representing an access decision event. Follow the output schema exactly. Use only the controlled vocabularies specified. Do not include commentary, markdown fences, or extra text.

## Input
- Principal: [PRINCIPAL_ID]
- Action: [ACTION]
- Resource: [RESOURCE_ARN]
- Policy: [POLICY_NAME]
- Policy Binding: [POLICY_BINDING_TYPE]
- Request Context: [REQUEST_CONTEXT]

## Output Schema
{
  "audit_record": {
    "event_id": "string (UUID v4)",
    "timestamp": "string (ISO 8601 UTC)",
    "principal": {
      "id": "string",
      "type": "enum: USER | SERVICE_ACCOUNT | ROLE | FEDERATED"
    },
    "action": "string",
    "resource": {
      "arn": "string",
      "type": "string"
    },
    "decision": "enum: ALLOW | DENY | EXPLICIT_DENY | NOT_APPLICABLE",
    "policy": {
      "name": "string",
      "binding": "enum: DIRECT | GROUP | ROLE | INHERITED | CONDITIONAL"
    },
    "context": {
      "source_ip": "string (IPv4 or IPv6)",
      "user_agent": "string",
      "mfa_present": "boolean"
    },
    "metadata": {
      "region": "string",
      "session_id": "string"
    }
  }
}

## Constraints
- Generate a new UUID for event_id on every invocation.
- Use the current UTC timestamp in ISO 8601 format.
- decision must be one of the four enumerated values.
- policy.binding must be one of the five enumerated values.
- principal.type must be one of the four enumerated values.
- If the decision is DENY or EXPLICIT_DENY, include a "reason" field inside the "policy" object with a brief explanation.
- Never invent principal IDs, resource ARNs, or policy names. Use only the provided input values.

Adapt this template by replacing the input placeholders with values from your IAM system. For AWS environments, [RESOURCE_ARN] should be a valid Amazon Resource Name. For GCP, replace it with the full resource name format. The policy binding type should reflect how the policy is attached: DIRECT for user-attached policies, GROUP for group membership, ROLE for assumed roles, INHERITED for organizational inheritance, and CONDITIONAL when attribute-based access control conditions are in play. If your IAM system uses different decision terminology, update the enum values in the schema to match your internal taxonomy before deployment.

This prompt is designed to be called as a deterministic function within an IAM decision pipeline, not as an open-ended chat interaction. The application layer should supply all required inputs—principal, action, resource, decision, and policy binding—from upstream policy evaluation engines such as OPA, Cedar, or custom RBAC resolvers. The model's job is to format these inputs into a structured, machine-readable audit record that conforms to a strict schema, not to make or override access decisions. Treat the prompt as a post-decision serialization step: the authorization decision has already been made by the policy engine; the LLM is only responsible for producing a compliant, enriched audit entry.

Wire the prompt into an application harness that enforces a validate-then-log pattern. After the model returns the structured record, run automated schema validation against the expected JSON Schema before writing to the audit log. Check for required fields (principal, action, resource, decision, policy_binding), controlled vocabulary adherence (decision must be one of Allow, Deny, NotApplicable), and timestamp format compliance (ISO 8601). If validation fails, retry once with the validation error message injected into the prompt as additional context. If the retry also fails, fall back to a template-based record using the raw inputs and flag the entry with "generation_status": "fallback" for human review. Log every generation attempt—including validation errors and retry counts—to a separate observability stream for prompt performance monitoring.

For high-risk environments, insert a human review gate for records where the decision is Deny and the resource is tagged as a sensitive system (e.g., production databases, financial ledgers, PII stores). Route these records to a review queue before they are committed to the immutable audit log. Use a model with strong schema-following behavior (such as GPT-4o with response_format set to json_schema or Claude 3.5 Sonnet with strict tool-use mode) to minimize format drift. Avoid using smaller or older models that are prone to enum leakage or field omission. If your IAM system generates high throughput, consider batching multiple decisions into a single prompt call with an array output to reduce latency and cost, but ensure each record is independently validated.