Export audit and policy decisions to a SIEM
A security team rarely asks "what does the gateway log". The question they actually bring is "what did the gateway decide, and why": for a specific request, on a specific date, against a specific caller. When a prompt was blocked, a response was redacted, or a request was rerouted, the team needs a structured record that names the decision, the policy that drove it, the version of that policy in force at the time, the identity behind the request, and the model that was targeted. That record has to be queryable on its own and exportable into the tooling the security organisation already runs.
Tetrate Agent Router records two related but distinct streams. The audit log captures state-modifying administrative actions (a model enabled, a provider edited, or a key revoked) and is browsed through the Admin Dashboard. Policy decisions are the inline, per-request verdicts the gateway reaches as traffic flows: allow, deny, modify, and redact. Both streams are structured, both carry a correlation identifier and a policy version where a policy was involved, and both can be exported to a customer security information and event management (SIEM) system. This guide covers why policy decisions warrant their own structured record, how that record relates to the audit log and its event schema, how the records are queried, and how they are exported to common SIEM targets: Amazon S3, Splunk, and Datadog among them.
Persona: Platform operator working in the Admin Dashboard, in coordination with security and compliance stakeholders who own the destination SIEM.
Estimated time: 30--45 minutes to choose an export path, configure a destination, and verify that records arrive.
When this guide applies
Exporting audit and policy-decision records is the right step in any of these situations:
| Situation | What export provides |
|---|---|
| A security team must answer "what did the gateway decide for this request, and under which policy" | Structured per-request decision records carrying correlation ID, policy version, caller identity, model, and the action taken |
| Compliance requires audit and policy events to land in the organisation's system of record | A delivery path into Amazon S3, Splunk, Datadog, or a comparable SIEM |
| Decision records must be correlated with the rest of the application stack | A shared correlation identifier that joins gateway decisions to downstream telemetry |
| Audit records must be retained beyond the in-platform window | Exported copies held under the SIEM's own retention policy |
| A periodic attestation must show that every allow, deny, modify, and redact verdict is recorded and exportable | A documented export pipeline plus the structured records it carries |
For browsing administrative events interactively rather than exporting them, the Audit platform activity guide is the right surface. For the field-level event schema, see Audit log events.
Outcomes
By the end of this guide:
- The distinction between the audit log (administrative actions) and policy-decision records (inline per-request verdicts) is clear, along with the fields each carries.
- An export path has been chosen, either the OpenTelemetry-based observability pipeline or a direct export to the SIEM, with the trade-offs understood.
- A destination SIEM has been configured to receive records, with Amazon S3, Splunk, and Datadog covered as representative targets.
- At least one policy decision and one audit event have been confirmed to arrive in the destination, located by correlation ID.
- The retention of exported copies is understood as distinct from the platform's own retention window.
Prerequisites
- Administrator access to the Admin Dashboard, typically the
super_adminrole for the audit and export surfaces. - A destination SIEM, with its ingestion endpoint, transport, and credentials obtained from whoever owns it. For Amazon S3 this is a bucket and a write credential; for Splunk an HTTP Event Collector endpoint and token; for Datadog an intake endpoint and API key.
- Confirmation that the destination endpoint is reachable from the deployment. This is a network reachability question rather than an Admin Dashboard one; where there is doubt, the operator who installed the platform is the right person to confirm.
- At least one policy in force (a guardrail, a routing rule, or a redaction rule) so that policy-decision records exist to export. A platform with no policies configured produces audit events but no inline decision records.
Step 1: understand what a policy-decision record carries
A policy decision is the verdict the gateway reaches inline, while a request is in flight, before the response is returned to the caller. Four verdicts are recorded:
| Verdict | Recorded when |
|---|---|
| Allow | The request satisfied every policy in force and passed through unchanged |
| Deny | A policy blocked the request, and no response was generated from the upstream model |
| Modify | A policy altered the request or routing before it reached the upstream model |
| Redact | A policy removed or masked content from the request or the response |
Each verdict is captured as a structured record carrying the fields a security review depends on:
- A correlation ID that is unique to the request and shared with the request's trace and logs, so the decision can be joined to the rest of the request's telemetry.
- The policy version in force when the decision was reached, so a verdict can be reproduced against the exact rule set that produced it rather than against whatever is current.
- The caller identity the request was attributed to: the API key and, where available, the user behind it.
- The model the request targeted.
- The action taken: the verdict above, plus the policy that drove it.
The reason these records are kept separately from the audit log is a difference in subject. The audit log answers "who changed the platform"; policy-decision records answer "what did the platform decide about this request". A security team investigating a blocked prompt needs the second, not the first. Keeping them distinct means a decision record can be queried by correlation ID without wading through administrative noise, and the two can still be joined where an investigation needs both: for example, when a deny verdict is traced back to a guardrail that an audit event shows was edited an hour earlier.
Step 2: relate decision records to the audit log schema
The audit log and the policy-decision stream share a structural shape, which is what makes them straightforward to correlate and to export through the same pipeline.
- Review the audit event envelope in Audit log events. Every audit event carries a timestamp, an actor, an action in
<resource>.<verb>form, the affected resource, adetailspayload, and arequest_idthat joins the event to other internal telemetry. - Map the policy-decision fields onto the same mental model. The verdict corresponds to the action, the caller identity corresponds to the actor, the targeted model and policy correspond to the resource, and the correlation ID plays the role that
request_idplays in the audit envelope. - Note where the two streams meet. An audit event such as a guardrail edit carries the policy and a timestamp; a later deny decision carries the policy version that edit produced. Joined on policy and time, the two answer "the gateway denied this request because a guardrail had been tightened at this moment, by this administrator".
The practical takeaway is that a single export pipeline can carry both streams, and a single correlation strategy (correlation ID for request-scoped joins, policy plus timestamp for decision-to-administration joins) covers the questions a security team brings.
Step 3: choose between the OTLP path and a direct export
Two export paths are available, and they are complementary rather than competing.
| Path | How it works | Best when |
|---|---|---|
| OpenTelemetry pipeline | Decision and audit records ride the same OpenTelemetry (OTLP) stream the gateway already emits for traces and metrics, into a collector that fans out to the destination | An observability or SIEM pipeline already consumes OTLP, or records must be correlated with traces on a shared identifier |
| Direct export | Records are delivered straight to the SIEM's own ingestion endpoint (an Amazon S3 bucket, a Splunk HTTP Event Collector, or a Datadog intake) without an intervening collector | The SIEM is the system of record and no trace correlation is required, or a collector is undesirable operational surface |
The OpenTelemetry path reuses the export mechanics already described for telemetry; see Export telemetry to an observability stack for the configuration of the OTLP endpoint, transport, and authentication, and OpenTelemetry metrics for the attributes carried on the stream. Because decision records share the same correlation identifier as traces, routing them through this path lets the SIEM join a verdict to the full request trace without additional work.
The direct path is the simpler model when the SIEM is the only destination that matters. Records are formatted for the target and delivered to its endpoint, with no collector to operate. The cost is that trace correlation, if it is needed later, has to be reconstructed from the correlation ID rather than arriving pre-joined.
Most deployments that already run an OpenTelemetry collector route through it; deployments whose SIEM is the single system of record favour the direct path. The choice is reversible; a destination can be moved from one path to the other without changing what the records contain.
Step 4: configure the destination SIEM
The configuration differs per target, but the shape is constant: an endpoint, a transport, a credential, and a confirmation that records are flowing.
-
Sign in to the Admin Dashboard with an administrator account.
-
Open the export configuration for audit and policy-decision records.
-
Select the export path chosen in Step 3, the OpenTelemetry pipeline or a direct export.
-
Enter the destination details for the target SIEM. Representative targets:
Target What to provide Amazon S3 A bucket name, a region, a path prefix, and a write credential. Records are delivered as structured objects under the prefix, which suits archival and downstream batch ingestion Splunk An HTTP Event Collector endpoint and token. Records arrive as structured events that Splunk indexes for search Datadog An intake endpoint and an API key. Records arrive as structured logs that Datadog correlates with the rest of the stack -
Set the authentication for the target: a write credential for Amazon S3, a token for Splunk, or an API key for Datadog.
-
Confirm with security stakeholders which streams are in scope. Both the audit log and the policy-decision stream can be exported; some destinations take both, others only one.
-
Save the configuration and enable the export.
Where the OpenTelemetry path is used, the endpoint, transport, and authentication are configured as for any OTLP destination, with the SIEM either receiving OTLP directly or sitting behind a collector that forwards to it. The mechanics are the same as for trace export, described in Export telemetry to an observability stack.
Step 5: verify records arrive and are queryable
An export that is configured but unverified cannot be attested to. Confirm the pipeline end to end before relying on it.
- Generate a policy decision to test against. Issue a request that a policy in force will act on (one that a guardrail denies, or one a redaction rule masks) so that a non-trivial verdict is produced.
- Note the correlation ID for that request from the in-platform surfaces.
- In the destination SIEM, search for the record by correlation ID. Confirm the verdict, the policy version, the caller identity, the model, and the action taken are all present and match the request issued.
- Confirm an audit event also arrives. Make a small administrative change (toggle a model, or edit a provider) and confirm the corresponding audit event appears in the destination with its actor, action, and resource intact.
- Confirm the records are queryable in the way the security team needs (by correlation ID, by caller, by verdict, and by policy version) rather than only present in raw form.
If records do not arrive while the in-platform surfaces show the decision and the audit event, the cause is usually the export path rather than the platform: an unreachable endpoint, a transport mismatch, or a credential the destination rejects. Each is checkable independently, the same way an OTLP export error is diagnosed in Export telemetry to an observability stack.
Step 6: account for the retention of exported copies
Once a record reaches the SIEM, it lives under the SIEM's retention policy, not the platform's. This separation is the point of exporting (long-horizon retention is delegated to the system built for it) but it has to be stated accurately.
- The platform's own audit and decision records age out on the deployment's configured window, which is intended for active investigation rather than indefinite storage.
- Exported copies persist for as long as the destination's policy keeps them. An Amazon S3 lifecycle rule, a Splunk index retention setting, or a Datadog retention tier governs the exported copy independently.
- A purge of a record from the platform does not remove any copy already delivered to the SIEM. That copy ages out, or is purged, on the SIEM's own terms.
The consequence for a right-to-erasure or subject-access response is that "the record has been deleted" is only true for the store it names. Removing a record from the platform and removing every exported copy from the SIEM are separate operations, each on its own clock. See Manage log retention and purge for the platform-side retention and purge workflow and how it accounts for external SIEM copies.
What to do next
- Manage log retention and purge: to govern how long the platform's own audit and request records live, and how purge accounts for exported copies. See Manage log retention and purge.
- Audit platform activity: to browse administrative events interactively alongside the exported stream. See Audit platform activity.
- Review the audit log event schema: to map exported fields back to the platform's event vocabulary. See Audit log events.
- Review the OpenTelemetry metric and span model: to understand the attributes that travel with records on the OTLP path. See OpenTelemetry metrics.
Where to go next