What We Will Not Automate, and Why

Every AIOps vendor publishes a capability list. Almost none publishes a refusal list. This is ours, along with the rule that decides what goes on it.

Why publish a refusal list at all

Every vendor in this category publishes what their agent can do. The capability list is the easy document: it is long, it is impressive, and it costs nothing to write. Almost nobody publishes the other list.

That is a mistake, and not only an ethical one. When an operations director evaluates autonomous remediation, the question underneath every other question is what is it allowed to do to me. A capability list cannot answer that. A refusal list can, and a vendor willing to write one down has told you something a demo never will.

The rule that decides what goes on the list

An action is never eligible to run unattended if any one of these is true.

It has no viable rollback. Not a rollback that exists in theory, or one somebody wrote in a template and never tested. A defined, checked path back to the prior state. If we cannot assert one, the action waits for a human regardless of how confident the diagnosis is.

It is destructive to data. Anything that deletes, truncates, overwrites or purges. Reversibility here is usually a fiction: a backup is a recovery procedure, not an undo.

It writes to a system of record. Ledgers, core banking, payroll, master data, regulatory extracts. A wrong write here does not stay in the estate. It propagates into statements, reconciliations and filings.

It moves money or grants access. Payments, settlements, entitlement grants, privilege escalation. These are decisions with names attached by design, and automating the name away is the whole problem.

It affects a person directly. Locking an account, isolating a device someone is working on, terminating a session. The cost of being wrong is not measured in minutes of downtime.

The list, in plain terms

Sentinel will not, on its own authority: delete or truncate data; execute a database migration; drop or rebuild an index on a live system of record; apply a change to a financial ledger; release a payment file; grant, escalate or revoke a user entitlement; lock a user account; isolate a host that is serving live traffic; fail over a path carrying live customer sessions; restart a core banking or settlement job; reprocess or replay a transaction batch; disable a security control; or execute any procedure whose rollback path has not been checked.

Every one of those can still happen through Sentinel. None of them happens without a named human approving a fully prepared Action Ticket, with the blast radius, the procedure and the rollback path already written and attached.

What this costs us, honestly

It costs us the headline. "Fully autonomous remediation" is a better slide than "autonomous where the blast radius is nil, governed everywhere else." We know which one wins a bake-off on paper.

It also costs us some genuinely safe automation at the margin, because the rule is deliberately conservative. There are cases where a system of record write would have been fine and we held it anyway.

We take that trade because the alternative failure is not recoverable. An operations team that switches autonomy off after one bad action never switches it back on, and the whole value of the platform is lost to a single incident that a gate would have prevented.

What it buys you

The refusal list is what makes the permission list credible. When we say Sentinel resolves a saturated connection pool or reclaims a full disk without paging anyone, that claim carries weight precisely because there is a written boundary around it.

It also makes the system auditable in a way a capability list never is. An auditor does not ask what your platform can do. They ask what it did, who authorised it, and what would have stopped it. A published refusal list answers the third question before it is asked.

How the list changes

It is not frozen. Actions move off the list when two things become true: a rollback path exists and has been tested against the specific estate, and the customer's own change policy sanctions it. That is a per-deployment decision made with the customer, not a product default we push.

Nothing moves onto the permitted side because a model got better at predicting. Improved accuracy changes how often a diagnosis is right. It does not change what happens when it is wrong, and the list is written entirely about the second thing.

The question to ask your current vendor

Ask them for their refusal list. Not their guardrail architecture, not their permission model, the actual list of things their agent is not allowed to do on its own.

If they do not have one written down, the boundary does not exist. It is being decided at runtime, by a model, using a threshold somebody set in a configuration file.