Automation & Investigation

Automation is the response engine. Reusable detection templates become rules scoped to your accounts and gated on inventory conditions; runbooks chain the actions that run when a rule matches — notify, contain a principal, or remediate a resource. Every run is recorded in the execution history with an investigation report, and every action it takes is reversible from the Actions page.

In the app: /automation

Detection Templates

Templates are reusable detection definitions (criteria only — no response). Each has an evaluator type:

  • field match — a single event matches an event name and/or field predicate (e.g. ConsoleLogin with MFAUsed = No).
  • threshold window — a count over a sliding window crosses a threshold (e.g. 10 GetSecretValue calls in 5 minutes).
  • sequence / absence — an ordered set of events (or a missing expected event) by the same principal.

A library of templates ships pre-seeded (login without MFA, CloudTrail tampering, public security-group exposure, IAM privilege escalation, ransomware-style S3 bursts, and more). Templates are versionable and read-only defaults you can copy.

Rules

A rule is a configured instance of a template: it is scoped to specific accounts, regions, resources and filter clauses, can override template parameters (e.g. raise a threshold), and binds a runbook (or inline actions) to run on a match. Rules are enabled/disabled individually and evaluated against the live event stream.

Resource Gate (inventory conditions)

A rule can be gated on the triggering resource's inventory state — for example, only act if the launched instance is in a given subnet, or the touched bucket is public. The gate is evaluated against the inventory graph and fails open (it never suppresses a real detection because the snapshot is missing), surfacing a warning instead.

Runbooks

A runbook is an ordered list of action steps executed when a rule matches. Built-in actions:

  • notify — publish an alert (optionally with a one-click, 24-hour containment link).
  • revoke_session / contain — contain the offending IAM user or role.
  • resource — a catalog remediation (stop / terminate / start an instance, revoke / re-authorize a security-group ingress rule) targeting the event's own resource or a graph-related one.

Executions & Reports

Every time a rule fires, an execution record is written: the rule, detection, severity, principal, resource and action counts, and a status (DETECTED, REMEDIATED or PARTIAL). Open the Report to see the investigation detail, including the resolved resources and, where relevant, an activity graph.

Reversible actions

Actions taken by a runbook are reversible where an inverse exists (contain ↔ release, stop ↔ start, revoke ↔ re-authorize). Each is recorded on the Actions page with a Rollback button; rolling back replays the inverse and marks the original action Reverted. See the Actions documentation for the unified action log.

⚠️ Warning

A rule with a containment action (revoke_session / contain) blocks the principal that performed the triggering event. Scope rules carefully and test with a throwaway identity — never run a broad containment rule that could contain your own admin or SSO role.

💡 Tip

Start a new rule with a notify-only runbook, watch the Executions tab for a few days to confirm it matches what you expect, then add a containment or remediation step once you trust it.

ℹ️ Note

Automation emails are configurable: a global master switch and per-step options on the notify action control whether an email is sent and whether it includes the one-click containment link.