Autonomous DevOps: A Framework for Deciding What AI Agents May Do Alone

Section 1

What is autonomous DevOps?

For two decades DevOps has been about automation: CI/CD pipelines, Infrastructure as Code, observability platforms, deployment systems. All of it moved execution off the human. None of it moved attention off the human. Someone still reviews the dashboards, investigates the alerts, decides whether an infrastructure change is safe, maintains the honeypots and keeps the Terraform aligned with reality.

The distinction that matters is between automation and autonomy:

So autonomous DevOps is not "an AI agent with production credentials". It is a way of engineering operational systems so that routine decisions no longer need our limited focus, while humans remain responsible for strategy, architecture and exceptions. Autonomy does not mean giving AI unrestricted control. It means identifying the operations that can be trusted to run alone, and building the machinery that enforces that decision.

Large language models matter here for one reason: they can assemble a fix for situations nobody wrote a rule for. That widens what an agent can do far beyond a scripted runbook. It also means the set of possible actions can no longer be listed in advance, so it can't be made safe by narrowing it to a few typed commands. It has to be made safe by deciding, case by case, whether each operation qualifies. That decision is the subject of this guide.

Section 2

Attention is the scarce resource

Opinion I think attention, not compute and not headcount, is now the binding constraint on running cloud-native systems. Here's the argument:

1. Automation scaled execution. Execution is now close to free.
2. Every automation we added created something new that needs watching: a pipeline, a dashboard, an alert rule, a Terraform state, a posture report.
3. So the number of decisions per engineer per week went up, not down. I call that attention debt: the accumulated volume of decisions a system needs from humans per unit of time. Every new alert rule and dashboard adds to it, and it compounds quietly.
4. Attention doesn't scale the way compute does. It's serial, it breaks under interruption, and it degrades with volume. Alert fatigue is what attention bankruptcy looks like.
5. So the next gain isn't "execute more". It's "decide less".

Two things from my own estate made this concrete for me. My IaC coverage was roughly half, which meant half the infrastructure was invisible to the tool that was supposed to manage it, and nobody was assigned to notice. And the posture scanners I run (Prowler, Trivy, Gitleaks, Checkov) produce findings faster than any person can triage them. The scan was never the bottleneck. Reading the output was.

AI coding tools make this worse before they make it better. They generate more infrastructure change, faster, and review capacity stays flat. In my view AI is both a cause of the review backlog and the only realistic response to it, which is exactly why the boundary has to be engineered rather than assumed.

Section 3

Autonomy is a property of the operation: verifiable, reversible, contained

Most discussion of AI agents in DevOps asks whether the agent is good enough. That's the wrong unit. The same agent can be perfectly safe planting a decoy credential and dangerous resizing a production database. What changes isn't the agent. It's the operation.

An operation can run without human attention when it has three properties:

These aren't a slogan. Each one can be measured from facts you already have: how many resources an operation touches and of what types, whether they're tagged production, whether the change class is additive or destructive, what the live metrics say about load right now, whether compliance tags are attached. Once you score operations instead of agents, a different set of questions becomes answerable:

This also reframes the useful engineering work. It isn't "build a smarter agent". It's building the machinery that decides which operations qualify, and making that decision auditable.

Section 4

The autonomy gate and the dial

In a real system the framework isn't a slide. It's a scoring function and a threshold. Here is how it works in Beamreach Compass, described in prose; the talk shows the code.

1. Score the operation. Every proposed operation gets a risk score built from five weighted components: blast radius, data loss, reversibility, operational load and compliance. Each component is computed from facts about the infrastructure (resource counts and types, environment tags, the change class, live CloudWatch metrics, compliance tags), not from the model's opinion of itself.
2. Score the urgency separately, because "risky" and "time-sensitive" are different questions.
3. Apply the gate. High-risk operations always require human approval, and so do moderately risky ones when they're also urgent. An operation may run unattended only if autopilot is enabled, it didn't trip the approval rule, and both its risk and urgency are at or below the ceilings the team configured.
4. Turn the dial. The team expresses how much autonomy it grants with one number: the maximum risk level allowed to run unattended. Everything else is derived. Unattended execution can be switched off entirely. When it's on, the default ceiling only admits the lowest-risk operations.

Raising the dial is an explicit configuration change made by a person, saved in the workspace config. It's not something the agent negotiates or adjusts for itself. Lowering it takes effect the moment trust is lost.

Section 5

Containing the model itself

