Autonomy tiers: observe, recommend, act

There is one setting that determines whether Sentinel-Q tells you about something, asks your permission to fix it, or fixes it and then tells you. It is called the autonomy tier. It has three values, it is set per detection rule rather than once for the whole organisation, and it is enforced by the server.

This article explains what each tier changes, what it does not change, where the setting lives, and how to pick one without either drowning in approvals or handing over more than you meant to. The short version, if you read nothing else: almost every rule is capped at asking you first, and the cap is not yours to lift.

The three tiers

The tier names undersell tier0 badly. Observe is not "do nothing" — it is a complete grounded investigation with a verdict and citations, available to an organisation that has given the platform no ability to change anything at all. First-line triage work is estimated at 50–60% of what a security operations team does, and essentially all of it fits inside observe and recommend.

The same alert at all three tiers

A sensor reports a process on one laptop writing a file that matches a known credential-dumping pattern, shortly after a sign-in from an unfamiliar network. Here is what each tier produces.

At `tier0`

Sentinel-Q pulls the process tree, the sign-in record, the account's recent behaviour and a threat-intel lookup; concludes true_positive at a stated confidence with the four findings cited; and puts the alert at the top of your queue. Because the disposition is a true positive and the tier prohibits acting, the classification is escalate_human with the recorded reason "assessed as a true positive, but this rule is configured tier0 (observe only), so no ticket was opened". No ticket exists. Nothing is contained.

At `tier1`

The same investigation, plus a prepared change set: isolate this one host, blast radius one machine, undo handle recorded, one-tap approval. The classification is recommend_action. Your laptop keeps working until you tap. If you never tap, nothing happens — which is a real risk and the honest cost of this tier.

At `tier2`

Nothing different happens, on this alert. Isolation never runs unattended — no rule in the shipped product is permitted to reach tier2 for it. The decision stays recommend_action and behaves exactly as it does at tier1. The one place tier2 changes the outcome is a different rule, described below.

Only one rule in the product can reach Act without asking

This is the single most important fact on the page, and it is easy to miss because the setting is offered on every rule. The server keeps a catalogue giving each detection rule a ceiling — the highest setting it will actually honour — and the ceiling is a hard limit, not a suggestion. Today exactly one rule has a ceiling of Act without asking: the built-in known-bad-file-hash rule, whose action is to quarantine the matching file on that one machine.

The reasoning is published on the rule itself, and it is worth reading because it is the standard every future candidate has to meet:

Every other rule is capped at Recommend, then ask, including all the behavioural ones. A rule added to the product without anyone writing down what it would do unattended is capped there automatically — the conservative direction is the default, not something someone has to remember.

Where you set it, and what the screen asks of you

Go to Autonomy policy in the console (Govern → Autonomy policy in the sidebar). It lists every rule grouped by what kind of action it can take — Containment — stopping or isolating something and Advice — raising an alert only — with four columns that matter: Default, In force, Highest allowed and Override.

Expanding a rule shows, before you change anything, four plain-language facts written for a non-specialist:

The setting control only offers the tiers that rule permits. There is no greyed-out option for something above the ceiling, because an option you cannot pick teaches you nothing — the ceiling and its reason are printed beside the control instead.

1. 1

   Pick the setting

   Only the permitted values appear. If the rule is capped, the note reads This rule may go no higher than "…".

2. 2

   Optionally raise the certainty required

   Certainty required is the confidence floor for that one rule, between 0 and 1. Leave it blank to inherit the default. See the next section for what the number means.

3. 3

   Give a reason

   Compulsory when you are granting unattended authority — the field relabels itself to Reason (required — recorded in the audit trail) and refuses to save without one, saying Give a reason before granting this rule unattended authority.

4. 4

   Confirm, if you are going to the top setting

   A second, explicit confirmation appears, headed You are about to let this rule act on its own. It restates how far the action reaches and whether it can be undone, and the confirm button names the setting rather than saying OK.

Two counters at the top of the page are the ones to glance at: At their highest setting ("these act with the least human involvement allowed") and Acting unattended ("these can act without asking you first"). If the second reads anything other than 0 or 1, somebody has changed something you should know about.

The confidence floor

tier2 does not mean "act whenever you feel like it". Autonomous execution requires the derived confidence to be at or above a floor, which defaults to 0.95. Below the floor, the decision becomes a recommendation and the escalation record says so, naming both numbers.

