Agreeing, disagreeing and escalating

Every Sentinel-Q decision carries a control for recording what you think of it. There are three options, they do different things, and one of them changes how future alerts on the same rule are triaged for your organisation.

The screen opens with a standing statement, shown on every decision without exception:

That is a statement of the intended relationship. The platform's job is to do the gathering, the correlating and the drafting; yours is to rule on it. Recording your ruling is not paperwork — it is the only mechanism by which the platform learns what your organisation considers normal.

The three options

They appear as three small buttons in an Override panel on the decision, labelled in lower case exactly as written below — accept, reject, escalate — with a reason box above them. The effect column is what each one records.

All three write to the same endpoint, which is shown on the decision itself so an integration or a script can do the same thing a person can:

POST /api/v1/organizations/{organization_id}/xdr/sentinel-q/decisions/{decision_id}/override

Once a decision has been overridden, the Override panel is replaced by a single pill showing which way you ruled, and the buttons do not come back — one ruling per decision, from this screen. The full record underneath it is richer than the pill: who ruled, when, which action and the reason they gave are all stored and are what an auditor is shown. If you need to see that record rather than the pill, read the decision through the API or ask us; the console does not surface it yet.

Why rejecting is the most valuable option

Rejection is the one option that changes future behaviour. Future triage of that rule reads your rejection as this tenant's ground truth — not as a vote, and not as feedback to be averaged with other customers' opinions. You are the authority on what is normal in your own business, and the platform treats you that way.

This is why the accuracy figures the product publishes about itself are meaningful. A decision's disposition says what the platform concluded; your rejection says what was actually true. Without the second half, "how often is it right?" is unanswerable, and every vendor claim in this category is unfalsifiable.

What rejection does not do is suppress the detection. A rejected decision does not silence the rule, and this is deliberate: false-positive suppression is always a human-approved change, it is versioned, and it expires. Permanent suppression manufactures blind spots, which is precisely what an attacker wants. If a rule genuinely needs quietening for your environment, that is a separate, expiring change with your name on it — see Shadow detections and why some rules stay quiet.

Escalating, and what a good handoff looks like

Escalation runs in both directions. The platform escalates to you when it cannot resolve something; you escalate onward when you cannot either. In both cases the useful part is the same field.

When the platform hands off, it records four things: a reason from a closed vocabulary, a detail sentence naming the actual numbers involved, a needs-human flag, and what would resolve it. That last field is the single most useful thing in a handoff, and the one a confidence score cannot carry. "Confidence 0.48" tells you the platform is unsure. "Check whether this account has signed in from this country in a normal week" tells you what to do next.

The investigate option exists so that field is not buried. Selecting it restates the reason and the resolution step in one line, and keeps the decision open while you work.

Some escalation reasons are worth recognising on sight because they change what you should do:

• grounding_failed — the platform could not substantiate its own findings. Go to the raw alert; do not read the narrative as evidence. See Why a confident answer can still be refused.
• insufficient_telemetry — the data needed to decide does not exist. A sensor was offline, a window was empty, a principal was unknown. Not resolvable by the platform trying harder.
• novel_pattern — no baseline and no precedent: a new host, a rule that has never fired here, nothing comparable in your history. This is the genuinely non-automatable share of the work, and it is where your judgement is doing something software cannot.
• prompt_injection_in_telemetry — the ingested logs contained text aimed at steering the verdict. The decision cannot auto-close or auto-execute and lands in front of a person with the payload quoted. Text in a log line asserting that an alert is benign or already reviewed was written by whoever generated the activity; on a real intrusion that is the attacker, and the attempt is itself evidence.
• policy_prohibits_action — the assessment supports acting and your tier does not permit it. Not a limitation to route around; it is your organisation's stated posture, and the fix is a deliberate decision about the tier.

Undoing something that already happened

When a decision was executed autonomously, the override control sits next to the reversal path rather than replacing it. Recording that you disagree is not the same as putting the world back, and the interface does not let the two be confused.

Every action records an undo handle at the moment it is taken, by the code that takes it, into a hash-chained audit row. Reconstructing a reversal afterwards from logs is what most products mean by reversible; this is not that. The handle carries:

Kind

The reversal operation. Examples in production: cancel_ticket, lift_isolation, restore_quarantined_file.

Ticket id and sensor id

The live-response ticket to cancel or counter, and the machine involved. Live-response tickets default to pending_approval, so a ticket existing is not the same as a command having run.

Command and parameters

The concrete counter-command a sensor would execute to reverse the action, with its arguments.

Instructions

The reversal path in plain language, shown next to the override control so you are never guessing. For a quarantined file: the original bytes are preserved in the sensor's quarantine vault under their SHA-256 manifest, and are restored from there.

Expires at

When reversal stops being possible — quarantine retention, for instance. Empty means no known expiry. Worth reading before you decide to think about it tomorrow.

Two honest limits. A killed process cannot be un-killed: what is reversible is the ticket, if the sensor has not yet collected it, and the instructions say exactly that rather than implying a rollback that does not exist. And an action class with no known reversal produces no handle at all — which is why such actions are never taken autonomously in the first place. The full mechanics are in Undo a change.

What the audit trail records

Every event on a decision is appended to a hash-chained log: the decision being recorded, an action being proposed, executed or reversed, a human override, a tier block, and a grounding rejection. Each row's hash covers the previous row's hash plus this row's content, so editing or deleting an intermediate row breaks the chain and verification reports the exact sequence number where it broke.

One detail matters more than it looks. The actor kind distinguishes human, ai and system. A deterministic auto-approval and a model inference must not share an identity in an audit trail, because "who decided this" is the first question any oversight review asks and "the platform" is not an answer. Your override is written as a human actor, with your identity attached.

This chain is what an evidence export draws on. See The evidence bundle for what an auditor receives.

In practice

1. Read the limitations block before you accept. It states, on every decision, that the assessment rests only on telemetry the platform holds for your organisation, and that absence of evidence is not evidence of absence. A clean decision means nothing was found in what was looked at.
2. Reject with a reason rather than leaving it open. An open decision helps nobody. A rejection with two words of context improves the next hundred.
3. Escalate rather than guessing. Escalation keeps the decision open, which is the correct state for something nobody has actually ruled on.
4. Check the undo handle's expiry on anything that was executed, before you decide it can wait.
5. Do not accept in bulk. Recording agreement with decisions you have not read pollutes the one dataset that tells you whether the platform is working.

If you are not sure what to do with an alert in front of you, What to do when an alert arrives is the shorter, more practical companion to this article.