A client's security settings, and one alert up close
The Security tab on a client record tells CyberSentry how that client's people normally work, and an alert's own page shows the score behind it, what a live response would have done, and a simulator for trying a change without saving one.
CyberSentry - this client
The card holding everything CyberSentry knows about this one client. The badge on the right says how much of the sign-in feed this client's Microsoft licensing allows: Full coverage, or No P1.
What is being watched
Token-theft detection is active means session-fork and token-replay analysis is running on this client's sign-in logs. Without Microsoft Entra ID P1 the card says that detection is off instead, and names what still runs on the free directory audit feed.
Risk posture and context notes
Risk posture is Inherit MSP default, Standard, Strict or Paranoid. Context notes for this client is free text about how this client works, which Elise reads when it triages.
Allowed countries and Allowed IP ranges
Countries as two-letter codes, one per line, and this client's known office or VPN ranges in CIDR, one per line. Neither is required. Left blank, as they are here, CyberSentry falls back to what it learns on its own, which is the table further down the card.
Workforce profile
How much this client's staff normally move around. The picker holds Office: works from known locations, Hybrid: some remote/travel is normal (default), and Field: travels constantly for work, and the line underneath explains the one you picked. It changes how loudly ordinary travel reads, never whether a real threat is detected, and it never opens or closes a ticket by itself.
Travel exceptions, and the networks the system learned by itself
Travel exceptions
A time-boxed exception for one person you know is travelling, added under User (UPN). Countries is optional and scopes it, Until sets the end date, Note is for your own team, and Add puts it on the list. The amber line warns you when Countries is left blank, because that dampens sign-ins from any country for that person.
Learned shared-egress networks
Read-only. The networks this client's own people keep signing in from, with how many distinct people used each one, how many days it has been seen, when it was first and last seen, and whether it is Trusted yet or still Learning.
Saving, and this client's own alerts
Save
Nothing you change on this card takes effect until you press Save.
This client's alerts
Under the card sits the same alert queue the CyberSentry Triage page shows, pinned to this client: severity, status, Elise's verdict, the alert itself, the rule that fired and when it was detected. A Cleared by Elise list sits below it, and clicking a row opens that alert's own page.
One alert: what fired, and the score behind it
The alert, and where it stands
The chain of signals that fired, the severity, and the status. The menu on the right holds Resolve for someone with edit access, and it disappears once the alert is resolved.
The facts
The client, the account, the rule that fired, when it was first detected and last seen, how many times the same thing has recurred, and the score. A Ticket line only appears here when this alert actually has a ticket.
Elise Triage
Elise's own read of the alert, with Re-run Elise triage beside it. An alert the confidence engine scored but Elise has not read says Not yet triaged, as this one does.
Confidence breakdown
Every factor that contributed to the score, in contribution order, with its weight. Positive weights push toward containment and negative ones push away, such as a network this client's own workforce regularly signs in from at minus 15. The highlighted row carries the Margin badge: the smallest factor pushing the score up whose removal alone would drop this alert below its band under today's weights. Reached band, at the bottom, names that band and the score.
What a live response would have done, and the levers for asking what if
Armed-path verdict
Whether this alert would lock the account if this client were armed Live right now. It was decided by the same blast-radius and systemic-cohort guard code a live run uses, at the moment the alert was scored, and it names the first guard that held it back. Other guards may also have applied. Here the guard was a shared signal across several accounts reading as one legitimate mass event. An alert recorded before this feature shipped says the adjustment is not available rather than guessing.
What-if simulator
A read-only counterfactual on the same numbers. It never touches the alert, never calls the AI, and saves nothing. As scored, above the levers, is the alert's own stored result and never moves while you play.
The levers
One row for each factor that pushed the score up. The checkbox approves the factor and takes it out of the sum, and the box on the right holds a different weight to try instead of the real one.
Moving the band, and reading the result
The band threshold
Moves the reached band's own threshold for the simulation only, and Apply runs it. A Reset button appears once a threshold is in play.
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 levers touched they match, and the line says the combination still reaches the original band.
Approving one factor, and the headroom that leaves
A factor approved
The approved row dims, its weight comes out of the sum, and the simulation reruns on its own.
What that would have meant
The simulated side falls from Contain: revoke sessions + lock at 90 percent to Notify / raise alert at 50 percent, and the last line gives the headroom: about 40 more points before it would climb back to the band today's settings give it. The two more actions is the loosest case, the points divided by the weakest factor, not a prediction.
Why it works this way
Nothing in the What-if simulator is ever saved. To make a weight or a band threshold permanent, open the Confidence Engine from CyberSentry then Response Rules and edit its Auto Response Thresholds. That is the only place a weight or a threshold is actually stored.
A travel exception never dampens a hard indicator. A banned country, a known attacker address, Tor or an anonymous proxy still flags however the exception is scoped, and an exception is meant for someone you trust to be where they say they are.
The learned network table is the automatic version of the allowed IP list. A network only becomes Trusted once enough distinct people at the client have used it across enough distinct days, and it never overrides a genuinely suspicious sign-in.
This tab only appears on a client whose Microsoft 365 is connected, because everything on it reads that client's own sign-in data.
The workforce profile, the allowed lists and the exceptions all change how loudly ordinary travel reads. None of them decides whether a ticket opens: that is decided by an armed response rule or by the confidence engine's own bands.
Questions this page answers
What does Workforce profile do?
Tells CyberSentry how much this client's staff normally move around, so it can judge new-network and new-device sign-ins accordingly. Office means staff work from known locations - an unfamiliar network or device is treated exactly as suspicious as it looks today, no change. Hybrid (the default) expects some remote work and travel is normal - when the sign-in data confirms MFA was satisfied, that can mildly soften an otherwise-corroborated alert, but it never eliminates one on its own; a genuinely dangerous sign-in still surfaces. Field means staff travel constantly for work - a sign-in from a new, in-country network or device with no other unfamiliar signal shows as a low-priority alert instead of going undetected. Pick the profile that matches how this client's team actually works - it changes how loudly ordinary travel reads, never whether a real threat is detected, and it never opens or blocks a ticket by itself (see "Why didn't this alert open a ticket?" on the alert page for where tickets actually come from).
What do Allowed countries and Allowed IP ranges do?
Tell CyberSentry where this client's legitimate sign-ins normally come from. Allowed countries lists the countries this client's staff sign in from as part of normal business - sign-ins from a listed country read as familiar; sign-ins from anywhere else still get evaluated, they just don't get the benefit of a known location. Allowed IP ranges lists this client's known office or VPN network ranges (CIDR notation) - a sign-in from one of these ranges is recognized immediately, without waiting for the platform to learn it the slow way. Neither field is required; leave them blank and CyberSentry falls back to what it learns automatically over time (the read-only egress ledger below shows what it has picked up on its own). Filling them in for a client with a lot of remote or travelling staff is one of the fastest ways to quiet first-week noise.
What is the Confidence Breakdown card?
The glass box for this one alert - every factor that contributed to its score, in contribution order, with each factor's weight. Positive weights push toward containment; negative weights (dampeners like a known device or trusted IP) push away. The highlighted row is the MARGIN factor - the smallest contributor whose removal alone would have dropped this alert below the band it reached.
What is the What-if simulator, and what can I do with it?
A read-only counterfactual on the transparent band math above, it never touches this alert, never calls the AI judge, and never saves anything. Try excluding a factor (e.g. "approve this IP/network"), typing a different weight for a factor, or moving the reached band's own threshold, and watch the simulated score/band update. It also tells you the headroom, roughly how many more signals it would take to climb back to the original band. To make a change PERMANENT (not just simulated for this one alert), open the Confidence Engine from CyberSentry → Response Rules and edit its Auto Response Thresholds, that's the only place a weight or band threshold is actually saved.
How do travel exceptions work?
A travel exception is a time-boxed dampener for one specific person (by UPN) who you know is travelling - it softens location/network/device signals for that person, it does not add them to a bypass list. Countries is optional: scope it to the countries this person is actually visiting, or leave it blank to dampen sign-ins from anywhere (a broad grant - the form warns you when you do this, so scope it whenever you can). Every exception needs an end date, or you can leave it Permanent - the badge for that just reads "Permanent", and the form reminds you to set an end date instead, since an open-ended exception is easy to forget about long after the trip is over. Important: a genuine hard indicator (banned country, known-attacker IP, Tor, anonymous proxy) is NEVER dampened by an exception, no matter how it's scoped. But combined with other legitimate signals available on that sign-in, an active exception CAN suppress an alert for that person entirely, not just soften it. That is deliberate: you are vouching for this person's travel, so use it only for someone you actually trust to be where they say they are, and remove it once they're back.
Was this helpful?