Action plans, and how to approve one

A plan is the artefact the platform produces when it has decided something should change and is not permitted to change it on its own. It is not a suggestion in prose. It is an exact action, an exact target, exact parameters, a stated blast radius and a recorded way to undo it — assembled so that your part is one tap rather than an afternoon of translation.

This article is for whoever runs IT. It covers what is in a plan, the difference between approving one and running one, what is written down while it happens, and the four things a plan structurally cannot contain.

What a plan contains

A plan has a summary and an ordered list of steps. The summary is the sentence you read; the steps are the thing that runs.

Summary

One short paragraph describing what this plan achieves and why. Written for the approver, not for the machine.

Steps, in order

Each step carries an ordinal, a plain-language description, the tool it will call, the arguments it will call it with, and its own blast radius and status. The arguments are shown, not summarised: if a step will revoke sessions for one named account, the account is named in the plan you approve.

Approval required

Whether this plan may execute without a human. Set from the blast radius of the steps and the autonomy ceiling of the tools they call — not from the model's opinion of its own plan.

Status

One of draft, approved, executed or rejected. A plan is never edited in place into another state: the transitions are recorded with who made them and when.

Approved by, approved at, executed at

Who authorised it, when, and when it actually ran. The gap between the last two is often the useful part of an incident timeline.

Each step also has its own status — pending, approved, rejected, executed or failed — and its own recorded result. A plan that half-ran is legible afterwards, step by step, which is why the per-step status exists rather than a single flag on the plan.

Blast radius, and what it decides

Every step declares a blast radius: low, medium or high. This is a property of the capability, fixed when the tool was registered, and not something the model chooses per plan. The rule it drives is short and absolute: any step marked high blast radius is blocked from autonomous execution and requires explicit human approval.

Blast radius and autonomy ceiling are two separate limits and the effective permission is the lower of the two. What Sentinel-Q is allowed to do carries the full ceiling matrix; this article is about the approval mechanics on top of it.

Approving one

Approving and executing are two separate operations, deliberately. Approval records that a human authorised the plan. Execution is what makes it happen. A plan can sit approved and unrun, and that is a legitimate state — the authorisation is not a trigger.

1. 1

   Read the target before the description

   The description tells you what the platform thinks it is doing. The arguments tell you what it will actually do. If the step names an account, check that it is the account you expect; if it names a host, check the host. This is the thirty seconds that catches the wrong-target mistake, and it is the only mistake in this area that is genuinely expensive.

2. 2

   Check the blast radius against the step count

   One medium step on one identity is a small change. Three steps across two modules is a sequence, and a sequence takes the autonomy of its weakest link — so if you are approving it, you are approving all of it. It will not run the permitted half and stop halfway, leaving you to work out which parts happened.

3. 3

   Check that an undo exists, and when it expires

   A step whose reversal has a recorded expiry — a quarantine retention window, for instance — is a step where deciding tomorrow may be deciding never. Undo a change covers the reversal mechanics and the honest list of what cannot be reversed at all.

4. 4

   Approve, or reject with a reason

   Rejection is recorded against the plan with the approver's identity. A rejected plan is retained rather than deleted: an authorisation that was refused is part of the record of what happened, and an auditor asking "was this ever proposed?" needs the answer to be findable.

5. 5

   Execute when you are ready

   Execution is a separate call and returns the updated plan with each step's result attached. If a plan requiring approval is sent for execution without it, the platform refuses with human approval required rather than running the steps it happens to be allowed to run.

POST /ai/plans/{plan_id}/approve
POST /ai/plans/{plan_id}/reject
POST /ai/execute/{plan_id}

An unknown plan id returns plan not found. Sentinel-Q decisions carry a related but separate control: an individual next step on an explanation can be run on its own, and that route requires the execute permission specifically rather than write. A step that exceeds the tier in force is refused there with the runner's own reason rather than being silently downgraded.

Who can approve

Approving, rejecting and executing all require write on the AI tools permission. Reading past sessions is a separate, lower permission. Roles and permissions covers which role carries which.

Two behaviours in this area were defects and are worth knowing about, because they change what you can assume about older integrations:

