Autonomy Tiers
Autonomy tiers classify how much independent action an agent identity is trusted to take, per the CSA NIST AI RMF Agentic Profile. AIControls uses the tier to scale policy enforcement automatically — the same governance model applies whether an agent is fully supervised or fully autonomous.
The four tiers
| Tier | Name | Meaning |
|---|---|---|
| T1 | Human-directed | Every action is reviewed by a human before or immediately after it happens. |
| T2 | Semi-autonomous | The agent acts independently within policy guardrails; high-risk actions are logged for review. Default for unassigned agents. |
| T3 | Highly autonomous | The agent acts independently across a broad range of tasks; behavior is continuously monitored against a baseline. |
| T4 | Fully autonomous | The agent operates with minimal oversight; privileged operations require human-in-the-loop (HITL) approval per the CSA NIST profile. |
Tiers are ordered by increasing independence, not by trust or risk ranking on their own — a T4 agent isn't "more dangerous" than a T1 agent, it's simply granted more room to act before a human is consulted. Governance compensates by tightening automated oversight (behavioral monitoring, HITL on privileged ops) as the tier rises.
Default tier
Every agent identity resolves to a tier. Agents with no explicit assignment resolve to T2 (Semi-autonomous) — this is the safe default: independent operation within policy guardrails, with high-risk tool calls logged. There is no "unassigned" state visible to policies; object.agent.autonomyTier is never empty.
A Workload Blueprint declares an Autonomy tier for its workloads on the same T1–T4 scale, and a workload's override can replace it for that one workload. Raising either is a widening that you acknowledge.
Where the tier comes from
object.agent.autonomyTier resolves to the first of these that applies:
- The registered workload's tier. When the calling identity is a Pod-bound Kubernetes ServiceAccount whose identity binding selects a registered workload, the tier is the workload's: its override's, or its Blueprint's. A legacy Blueprint value reads as its tier:
supervisedas T1 andautonomousas T2. - The tier assigned on the Identities page (Inventory → Identities). This is how you set the tier of an identity that isn't a registered workload, such as a developer tool calling with a personal access token or an agent outside Kubernetes. See Assign Autonomy Tiers.
- T2, the default.
The workload's tier applies only through the identity binding created when you register the workload, never through the workload an identity was last seen running. When the binding is missing, ambiguous, or shared by more than one workload, the identity falls back to steps 2 and 3. When a workload acts on behalf of a user, the tier is still the workload's.
Registering a workload doesn't write anything to the identity: its effective tier changes to the workload's on its next request, and a change to the Blueprint's tier or the workload's override reaches its requests within about a second. A tier assigned on the Identities page takes effect fleet-wide within about 30 seconds.
The Identities page shows each agent's effective tier and where it comes from: from a Blueprint, from a workload's override, assigned, or the default. For an identity bound to a registered workload, the tier is read-only there and links to the Blueprint or workload where you change it.
Tier conflicts
An identity may already have an assigned tier when you register its workload. If the assigned tier differs from the workload's, the stricter (lower) tier applies until you resolve the conflict, so registering a workload never loosens its oversight. The Identities page lists every conflict, and on the identity's page you choose one:
- Use the workload's tier: clears the assigned tier.
- Keep the assigned tier in the workload's override: sets the workload's override to the assigned tier, then clears the assigned tier.
Each resolution writes a configuration audit event.
If a replica can't load the assigned tiers, such as when the store is unavailable at startup, it can't rule out a stricter assigned tier. Until the tiers load, it caps a workload's tier at T2.
CEL policy fields
Two fields are available on every agent identity in policy context:
| Field | Type | Description |
|---|---|---|
object.agent.autonomyTier | string | "T1"–"T4". Never empty — unassigned agents resolve to "T2". |
object.agent.autonomyLevel | int | The same tier as a number, 1–4. Use for range checks. |
# Match a specific tier
- expression: object.agent.autonomyTier == 'T4'
# Match T3 and above
- expression: object.agent.autonomyLevel >= 3
See Policy Context for the full field list.
Built-in policies
Four built-in policies ship enabled in Audit mode, under the Autonomy Governance category:
| Policy | Tier | What it does |
|---|---|---|
| autonomy-t1-audit-all | T1 | Records every action taken by a T1 agent, since the CSA NIST profile expects each one to be human-reviewed. |
| autonomy-t2-high-risk-tools | T2 | Audits high-risk tool calls (file writes, shell execution, database mutations, kubectl mutations) made by T2 agents — the default tier. |
| autonomy-t3-behavior-monitor | T3+ | Records all actions of T3 and T4 agents to feed behavioral baselines and budget review, satisfying the profile's continuous-monitoring requirement. |
| autonomy-t4-hitl-privileged | T4 | Flags privileged/write operations by T4 agents. Ships in Audit mode so upgrades never change behavior — switch it to Require Approval to enforce the CSA NIST T4 HITL requirement for real. |
All four start in Audit mode: enabling the tier model never blocks anything by itself. Graduate autonomy-t4-hitl-privileged to Require Approval once you've reviewed what it would have caught — see Replay.
Quarantine is the T4 kill switch. If a fully autonomous agent needs to be stopped immediately rather than routed through HITL approval, quarantine the identity from Inventory → Identities — this suspends the agent outright regardless of tier.
What the product does not do
The CSA NIST Agentic Profile recommends periodic reassessment of an agent's assigned tier (annual, quarterly, or monthly depending on risk). AIControls does not schedule or track these reviews — tier reassessment is an organizational process your team runs against its own cadence; the product's job is to enforce whichever tier is currently assigned.