What Sentinel-Q is allowed to do

Sentinel-Q is the part of Qorionix that reaches a verdict on an alert and, depending on a setting you control, either tells you about it or does something about it. This article is the full list of what it can do, what it can only propose, and what it cannot do at any setting, at any confidence, for any customer.

The list is deliberately specific. A vendor who describes their automation as "intelligent response" is asking you to accept an unbounded permission. What follows is bounded, and the bounds are enforced by the server rather than by asking the model to behave.

Autonomy is not a yes-or-no question

The useful question is not "is it autonomous?" but "how far up does it go, and what stops it going further?". Internally we describe capability as six rungs. Naming them separately matters, because the interesting risks all sit at the joins between them rather than inside any one rung.

L0 — Report

The signal exists and you can see it: dashboards, a searchable log, raw events. No interpretation. Every configuration includes this.

L1 — Explain

For a given event, what happened in plain language with the evidence cited underneath. Answers "is this bad?" when you ask. Still entirely reactive — you point at something, it explains it.

L2 — Investigate

Unprompted. It gathers its own evidence across identity, privileged access, logs and endpoints, correlates what it finds, reaches a verdict with a calibrated confidence figure and citations, and ranks your queue accordingly. It changes no state whatsoever. This is where most of the value lives.

L3 — Recommend

A fully specified, executable change set: the exact action, the exact target, the exact parameters, the stated blast radius and the undo plan, queued for you to approve with one tap. Nothing happens until you tap.

L4 — Act within bounds, then report

It executes on its own, but only inside an envelope declared in advance: an enumerated list of action classes, reversible actions only, evidence that verified, blast radius below a threshold, and confidence above a floor. Then it tells you what it did.

L5 — Act and adapt

The system writes its own detection rules, retunes its own thresholds and adjusts its own autonomy envelope. This rung is not implemented and its absence is deliberate.

Three transitions on that ladder carry nearly all of the risk, and each has its own gate. L2 to L3 is gated by grounding: a verdict may only become a proposed change if its citations verified. L3 to L4 is gated by a server-enforced envelope: a proposal may only execute itself if it falls inside limits recorded before the alert arrived. L4 to L5 has no gate, because the transition does not exist.

The three tiers you actually choose between

The setting you control is called the autonomy tier, and there are three of them. They map onto the ladder as follows.

Note what tier0 is not. It is not "do nothing" — it is a complete grounded investigation with a verdict and citations, available to an organisation that trusts the platform with no ability to act at all. The industry estimate is that first-line triage work (enrichment, indicator lookups, classifying known patterns) is 50–60% of what a security operations team does, and all of it sits at L2 and L3.

tier1 is the compiled default, and that choice is load-bearing in one specific failure case. If the tenant policy lookup fails — a database hiccup, a slow replica — the platform falls back to tier1, never to tier0 and never to tier2. A transient fault must not become a human-in-the-loop denial of service, and it must certainly not become an auto-execute-everything event. A policy row that exists but is switched off also reads as tier1, for the same reason.

Two properties that are not configurable

Both of these make for a worse demonstration and a better product, so they are worth stating in the words the code uses.

The function that resolves permission does not read the recommended action. It reads your policy row, the platform default for that rule, the grounding verdict and the derived confidence. Persuasive wording in a model's output has no path to a wider permission, because the permission was decided without looking at the wording.

A verdict whose citations did not verify never reaches tier2, regardless of confidence or severity. If the platform cannot re-resolve the evidence a finding rests on against your own data, that finding does not get to move anything. Why a confident answer can still be refused explains the checks in detail.

The action matrix

This is the operative list. The right-hand column is the highest rung each action can reach under any tier — so an action marked L3 requires your approval even if you have set tier2, because the ceiling is per action and not per organisation. Ceilings are enforced at tool-registration time, not described in a prompt.

One line in that table deserves reading twice. Granting privileged access is never automated, and the way that is guaranteed is structural: no grant tool is exposed in the registry. The model is not instructed to refrain from granting access. It has no means of requesting it, in the same sense that a keyboard has no means of requesting a pay rise.

The reasoning behind those ceilings

The ceilings are not a ranking of how scary each action sounds. They follow from four rules about what makes an action safe to take unattended.

