Send AI Agent Audit Logs to Your SIEM
Decision Terrain can forward its audit events to your security information and event management (SIEM) system, so analysts can search, alert on and retain agent and administrative activity alongside the rest of your security data. Forwarding is read-only: it sends records out and does not change what agents can do. To let your security tooling halt an agent, see the Security Response API.
What is forwarded
| Family | What it contains |
|---|---|
agent.audit | Retained execution events for Organization-owned agents: bounded summaries, run and action identifiers, outcomes, and allowlisted model metadata |
organization.security | Recorded membership, identity, credential, integration, policy, access-review, export and emergency security activity, with categorical text and approved identifiers |
Both families exclude prompt and tool bodies, reasoning, credentials and arbitrary evidence. The agent body keeps a summary of up to 500 characters. An Organization chooses one or both families per destination.
Supported destinations
| Destination | What you prepare | Guide |
|---|---|---|
| Splunk | An HTTP Event Collector (HEC) input, an approved index and a token | Splunk |
| Microsoft Sentinel | A workspace, two Analytics tables, a data collection rule and identities | Microsoft Sentinel |
| Wazuh | An enrolled collector, decoder rules and an indexer with read-only query access | Wazuh |
| Custom OTLP | An HTTPS receiver for OTLP logs over HTTP/protobuf | Add it as a destination with its /v1/logs URL; acceptance means the receiver took the batch, not that anything was indexed downstream |
Decision Terrain does not provision vendor infrastructure, detection rules or response automation for you. The guides give the provider-side setup and starter detections.
How to set it up
Prerequisite: your installation operator must deploy the managed audit delivery service and enable managed forwarding (SIEM_MANAGED_ENABLED=true). Installation staff must also permit forwarding for your Organization in System Settings → External security deployment: enable Permit managed audit forwarding, then choose All Organizations or include yours under Selected Organizations. Fresh installations permit all Organizations by default; existing saved restrictions may differ. If Add destination is unavailable, ask installation staff to check these settings. Activation and delivery also require a ready, compatible audit service. Operators follow the deployment prerequisites and automatic installation instructions in the installation documentation. These forwarding settings are independent of security response enablement.
- Prepare the provider side, following its guide.
- In Decision Terrain, open Governance → Policies → External security → Audit forwarding and choose Add destination. Owners, Admins and Security Admins manage forwarding, and changes need recent authentication. See Configure external security for the full walkthrough.
- Select the provider and the audit families, then enter its endpoint, credentials and trust settings. Save, validate, and send a synthetic test, completing the independent review procedure for the test and subsequent destination controls.
- Choose Activate collection when ready. New destinations start disabled. Activation is queued and takes effect only after the audit bridge acknowledges the configuration. Wait for the destination to show Collecting and the applied revision to match the desired revision. The destination then collects new events for its selected families; activation does not automatically forward older retained events.
- Generate and verify real events in your provider after activation takes effect, as the guides describe. Synthetic tests are labeled and never substitute for real product events.
To forward older events that are still retained, open the destination's Delivery recovery section and select Enqueue retained history missing a delivery. Choose an enabled audit family and a time range of up to 31 days per request, preview the eligible events, and apply each page before advancing. Replay creates missing deliveries for that destination; it does not resend accepted/indexed work or recover events that were never captured or are no longer retained. Use additional ranges for longer retained history. See delivery recovery.
Some pieces are set up by your installation operator rather than in the destination form, for example the Wazuh collector route and any Azure managed identity. Ask your operator which apply to your installation.
Independent review of forwarding changes
The current release requires independent human security-policy approval for Send synthetic test, Activate collection, Stop collecting, Pause sending, resuming sending, and retiring a destination. Saving changes to a destination that is collecting or has an applied configuration also requires review, including changes to its credentials, trust, endpoint or audit families. Saving a new inactive destination does not require this review. Validation and status refresh do not require it; role, SSO and recent-authentication checks still apply to these controls.
When an action awaits independent approval, the requested change has not taken effect and no corresponding bridge operation has been queued. Complete the review as follows:
- The requester attempts the save or destination action to create the pending change.
- A different current Owner, Admin or Security Admin opens the same Organization's Governance → Policies → Tool access → Execution protection → Security policy changes. Review the pending entry and expand Complete configuration change before choosing Approve change or Decline. The requester cannot approve their own change; agents and machine credentials cannot supply the approval.
- After approval, the original requester returns to Audit forwarding and repeats the exact save or action. Approval alone does not apply it. Keep the same configuration and credential values; if the destination state or requested change differs, a fresh review is required.
- Confirm the save or operation result and, for activation, wait for the applied configuration and collecting status as described above.
Requests expire 24 hours after creation, including approved requests that have not been applied. An approval is consumed when the matching action is applied; a later operation needs its own review. Recent authentication is required in addition to independent approval. A separately configured, non-production single-administrator testing exception can bypass independent review; it is not the normal deployment path.
Event identity and duplicates
Every event carries its family, Organization and event ID. Delivery can repeat an event after a lost acknowledgement, so deduplicate by family, Organization and event ID before counting. Do not merge agent attempts and outcomes by run or source ID, because they are different events. Use the original occurrence time (audit.event.occurred_at or OccurredAt) for timelines, not the time your provider received the event.
An Organization with an active destination that includes the security family also sends a siem_heartbeat security event, by default once an hour (your operator can change the interval). Alert on its absence to detect a forwarding path that has gone silent; the provider guides show how.
For active destinations, Decision Terrain attempts to email eligible Owners and Security Admins with verified email addresses when a detected degradation persists beyond the configured grace period (10 minutes by default). Notification timing also depends on scheduled health checks and workers, and delivery requires a working email connection. The destination card shows the detected degradation and notification status, including pending or failed notices and missing eligible recipients. Monitor heartbeat absence independently in your SIEM: an outage that stops the application's health checks or email delivery can also prevent these notifications. The installation documentation covers the operator settings and delivery behavior for failure alerts and the heartbeat.
Starter detections
Each guide links generated starter detections for audit-policy changes, evidence reveal or export, forwarding being stopped, credential issuance, role changes, SSO weakening, security holds, failed emergency steps, repeated failed sign-ins or credential rejections, and repeated agent policy denials. Splunk saved searches and Sentinel analytics rules ship disabled and must be enabled after configuration and testing. Wazuh rules take effect when installed and loaded by the manager; validate them before loading. Response automation is configured separately.
The detections target the same conditions, but counting differs: Splunk and Sentinel queries deduplicate event identities, while Wazuh frequency rules count matching deliveries, so retries can inflate their counts. See the Wazuh detection guidance for unique-event counting alternatives. Thresholds are starting points, not tuned baselines; test the selected provider's detections against your data, including duplicate deliveries.
Limits
- Forwarding is not an archive and is not exactly-once. Keep your own retention in the SIEM.
- A successful HTTP response from a provider is not proof of indexing. Search for real events.
- Forwarding cannot reconstruct events that were never captured, and it does not change retention.