• A token carrying no organisation is now refused, with token carries no organization. It previously skipped the permission check entirely, which meant every route using that middleware — plan approval and execution included — was open to any authenticated user, read-only viewers included. It now fails closed.
• The organisation is always taken from your token, never from the request body. A body value that disagrees with your token is rejected rather than preferred. Previously the body won, while the permission check authorised against the caller's own organisation: the check and the action could run against different tenants.

What is written down

Two separate records, for two separate questions.

Every model call is persisted with its prompt, its reasoning and its response, alongside the session and plan it belongs to. That exists so that governance questions — what did the model see, what did it say, and when — can be reconstructed rather than reasoned about. It is the record an EU AI Act Article 14 review draws on.

Every event on a decision is appended to a hash-chained log: the decision being recorded, an action being proposed, executed or reversed, a human override, and a tier block. Each row's hash covers the previous row's hash, so removing or editing an intermediate row breaks the chain at a reportable sequence number. The chain is kept per organisation and per decision, so one tenant's activity can never be interleaved with another's, and the undo handle lives on it — which is the difference between "we can roll this back" as a claim and as a capability.

The actor on each row is recorded as human, ai or system. A deterministic auto-approval and a model inference must not share an identity in an audit trail, because "who decided this" is the first question any oversight review asks and "the platform" is not an answer. The evidence bundle covers what an auditor receives.

Retention follows your tenant's configured retention period, and a GDPR erasure request cascades through the audit trail, the steps, the plans, the messages and the sessions.

What a plan structurally cannot contain

Three rules hold at every tier and every confidence. They are properties of the system rather than instructions to the model, which is the distinction that makes them worth anything.

• Anything irreversible needs a human. Autonomous execution requires a recorded undo handle. Where there is none, the platform's own refusal is no recorded undo handle: L4 permits reversible actions only. The same envelope also refuses to act when the asset's criticality is unknown — acting inside an envelope requires knowing what is inside it — and when the blast radius is more than one host.
• Ungrounded means unauthorised. A verdict whose citations did not verify against your own data cannot produce an executable plan, at any confidence. See Why a confident answer can still be refused.
• Granting privileged access is never automated, and the guarantee is structural rather than instructed. The tool registry refuses to hold a grant-class capability at all, failing at start-up if one is declared, with the message: grant-class capabilities are not registrable — an AI may recommend an access grant but may never effect one.

Being precise about that third rule matters, because a looser version of it would be false. There is no tool anywhere in the platform that can approve, extend or elevate privileged access; what replaced the one that used to exist reads a pending access request and returns advice to the human approver, carrying an explicit flag saying nothing was effected. Role changes are a different thing: a tool that changes a member's role does exist, it does write, and it is high blast radius and capped at recommend — so it always waits for your approval and can never run unattended. The claim is "privileged access grants are not exposed to the model, and role changes require your approval", not "no write tool exists".

A fourth rung is also refused at registration: a tool that declares the ability to write its own detection rules or adjust its own autonomy envelope cannot be loaded. Rule-writing autonomy without versioning and rollback is how a system quietly degrades its own coverage.

Limits worth knowing before you rely on this

• Privileged credential rotation is not implemented as an AI action. The tool is registered and described, and calling it returns a deferred-implementation error rather than rotating anything. A plan containing that step will fail at it. Use the credential rotation workflows in the privileged-access module instead, which are real.
• There is no customer-pressable stop control. The switch that disables autonomous execution across a deployment is a deployment variable set by whoever operates the platform, not a button in your console. That is an acknowledged gap against the human-oversight obligation we hold ourselves to, and the honest interim answer is that the per-rule autonomy tier is the control you have — set the rules you are unsure about to recommend or observe.
• We have no automation-bias countermeasure beyond disclosure. Every decision carries its limitations and its standing statement that it is a recommendation rather than a determination. That is disclosure, not a control, and we count it as unfinished work rather than as a feature.

When you are deciding how much of this to hand over, Autonomy tiers: observe, recommend, act is the article to read next — particularly the section on why raising a tier to compensate for an unread queue is the wrong fix.