Write the rule once. It runs on every client.
Conditions over seven subjects, from devices and Microsoft 365 to certificates and firewalls, decide when a risk is raised. Seventeen triggers on risks, investigations, patches, devices and Microsoft 365 drive actions in four tiers. Thirty-three starter rules install ready to run, and everything you build runs report-only until you say otherwise.
- Starting mode
- Report-only
- Report-only history for tier 2
- 14 days
- Fleet ceiling per rule
- 25%
Rules raise the risk. Automations act on it.
Both read the same conditions and return the same evidence, because the automation engine reuses the rule evaluator rather than growing a second one. What separates them is what happens when the condition holds.
Custom risk rules
Evaluate inventory and posture on a schedule. When the conditions hold, a risk is raised carrying the evidence that raised it. Raising a risk is the only thing a rule does, and that is deliberate: everything else lives in the automation engine rather than in a second evaluator.
Automations
Wait on a domain event rather than a clock. When one arrives, the same conditions run against the entity behind it, and anything from a notification to an isolation can follow. Seventeen triggers today, across risks, investigations, patches, devices enrolling, going offline and coming back, and Microsoft 365 findings, posture drift and account takeover.
One condition language
Seven subjects, twenty-one operators, nested AND and OR groups, the same three-valued logic in both places. Learn it in the rule builder and you already know the automation builder.
Anything the platform can see, a rule can test.
The check engine began device-only and is now general. Each subject exposes a catalogued field list, so the builder can only offer a field the evaluator is actually able to read. A path that does not resolve returns undeterminable with a message rather than silently matching nothing.
- Device fields limited to what the agent actually reports: installed software, open ports, running processes, local users and groups, startup items, scheduled tasks, services, kernel drivers, Defender exclusions, firewall rules, root certificates, patch counts and exposure tier
- Twenty-one operators with nested AND and OR groups, including any, none and all matches against a list. Several checks can be required to hold on the same item, so "a service running as SYSTEM from a user-writable path" never matches two different services
- Three-valued logic throughout. Missing data is not a passing check, and a rule abstains where it cannot see
- A subject whose data is older than the rule's freshness limit is skipped as undeterminable rather than judged on old data, and a rule's health reads degraded when any condition could not be determined
- Every evaluation returns the predicate that ran and the value it actually read, so a risk arrives with its own evidence attached
- Rules carry a version that increments on edit, and every evaluation records the version it ran under
- Preview the impact with a dry run before the rule goes live, then scope it to one client or across the portfolio
- Escalate to a higher severity when a rule-raised risk stays open past a threshold you set
- Map a rule to framework controls and it renders as coverage on the compliance report
- Sixty presets to start from: 41 for devices, 6 for the Microsoft 365 tenant, 5 for Microsoft 365 users, 3 for Microsoft 365 applications, 2 for Microsoft 365 findings and 3 for certificates. Each starts report-only with editable thresholds, and the Microsoft 365 presets carry their framework references
Trigger, condition, action.
An automation waits on something happening rather than on a schedule. Only events that carry an entity the engine can load are offered as triggers, because a condition has to be able to read the thing it is judging.
- Conditions evaluate the entity fetched fresh at the moment the rule runs, never the display text carried in the event. An event is a pointer to truth, not truth itself
- Each trigger exposes its own field catalogue, so the builder offers only what that entity actually carries
- Thirty-three starter rules install through the same path as a rule you build by hand, so scoping, audit and report-only apply identically
- A third mode between watching and acting: in approve mode ("asks first") a match holds its planned actions and notifies the client's admins, and a person runs it with one tap from the Approvals page, the header or the banner on the case. The actions are fixed at match time, requests expire after four hours, and approval removes the wait, never a guard: kill switches, a fresh read of the entity and the tenancy check still apply
- A rule can wait before checking, so "still untriaged after 24 hours" is one rule. Rules on investigations can match the subject account, so a containment rule can leave break-glass accounts alone. Every saved version is kept and can be restored
- Client scope is stated on every rule rather than inherited from whatever page you happened to be on
- The rule list reads as a table or as a flow, and the builder shows the rule back to you in plain English with a dry run before you commit it
Every action, sorted by what it costs when the rule is wrong.
Picking an action from a dropdown is not consent to run it. Anything past a notification needs an explicit opt-in on the rule, and the two tiers that are hard to walk back need considerably more than that.
Two actions from the original specification were deliberately not built: terminating a process and quarantining a file. Both are parameterised on a process id or a file path, and no trigger entity carries either under contract, so the value would have to come from hours-old free-form evidence. A recycled process id points at an innocent process. Where killing something at the moment of detection is worth doing, the agent's own local rule engine already does it, in milliseconds rather than minutes.
Built on the assumption that a rule will eventually be wrong.
Every guard below exists to bound what a wrong rule costs. All of them are on by default.
Report-only is the default, and it is not skippable
A new rule starts in report-only and cannot be created any other way. Moving it to approve or enforce is a separate, explicit, audited act, and a meaningful edit demotes an enforcing rule. The report-only log is what makes the case for promoting a rule, which is the point.
Every evaluation is written down
Matched or not, enforcing or report-only, with the mode at the time, the predicates that ran, the values read, the status of each action and any guard that suppressed it. An automation that has quietly stopped working looks exactly like one with nothing to do, unless the non-matches are records too.
Ceilings on reach
Twenty-five entities per run, twenty runs per hour by default, at most five actions per rule, and never more than a quarter of the fleet: past that the rule halts and raises instead. A behavioural containment rule stops at five percent. A rule cannot work through an estate faster than a person can notice it going wrong.
Stale data does not act
Events older than forty-eight hours are ignored, and conditions read the entity fresh at the moment the rule runs. Acting on a reading from last week is how an automation isolates a machine that was fixed on Tuesday. Maintenance windows govern patching only: containment does not wait for one.
A kill switch, global and per client
Stop every automation across the platform, or stop them for one client, without editing or deleting a single rule. The rules stay exactly as they were for when you want them back.
It cannot loop
Events caused by an automation action carry their cause, so a rule triggered by its own action is recorded as a loop and stopped, and a cause chain ends at three steps. Tier-2 and tier-3 rules cannot use a cooldown, so a second containment is never skipped.
Thirty-three rules you can install today.
The library ships as content rather than as a feature that has to be maintained separately.
The identity rules ticket every external forwarding rule, sign out a user Identity Protection marks at risk, ticket every critical Microsoft 365 finding, notify on privileged access changes and ticket when tenant protection is weakened. Two respond to a corroborated account takeover: one contains the account and raises a critical ticket, and installs in approve mode; the other signs the user out and switches off external forwarding, and installs report-only, earning enforce like any tier-2 rule. Installing a library rule runs the same create path as a rule you build by hand, so report-only, audit and client scoping apply identically. Templates that reach the higher tiers ship with their opt-in set and their promotion gates untouched. Every entry is checked at build time against the same validation a hand-built rule faces, so a stale template fails the build rather than failing on your estate.
The things worth asking first.
What is the difference between a custom risk rule and an automation?
A rule runs on a schedule and its only outcome is raising a risk with the evidence behind it. An automation waits on an event, evaluates the same kind of conditions against the entity, and can then notify, ticket, assign, tag, add to a watchlist, open an investigation or an incident, change a severity, approve or schedule a patch, sync a device, run a YARA sweep, isolate a device or apply a lateral quarantine and release either, reboot inside the window, revoke a Microsoft 365 user's sessions or disable or contain the account, or accept, close or snooze a risk. They share one evaluator, so a condition means the same thing in both.
Will an automation ever act without us knowing?
No. A rule cannot be created in enforcing mode. It starts in report-only, where it evaluates and records but changes nothing, and promoting it is a separate audited act with a named person behind it. In approve mode nothing runs until a person taps approve. Once enforcing, every execution is still recorded, including the ones that matched nothing, so you can tell the difference between a rule with nothing to do and a rule that has broken.
Can an automation kill a process or quarantine a file?
No, and that is a decision rather than a gap. Both actions need a process id or a file path, and no trigger entity carries either under contract, so the value would come from free-form evidence that may be hours old. A recycled process id points at an innocent process, and quarantining the wrong file on a client's server is not something you undo with an apology. Killing at the moment of detection already exists where the latency makes it meaningful: in the agent's own local rule engine, in milliseconds.
How does this work across a portfolio of clients?
Every rule states its scope explicitly, either one client or the whole portfolio, so a rule written once covers every estate you manage without being copied per tenant. The kill switch works at both levels too: you can stop automation for a single client who is mid-migration without touching anything else.
What happens when a rule turns out to be wrong?
The ceilings decide how much it costs. At most twenty-five entities in one run, twenty runs an hour, and never more than a quarter of the fleet, so the damage is bounded before anyone has noticed. Flip the kill switch and everything stops without deleting a rule. The execution log then tells you exactly which entities were touched, which predicate matched, and what value it read at the time.
Bring us a rule you keep applying by hand.
The fastest way to judge an automation engine is to watch it run report-only against something real. We will build the rule with you and read the execution log together.