Log exports

Two different jobs, two different mechanisms. Alerting pushes findings to your SIEM as they happen. Evidence is pulled on demand, when someone needs to reconstruct what occurred. Do not use one for the other: a webhook is best-effort by design, and the record you can prove is the one you pull.

Forward findings to your SIEM

Configure one HTTPS destination per workspace, on the dashboard under Settings → Alerts, on its Destination tab. Sentisec POSTs an alert to it whenever a finding is recorded.

Only non-nominal findings fire. A healthy session emits a verdict per tool call and your collector is not the place for that traffic — NOMINAL is filtered out before delivery. Everything else is sent.

What you configure

Field	What it does
Destination URL	Absolute `http://` or `https://`. Any other scheme is rejected.
Format	`json` for a flat object, or `cef` for the nested CEF envelope ArcSight-lineage collectors expect.
Auth header	One raw header line, `Header-Name: value`. Use whatever your collector wants — a bearer token, a Splunk HEC token, a Datadog API key.
Enabled	Turn forwarding off without discarding the configuration.

The auth header is write-only. It is encrypted before it reaches storage and no endpoint ever returns it — reading the configuration back tells you only whether one is set. To replace it, send a new one; to clear it, send an empty string; to leave it alone, omit the field.

There is a Send test alert button next to the configuration. It fires one synthetic ELEVATED finding, clearly marked as a connectivity test in its explanation so nobody pages an on-call for it, and records the outcome in delivery health.

The alert body

Both formats carry the same facts. json puts them at the top level with a schema marker; cef nests them under extension. Switching format keeps your dashboard queries working, because the field names are identical either way.

format: json

{
  "schema": "sentisec.alert.v1",
  "vendor": "sentisec",
  "product": "sentisec-control-plane",
  "signature_id": "…",
  "name": "one-line explanation of the finding",
  "severity": 9,
  "session_id": "ses_…",
  "step_idx": 7,
  "verdict": "HIJACK",
  "intervention": "HALT",
  "forensic_id": "forensic_…",
  "timestamp": "2026-08-03T14:25:13+00:00"
}

signature_id identifies which rule produced the finding — group on it to see repeat offenders. forensic_id is the handle for the full evidence record. Additional diagnostic fields ride along; treat the payload as additive and index the ones you need.

Severity is stable. These numbers are what you wire your thresholds against, so they do not move without a changelog entry:

Verdict	Severity
ELEVATED	5 — informational
SUSPICIOUS	7 — needs attention
HIJACK	9 — active compromise

Delivery is best-effort, deliberately

A collector that is unreachable must never cost you a verdict, so forwarding fails open: the finding is recorded, the response is served, and the delivery failure is logged rather than raised. Nothing in your traffic path depends on your SIEM being up.

The consequence is that the webhook is a notification channel, not a ledger. GET /v1/workspaces/{id}/integrations/siem-webhook/health reports recent delivery outcomes so you can see whether what you configured is actually arriving — check it after any change to your collector, and alert on it if forwarding is load-bearing for you.

Alert rules

Alongside SIEM forwarding, alert rules let you define narrower conditions and route each to its own destination — one rule to a paging channel for blocked actions, another to a chat channel for anything merely elevated. Manage them under /v1/workspaces/{id}/alert-rules; they have their own test-fire and their own delivery health, and they use the same fail-open transport.

Pull evidence

Three endpoints cover what an auditor asks for. All are pull-based, all return the record itself rather than a notification about it.

You need	Endpoint
Who changed the workspace, and when	`GET /v1/workspaces/{id}/audit-log`
What one agent run did, step by step	`GET /v1/workspaces/{id}/sessions/{sid}/timeline`
The signed record for a specific incident	`GET /v1/workspaces/{id}/sessions/{sid}/forensic`
Every evidence record, filterable	`GET /v1/workspaces/{id}/forensic/bundles`

Add ?format=verify to the forensic endpoint and you get a verification envelope instead of the raw record: the content hash, the signature, and the signing key id. That is the artefact to hand a third party — they can confirm the record has not been altered without having to trust the API that served it.

Evidence records carry compliance tags mapping them to the control they evidence, so you can pull "everything relevant to this control" rather than filtering by timestamp and hoping.

See Audit and metrics for the full parameters on each.

Retention

Content retention is a workspace setting. Once the window passes, the request and response bodies are removed and the record is stamped to say so — while the usage row itself survives, so your spend history, request counts and verdict record stay intact. Pruning content never rewrites numbers an operator has already seen.

If you would rather never store bodies at all, set the workspace to capture metadata only.

Audit and metrics
In-VPC deployment — keep evidence inside your boundary
Security

On this page