Response Rules and the Confidence Engine at a glance
The two doors that can act on a security finding on their own: a response rule you arm, and the always-on Confidence Engine that scores every finding and maps that score to a set of actions.
What this page is
Response Rules is CyberSentry's IF/THEN layer. When a sequence of things happens in order for one user, the rule runs a set of effects: lock the account, revoke sessions, open a ticket, notify. The line also states the default, which is that a new rule starts in Monitor mode and only records.
The Confidence Engine row
The engine sits at the top of the list as a row of its own, with its arming state beside its name. It reads Monitor here. The toggle on the right only moves the engine between off and Monitor; Live is a separate, deliberate step on the engine's own page. Clicking the row opens that page.
Source filter
Rules are grouped by the signal source they reason over. Identity (M365) is the only source today, so All sources and Identity (M365) show the same list.
The rules themselves
The table, and the one rule switched on
Every rule shows its Name, Source, Sequence, Mode, Status, Scope and Priority. Mode and Status are two different things: Status says whether the rule evaluates at all, Mode says whether a match acts or is only recorded. The top row here is Enabled and still in Monitor, and it is scoped to one client rather than to all of them.
A shipped rule still switched off
The rules that ship with CyberSentry arrive Disabled. This one chains two ordered steps, so its Sequence column reads Multi-stage. Nothing about it runs until someone enables it.
Inside one rule: state and triggers
Disabled, Monitor, Live
Three states, picked at the top of the rule. Disabled is off entirely, and the line under the buttons says so. Monitor evaluates every match and records what the rule would have done. Live is the only state that acts. This rule is Disabled, and its own description says it ships inert and should be armed only after review.
Triggers
The when half of the rule. The steps must happen in order, for the same user, inside the match window. Step 1 matches all of its conditions, a successful sign-in from an unexpected country. Step 2 matches any one of four follow-on events: an inbox rule created, an MFA method changed, an OAuth app consent, an admin role granted.
Inside one rule: actions
Actions
The then half, run top to bottom. This rule would revoke sessions, lock the account, open a ticket and notify. Open ticket carries its own Ticket board field, left on the CyberSentry default here, and Notify carries a notification tier. The bundles underneath add several actions at once, and Stop if an action fails halts the rest on the first failure, so a rule never reports containment when only half of it ran.
Inside one rule: settings, safety and a dry run
Match window and priority
The match window is how far apart the trigger steps may be and still count as one sequence, so it only matters once a rule has more than one step. Priority decides which rule runs first when several match the same event, lower numbers first.
Scope and the blast radius cap
Applies to is either All clients or Manual, and Manual reveals a client picker. The auto-action cap beside it is the most distinct accounts one rule may act on in a rolling hour, so a misfiring rule cannot lock out a whole client at once. Left empty the field reads Unlimited, which is what this rule shows.
The guards
Stop processing further rules on match makes a firing rule skip lower-priority rules for that same account. Never act on break-glass / service accounts keeps a rule away from a client's designated emergency-admin accounts. Never act on our own (MSP) access keeps it off your own team's logins into the client. The last two are on by default, and none of them does anything until the rule is Live.
Recent activity
A rule's own ledger. In Monitor mode every match lands here with what the rule would have done. This rule is Disabled, so it records nothing and the card says so.
Test against history
A dry run of the rule over one client's recent activity, to preview its blast radius before it is enabled. Pick a client and a window, then Run test. Nothing is locked, revoked or notified by a test.
The Confidence Engine
Arming
The engine's own page, opened from the row on Response Rules. The badge beside its name is the arming state, Monitor here, and Promote to Live is the deliberate second step that lets the bands act for real. When it is Live the same button becomes Return to Monitor.
Auto Response Thresholds
The glass box: how a signal becomes a confidence percentage, and what that percentage fires. The same arithmetic is printed on every alert that the engine scored.
Confidence bands
A band is a threshold plus a set of actions: at this confidence or above, fire these. Bands are evaluated highest-first, so the strongest band an alert reaches is the one that wins. Each band lists what it fires as chips, and can require corroboration, a second independent signal, before it acts. The two upper bands here require it and the lowest one does not. Enabled turns a band off without deleting it.
What adds up to the score
Location and network factors
Each piece of evidence carries a weight, and the weights of everything observed for one event add up to the confidence percentage. The Strong pill marks the factors meant to move the needle hard on their own. A trusted corporate address carries a negative weight in the same group, so it pulls the score down instead.
Token and session factors
The same shape on the token side. A correct password followed by a denied MFA challenge is marked Strong; a non-interactive redemption from a new network, and no matching interactive login behind it, each add less on their own. Every weight is editable, and the Enabled box turns a factor off without deleting it.
Dampeners, and what the engine would have done
Dampeners
Negative weights are evidence against. A known travel exception on file, a network this user or this organization signs in from regularly, and a satisfied MFA challenge all subtract. Amplifiers sit in the same group and add: a sensitive app or resource, a privileged account.
Would-Have-Fired Observations
While the engine is in Monitor, every evaluation still records the band it would have hit. The table groups those by band over the last 7, 30 or 90 days, with the number of distinct accounts behind each one and the confidence range that produced it. This is the evidence to read before promoting anything to Live.
How one alert reads back to these pages
The alert, and what its badges say
An alert that CyberSentry's triage pass escalated. The badges beside the title are its severity, its status, and the triage verdict, which reads Needs human review. Escalating keeps the alert in the queue and in the staff digest. It is not the same as ticketing or notifying.
The facts, and the line that is not there
Client, user, which detector raised it, when it was first and last seen, how many times it recurred, and its confidence. A ticket reference would sit in this same list if one had been opened. There is none here, because neither door has fired: every rule on this instance is in Monitor, and so is the Confidence Engine.
Why it works this way
The triage pass never opens a ticket and never sends a notification, for any alert. It clears noise, annotates, and raises the alert for a human, for Response Rules and for the Confidence Engine to read. The triage module says so in as many words.
That leaves exactly two doors that can page a person on their own: a response rule armed past Monitor that carries an Open ticket or Notify action, and the Confidence Engine promoted to Live, whose bands carry the same action keys.
So a fresh or lightly-armed instance opens no tickets and sends no real-time push at all. That is the intended default rather than a gap, and the alert is never hidden either way: it stays on the Alerts list, on its own detail page, and in the periodic Cleared-by-Elise digest, notified or not.
Monitor is not a half-armed Live. A rule in Monitor evaluates every match and writes what it would have done into its own Recent activity; the engine in Monitor writes the band it would have hit into Would-Have-Fired Observations. Nothing is locked, revoked, ticketed or notified from either.
A band's actions and a rule's actions are the same set of effects written two ways. A rule lists them in order in its own Actions card; a band names them as chips beside a confidence threshold.
Editing a band changes what happens at that confidence level across the whole instance, because the engine is instance-wide. Response rules are the scoped half: All clients, or a picked list. The shipped band defaults are deliberately conservative, and an instance that has never edited them says so on this page instead of rendering an empty box.
Questions this page answers
How does the confidence score work (Factor Weights)?
Each piece of evidence - impossible travel, a token replayed, a suspicious OAuth consent, an MFA change, and so on - carries a weight. The weights of everything observed for one event add up to the confidence %. "Strong" factors move the needle hard; negative weights are dampeners (evidence AGAINST, e.g. a familiar device). Every alert shows its own math, so you can see exactly which signals produced its score and tune the weight of any factor.
What are Confidence Bands?
A band maps a confidence threshold to a set of actions: "at ≥ X% confidence, fire these." Bands are evaluated highest-first, so the strongest band that an alert reaches wins. Each band lists the actions it fires (raise alert, notify, open ticket, revoke sessions, lock account, …) and can require corroboration - a second independent signal - before it acts. Editing a band changes what the whole fleet does at that confidence level; the seeded defaults are conservative.
Why wasn't I notified about this alert?
The same rule as tickets applies to real-time notifications (bell + email): Elise's triage pass never sends one, for any alert, on its own initiative - it clears noise, annotates, and raises the alert, full stop. A notification comes from exactly one of the same two places a ticket does. First, an operator-armed Response Rule with the "Notify" action (CyberSentry → Response Rules). Second, the AUTO confidence-band engine promoted to Live (CyberSentry → Response Rules → Confidence Engine) - a band's own actions decide whether it notifies. A fresh or lightly-armed instance - including one whose confidence engine is still sitting in Monitor - sends no real-time push at all until you arm one of these two doors. The alert itself is never hidden either way: it stays visible on the Alerts list, this detail page, and the periodic Cleared-by-Elise digest, notified or not.
Was this helpful?