• "Prefer the action the affected user can undo by proving who they are. A step-up challenge is autonomous-safe. A suspension is not." The difference is who holds the remedy. A challenged user carries their own remedy in their pocket; a suspended user has to find somebody with an administrator account.
• "Step-up multi-factor is the flagship autonomous action, because the user proving their identity is the remediation — the action is self-correcting when wrong." If Sentinel-Q challenges a legitimate sign-in, the cost is one extra prompt and the sign-in proceeds. If it challenges an attacker holding a stolen password, the sign-in stops. The failure mode is mild in one direction and decisive in the other.
• "Revoke may be autonomous; grant never — enforced structurally by not exposing a grant tool in the registry, not by prompt instruction." Removing access has a bounded worst case: somebody is inconvenienced and signs in again. Adding access has an unbounded one.
• "False-positive suppression is always L3 and must expire — permanent autonomous suppression manufactures blind spots, which is precisely what an attacker wants." The most attractive thing an intruder could ask a detection system to do is to stop looking at them, permanently and quietly. Suppression therefore needs your approval, is versioned, and has an expiry date.

One further rule governs anything multi-step: the chain's autonomy is the minimum of its links, not the maximum. A sequence that steps up multi-factor (L4) and then suspends an account (L3) is an L3 sequence, and waits for you in full. It does not run the first half and stop.

Isolating a machine: why it never happens on its own

Cutting a laptop off the network is the most disruptive thing the platform could do without human involvement, and it is the action customers ask about first. In the shipped product it is never taken without a human, at any setting. Every detection rule is capped below the top autonomy tier for it — the one rule that reaches the top tier quarantines a file, not a machine — so there is no configuration of yours that produces an unattended isolation.

The conditions below are the envelope this action would have to satisfy before it could ever be autonomous. They are published because they are the standard, and because two of them describe things that do not exist yet — a mobile one-tap un-isolate, and a per-action-class opt-in screen. Read the list as the bar, not as a description of a feature you can turn on.

1. Confidence is above a floor set materially higher than the general tier2 floor, which itself defaults to 0.95.
2. The evidence was verified by the server, the grounding report is clean, and there are zero off-ledger citations.
3. The host is not flagged business-critical — which requires that somebody has answered the asset-criticality question for your organisation.
4. The blast radius is exactly one host. Any action touching more than one host is L3 regardless of confidence.
5. A one-tap un-isolate is reachable, with the undo handle recorded before the action runs. Not yet true on mobile. In the console the reversal is Endpoints → Restore network access, which is built and works.
6. Notification fires before, or simultaneously with, the action. A customer learning that their laptop died from the laptop dying is the failure experience we are designing against.
7. There is no declared change freeze or maintenance window in effect.
8. Your organisation has explicitly opted in to this action class, with the risk stated in plain language at the point of opting in. This opt-in does not exist in the product. There is no per-action-class consent screen, which is one reason the condition cannot currently be met.

Reversibility is a property, not a promise

Every action the platform takes records an undo handle at the moment it is taken, by the code that takes it, into a hash-chained audit row. That is a different thing from a datasheet sentence about reversibility, which is typically reconstructed after the fact by somebody reading logs.

• Quarantine moves the file into a vault named by its SHA-256 digest, so the original bytes are restorable.
• Isolation snapshots the host firewall rules before mutating them, so the previous state is restorable.
• Killing a process is honestly labelled: what is reversible is the ticket, if the sensor has not yet collected it. A terminated process cannot be restored, and the undo instructions say so rather than implying a rollback that does not exist.
• An action class with no known reversal returns no undo handle at all — and a missing handle is treated as "this must not be taken autonomously".

Live-response tickets default to pending_approval. See Undo a change for the operator's side of this.

What to do next

1. Read Autonomy tiers: observe, recommend, act and decide which tier you want, per action class rather than globally.
2. Answer the asset-criticality question for your organisation. Several ceilings in the matrix above depend on it, and an unanswered question is resolved conservatively.
3. Read Reading a Sentinel-Q decision so that the first decision you see is legible rather than intimidating.
4. If what you actually want is to change something rather than wait for it to be flagged, read Asking Sentinel-Q to change something — a narrower, human-initiated path that still ends in your approval.