Four-Tier Classification Over Binary Allow/Deny

The Limit of Binary Decisions

Traditional access control systems—especially those guarding infrastructure—default to binary outcomes: allow or deny. When dealing with human operators, this often works. Humans understand context. If a human requests admin access and receives a denial, they can file a ticket, explain the business justification, and wait.

Autonomous AI agents do not wait well.

If you put a coding agent or an autonomous SRE bot behind a strict deny-by-default firewall, it fails immediately. It tries to run kubectl get pods to orient itself, receives a 403 Forbidden, attempts to debug the 403 by creating a new IAM role, fails again, and spirals into an unrecoverable hallucination loop. To make the agent useful, operators often surrender and grant it broad, dangerous permissions.

We needed a system that breaks this binary. We needed graduated access.

The Four Tiers of Risk

In Iddio, the command classifier dissects every incoming HTTP request and assigns it to one of exactly four risk tiers: observe, modify, sensitive, and break-glass.

These are not arbitrary numbers. They are named strings, and the policy engine refuses to load a policy that references anything else.

Here is what they mean and why they exist:

1. Observe

This covers reads: GET, HEAD, OPTIONS, lists, and describes. The AI Reality: Agents need to read constantly to understand their environment. Policy almost always auto-allows this tier. Blocking reads makes an agent useless.

2. Modify

This covers ordinary writes: POST, PUT, PATCH. The AI Reality: Agents need to apply changes, but humans need to verify them. The default policy escalates these operations. The connection hangs, a human reviews the intent, and approves it.

3. Sensitive

This covers destructive or high-blast-radius operations. It includes DELETE verbs, but also mutations where the verb prefix indicates destruction (e.g., delete*, destroy*, purge*, evict*) regardless of the HTTP method. The AI Reality: When an agent decides to delete a namespace or drop a table, the human approver needs to know this isn't just a routine configuration update. Escalating this separately from modify ensures the human brings the right level of scrutiny.

4. Break-Glass

This covers the most dangerous operations: kubectl exec, port-forward, RBAC mutations, and credential-bearing cloud services like IAM, STS, or Secrets Manager. The AI Reality: Agents rarely need interactive shell access or the ability to mint new long-lived credentials. By default, these are hard-denied. They are only allowed when an operator explicitly opens the door via policy.

Why Not Just Use RBAC?

A common question is: "Why build this classifier? Why not just use Kubernetes RBAC or AWS IAM?"

The problem with native RBAC is that it operates on API verbs and resources, not on risk. In Kubernetes, a GET on pods and a GET on secrets both evaluate as "get" verbs in RBAC. But reading a pod's status and reading a database password have wildly different security implications.

Furthermore, RBAC is protocol-specific. Kubernetes RBAC cannot classify a Terraform plan or a raw gcloud API call.

Iddio's four-tier model is protocol-agnostic. The classifier maps the specific semantics of kubectl, aws, gcloud, github, and terraform into this universal vocabulary.

The Goldilocks Number

Why four tiers? Why not three, or five?

We tried other numbers. An earlier design featured five numbered tiers (T0–T4) with a complex runbook-based downgrade system. It failed because operators couldn't reliably predict which bucket a command would land in.

Three tiers (read, write, dangerous) also failed. It couldn't separate an ordinary write (deploying a new pod) from an irreversible one (deleting a production database). That separation is exactly where human judgment provides the most value.

Four named tiers—observe, modify, sensitive, break-glass—are the smallest set that allows a policy to say: "reads are free, writes need a nod, deletions need a careful nod, and shell access is off." It aligns perfectly with how operators already think about risk, translating their intuition directly into policy.