> ## Documentation Index > Fetch the complete documentation index at: https://explore.airia.com/llms.txt > Use this file to discover all available pages before exploring further. # 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 | Setting | Description | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Server URL | Hostname or IP of your syslog server. | | Port | Syslog listening port (1–65535). | | Protocol | **TCP** (recommended) or **UDP**. UDP cannot confirm delivery and silently drops messages larger than a single datagram. | | Format | **RFC5424** (modern, structured) or **RFC3164** (legacy BSD). | | Framing | TCP message delimiting — see [Message framing](#message-framing). | | Use TLS | Encrypt the TCP connection. | | Ignore TLS certificate | Skip certificate validation. Leave off in production so untrusted certificates are rejected. | | Forward audit logs | Forward 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 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. | Category | Message content forwarded | | ------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Pipeline execution | **Yes** — per-step inputs, outputs and debug detail, conversation history, variables, and the halting step's output | | Gateway request telemetry | **Yes** — request body (prompt) and responses (completions) | | Audit log | No — records who did what, and when | | Guardrail violation | No — the matched content is not forwarded | | Tool-constraint violation | No — tool-call runtime arguments are not forwarded | | Shadow-AI event | No — the request body is not forwarded | | Gateway usage | No | ### 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. | Control | Effect on forwarded events | | -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Conversation Privacy** set to *Yes – Restrict Access* in [Data Retention Settings](/admin-hub/account_settings/data-retention-and-privacy) | Agent-execution **and** gateway-telemetry events are reduced to metadata. A syslog destination has no originating user, so this applies to every conversation. | | **[End-User Privacy](/admin-hub/airia-agent/access-and-privacy)** enabled on an agent | That agent's execution events are reduced to metadata, for every user. | | Execution of one of Airia's **built-in system agents** | The system prompt and tool definitions are withheld. User and assistant messages are still forwarded. | Where an execution qualifies under more than one control, the strictest applies. These controls are stricter than forwarding was before this change, which honoured none of them. If your SIEM previously received the system prompt of a built-in system agent, or content from an End-User Privacy agent, it no longer will. ### 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. | Category | MSGID | | ------------------------- | --------------------- | | Audit log | `audit_log` | | Guardrail violation | `guardrail_violation` | | Tool-constraint violation | `tool_constraint` | | Shadow-AI event | `shadow_ai` | | Gateway request telemetry | `gateway_telemetry` | | Gateway usage | `gateway_usage` | | Pipeline execution | `pipeline_execution` | ## AWS S3 log shipping Optionally ship SIEM logs to an S3 bucket in addition to (or instead of) syslog. | Setting | Description | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Bucket name / Region | Target S3 bucket and AWS region. | | Key prefix | Object key prefix for shipped logs (default `logs/`). | | Authentication | **Role ARN** (recommended — cross-account `AssumeRole`, with an optional external ID) or **access keys** via a stored credential. | | Rolling interval | How 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.