Detection and response
Authpermit turns what happens into what it means: events → signals → findings → incidents. An alert is not an incident: signals of one detection about one key join one finding, and findings about the same identity or device join one incident.
Detections as code
A detection is YAML (or the same structure in JSON), parsed into a validated AST and compiled into a plan — the same engine whether the rule was written in an editor, sent over the API or proposed by an AI. Four kinds:
match— one observation is enough (a signature);threshold—countobservationswithina window persamekey;sequence— A THEN B WITHIN t SAME key, each step with its own count;correlation— members from different sources about the same key within a window.
Rules read four sources: events from the event fabric, risk_signals, findings (vulnerabilities, the Auditor's application-security findings, other detections' findings) and other detections' signals. Conditions use the policy language (all/any/not over {fact, op, value}).
key: password-spray-then-sign-in
name: Password spraying followed by a successful sign-in
kind: sequence
severity: high
produce: incident
category: account_takeover
mitre: [T1110.003, T1078]
within: 10m
same: [payload.email]
sequence:
- {name: failures, event: auth.sign_in.failed, count: 5}
- {name: success, event: auth.sign_in.succeeded}
tests:
- expect: fire
observations:
- {event: auth.sign_in.failed, payload: {email: a@x.test}, repeat: 5}
- {event: auth.sign_in.succeeded, payload: {email: a@x.test}, at: 60}
Every edit is a draft version. POST /api/v1/detection/rules/test runs the rule's embedded tests and, with replay_hours, replays your recent events to show how often it would have fired. Activation (POST /api/v1/detection/rules/{id}/activate) refuses a rule whose tests fail. An AI can draft and test detections, never deploy or disable one without a person's approval.
Suppression
Exceptions are first-class and audited: a reason, an expiry (only a permanent exception has none), and a scope — a rule, an entity, conditions, or a severity ceiling. Only a person creates one (POST /api/v1/detection/suppress, scope detection:suppress); an AI's recommendation becomes a task a person approves, and is marked as such. A suppressed signal is still recorded.
MITRE ATT&CK
Tag detections with technique ids. The catalogue is imported from a STIX bundle you download (mix authpermit.detection.mitre.import enterprise-attack.json); nothing is fetched at runtime. GET /api/v1/detection/coverage shows, per tactic, how many techniques an active detection covers — rule coverage, not proof that the telemetry arrives.
Incidents
An escalated finding declares an incident, or joins the open one with the same identity or device. Incidents carry a confidence, the ATT&CK stage reached and techniques, and close either normally or with a verdict — false_positive, duplicate (naming the original) or accepted_risk — with a reason (POST /api/v1/incidents/{id}/disposition). GET /api/v1/detection/incidents/{id}/story returns the attack story: events, signals and findings on one timeline with the stages reached.
Response with AlertMattic
The security incident is the truth; the AlertMattic incident runs the operational response — responders, acknowledgement, escalation. Incidents at or above your floor (default high; settings.alertmattic_min_severity) are escalated automatically, others with POST /api/v1/response/escalate. Status changes move the AlertMattic incident forward, never backward, and its acknowledgement and resolution are read back every five minutes. When AlertMattic is not configured, nothing is escalated and the incident says so.
Response actions and verification
Every automation action states whether it can be undone (reversible, rollback) and what else it changes (side_effects) — visible in GET /api/v1/capabilities. A step whose effect can be confirmed gets a verification (GET /api/v1/workflow-verifications): a quarantine reads requested, not verified until the endpoint confirms it, and becomes unverified if nothing does.