How to decide what an autonomous agent is allowed to do before you decide how clever it is.
Originally published on AWS Builder Center
[https://builder.aws.com/content/3HRGyQKfP1sAjbyhm1WkJsBDca8/blast-radius-first-a-trust-tier-model-for-letting-ai-agents-touch-production]
Most conversations about AI in operations start in the wrong place. They start with the model - how good is it, how much can we trust its judgment, will it hallucinate a kubectl delete at 3 a.m. The capability question feels like the important one, so it gets all the attention.
It's the wrong question to lead with.
The question that actually determines whether AI-driven operations is safe or reckless isn't how good is the agent - it's what happens when it's wrong. Not if. When. Every automated actor, human or machine, eventually takes the wrong action against a live system. The engineers who've run production at scale know this in their bones: you don't design for the day everything works, you design for the day it doesn't. AI changes nothing about that principle and everything about its urgency, because an agent can be wrong faster, more confidently, and at higher frequency than any on-call human.
So this piece is about designing from blast radius first. Decide what an agent is allowed to touch based on what breaks when it's wrong - and only then worry about how capable it needs to be. I'll lay out a trust-tier model I've found useful for that, grounded in the same reliability discipline - SLOs, error budgets, progressive delivery - that we already trust to govern human change.
The capability trap
Here's the seductive logic that gets teams into trouble. The model is getting better every quarter. Once it's good enough, we'll let it do more. So autonomy becomes a function of trust in the model's judgment, and trust grows with benchmarks and vibes.
The problem is that model capability and blast radius are completely independent axes, and teams collapse them into one. A highly capable agent restarting a stateless pod is low-risk. A mediocre agent modifying an IAM policy is catastrophic-risk. Capability tells you how often the agent is right. Blast radius tells you how bad it is when the agent is wrong. You cannot buy down the second with the first. A 99.9%-accurate agent acting on something with an irreversible, estate-wide blast radius is still one bad call away from an incident you can't take back - and at machine frequency, 99.9% accuracy produces a wrong action surprisingly often.
This is why "let it do more once it's smarter" quietly inverts the safety model. It ties the size of the blast radius to the thing that varies most (model quality) instead of the thing you actually control (permissions). Reliability engineering solved this for humans decades ago and we forgot to apply it: we don't give a new SRE root on the billing database because they're clever. We give them scoped access that widens as the cost of their mistakes proves survivable. Same principle. Different actor.
Trust tiers: permissions scoped to reversibility
The model I use scopes agent authority to a single question asked of every possible action: how expensive is it to undo this if it's wrong? That gives four tiers.
Tier 0 - Observe
The agent can read everything and act on nothing. It surfaces correlations, drafts a diagnosis, proposes a remediation - and stops. A human executes. Blast radius: zero. This is where every agent starts and where most should live longer than teams want them to. The value here is real and underrated: a good Tier 0 agent that turns forty dashboards into one ranked hypothesis has already paid for itself, with none of the risk.
Tier 1 - Reversible action
The agent can take actions that fully self-heal or roll back with no residual state. Restart a stateless pod. Scale a deployment within pre-set bounds. Drain and cordon a node the cluster will replace. Flush a cache. The defining test: if the agent is wrong, the system returns to its prior state automatically or with a trivial, well-understood undo. Blast radius: bounded and recoverable. This is the sweet spot where autonomy earns its keep on toil.
Tier 2 - Semi-reversible action
Actions that can be undone, but at a cost - a config change that requires a redeploy to revert, a traffic shift, a scale-up that costs real money. Reversible in principle, but the undo has latency, blast radius, or a price tag. Agents operate here only with a guardrail outside the model: a policy engine that bounds the action, a canary that must stay healthy, an error-budget check that halts the action if the service is already burning budget. The agent proposes and initiates; the system, not the model's confidence, decides whether it proceeds.
Tier 3 - Irreversible / high-consequence
Deleting persistent data. Modifying IAM or security groups. Anything touching secrets, billing, or the control plane itself. Anything a human would need a second reviewer for. The agent's authority here is exactly zero, permanently, regardless of how capable it becomes. Not "not yet" - no. These actions get a human in the loop by design, because the cost of being wrong is unbounded and no accuracy figure justifies unbounded downside. The point of naming this tier explicitly is to stop the quiet drift of Tier 3 actions into Tier 2 because the demo looked impressive.
Mapping this onto real platform work makes it concrete. Automated pod restarts and bounded autoscaling sit comfortably at Tier 1 - reversible, well understood, safe to let run. Traffic shifts and configuration changes that need a redeploy to undo belong at Tier 2, gated behind canary health and an error-budget check rather than the agent's own confidence. And the things that warrant the tightest governance in any DevSecOps context - CI/CD pipeline changes, tool-access controls, IAM policy - are unambiguously Tier 3: no autonomous authority, human review by design, regardless of how good the tooling becomes.
Wiring the tiers to reliability primitives you already have
The elegant part - and the part that makes this practical rather than aspirational - is that you don't need new machinery to enforce these tiers. The primitives already exist in any mature SRE practice.
Error budgets become the throttle. A Tier 2 action shouldn't fire when the target service is already burning its error budget - that's precisely when an automated change is most likely to compound an incident. Gate agent actions on burn rate the same way you gate deploys. When the budget is healthy, the agent has room to act; when it's exhausted, autonomy contracts automatically. The error budget stops being just a release-cadence signal and becomes a real-time autonomy governor.
Progressive delivery becomes the safety envelope. Any Tier 2 agent action ships the way a risky deploy ships: to a canary first, watched against SLIs, with automated rollback if the signal degrades. The agent doesn't get a special fast path around the safeguards humans use - it gets the same envelope, which is the whole point. If your rollback automation is good enough to trust with a human's deploy, it's good enough to backstop an agent's action.
Policy-as-code becomes the tier boundary. The line between tiers can't live in a prompt - prompts are suggestions, and an agent under pressure will rationalise past a suggestion. The boundary lives in an external policy engine (OPA, admission control, IAM itself) that the agent physically cannot talk its way around. This is the single most important design commitment in the whole model: the tier boundary must be enforced by something the model cannot reason with. Guardrails the agent can argue with are decoration.
Put together, these give you an agent whose authority expands and contracts with the real-time health of the system, bounded by machinery it can't override - which is a far more honest safety story than "the model is good, trust it."
Why this beats "trust the model"
Three reasons this framing holds up where capability-first thinking doesn't.
It's auditable. "The agent can take Tier 0 and Tier 1 actions on these services, gated on error budget, with everything above requiring a human" is a sentence you can put in front of a security review, an auditor, or a nervous VP and have it mean something. "We trust the model's judgment" is not.
It's stable under model change. Swap the underlying model, upgrade it, downgrade it to save cost - the safety envelope doesn't move, because it was never a function of the model in the first place. Your risk posture doesn't silently drift every time a vendor ships a new version.
It decouples value from danger. Most of the operational value of AIOps lives at Tiers 0 and 1 - faster diagnosis, less toil, quicker recovery on reversible actions. Most of the danger lives at Tier 3. Teams that lead with capability chase the danger to get the value. Teams that lead with blast radius harvest the value and leave the danger on the table where it belongs.
Where to start on Monday
You don't roll this out as a platform program. You start by asking one question of whatever automation or agent you already have, or are about to build: what's the worst irreversible thing this could do, and what physically stops it? If the answer is "the prompt tells it not to," you have a tier boundary enforced by a suggestion, and that's the first thing to fix.
From there: inventory your candidate remediation actions and sort them into the four tiers by reversibility, not by how confident you are in the model. Enforce the Tier 2/3 line in policy-as-code, not prose. Gate Tier 2 on error budget. Keep everything at Tier 0 longer than feels necessary, and promote actions up a tier only when the tier below has proven boring. Boring is the goal. Boring is what safe automation looks like from the outside.
The agents will keep getting better. That's exactly why the discipline has to come from somewhere other than the agent. Blast radius first, capability second - and the reliability practice you already trust to govern human change is more than enough to govern the machine kind too.
This trust-tier model sits above two companion pieces I've written: pricing agent autonomy against error budgets and dollars, and building a production-safe AI remediation firewall for Amazon EKS.
Top comments (0)