What a CyberSentry alert page shows, and what you can do on it
Read why an alert fired factor by factor, see what a live response would have done to the account, ask Elise for her read, resolve it, unlock the account or send it back to the queue, and test a change in a simulator without saving one.
The alert, and where it stands
The chain of signals that fired, written out in one line, with its severity and status beside it. When Elise has cleared or escalated the alert, a verdict badge (Cleared by Elise or Needs human review) joins them. A three-dot menu holds Resolve, which asks for a resolution reason. When CyberSentry locked the account, an Account locked badge shows, and an Unlock account button appears for staff who can edit CyberSentry. Resolve needs the same edit access.
The facts
The client, the user, the rule that fired, when it was detected and last seen, and the confidence score. An Occurrences line appears once the same alert has recurred, and a Ticket line with a link appears when the alert has a ticket.
Elise Triage
Elise's own read of the alert, with Re-run Elise triage beside it. When she has not read the alert yet, the card says Not yet triaged. When Elise cleared the alert as noise, Return to queue appears next to it.
Confidence breakdown, and the band it reached
Every factor that contributed to the score, in contribution order, with its weight. Positive weights push toward containment and negative ones, called dampeners, push away. The highlighted row, marked Margin, is the smallest factor whose removal alone would have dropped the score below its band. The last line names the band the score reached.
Browse
On this page
What a live response would have done, and the levers for asking what if
Armed-path verdict
When the reached band can contain an account, this card answers one question: if this org had been armed Live when this alert arrived, would it have locked the account. It is worked out once, when the alert is recorded, and only read back here, so opening the page never runs it again. It applies the same guards a live run would: the blast-radius cap (too many accounts already acted on in the rolling hour), the systemic-cohort guard (one shared signal across several accounts reads as one legitimate mass event), the containment floor (evidence that is behavioral-only or not corroborated alerts a person instead of locking), and the band Live auto-containment is armed for. When one of them holds the alert back, a line under the verdict says which. An alert recorded before this existed says the verdict is not available rather than guessing one.
The levers
One row for each factor that pushed the score up. The checkbox, labelled Approve / exclude, takes the factor's weight out of the sum, and the box on the right holds a different weight to try instead of the real one.
The band threshold
Moves the reached band's own threshold, for the simulation only. Apply runs it and Reset puts it back.
Current and Simulated
The band and score today's settings give this alert, next to the simulated pair, with a sentence naming the move. With no lever touched the two match, and the line underneath says the combination still reaches the original band. When a lever drops the band, the line says roughly how many more points it would take to climb back.
Why it works this way: What a CyberSentry alert page shows, and what you can do on it
Nothing in the What-if simulator is saved. To make a weight or a threshold permanent, open CyberSentry, then Response Rules, then the Confidence Engine, and edit its Auto Response Thresholds there.
The verdict and the score answer different questions. The score says how sure the engine is. The verdict says what a live response would actually have done to the account, guards and all.
Ask Elise for her read from the chat, for example "Assess this alert and tell me the next step." Elise writes the plain-English read onto the alert and does not change its severity or status. She can also triage it: "Triage this alert again." Triage can clear benign noise from the human queue, and Return to queue undoes that.
Elise's read never opens a ticket or sends a notification. Her triage sends no notification either, and it opens a ticket only when its verdict on an open alert is escalate, one ticket per alert. Otherwise a ticket comes from an armed Response Rule or from the Confidence Engine promoted to Live. The one button on this page that asks for a ticket is Return to queue, which appears when Elise cleared the alert: it pulls the alert back for a person and asks for a ticket in the same step, adding it to the account's open incident ticket if there is one.
Unlock account turns Microsoft 365 sign-in back on for that one account. Sessions that were revoked stay revoked, so the person signs in again.
Below the cards, Note history lists who did what and when, in order. Evidence holds the raw signals behind the alert and starts folded. When the alert carries a source address, an IP details panel shows what is known about it.
Questions this page answers
What does "Armed-path verdict" mean?
The honest answer to "if this org had been armed Live when this alert arrived, would this specific alert actually have locked the account?" It is worked out once, when the alert is recorded, and only read back here - opening this page never re-runs it. It reflects the SAME blast-radius cap and systemic-cohort guards a real Live execution would apply - so a firing that looks severe can still show "would not lock" if, say, too many accounts had already triggered the same guard that hour, or a shared signal across several accounts read as one legitimate mass event across the organization rather than a single-account incident. Alerts recorded before this feature shipped show "not available" rather than a guessed value.
Was this helpful?