Alerts and SIEM
Define alert rules that fire on a verdict pattern, deliver them by email or webhook, and forward workspace events to your SIEM in JSON or CEF.
Two separate things live under Settings → Alerts, and it is worth keeping them apart:
- Alert rules — "tell me when this happens." A rule watches for a verdict pattern and notifies you.
- SIEM delivery — "send me everything." A standing webhook that forwards workspace events to your collector.
Most teams end up using both: the SIEM feed for retention and correlation, one or two alert rules for the things that need a human tonight.
Alert rules
A rule fires when a verdict level occurs often enough inside a time window. You give it:
| Field | What it does |
|---|---|
| Name | How the alert identifies itself. |
| Verdict | Which level to watch — NOMINAL, ELEVATED, SUSPICIOUS, or HIJACK. |
| Threshold | How many occurrences it takes to fire (1–100). |
| Window | The period those occurrences must fall inside, in seconds. |
| Consecutive | Whether the occurrences have to be back-to-back, or just within the window. |
| Severity | info, warn, or critical — carried into the notification. |
| Delivery | none, webhook, or email. |
A threshold of 1 on HIJACK is the rule most workspaces start with:
tell me the first time anything gets hijacked. A threshold of 10
ELEVATED in 300 seconds is the shape you use for "something has
started going wrong" without paging on every single event.
You can also give a rule a custom notification title and body, so the message that lands in your inbox or your incident channel reads the way your team expects.
Delivery channels. none records the alert in the dashboard and
sends nothing outward — useful while you are tuning a rule's threshold.
webhook POSTs to a URL you supply, optionally with an authentication
header. email sends to an address you supply.
Every rule has a Test action that fires it with a synthetic event and reports the real delivery result, so you find out that your webhook URL is wrong now rather than during an incident. The Alerts page also shows delivery health per rule, so a channel that has started failing is visible without you going looking.
SIEM delivery
Point Sentisec at your collector and workspace events are forwarded as they happen.
You configure three things: the collector URL, the format, and
optionally an authentication header line (Header-Name: value) that
is sent with every delivery.
Two formats are supported:
- JSON — the default; a structured event object per delivery.
- CEF — ArcSight Common Event Format, for collectors that expect it.
There is a Test action here too, which sends a synthetic event to your collector and reports what came back. The health panel beside it shows recent delivery outcomes.
Turning the integration off keeps your configuration in place — useful when you want to pause delivery during a collector migration without losing the settings.
What this is not
Alert rules and SIEM delivery are notification surfaces. They tell you what happened; they do not change what Sentisec does about it. What gets blocked is decided by enforcement mode and the egress allowlist.
Related
- Verdicts — what each level means
- Enterprise — log exports
- Dashboard — where both settings live
Approval for payments, messages and contact changes
Make money movement, outbound messages and contact or identity changes wait for an admin's approval: always, after the agent has read outside content, or when a recipient or account is not one you know. No learning step needed.
Provider errors (503, 401, 400, 404)
Diagnose provider_unavailable, no_upstream_credential, upstream_provider_header_invalid, bedrock_credential_missing, and embeddings_not_supported_for_provider.