SIEM forwarding

The Scrydon audit log can be forwarded to your SIEM in near real time. This page covers the supported destinations and the configuration model.

Supported destinations

Custom destinations are supported through the platform's webhook adapter — point Scrydon at your collector's ingest URL with the right auth.

Configuration

Under Settings → Platform → Audit logs → Forwarding, configure one or more destinations:

• Destination type — pick from the list above.
• Endpoint URL — your collector's ingest URL.
• Authentication — bearer token, basic auth, mTLS, or signed request, depending on the destination.
• Event filter — optional. Forward all events, or filter by action namespace.

Multiple destinations can be active at once (e.g. forward all events to your data lake + critical events to your SIEM).

What gets forwarded

Every event in the audit log is eligible. The forwarder respects the same filtering and retention as the audit log itself — events that are filtered out of the local audit log are not forwarded.

The wire format is structured JSON:

{
  "id": "aud_abc123",
  "action": "SECRET_ACCESS",
  "resourceType": "secret",
  "resourceId": "sec_xyz789",
  "actorId": "usr_456",
  "organizationId": "org_001",
  "metadata": { "secretName": "OPENAI_API_KEY", "strategy": "LOCAL" },
  "ipAddress": "10.0.1.42",
  "userAgent": "Mozilla/5.0...",
  "createdAt": "2026-03-16T10:30:00Z"
}

This is the same shape you'd see in the audit-log UI, so the same dashboards work everywhere.

Delivery guarantees

• At-least-once delivery. Events may appear more than once in your SIEM after retries. Use the id field for deduplication.
• Ordered per-event. The forwarder doesn't reorder events; downstream collectors may, depending on their ingest pipeline.
• Buffered. Brief SIEM outages don't lose events — the forwarder buffers locally and replays once the destination recovers.

Backpressure

If your SIEM rejects events for an extended period (auth expired, ingest disabled), the local buffer fills. When it's full, the forwarder backpressures the audit log itself — that's a safety property: audit events should never be silently dropped just because forwarding is broken.

Symptoms of backpressure:

• audit_log.forwarding_buffer_full metric exceeds threshold.
• Audit-log writes slow down.
• An AUDIT_FORWARDING_DEGRADED event appears in the local log.

Fix: re-establish the SIEM destination or temporarily disable forwarding while you investigate.

Related

• Audit logging — the source of forwarded events.
• Observability — for metrics + traces (separate from audit).
• Compliance — frameworks that mandate SIEM forwarding (ISO 27001 A.8.16, SOC 2 CC7).