You can move that floor in your policy, within limits. A floor of zero or one outside the 0–1 range is snapped back to the default rather than honoured, because a policy row carrying 0.0 would otherwise unlock autonomous execution at any confidence at all. Isolating a host uses a floor set materially higher than the general one.

The tier is per rule, and the ceiling is per action

Two independent limits combine. Your tier sets how far the platform may go for a given detection rule. The action matrix sets how far a given action may ever go, for anybody. The effective permission is the lower of the two.

So setting tier2 on a rule does not enable autonomous account deletion, privileged-access grants, domain-controller credential rotation or permanent detection suppression, because those actions are capped below L4 — or, in the case of granting access, not exposed to the model at all. What Sentinel-Q is allowed to do carries the full matrix.

For multi-step sequences one further rule applies: the chain's autonomy is the minimum of its links, not the maximum. A sequence containing one L3 step is an L3 sequence and waits for you in full. It does not execute the permitted half and stop halfway, leaving you to work out which parts ran.

There is no blanket switch, and there is no per-action-class opt-in either

Two things people expect to find here, and do not:

• A single switch that turns automation on for the organisation. There is none, deliberately. The decision is made one rule at a time, because a blanket consent is a consent nobody read.
• A consent screen per class of action — "yes to quarantining files, no to killing processes". There is none of these either. The ceiling catalogue does that job on your behalf and it is not adjustable by you, which is why in practice only one rule can act unattended at all.

The principle the ceilings are drawn on is worth knowing, because it predicts what will and will not be allowed to act on its own in future: prefer the action the affected person can undo by proving who they are. A step-up multi-factor challenge is autonomous-safe in that sense — a legitimate user sees one extra prompt and an attacker with a stolen password is stopped, so the action self-corrects when it is wrong. Killing a process, suspending an account or cutting a machine off the network do not self-correct, which is why they sit where they sit.

What happens when the setting cannot be read

If the tenant policy lookup fails — a database hiccup, a slow replica, a network blip — the platform falls back to the compiled default, which is tier1. Not tier0, and not tier2.

Both alternatives are worse in a way that is easy to miss. Falling back to observe-only would turn a transient database fault into a silent denial of service on your own response capability, at exactly the moment you might need it. Falling back to auto-execute would turn the same fault into an act-on-everything event. Recommend is the only fallback that fails in a direction you can see and correct.

A policy row that exists but has been disabled also reads as tier1, for the same reason. Disabling a row is not a way to reach observe-only; to get observe-only, set the tier to tier0 explicitly.

Choosing a tier

Most organisations should start at tier1 everywhere, which is where they already are, and then move individual rules — not the whole organisation — as they build a view of how the platform behaves on their own traffic.

• Stay at tier0 for a rule when a false positive on that rule would be genuinely expensive and you would rather triage it yourself. Also a reasonable posture for the first fortnight, while behavioural baselines are still forming and the platform has not yet learned what normal looks like for you.
• Stay at tier1 if somebody checks the queue at least once a working day. This is the right default for the large majority of our customers, and it is the tier we recommend if you are unsure. Its weakness is honest: an alert nobody taps is an alert nobody acted on.
• Consider the top setting only on a rule that offers it — today that means the known-bad-file-hash rule and nothing else — and only when two things are true: the rule has produced decisions you agreed with over a meaningful period, and there are hours in your week when nobody would be reading the queue. The second is usually the real argument for it. On every other rule the option is not offered, so there is no decision to make.

What the tier does not change

• It does not change what the model is asked, or how hard it looks. The same investigation runs at all three tiers. The tier decides what may be done with the result.
• It does not let a persuasive proposal widen its own permission. The function that resolves permission does not read the recommended action at all.
• It does not affect the audit trail. Every decision, every proposal, every execution, every block and every human override is written into a hash-chained audit row, with a machine actor recorded distinctly from a human one.
• It does not remove the undo handle. Reversibility is recorded at the moment of action by the code taking it, at every tier. An action class with no known reversal produces no handle — and a missing handle is treated as "this must not be taken autonomously".

When you are ready to change a tier, read Done, approve, decide for how the platform groups changes by who has to authorise them, and Undo a change for how to reverse one.