The platform
Four signal domains, one schema, 412 correlation patterns held in your own Git repository. Every situation arrives with the rule that matched, the raw events that matched it, and the query you can re-run yourself. This page is the detail.
What it watches
Configuration scanning tells you what could go wrong. These four tell you what is going wrong, which is a much smaller and much more urgent set.
Every authentication, role assumption, token exchange and permission change is attributed to a principal and compared against ninety days of that principal's own behaviour — source ASN, source region, hour of week, target service, session duration.
An eBPF sensor on your nodes reports process execution, binary provenance, connection establishment and per-socket byte volume. It runs at 0.7% node CPU at p50 on a typical HTTP service — and we publish the p99 and the two workload shapes where we tell you not to deploy it.
Byte volume is accumulated in kernel per socket and emitted on a one-second tick, then compared against the workload's own forty-day profile. Destinations are resolved to organisation and first-seen date, so a bucket created ninety minutes ago is a fact, not a guess.
IAM policy edits, trust-policy changes, security group and firewall rules, KMS key policies, logging configuration. Each change is evaluated for reach — the set of workloads, identities and data stores it newly exposes — computed from your live policy graph.
The pipeline
Every stage below is measured and published. The first one is not ours, and we say so rather than quietly measuring from the point the event reaches us.
Control-plane logs land on your provider's schedule; runtime and egress arrive on ours in under a second. Where EventBridge carries an event, we take it and reconcile against CloudTrail later.
Everything becomes OCSF 1.3. One schema across AWS, GCP and Azure, so a detection written once applies to all three and a query written once does not need three dialects.
Identities resolve to humans and pipelines, workloads to owning teams, principals to their IAM reach. Destinations resolve to organisation and first-seen date.
Signals hold in a window — typically ten seconds, up to fifteen minutes for slow chains — waiting for their siblings. Partial matches are visible asforming from the first condition.
One situation, one notification, everything attached. Slack thread, PagerDuty incident, Opsgenie alert or a signed webhook into whatever you actually use.
Median end to end: 38s. Ninety-ninth percentile six minutes four seconds, almost all of it waiting for CloudTrail.
The console
Four panes and no score. Sorting is by reach, novelty and motion — three facts you can each interrogate.
events
| where principal == "northwind-deploy-ci"
| where time between (02:00 .. 02:15)
| join principal.asn_history(90d) on principal
| where source.asn !in history.asn
| project time, source.asn, api, outcomeThe named correlation pattern, its conditions, which matched and which did not, and a link to the exact line in your Git repository. Partial matches are shown, not hidden — a situation that reached three of four conditions tells you something.
Every normalised event that matched, in full. Not a summary, not a sampled subset. Alongside each one, the history that made it unusual: if the pattern fired on an unseen ASN, you get the ninety-day ASN distribution that justifies the word 'unseen'.
The literal query that produced the evidence, in a copyable box. Change the window, change a condition, run it against the last six months. The detection engine and the ad-hoc query engine are the same engine, which is why this works.
What the involved principal could touch, walked from your live IAM graph: workloads, buckets, databases, secrets, and the other principals it can assume. This is the number that should decide what you open first.
Detections as code
We fork our detection library into a repo you own on day one. You review changes the way you review any other code — pull request, diff, approval — and the console links every situation back to the exact line that fired.
name: credential-use-anomaly
severity_inputs: [reach, novelty, motion]
window: 15s
require: 3
conditions:
- id: unseen_asn
expr: source.asn not in principal.asn_history(90d)
min_observations: 50
- id: orientation_pass
expr: api_sequence matches sequences.orientation
- id: stale_credential
expr: credential.age > policy.max_age
- id: protected_write
expr: outcome == "success"
and target.tags contains "protected"
suppress_when:
- principal.tags contains "break-glass"
and change_ticket.existsIntegrations
Nothing in the inbound list needs write access. Nothing in the outbound list is a proprietary format.
Scope
Thirty minutes
We start every demo in the rule repository, not the dashboard. If the 412 patterns do not describe threats you actually have, the next twenty minutes are not worth either of our time.