From raw alert to closed case in one deterministic pipeline.
Every alert passes through a fixed sequence, and every stage is observable, auditable, and policy-governed. This page describes each one.
via API key
canonical schema
+ SLA watcher
related alerts
JSON prefill
hard rules
HMAC trail
email Β· webhook
π Ingestion layer API key
We issue tenant-scoped ingestion API keys; you add a forwarding rule in your SIEM or XDR that sends alerts to Triage Beacon with that key. Keys are hashed at rest and revocable per tenant. Raw payloads are validated and normalized into a shared canonical schema before entering the queue.
βοΈ Worker 30s SLA 60s
The worker runs two independent loops: a 30-second ingest loop that pulls batches of queued alerts through the triage pipeline, and a 60-second SLA watcher that escalates any case sitting past its configured response window. Informational noise (low severity, unrecognized family) closes deterministically without an AI call, which keeps per-alert cost flat.
π Enrichment engine parallel
Independent lookups run in parallel: IP reputation, user context (role, privilege tier, MFA status), host criticality, geo baseline, file-hash intelligence, and related alerts from the past 30 days. Each lookup tolerates failure and reports a coverage score, the policy engine downgrades any verdict built on thin evidence.
π§ AI analysis versioned
The model is called with two prompt-cache breakpoints, a static system prompt and a per-family playbook, while the variable alert JSON rides in the user message. The assistant turn is pre-seeded with { to force pure JSON output. The full detail lives on the AI Engine page.
ποΈ Policy engine post-LLM
Deterministic rules run after the model and override its output in code: known-malicious IPs force a true positive, critical privileged sign-ins force human escalation, and thin enrichment forces an inconclusive verdict. Prompt injection and model updates cannot bypass these rules.
π API server separate
A separate API server handles the analyst console and alert ingestion. All DB queries are tenant-scoped. Five roles govern access, from Viewer to Admin, with least privilege by default. JWT sessions, TOTP MFA configurable per tenant.
Every source speaks one language
before the AI sees anything.
Defender, Sentinel, Splunk, CrowdStrike, and Wazuh alerts all normalize into the same canonical shape. Fields that a family never populates are stripped before serialization, a risky_signin alert carries no command_line, so the model never sees noise.
{
"alert_id": "SEN-2026-1142",
"source": "sentinel",
"family": "brute_force_password_spray",
"severity": "high",
"received_at": "2026-07-06T14:03:22Z",
"user_principal_name": "reception@client.example",
"ip_address": "23.129.64.190",
"mitre_tactics": ["T1110"],
"tenant_id": "acme-mssp"
}
Why a canonical schema matters
One prompt, every source. The AI playbooks reason over the same field names whether the alert came from Defender or Wazuh. Adding a connector never changes triage behavior.
Validation at the boundary. Every alert is schema-validated on ingestion, and malformed payloads are rejected with a clear error.
Token discipline. Null and empty fields are stripped before the model call, which keeps per-alert cost flat as connector coverage grows.
Two surfaces, one region.
The same console bundle serves two audiences split by hostname, app.triagebeacon.com for analysts, admin.triagebeacon.com for platform administration. Everything runs in AWS Canada (ca-central-1): container workloads on ECS Fargate, PostgreSQL on RDS with encryption at rest, static delivery via CloudFront, secrets in AWS Secrets Manager.
Analyst surface
Queue, case detail, reports, and tenant settings at app.triagebeacon.com. Focused on the confirm/override loop, no platform clutter.
Admin surface
Cross-tenant client management, onboarding, and platform-wide tickets at admin.triagebeacon.com. Restricted to platform staff with full access logging.
Canadian infrastructure
ECS, RDS, Secrets Manager, and CloudWatch all in ca-central-1. No service runs outside Canada without explicit customer approval. Full detail on the Security page.