Skip to main content
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. Platform admin access is required.

​
Syslog forwarding

SettingDescription
Server URLHostname or IP of your syslog server.
PortSyslog listening port (1–65535).
ProtocolTCP (recommended) or UDP. UDP cannot confirm delivery and silently drops messages larger than a single datagram.
FormatRFC5424 (modern, structured) or RFC3164 (legacy BSD).
FramingTCP message delimiting — see Message framing.
Use TLSEncrypt the TCP connection.
Ignore TLS certificateSkip certificate validation. Leave off in production so untrusted certificates are rejected.
Forward audit logsForward platform audit-log events (logins, configuration changes, resource create/edit/delete) to the syslog destination.
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 and routing

Forwarded events contain security and operational metadata only — never message content. Request and response bodies (prompts and completions), conversation history, tool-call arguments, guardrail-matched content, and request/response headers (including Authorization and API keys) are omitted or redacted before an event leaves the platform. 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.
CategoryMSGID
Audit logaudit_log
Guardrail violationguardrail_violation
Tool-constraint violationtool_constraint
Shadow-AI eventshadow_ai
Gateway request telemetrygateway_telemetry
Gateway usagegateway_usage
Pipeline executionpipeline_execution

​
AWS S3 log shipping

Optionally ship SIEM logs to an S3 bucket in addition to (or instead of) syslog.
SettingDescription
Bucket name / RegionTarget S3 bucket and AWS region.
Key prefixObject key prefix for shipped logs (default logs/).
AuthenticationRole ARN (recommended — cross-account AssumeRole, with an optional external ID) or access keys via a stored credential.
Rolling intervalHow often a new log object is rolled (Minute, Hour, Day, Month, Year).
Use Test Connection in the S3 section to verify the bucket is reachable with the configured credentials.