Self-healing agent infrastructure needs a permission ladder, not an autonomy switch

An autonomy switch collapses several operational decisions into one setting. Can the system inspect telemetry? Diagnose an incident? Change infrastructure? Verify the result? Reverse the change?

Those permissions do not carry the same consequence. A more useful design hypothesis is a ladder: grant authority separately for observation, proposal, approval, execution, verification, and reversal.

That hypothesis builds on a proposed vendor-agnostic architecture combining monitoring, pipeline metadata, incident history, deterministic policy checks, AI-assisted diagnosis, approval workflows, controlled remediation, and post-action verification. Its authors describe an eight-stage lifecycle with a human approval gate and mandatory handback when verification fails or no playbook applies (source).

The distinction between proposal and proof matters. An independent assessment says the work contains no primary empirical dataset or production field trial (assessment). The sequence is therefore an architecture to interrogate, not evidence that it heals production systems successfully.

Six different grants of authority

“Autonomous” is too coarse to describe incident authority. One agent might have broad read access but no write access. Another might execute one pre-approved playbook while lacking permission to select a different intervention. A third might verify a change without being allowed to reverse it.

The permission ladder separates those cases:

State	Operator question	Example evidence
Observe	What data may the system read?	Named telemetry, metadata, and incident-history sources
Propose	What diagnosis or action may it recommend?	Diagnosis record, candidate playbook, and supporting signals
Approve	Who or what may authorize execution?	Policy result, human decision, approver identity, and expiry
Execute	Which exact mutation may run?	Bounded command, target, parameters, credential, and timeout
Verify	What result counts as acceptable?	Post-action checks and comparison criteria
Reverse	Which recovery action is permitted if verification fails?	Rollback playbook, handback route, and escalation owner

This table is an SGL operating worksheet derived from the proposed lifecycle, not a validated feature of the cited architecture. Its purpose is to expose every point where authority changes hands.

The cited architecture places deterministic policy checks alongside AI-assisted diagnosis and approval workflows (source). In the permission-ladder framework, that separation keeps diagnosis from silently becoming authorization. A policy record can identify the incident class, affected target, playbook version, allowed parameters, prohibited mutations, maximum action scope, approver, expiry, verification procedure, and response to failed or inconclusive verification.

A model-generated diagnosis is evidence supplied to a decision point. It is not permission to mutate a system. That boundary is an engineering prescription from this framework, not an observed result from a field trial.

The action envelope

Approval such as “restart the pipeline” leaves material questions unresolved: which pipeline, which environment, which revision, how many attempts, and what happens after a failed restart?

A short-lived action envelope makes the execution grant narrower:

action: restart_pipeline
target: pipeline-17
environment: staging
playbook_version: 4.2
attempt_limit: 1
expires_at: 2026-08-15T19:30:00Z
verify_with: pipeline-17-postcheck-v3
on_failed_verification: hand_back

This is a proposed control format. The sources do not test the schema or establish that these fields are sufficient. Its value is diagnostic: if an approval cannot be converted into a narrow envelope, the permission has not yet been expressed precisely.

Execution establishes only that an action ran. It does not establish recovery. The proposed architecture includes post-action verification and specifies handback when verification fails or no playbook applies (source). The permission ladder distinguishes three verification outcomes:

1. Verified: the named checks meet their acceptance criteria.
2. Rejected: at least one check produces a defined failure.
3. Inconclusive: evidence is missing, stale, contradictory, or outside the verifier’s scope.

The third state prevents absence of evidence from being recorded as success and gives the handback path a concrete trigger. Whether these states improve recovery outcomes remains an empirical question; the available assessment identifies no production trial (assessment).

Reversal is not inherited

Rollback is another mutation, sometimes with a different blast radius from the original action. Permission to restart a component does not imply permission to restore data, change routing, rotate credentials, or deploy an earlier revision.

Reversal authority can therefore have one of four bounded dispositions:

• no automated reversal;
• propose reversal for human approval;
• execute one named reversal playbook after failed verification;
• hand back immediately because no approved reversal exists.

This classification is derived guidance. It turns the architecture’s handback condition into an explicit permission decision without implying that every incident has a safe automated rollback.

A team can test the framework against one recurring, low-scope incident class before granting remediation authority. The completed record should name every data source, policy check, approver, executable action, verification signal, reversal option, and handback owner. Denial and inconclusive-verification paths deserve the same scrutiny as the successful path.

The useful artifact is not an autonomy label. It is an action-level account of what the system may observe, propose, approve, execute, verify, and reverse—and where a person resumes control. Teams exploring this boundary can apply the same framing as they build agent systems.