Auto-Incident Rules

Build rules that open an incident on their own when a connector event matches conditions you have set — so a known signal becomes a tracked incident without anyone watching a feed.

An auto-incident rule (a saved set of match conditions plus a template for the incident it should raise) sits between your connectors and the Incidents module. When a connector delivers an event — a cloud-security detection, an endpoint alert, a webhook (a message one system pushes to another) — Aegis checks it against every enabled rule, and a match creates an incident from the title, severity, category and tags you chose. This page is where you create, edit, test, enable, disable and delete those rules.

Rules are tenant-level configuration, so the page sits behind the settings permission — and because a broad rule can open many incidents quickly, each rule carries its own deduplication, rate-limit and cooldown controls.

Who uses it

• Admin Full access — view the list, create and edit rules, run the dry-run test, toggle rules on or off, and delete them. The route checks settings:update, the same permission the underlying API enforces.
• Manager Contributor Viewer No access. The link is absent from the left menu, and opening /incidents/auto-rules directly sends you back to the Incidents list rather than showing an error. These roles still work the incidents rules create — they cannot change the rules.

The page belongs to the Incidents module. If that module is not provisioned for your organisation the menu entry is hidden, and the rules list stays empty even if you type the address in. Settings shows which modules you have.

What's on this screen

The page is headed Auto-Incident Rules, with the line "Automatically create incidents from connector events using condition-based rules." beneath it. On the right sits Create Rule, the only way to start a new rule. Below that is a single-row filter bar: a Search rules... box with a Search button, and an All Statuses dropdown that narrows the list to Enabled or Disabled rules.

Everything below is the rules table. Once rules exist it shows Rule Name and Trigger Type as plain text, Incident Severity and Status as coloured pills, then Actions with a per-row Enable/Disable link and a red Delete link. Clicking elsewhere on a row opens it for editing; the list pages at twenty rows.

In the captured screenshot the tenant has no rules yet, so the table area shows the empty state: a document icon above "Nothing here yet" and "No items have been created yet".

1. Open SECURITY INCIDENTS in the left menu and choose Auto-Incident Rules. The group expands to show Incidents, Reporting and Auto-Incident Rules; the last is admin-only.
2. Type into the Search rules... box to narrow the list by rule name, then select Search; pair it with the All Statuses dropdown to show only enabled or only disabled rules. With no rules yet, both return nothing.
3. The centre panel holds the rules table. Here it shows the empty state — "Nothing here yet" — so no rule exists. Choose Create Rule in the top right to add one; the table replaces the empty state as soon as a rule is saved.
4. The ? button in the top bar opens the in-app help for a reminder of how conditions or dedupe windows work while you build a rule.

Create a rule

Selecting Create Rule opens the Create Auto-Incident Rule dialog — a long, scrolling form in four parts: what the rule is, what it matches, what incident it produces, and how much noise it may make. Rule Name and Incident Title Template are required; miss either and a red message appears at the top while Aegis scrolls that field into view.

1. Enter a Rule Name you will recognise in the list — the placeholder suggests "e.g. Critical CrowdStrike Alerts".
2. Choose a Trigger Type — Connector Event, AI Analysis, Threshold Breach, Webhook, Schedule or Manual. Connector Event is the default and the only type the connector pipeline evaluates — the others are stored on the rule but reached only through the API, so a rule set to one of them will not fire from a connector.
3. Add an optional Description, and a comma-separated Source Types list such as crowdstrike, aws-guardduty to limit the rule to those sources. Left empty, it accepts any source.
4. Build the match in the Conditions panel (next section). Left empty, the rule matches every event that reaches it — rarely what you want.
5. Fill in the incident template. Incident Title Template accepts placeholders in double braces, so {{data.title}} - {{data.hostname}} yields "Malware detected - srv-web-01" from the event itself. Set Incident Severity (Medium by default), and optionally Incident Category and Incident Tags.
6. Set the noise controls: tick Deduplicate matching events (unticked on a new rule) with a Dedupe Window (seconds), cap the rule with Max Incidents / Hour, pause it with Cooldown (minutes), and order evaluation with Priority — lower numbers run first, and a blank box stores 50, the middle of the 0–100 range it accepts.
7. Leave Rule enabled ticked to start it straight away, or clear it to save the rule dormant. Select Create Rule at the foot of the dialog: it closes and the new rule appears in the table.

