Why nothing is fixed automatically
The posture engine can propose a fix for a finding and is switched off from doing it. The switch is the operator's, not yours, and it is off in every shipped configuration.
The posture assessment finds things and, for many of them, works out exactly what change would fix it. It then does not make that change. Every finding in your report is reported and left alone, and this article is about why, what you are seeing when a finding says a fix was refused, and what it would take to change.
The one-line version: automatic remediation is a deployment-level switch, it is off, and it is not set in any shipped configuration. Not off for your organisation, not off for your plan — off for the deployment, above the level anything you can configure reaches.
What still happens, which is most of it
Off here means one specific thing: the engine does not make the change. It does not mean the engine sits idle.
- The sweep runs. On its schedule, against your tenant, as normal.
- Findings are produced and the report is written. Nothing about reading your posture report is affected.
- The refusal is recorded against each finding it would have fixed — with a reason code, the tier it was operating under, and a note describing the change that was not made.
That last point is the useful one and it is easy to miss. A refused remediation is not silence; it is a record saying here is the change I would have made. The message you will see against such a finding is:
automatic remediation is switched off for this deployment, so the finding is reported and left alone. The change below is what would have been made; enable automatic remediation once you are satisfied with what these sweeps are finding.
The reason code stored alongside it is automatic_remediation_disabled, and it is deliberately distinct from every tenant-level refusal, because nothing you configure produces it and nothing you configure overrides it.
This switch is not yours, on purpose
There is no API route, no console control and no plan entitlement that reaches it. The reasoning is recorded in the code and it is a real argument rather than a limitation being dressed up:
This is deliberately NOT a per-tenant setting and cannot be reached from the API: it is the operator's switch, above the tenant's autonomy policy, and a tenant raising its own tier must not be able to cross it.
Read that against the autonomy tiers described in What Sentinel-Q is allowed to do. Those tiers are yours to set, and they govern what the AI may do about an alert. This switch sits above them: whatever tier you choose, posture remediation stays off, because a customer moving their own dial should not be able to authorise the platform to start making unattended configuration changes in their directory.
It also means the answer to can we turn it on for our tenant is no. What you can do is ask, and the useful form of asking is telling us which specific check you would want acted on and why — a request naming one check is a decision somebody can make, and enable auto-remediation is not.
Six other gates behind the same door
Worth knowing that the deployment switch is only the first gate. Even with it on, a remediation still has to pass every one of these, and each refusal is recorded separately so you can tell them apart.
| Gate | What it requires |
|---|---|
| A remediator exists | There is code that knows how to make this particular change. |
| A reversal exists | The change has a known way back. An action with no reversal is not taken unattended. |
| Approval, where the tier requires it | Your autonomy tier and the action class together decide whether a human tap is needed. |
| Grounding verified | The evidence the finding rests on re-resolved against your own data. See Why a confident answer can still be refused. |
| Budget | The tenant has not exhausted its allowance. |
| An audit chain is wired | Without a tamper-evident record, no change is made — see below. |
What does change things, and how
The platform is not incapable of changing your configuration. It changes things when a person approves a change, and that path is fully built. The distinction is between unattended and unable.
- The done, approve and decide buckets
- The posture report sorts changes into what has been done, what is waiting for your approval, and what needs a decision only you can make. Approving one applies it. Done, approve, decide is the full account.
- Action plans from Sentinel-Q
- A fully specified change with its blast radius and its undo plan, waiting on a tap. Action plans, and approving one.
- Undo
- Every applied change records an undo handle at the moment it is applied, by the code that applies it. Undo a change.
So the honest summary of the platform's behaviour towards your configuration is: it proposes, you approve, it applies, and you can reverse it. The missing rung is the one where it applies without asking, and that rung is switched off at the deployment.
Should you want it on?
A fair question, and the answer is not obviously yes, so it is worth setting out both sides rather than presenting the current state as unambiguously good.
The argument for it is the whole premise of the product: an organisation with no security team benefits most from things being fixed rather than reported, and a finding nobody acts on is a finding that may as well not exist. A queue of approvals that nobody works through is a slower form of the same problem.
The argument against it, and the reason the switch is off today, is that posture remediation touches identity and tenant configuration — conditional access, consent grants, administrative role assignments. The blast radius of getting one of those wrong is your staff cannot sign in on Monday morning, and that is a worse Monday than the finding was a risk. Getting there needs more confidence in the remediators than we currently have evidence for, and we would rather run detect-only for longer than ship an outage.
What to read next
- Done, approve, decide — the three buckets, and how to work through the middle one.
- Undo a change — the reversal path, which is what makes approving a change a low-risk act.
- What Sentinel-Q is allowed to do — the autonomy ceilings this switch sits above.