The gate decides whether an operation may proceed unattended. A second, independent layer decides what the model can physically do, and that layer doesn't depend on the model behaving. In Compass the LLM runtime works under a restricted execution contract:

The last row is the weakest guardrail and the first five are the real ones. A prompt is a preference. A missing IAM permission is a boundary. Never rely on the model to respect a rule you could have enforced structurally.

Security challenges of autonomous DevOps agents

This is where most of the security risk lives, and it's worth listing plainly:

• Inherited credentials. An agent running on an engineer's session has the engineer's permissions. That's a loophole, not an operating model. Give agents their own narrow identity.
• Prompt injection through data. Agents read findings, logs, tickets and repository content, and any of it can carry instructions. Containment matters more than filtering: an injected instruction that can only produce a diff in a PR is a review problem, not an incident.
• Unbounded loops and spend. Agents don't get tired, so a stuck task can burn tokens indefinitely. Turn and loop limits are guardrails, not tuning knobs.
• Silent failure. Some operations fail by omission: a suppressed alert that should have fired. These need the most careful scoring (see the noise example below).
• Prompt-only rules. Any boundary that exists only in a system prompt should be treated as absent.

The design goal is to make the failure mode boring. If the model does something nobody anticipated, the worst case should be a bad diff in a PR that nobody merges. For the organisational side of this (trust, control, cost) see obstacles for autonomous software.

Section 6

Trust Engineering, and how teams actually adopt autonomy

Trust Engineering is the discipline of making an autonomous system's boundaries explicit, measurable and inspectable, so a human can extend or withdraw autonomy as a deliberate configuration change rather than an act of faith. The scoring function, the gate, the dial and the containment layer are all Trust Engineering. So is being able to answer, after the fact, why a given operation was allowed to run.

Opinion My bet is that most teams will adopt autonomy per operation class, not per team and not per tool. Nobody will "turn on the AI". They'll let canary placement run alone first, then Terraform imports, then low-risk finding triage, and keep rightsizing and deletions behind approval for a long time. The adoption curve is a risk threshold being raised one notch at a time, each notch justified by a track record on the notch below.

In practice that looks like this:

1. Observe. Let the agent find, score and propose. Every change goes through a PR a human merges. You're calibrating your trust in the scores, not the agent's prose.
2. Pick one operation class that scores high on all three properties and enable unattended runs for it alone, at the lowest ceiling.
3. Watch the outcomes, not the volume. Did anything need reverting? Did anything get wrongly suppressed?
4. Raise the ceiling one step, or don't. Lower it immediately when something surprises you.

Opinion Two more hypotheses I hold and want challenged. First, autonomy's real value is that it makes expertise modular, distributable and actionable: a version of "good" for a given operation that you can subscribe to and inspect, instead of rebuilding it in every team. Second, the moat isn't the agent. Agents are becoming a commodity. The assembled context is not: a queryable map of the estate where every fact carries provenance, confidence and freshness. Without that map, none of the scores above could be computed.

Opinion I also think self-hosting multiplies trust rather than being a feature: when the runtime is inside your boundary, "what is it doing with my data" stops being part of the conversation.

Section 7

Four worked examples

Each example follows the same pattern: what the operation is, how it scores on the three properties, whether it earns autonomy, and what actually exists. Using the same shape every time is the point. It's what makes this a framework rather than a set of demos.

Section 8

What's still hard: verifiability

The framework says verifiable, reversible and contained. The scoring function in Compass today measures containment and reversibility. It doesn't score verifiability at all. I'd rather say that here than have someone find it in the code.

Today, verification is after the fact and human: someone reviews the PR. For an operation to be genuinely unattended, the system needs a mechanical answer to "did this achieve its intent?" That could be a re-scan confirming the finding is gone, a plan diff that matches the proposal, or a canary that fires on demand. The IaC example shows it's solvable for some operation classes, because terraform plan already is that verifier. For others, like rightsizing and alert suppression, it's an open problem.

Opinion I think verifiability will turn out to be harder than reversibility or containment, and it's where the field is weakest right now, mine included. Everyone builds governance first because buyers ask for approval gates. Almost nobody asks for verification.

Other open problems I don't have good answers to yet:

• Are the weights right? I don't know. They're calibrated on my own estate and they're configuration, not doctrine. They need testing against other people's environments.
• Auditability of the gate itself. The action is a reviewable PR, but the reasoning behind each gate decision (the risk breakdown and thresholds at that moment) should be as inspectable as the action. That's work in progress.
• Cost. Turn and loop limits bound token spend, but budget-aware planning isn't solved.

Section 9

Frequently asked questions