Build the conditions

The Conditions panel is a visual builder, not a text box. It opens as one blue AND group labelled "All must match" holding a single empty row; switch the group dropdown to OR and it turns orange and reads "Any can match". Reset beside the panel heading clears the tree back to one empty group, and the line beneath it repeats the warning: leave it empty and every event matches.

1. Click the field box in a row. A suggestion list drops down with common event paths — severity, data.hostname, data.title, sourceType — each described. Pick one, or type your own dotted path.
2. Choose the operator: equals, contains, greater than, in list, matches regex, is empty and the rest. The value box adapts — in list takes a comma-separated list, is empty hides it.
3. Enter the value, then use Add Condition for another row in the same group, or Add AND Group / Add OR Group to nest a sub-group — that is how you express "this and that, or the other thing". The small NOT button inverts a row, and × removes it.

Edit a rule and test it

Clicking a row opens the same dialog headed Edit Auto-Incident Rule, pre-filled and with one panel create mode lacks: Test Rule. It evaluates the saved rule against a sample event and reports what would have happened, creating nothing.

1. Click the rule's row. The dialog opens with every field populated; change what you need.
2. Scroll to Test Rule at the foot of the form. The box starts with a worked sample event in JSON — a severity, a hostname and a title. Edit it to resemble a real one.
3. Select Run Test. A green box reports "Matched — an incident would be created." with an Incident preview line showing the title the rule would produce, or a grey box reports "No match — no incident would be created." The test runs against the last saved version of the rule, not unsaved edits on screen, and invalid JSON is rejected before anything is sent.
4. Select Save Changes to keep your edits, or Cancel to discard them. The test result is never saved — it is a dry run only.

Enable, disable or delete a rule

1. Select Disable on a live rule, or Enable on a dormant one. The Status pill flips and a confirmation appears — "Rule disabled" or "Rule enabled". A disabled rule stops matching but keeps every setting.
2. Select Delete to remove a rule. A dialog headed Delete Rule names it — "Delete the rule ...? This cannot be undone." — and waits.
3. Confirm to delete, or close the dialog to keep the rule. Incidents it already created stay in the Incidents list.

How a rule actually fires

Aegis hands a delivered connector event to a background job rather than evaluating rules on the request itself, so a busy source cannot slow the receiver down. The job checks the event against your enabled rules in priority order — lowest number first — and a matching rule can still be held back by its own controls.

Tips and limits

• The test is a genuine dry run — it reports the match and previews the title, but never opens an incident. It appears only once a rule is saved, so create first, then reopen to test. It weighs the conditions alone: a "Matched" result is not a promise of an incident, because dedupe, Max Incidents / Hour and Cooldown (minutes) are not applied to a test.
• Source Types and Incident Tags are comma-separated lists, and the numeric boxes take whole numbers. Leaving Dedupe Window, Max Incidents / Hour or Cooldown (minutes) empty means no limit rather than zero. The table shows the stored code for trigger type and severity — CONNECTOR_EVENT, CRITICAL — while the dialog dropdowns show the readable label.
• If a rule never fires, work backwards: check it is Enabled, that its Source Types match what the connector sends, and that the connector is delivering at all. Then test it with a real event.
• This page manages rules, not incidents. What a rule creates is triaged and closed in Incidents; rule changes and test runs are recorded in the Audit Log.

Where this connects

• Incidents — where the incidents these rules open are tracked, assessed and closed.
• Connectors — the sources whose events the rules match against.
• Workflows — automating what happens once an incident exists.
• Incident Reporting — regulator deadlines for qualifying incidents.