AI Audit Event Catalog
Audience: DevOps / Security engineers, compliance officers
Time: ~10 min
Control Core captures a structured audit record for every AI transaction that passes through the Bouncer. These events are stored in the Control Plane audit log and forwarded to any configured SIEM or webhook destination.
Privacy guarantee: Prompt and completion text are never stored in plaintext. The audit record contains only SHA-256 hashes of the prompt and completion content. Sensitive content remains on your infrastructure; the audit record is safe to forward to any external system.
AI event types
There are four event types that appear in your audit log and SIEM feed when the Bouncer intercepts an AI transaction.
| Event type | When it appears |
|---|---|
AI_TRAFFIC_LOG | Every AI transaction — the primary per-request record |
AI_POLICY_VIOLATION | When a control blocks an AI transaction |
AI_PII_REDACTION | When a control rewrites (masks) part of the AI response |
AI_TOKEN_USAGE | Retained alias — same data as AI_TRAFFIC_LOG; present for backwards compatibility with existing SIEM filters |
AI_TRAFFIC_LOG
Emitted once per completed AI transaction. This is the canonical event for usage tracking, cost attribution, and compliance evidence.
Key fields:
| Field | Description |
|---|---|
ai_model | AI model identifier |
ai_provider | Provider (e.g. openai, azure_openai, anthropic, bedrock) |
ai_token_input | Prompt / input token count |
ai_token_output | Completion / output token count |
ai_cost_estimate | Estimated transaction cost in USD |
latency_ms | End-to-end latency in milliseconds |
prompt_hash | SHA-256 hash of the prompt — not the prompt text |
response_hash | SHA-256 hash of the completion — not the completion text |
redaction_applied | true if the response was rewritten by a masking control |
user_subject | Identifier of the requesting user or agent |
correlation_id | Cross-system correlation identifier |
target_type / target_id | Logical resource the AI transaction targeted |
AI_POLICY_VIOLATION
Emitted when a control blocks an AI transaction. Contains the control that triggered the block, the action taken, and a human-readable reason code.
| Field | Description |
|---|---|
guardrail_trigger_id | Identifier of the control that blocked the request |
guardrail_action | Action taken (e.g. block, deny) |
action_taken | Enforcement outcome recorded in the audit row |
request_id | Cross-system correlation with the originating request |
policy_path | Policy query path evaluated |
decision_source | Origin of the decision (bouncer, ext_proc) |
Troubleshooting: If
AI_POLICY_VIOLATIONevents appear unexpectedly, check Observe & Audit → Audit Logs in the Control Plane and filter by event typeAI_POLICY_VIOLATION. Common causes: a control's conditions are broader than intended; theguardrail_trigger_idfield identifies which control to inspect. Full reference: Troubleshooting controls.
AI_PII_REDACTION
Emitted when a control's masking obligation rewrites part of the AI response before it is returned to the caller. The original content is never stored.
| Field | Description |
|---|---|
redaction_applied | Always true for this event type |
guardrail_trigger_id | Control that triggered the redaction |
guardrail_action | Masking action (e.g. redact, mask) |
response_hash | SHA-256 of the rewritten response |
AI_TOKEN_USAGE (compatibility alias)
This event type was the original token-tracking record and is retained so that existing SIEM filter rules continue to work without modification. It carries the same data as AI_TRAFFIC_LOG. For new SIEM rules and dashboards, use AI_TRAFFIC_LOG — it is the superset going forward.
Full field dictionary
The table below covers all fields defined in the audit event contract (AUDIT_EVENT_V2_FIELDS). Fields marked AI are specific to AI transactions; all others appear across event categories.
| Field | Description |
|---|---|
request_id | Cross-system request correlation identifier |
trace_id | Distributed tracing trace ID (W3C / OpenTelemetry) |
span_id | Distributed tracing span ID for the current evaluation step |
latency_ms | Decision latency in milliseconds |
decision_id | Decision engine identifier (OPA decision_id or equivalent) |
policy_bundle_revision | Control bundle revision in effect during evaluation |
policy_path | Policy query path evaluated |
decision_source | Origin of the decision (opa_native, bouncer, ext_proc, pap) |
actor_type | Actor category (human_user, service_account, ai_agent, system) |
actor_idp | Identity provider or issuer context |
resource_fingerprint | Stable hash for the target resource identity |
risk_score | Runtime risk score for the decision context |
action_taken | Enforcement action (allow, deny, redact, annotate, monitor) |
ai_model | AI — Model identifier |
ai_provider | AI — Provider / source |
ai_tool_name | AI — Tool or function invoked in the transaction |
ai_token_input | AI — Prompt / input token count |
ai_token_output | AI — Completion / output token count |
ai_cost_estimate | AI — Estimated cost for the operation |
ttft_ms | AI — Time to first token in milliseconds |
itl_ms | AI — Inter-token latency in milliseconds |
redaction_applied | Indicates content redaction or masking occurred |
guardrail_trigger_id | Identifier of the control that triggered enforcement |
guardrail_action | Action executed by the control |
control_id | Stable identifier tied to the control lifecycle record |
control_version | Control version in effect for this event |
regulation_tags | Regulatory framework tags (e.g. SOC2, HIPAA, FFIEC) |
event_context | Redacted JSON map for extended audit metadata |
Troubleshooting: If expected AI events do not appear in your SIEM, confirm that the Bouncer is registered in the Control Plane under Administration → Bouncers and that its policy sync is healthy (green indicator). Common causes: misconfigured SIEM outbox destination; policy sync lag preventing the AI governance control from reaching the Bouncer. Full reference: Audit & SIEM integration.
Where to configure event forwarding
AI events flow through the same outbox pipeline as all other audit events. Configure delivery targets under Settings → Action Destinations → SIEM in the Control Plane UI, or via the Control Plane API. See Audit & SIEM integration for the full delivery architecture.
Next steps
- Audit & SIEM integration — configure Splunk, Sentinel, Elastic, and other targets
- Audit tamper evidence — hash-chain and WORM checkpoint for immutable audit records
- How logging works — end-to-end capture architecture
- Troubleshooting controls — diagnose unexpected blocks or missing events