Giving an AI agent access to production is not a yes-or-no decision. The useful question is which actions it gets, under which conditions, and who is accountable when one goes wrong. This post lays out tiered autonomy for AI agents: a way to draw the line per action instead of per agent, so trust is earned in steps and mistakes stay small.
I’m writing this as a design opinion, not a case study. The reasoning comes from how reliability engineering already treats risk: blast radius, reversibility and detection time.
Why all-or-nothing access fails
Most teams start with one of two positions. Either the agent gets nothing, or it gets the same credentials an engineer has. Both are bad defaults.
“Nothing” wastes the part where agents are genuinely useful: reading logs, correlating signals, drafting a fix at 3 a.m. “Everything” ignores that an agent is a non-deterministic system acting at machine speed. It can be wrong confidently, and it can be wrong 40 times in a minute.
The line should not sit between the agent and production. It should sit between individual actions.
Why tiered autonomy for AI agents works
Tiering maps cleanly onto how we already think about change risk. You don’t treat a log query and a database migration the same way. The agent shouldn’t either.
Four questions place any action in a tier:
- Is it reversible? Restarting a stateless pod is. Deleting a volume is not.
- What is the blast radius? One replica, one service, one region, or everything?
- How fast would we notice a mistake? Actions with loud, immediate failure signals are safer than silent ones.
- Does it touch sensitive data or credentials? If yes, the bar goes up regardless of the other answers.
The five tiers
| Tier | Name | What the agent can do | Human involvement |
|---|---|---|---|
| 0 | Observe | Read logs, metrics, traces, resource state | None needed |
| 1 | Propose | Open a pull request, create a ticket, post findings to the incident channel | Human reviews and applies |
| 2 | Act within limits | Reversible, low-blast-radius actions such as restarting a pod or scaling within bounds | After the fact (audit log, alerts) |
| 3 | Act with approval | Deploys, config changes, anything with wider impact | Explicit approval before execution |
| 4 | Never | Deleting data, changing IAM, disabling audit logging, billing changes | Humans only |
Tier 4 is not a temporary state. Some actions stay human-only because the cost of one bad call is higher than any time saved.
A policy sketch
Here is how I’d express the tiers as policy. This is an illustrative sketch, not the format of any specific tool.
# Illustrative policy sketch. Not tied to any specific product.
tiers:
observe:
allow: [read_logs, read_metrics, list_resources]
propose:
allow: [open_pull_request, create_ticket, post_to_incident_channel]
act_with_limits:
allow: [restart_pod, scale_deployment]
limits:
environments: [staging]
max_actions_per_hour: 5
require: [audit_log, rollback_plan]
act_with_approval:
allow: [deploy_release, change_config]
require: [human_approval]
never:
deny: [delete_data, modify_iam, disable_audit_logging, change_billing]Note that act_with_limits starts in staging only. Production comes later, per action, once the agent has earned it.
Enforce tiers in infrastructure, not in the prompt
A system prompt that says “never delete anything” is a suggestion. Real boundaries live in the credentials the agent holds.
Give the agent its own identity, never a human’s. In Kubernetes, a Tier 0 identity can be a read-only Role bound to a dedicated ServiceAccount:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: staging
name: agent-readonly
rules:
- apiGroups: ["", "apps"]
resources: ["pods", "pods/log", "services", "events", "deployments"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: staging
name: agent-readonly-binding
subjects:
- kind: ServiceAccount
name: sre-agent
namespace: agents
roleRef:
kind: Role
name: agent-readonly
apiGroup: rbac.authorization.k8s.ioThen verify the boundary instead of trusting it:
kubectl auth can-i get pods \
--as=system:serviceaccount:agents:sre-agent -n staging
kubectl auth can-i delete pods \
--as=system:serviceaccount:agents:sre-agent -n stagingExpected output:
yes
noThe same idea applies outside Kubernetes. Use separate cloud roles per tier, short-lived credentials, and an approval step enforced by the pipeline rather than by the agent’s good manners.
Moving an action up a tier
Promotion should be per action, not per agent. “The agent is good now” is not a criterion. “The agent proposed this exact action 30 times and humans approved it unchanged every time” is closer to one.
Record every proposed action alongside what the human did with it: approved, edited or rejected. That log is your evidence. If the edit and rejection rate for an action is high, it stays where it is.
Demotion needs to be just as easy. One bad outcome should be able to drop an action a tier immediately, without a committee.
When to use it, and when not to
Tiered autonomy fits when:
- The agent will act on live systems, not just answer questions.
- You already have audit logging, RBAC and a change process to hang tiers on.
- You want to expand agent capability gradually and defensibly.
Skip the heavy version when:
- The agent is read-only by construction and has no tool that can change state.
- The environment is disposable, such as a throwaway sandbox where nothing is lost on failure.
Pitfalls and what I’d do differently
Tiering by tool instead of by action. A generic “run shell command” tool collapses every tier into one. Expose narrow, named actions instead, so the policy can say yes to restart_pod and no to delete_namespace.
Treating read access as harmless. An agent that reads logs, tickets or web pages is reading text that someone else may have written. That text can contain instructions aimed at the agent. If an agent has both untrusted input and the ability to act, the read tier is not risk-free. Keep untrusted-input agents away from Tier 2 and above.
Approval fatigue. If a human clicks “approve” 200 times a day, approval is theater. Keep Tier 3 small and make each request show what will change, not just what the agent wants to do.
Shared credentials. If the agent uses an engineer’s token, your audit log lies and your tiers don’t exist.
No kill switch. You need a single, tested way to revoke the agent’s access immediately.
If I were starting today, I’d stay at Tiers 0 and 1 for longer than feels necessary. Proposals build the evidence you need, and they cost almost nothing.
FAQ
What is tiered autonomy for AI agents?
It is a model where an agent’s permissions are grouped into levels by risk, from read-only observation up to actions that need human approval, with some actions permanently off-limits. Each action is placed in a tier based on reversibility, blast radius and detection time.
Should an AI agent ever have write access to production?
Yes, but only for narrow, reversible actions with limits and an audit trail. Anything wider should require explicit human approval, and some actions should never be delegated.
Is a system prompt enough to keep an agent safe?
No. A prompt can be ignored, overridden or misread. Enforce boundaries with identity, permissions and pipeline controls that the agent cannot change.
How do I decide when to give an agent more autonomy?
Promote one action at a time, based on a recorded history of proposals that humans approved without changes. Make demotion immediate after a bad outcome.
Summary
- Draw the line per action, not per agent.
- Place each action using four questions: reversibility, blast radius, detection time and data sensitivity.
- Enforce tiers with identities and permissions, not prompts.
- Promote actions based on recorded evidence, and demote quickly.
- Keep a permanent “never” tier for actions humans must own.
Next step: Which single action would you let an agent do unattended in production today, and what would have to be true first? Tell me through the Contact Me page.