Every conversation about "AI autonomy" collapses into two camps within about ninety seconds. One says the agent should do everything, humans should review nothing. The other says the agent should suggest, humans should approve everything.
Both are wrong, in the same way. They treat autonomy as a single switch.
Autonomy is a ladder. You climb it one action category at a time, and only when you can prove the agent has earned the next rung. This is the framing under Trustworthy Autonomy™, and it is borrowed directly from the Cloud Security Alliance's Agentic NIST AI RMF Profile — four tiers of graduated autonomy, each with its own evidence bar.
The four tiers
The CSA taxonomy splits "how autonomous" into four distinct postures. These are not stages an agent passes through; they are postures an agent operates in per action category. The same agent can be Tier 1 on one kind of action and Tier 2 on another.
Most "AI compliance" products in 2026 are Tier 1 across the board. Some claim Tier 2 on narrow categories (drafting, summarization). Almost nothing in production runs at Tier 3 on a consequential action, and Tier 4 is a research target, not a shipping product.
The same event, three different responses
Walk through one event — a real one that ops teams see every week — to see how the tiers behave.
The event. The cloud-posture scanner flags an S3 bucket as publicly readable. The bucket was provisioned six weeks ago by an engineer who shipped a marketing landing page. The data in the bucket includes a CSV of leads, which is regulated under the customer's privacy policy. The agent has access to the cloud provider's API, the company's policy library, and the scanner's finding stream.
A public S3 bucket is the rare compliance event that is both fast to diagnose and high-cost to get wrong. The right action is technically simple. The autonomy question is not "can the agent do it" but "is the agent permitted to do it without a human."
Tier 1 — Supervised
The agent ingests the scanner finding, joins it to the policy library, produces an attestation that the bucket violates the public-data policy, drafts the bucket-policy change that would close the exposure, and queues all of it for human review. The human reads the analysis, approves the policy change, and clicks Apply. The change runs.
Time to resolution: hours to days (bounded by the human's queue). Risk surface:the agent cannot make any wrong action stick — the human is the gate. Cost of being wrong on the analysis: low; the human catches it.
Tier 2 — Constrained
"Close a public bucket containing regulated data" is, in the customer's policy, a pre-approved action category. The agent ingests the finding, produces the attestation, applies the bucket-policy change directly, and writes the action record. The runtime monitor watched the trajectory and confirmed nothing about the agent's reasoning looked anomalous. The on-call engineer receives a notification: "Auto-remediated finding F-1284. Public-data bucket policy applied. Action record: verify://…"
Time to resolution: minutes. Risk surface:only inside the pre-approved action category — anything outside escalates. Cost of being wrong: bounded by the per-category certified miss-rate, and by the canary check that compared this action to its Tier-1-supervised baseline.
Tier 3 — Broad-within-boundary
The customer has authorized the agent to act across a broader surface — any S3 misconfiguration touching regulated data classes, across the production AWS account. The agent finds the bucket, applies the change, and then runs through three adjacent buckets it finds in the same scan that share the same misconfiguration pattern. It writes one action record per bucket, all bound to the same scanner finding chain. A human reviews the action stream daily — or immediately if the runtime monitor flags an anomaly.
Time to resolution: minutes, across multiple findings.Risk surface:the broader scope — the boundary is the regulated-data-class envelope. Cost of being wrong:higher per-action than Tier 2, but the per-category certified miss-rate for this scope is tighter (the threshold tightens with the tier).
Tier 4 — Goal-oriented
The customer has set an objective: maintain SOC 2 CC6.7 compliance posture across the production AWS account.The agent decomposes the objective into sub-goals (no publicly-readable buckets containing regulated data; no IAM users with stale keys; encryption-at-rest on every storage service), plans the work, and runs it. The guardrails are a policy floor — never delete, never modify production identity boundaries, escalate before any cross-account action. The human set the objective and the floor; the agent executes within both. This tier does not exist in production today (more on that in article 6).
The two gates, not one
Every conversation about autonomy that conflates two distinct protections eventually breaks. Trustworthy Autonomy separates them on purpose.
The authority gate — who is permitted to license the action
Human-in-the-loop approval is an authority control. It answers 'is anyone allowed to do this' and binds the action to a human principal in the delegation chain. At Tier 1 the gate fires per action; at Tier 2 it fires once (when the scope is defined); at Tiers 3 and 4 it fires on objectives and out-of-scope escalations. HITL is necessary at every tier, just at different cadences.
The reliability gate — whether THIS run is going wrong
The runtime monitor watches the agent's trajectory as it executes and halts a run that is looping, misusing a tool, or drifting in its reasoning. It is independent of the human-approval queue. The point of the monitor is that a confidently-wrong agent run, with all the right approvals, is still a wrong run — and the monitor is what catches it between approvals.
Treating the human-approval queue as the reliability gate. It is not. The human at the queue sees the agent's output, not the agent's trajectory; they can catch obvious errors and approve subtle ones with equal confidence. The runtime monitor catches things the human approver could not see — the loop, the tool misuse, the reasoning drift — and halts them before they reach the queue at all. Trading the monitor for "we have HITL" is trading two protections for one.
What a tier promotion actually requires
Climbing the ladder is not a vendor choice; it is an evidence threshold. Each tier has a published bar across every measurable property of the action category. A promotion to Tier 2 on "auto-attest a SOC 2 CC6 control" requires, at minimum:
- The certified upper bound on the wrong-attestation rate for that category sits below the tier's threshold (10% at Tier 2, 3% at Tier 3).
- The runtime monitor's detection recall on that category's failure modes clears the tier's floor (95% at Tier 2, 99% at Tier 3).
- Reproducibility clears the floor (95% at Tier 2, 99% at Tier 3).
- The adversarial suite for the OWASP agentic-AI risk classes returns zero violations on the catastrophic subset, and below threshold on the broader set.
- Every action record completes the provenance schema and the action chain verifies.
- A canary run — the agent shadowing a human-supervised baseline on the same actions — agrees with the baseline at the canary threshold (97% over at least 200 shadowed actions for Tier 2; 99% over at least 1,000 for Tier 3).
Miss any of these and the category does not move. The action stays at the lower tier. The remediation is named explicitly. This is the difference between earning a rung and asserting one.
What this looks like for the buyer
For the team buying compliance AI, the trust ladder is the framework for asking better questions in the demo. "Is this agent autonomous" is the wrong question. "Which action categories is this agent autonomous on, at which tier, and what is the evidence?" is the right one.
A credible vendor answers: "On categories X, Y, Z we operate at Tier 2. The certified wrong-attestation rate, the runtime-monitor recall, the reproducibility floor, the canary-agreement number, the provenance completeness — here. Outside of those categories we escalate. Here is what we would need to clear before category W moves to Tier 2."
Anything else is a marketing answer. The next article in the series explains why the action record underneath all of this — the signed, hash-chained trail that lets an auditor reconstruct any action — is the substrate the whole framework rests on.
Where this matters next
How often is your compliance AI actually right? — the pillar of this series. Why the wrong-attestation rate is the binding metric for tier promotion, and why the certified bound (not the point estimate) is what decides whether an action category clears the gate.