SIEM Log Forwarding

Forward platform audit and security events to your SIEM in real time over syslog, and optionally ship logs to an AWS S3 bucket for retention and analysis. Navigate to Settings → Log Management → SIEM to configure forwarding. Access requires the SIEM settings permission (held by Platform Admin, Admin, and other administrative roles by default).

​

Syslog forwarding

Use Test Connection to send a test message to the configured destination and confirm reachability before saving.

​

Message framing

When syslog runs over TCP, multiple messages share one connection, so the receiver needs to know where each message ends. The platform supports two methods (RFC 6587):

• Octet-counting (default) — each message is prefixed with its byte length. Used by RFC 5425/6587; accepted by rsyslog, Splunk, and most modern SIEMs.
• Newline (LF) — each message is terminated by a line feed. Choose this for receivers that expect non-transparent framing, such as syslog-ng’s default network() source and many legacy RFC3164 servers, which mis-parse octet-counted frames.

Framing applies to TCP only.

​

Event content

Agent-execution and gateway-telemetry events carry the runtime conversation — the user’s input, the model’s response, and each step’s inputs, outputs and debug detail — so that a SIEM can inspect what was actually asked and answered. The remaining categories carry metadata only.

​

Never forwarded

Some fields are excluded from every category and cannot be re-enabled:

• Request and response headers, which carry Authorization values and API keys.
• Tool-call runtime arguments, which frequently carry credentials passed to a tool.

The payload is built as an allow-list, so a new sensitive field cannot begin forwarding by default.

​

When content is withheld

Syslog forwarding honours the same privacy controls that apply in-product, so a SIEM destination does not receive content the platform hides from your own administrators. Where an execution qualifies under more than one control, the strictest applies.

​

Oversized events

Syslog delivers one event per frame and has no fragmentation standard, so an event that exceeds the frame budget is reduced rather than split. The budget is derived from the transport: roughly 256 KB over TCP and 32 KB over UDP, where a single datagram is a hard limit. When an event is too large, the lowest-value content is dropped first, and only as much as is needed to fit — retrieval chunks and generated images before ordinary step content, and the conversation itself last. A dropped field keeps its name and becomes {"omitted":"size","bytes":N}, and the event gains "ContentPartiallyOmitted": true at the top level so your SIEM can tell a reduced event from a complete one. An event that still does not fit is forwarded as metadata only. Prefer TCP if your agents produce long conversations: the UDP budget is eight times smaller, so UDP destinations see reduction far more often.

​

Event routing

Each event is tagged so your SIEM can route or drop it from the syslog header alone, without parsing the message body:

• Severity (PRI) — set on every event, in both RFC5424 and RFC3164. Security and compliance events (audit logs, guardrail and tool-constraint violations, shadow-AI events) are emitted at Warning; high-volume operational telemetry (gateway requests and usage, pipeline executions) at Informational. Filter on severity to keep security events and drop operational noise.
• Message ID (MSGID) — RFC5424 only. Carries the exact event category (see table below) for precise routing. RFC3164 has no MSGID field; on that format, route by severity instead.

​

AWS S3 log shipping

Optionally ship SIEM logs to an S3 bucket in addition to (or instead of) syslog. Use Test Connection in the S3 section to verify the bucket is reachable with the configured credentials.