Stopping autonomous response

There is one switch that decides whether Sentinel-Q may act on its own at all, anywhere in your organisation. It is called Autonomous response, it lives on Govern → Autonomy policy (/policy/autonomy), and it has two buttons: Stop autonomous response and Resume autonomous response.

It exists so that the answer to what is this thing about to do to my machines while nobody is watching? can be nothing, immediately, decided by you. You do not need to open a support ticket, wait for us to act, or unpick per-rule settings one at a time under time pressure. During an active incident — or on any day when you would simply rather a person looked first — one button takes every automatic containment out of the platform's hands and puts it back into the approval queue.

This switch sits underneath the per-rule autonomy tiers described in Autonomy tiers: observe, recommend, act. The two combine in the obvious direction: a rule set to act without asking only acts if this switch is also running. Stopping the switch does not change any rule's setting; it withdraws the permission those settings depend on.

Where it is, and what it says

Go to Govern → Autonomy policy in the console. The panel you want is headed Autonomous response, under the small label Stop button. It carries the current state, a reason field, the button, and this description — worth reading in full, because it is the whole feature in two sentences:

The state is shown as a pill with one of three values. Two of them mean the same thing in practice, and that is deliberate.

This screen is the only place the state is shown. It does not appear on a dashboard, in a banner, on the alerts list, or anywhere else in the console. If you want to know whether autonomy is currently on, you have to come here and look.

Stopping it

1. 1

   Give a reason — this is compulsory, and it comes first

   The field is labelled Why are you changing this?, with the help text Required. The reason is written to the audit trail with your name and the time. A blank reason is not a warning you can click past: the change is refused with A reason is required before the switch can be changed. Write something a colleague reading it in three months would understand — suspected intrusion on the finance server, want eyes on every action is useful; test is not.

2. 2

   Press Stop autonomous response

   The button is styled as a destructive action rather than an ordinary one, which is a fair description of what it does to the platform's ability to defend you unattended. A confirmation appears.

3. 3

   Read the confirmation

   It is headed Stop autonomous response now? and states exactly what you are about to do: Sentinel-Q stops acting on its own for this organisation immediately. Every containment it would have run waits in the approval queue instead. Detections and tickets continue. You can resume at any time.

4. 4

   Confirm with Stop now

   The confirm button is labelled Stop now, not OK. It takes effect immediately: there is nothing to propagate and nothing to restart.

5. 5

   Check that it took

   You should see Autonomous response is stopped. The decision is in the audit trail. The pill changes to Stopped, and a row appears in Recent policy changes on the same page.

Resuming it

Resume autonomous response works the same way and asks for the same things. The confirmation is headed Resume autonomous response? and reads: Sentinel-Q may again act without asking, within the per-rule limits on this page and the confidence floor. This applies immediately. The confirm button is Resume, a reason is required in this direction too, and success reads Autonomous response is running again.

Note what resuming does not do. It does not retroactively approve anything that was left waiting while the switch was stopped. Whatever is in the approval queue stays in the approval queue, subject to the ordinary expiry described below. Resuming changes what happens from now on; it does not reach back over the period you were stopped.

What stopping actually stops — and what it does not

This is the section to read carefully, because the switch is easy to over-read in both directions.

What it stops: every containment Sentinel-Q would otherwise have run without asking. Today, in practice, that is one thing — the automatic quarantine step that runs when a file on one of your machines matches a known-bad indicator at high confidence. That is not an arbitrary example. It is the only action in the shipped product that any rule is permitted to take unattended, for the reasons set out in Autonomy tiers: observe, recommend, act. So the switch has exactly one thing to take away, and it takes it away completely.

What it does not stop, all of which continues exactly as before:

• Detections. Every rule keeps evaluating and keeps firing.
• Alerts and tickets. They keep arriving in the queue at the same rate.
• Investigation. Sentinel-Q still gathers evidence, correlates it and reaches a verdict with a confidence figure and citations.
• Triage, classification and recommendation. The reasoning is unchanged. What it produces is a recommendation for a person rather than an action it takes itself.
• Anything a person does. Live response, approvals, isolation, un-isolation and undo all work normally — see Live response and approval. The switch constrains the machine, not you.

Put the difference in one sentence: with the switch stopped, instead of Sentinel-Q approving its own containment action, a person has to approve it.

It fails closed, in several places at once

Everywhere this switch could be ambiguous, the platform resolves the ambiguity towards stopped. That is a safety property rather than a defect, and it is worth knowing about because it predicts the behaviour you will actually see.

Never set means off

If the switch has never been set for your organisation, autonomous response is off, not on. An unconfigured tenant is a stopped tenant. Nobody inherits unattended automation by never having made a decision about it.

Unreadable means off

If the stored state cannot be read for any reason — a database fault, a slow replica, a network blip — it is also treated as stopped. A failure to read a permission never grants the permission.

The switch can only narrow, never widen

Setting it to running does not turn on anything the deployment itself has not enabled. It can withdraw authority the platform would otherwise have granted; it cannot manufacture authority that was never there. So pressing Resume on a deployment where autonomy is disabled changes nothing, and that is the correct outcome rather than a fault.

The console mirrors the same rule rather than papering over it. If the current state fails to load, the screen shows Stopped, warns you that the state could not be read, and disables both buttons — so a screen that cannot tell you the truth does not let you act on a guess. If you see that warning, reload the page; if it persists, see How to get help.

What is recorded

Every stop and every resume is written to the audit trail with your identity, the time, whether it succeeded, and the reason you gave. So is every failed attempt to change it — a refused change is recorded as a refused change rather than vanishing, which is what lets the record answer did anybody try to turn this back on? and not only who turned it on? See Reading the audit log.

The same events also appear in the Recent policy changes panel on this screen, labelled Autonomous response stopped and Autonomous response resumed, with columns for when it happened, the change, the rule, who made it, and the outcome — applied or refused. For day-to-day questions that panel is the quickest answer; the audit trail is the authoritative one.

Who can change it

Reading the current state needs read access to XDR rules. Changing it needs two things at once: write access to XDR rules and an administrator-level role in the organisation specifically — owner or admin. Holding the write permission is not sufficient on its own.

Nothing is sent when you change it

Stopping or resuming autonomous response raises no email, no Slack or Teams message and no webhook of its own. The audit trail and the Recent policy changes panel are the entire record. That has a practical consequence worth planning around: if one administrator stops autonomy during an incident and forgets to resume it, nothing will remind anybody — and because the state is not surfaced on any other screen, nothing will draw your attention to it either.

So if you stop it, tell whoever else administers the console, by whatever means you normally use. The platform will not do it for you, and we would rather say so than let you assume a message went out.

What to do next

1. Look at the pill today, before you need it. If it reads Never switched on, that is worth knowing: nothing has ever acted unattended in your organisation, and nothing will until somebody presses Resume.
2. Check who holds owner or admin. They are the only people who can press either button, and an emergency stop that waits for one specific person on holiday is not an emergency stop. Roles and permissions has the grant list.
3. Read Autonomy tiers: observe, recommend, act for the per-rule layer this switch sits underneath, and for why only one rule can act unattended at all.
4. Read Live response and approval before you stop autonomy in anger, so you know what the approval queue will expect of you while it is stopped — particularly the fifteen-minute expiry.
5. Agree in advance who resumes it, and when. A stop with no agreed end is how an organisation quietly runs a whole quarter without the automation it thought it had.