Log shipping

NomOS sends the audit events of your tenant to a SIEM such as Splunk, or a SIEM fetches them itself. Only platform admins can set this up.

What is shipped

Each event is one governed run or one resource read, with metadata only: event_id, record_source, class, kind, occurred_at, tenant, room, actor, agent, outcome, governance acts (verb, subject type, subject id), the read resource URI, run_id, whether the evidence bundle is signed, and a link to the bundle in NomOS. Questions, answers, reasons, decision titles, and document text never leave the platform.

Push to Splunk

In Splunk, create an HTTP Event Collector token and choose an index. In NomOS, add a destination with the HEC URL and token, send the test event, and activate it. About every minute, the shipper sends new events with the source type ainomos:audit. The cursor moves only after Splunk accepts a batch, so delivery is at least once: remove repeats in a search with dedup event_id. The status shows the last delivery, the last error, and how far behind the destination is: amber from 15 minutes, red from 60.

Pull through the API

Create a reader client on the log shipping page; its secret is shown once. The SIEM gets a token with the client credentials grant and calls GET /api/platform/audit-events with limit, class, and format, then passes next_cursor back as cursor. The first call can use since to skip older history. Every page that returns events writes its own audit record. Revoking a reader blocks it at once.

Formats

You choose the format per destination and when fetching. The default is the NomOS JSON with the fields listed earlier. OCSF maps each event to OCSF 1.9.0, class API Activity (6003); fields without an OCSF counterpart go to unmapped. A destination can also send only selected event classes and start from an earlier date instead of from now.

Security

Destinations must use HTTPS with a certificate that NomOS trusts: a publicly valid one, one from a company CA, or one that an admin pinned. The operator can provide a company CA for the whole installation, or a platform admin for one destination; it is added to the public certificate authorities, and the host name is still checked. Pinning trusts exactly one certificate for one destination, after the admin compared its SHA-256 fingerprint; it suits a Splunk with a self-signed or default certificate. Neither is a way to switch verification off. Addresses in private networks are refused, and redirects are not followed. The HEC token is stored encrypted and shown only by its last four characters. Every change to a destination, reader, CA, or pinned certificate needs a reason and is recorded as evidence.

Your own Kubernetes

On a self-hosted installation, log shipping runs inside the chart and needs no cloud service. If your Splunk certificate comes from a company CA, the operator provides that CA as a Secret (logShipping.caBundleSecret); certificate verification stays on. A Splunk at a private address is allowed only when the operator lists its host name in logShipping.allowedPrivateHosts. Destination tokens need a keyring Secret (logShipping.keyringSecret); if it is empty, the chart uses the keyring of the email credentials. This works whether email runs over SMTP or an API. If the cluster blocks outgoing traffic by default, allow HTTPS from brain-core and log-shipper to the Splunk port.

Limits

Only audit events are shipped, not technical logs of the application, gateway, or sign-in. Splunk indexer acknowledgment is not used: HTTP 200 counts as accepted. New events arrive with a delay of one to two minutes.