Your Infrastructure Assumes a Human at the Keyboard

In July 2025, a Replit AI agent deleted a live production database during an explicit code freeze, affecting over 1,200 executive users.

The detail that matters is not that an agent made a mistake. Agents make mistakes, and so do people. The detail that matters is this: the agent had the permissions to do it. Nobody gave an agent the right to drop a production table. Somebody gave a service account broad database access years earlier, for a deployment script. Then an agent was handed that account, because it was the one that worked.

That is the whole story of infrastructure in 2026, and it is not really a story about AI. It is a story about tools that were designed, at every layer, around things human operators do that agents do not.

A human running terraform apply against production reads the environment name and feels something. A human about to run kubectl delete in a namespace they don’t recognize hesitates. A human in a cloud console at 2 AM types slowly. That hesitation was never a control anyone designed. It was a free one, and we built the whole operational stack on top of it without ever writing it down.

Every safety feature you got from human hesitation is now gone, and it was never in your architecture diagram — so nobody will notice it is missing until it is the subject of a postmortem.

This is part seven of Rethinking the SDLC. The previous pieces dealt with producing and verifying changes. This one is about the ground they land on, and what it takes to hand the operator’s chair to something that never gets nervous.

The unwritten controls we’re losing

#

Let’s be exact about what human operators gave you that nothing in your stack replaces.

Hesitation that grows with the danger. Humans slow down near danger. Not reliably, but roughly in step with the stakes. An agent runs list_buckets and delete_bucket at exactly the same speed.

Context that never entered the system. “We don’t touch that cluster on Fridays.” “That table looks unused but the monthly usage report reads it.” “That service account is over-permissioned, we’ve been meaning to fix it.” All real constraints, all living in people’s heads, all invisible to anything that is not a person who has been here two years.

Fear of the consequences. A human who drops a production table has a very bad week. That is a real control, and I don’t mean that unkindly — accountability changes behavior. An agent cannot be held accountable. Only its operator can, which is exactly why the operator’s power to fence it in is the whole game.

Making it up, but with judgment. When a human hits an unexpected state halfway through a procedure, they stop and think. An agent hitting an unexpected state tries the next likely thing, confidently, straight away. That is usually helpful. During an incident, in production, it is how a small problem becomes a large one.

Reading the room. A human sees the deploy channel is on fire and doesn’t ship. An agent has no room to read, unless you deliberately wire the room into its context.

None of these were controls we designed. They came free with the operator, and we quietly built assumptions on top of them. Every one has to become a real mechanism now, or it is gone.

Declarative infrastructure was right all along — and we kept sabotaging it

#

Here is the genuinely good news, and it should change how you think about this whole shift.

Infrastructure-as-code, done properly, is already the right interface for a non-human operator. Think about what a Terraform plan actually is: a stated target state, a computed diff against reality, a clear list of what will be created, changed, and destroyed, and a separate approval step before anything happens.

That’s an evidence package. That’s exactly the artifact the previous articles in this series have been demanding — intent, diff, blast radius, and a gate. We built the right pattern fifteen years ago for reasons that had nothing to do with AI, and it turns out to be the pattern that makes agent operation workable.

The problem is that no organization actually operates that way, and we all know it. We have IaC and we have:

• Cloud consoles with no plan, no diff, no dry run, and no undo.
• kubectl exec into a running pod, because that’s how you actually debug.
• Prod shell access for the on-call, because sometimes you need it.
• Manual scaling during a traffic spike, because the automation was too slow.
• A dozen scripts/ files that do imperative things nobody reviews.
• Drift, everywhere, because the console change never made it back to the repo.

Every one of those escape hatches exists for a good reason: a human needed to do something urgent, and the declared-state path could not say it fast enough. And every one of them is an unguarded door into production where you tell the system what to do rather than what should be — with no diff, no plan, and no approval step.

When the main operator was human, escape hatches were a manageable risk, held down by fear and by how rarely anyone used them. Hand them to a fleet that never stops, and they become your biggest risk. The Replit incident is an escape-hatch incident. So is nearly every agent infrastructure failure I have seen or heard about.

The conclusion is unusually clean: the job is not to build new agent-safe infrastructure. It is to finish the declarative work we started and close the hatches. That has been sitting in the backlog for a decade, and it just became urgent for a new reason.

Five properties infrastructure needs when the operator isn’t human

#

1. Every action is a declared intent with a computed diff

#

An agent should never be able to tell your infrastructure to do something. It should only be able to say what should be true, and let the system work out what changes — so somebody can inspect the change before it happens.

This means the agent’s interface to production is not the AWS SDK, not kubectl, and definitely not a console. It’s a pull request against a declared state, plus a plan. If your agents can reach production APIs directly, you have no gate. You have a hope.

Practically: an agent that needs to scale a service opens a change to the declared replica count. An agent that needs to investigate a pod uses a read-only diagnostic path, not exec. An agent that genuinely needs to perform a direct action gets a narrow, purpose-built tool that does exactly that one thing, with its own permissions and its own audit record — not general shell access.

That last point is the design rule worth learning by heart. Every capability you grant an agent should be the narrowest tool that does the job, not the general interface that happens to include it. Anthropic’s engineering write-up on containment puts it well: supervise what agents can do, not what they do. Watching behavior doesn’t scale. Limiting capability does.

2. Blast radius is a budget, declared per lane

#

Right now your agent’s blast radius is “whatever its credentials allow” — which is almost always far more than the task needs, because credentials pile up and nobody ever takes one away.

Turn it around. Each agent lane gets a written budget, and the credential enforces that budget — not an instruction:

• Scope: which accounts, projects, clusters, namespaces, and resource types.
• Actions: read, create, modify, destroy — listed one by one. Most lanes never need destroy.
• Volume: how many resources may change in one run. An agent that has changed 200 resources when it expected to change 3 should be stopped by a quota, not spotted later by a human.
• Spend: a hard cost ceiling per run. Infrastructure mistakes turn up on the bill before they turn up in an incident, and a spend cap is the cheapest circuit breaker there is.
• Time: credentials that expire in minutes. A short-lived credential is worth more than a long policy document.

Two things make this real instead of a wish. First, the credential belongs to the lane, not to the agent. One agent doing three jobs should hold three credentials and use the narrow one. Second, going over a budget stops the run, it doesn’t warn. A budget that sends a Slack message is a metric. A budget that halts execution is a control.

And on credentials: GitGuardian detected 28.6 million new secrets in public commits in 2025, up 34% year over year, with AI-assisted commits leaking at roughly twice the baseline rate. Long-lived fixed credentials in an agentic environment are no longer a tidiness problem. They are how a small mistake turns into a breach. I’ll take the full agent-identity problem apart in the security piece later in this series.

3. Reversibility is a precondition, not a hope

#

Here’s a rule I’d hold hard: an agent may not take an action whose undo path doesn’t exist before the action runs.

Not “we have backups.” A real, tested, runnable way back, named in advance:

• Deploy → previous version pinned and one command away.
• Schema migration → down-migration written, tested against a production-shaped snapshot, and required as part of the change.
• Resource deletion → soft delete with a retention window, or a snapshot taken and verified first.
• Config change → previous state captured and restorable.
• IAM change → the previous policy recorded, ready to reapply.

Then sort changes by how easily you can undo them, not by how big they look, because that is what really decides the shape of a bad day:

Reversible in seconds (scale, flag flip, cache clear): high autonomy is appropriate. Let the agents run. Reversible in minutes (deploy, config): autonomy with automatic rollback triggers on health signals. Reversible with data loss (destructive migration, deletion): human authorization, always, with the reversal plan reviewed as part of the approval. Cannot be undone (data destroyed past retention, key deletion, anything sent outside the company): agents prepare, humans execute. Full stop. No track record is good enough to earn this rung, because there is no way back when it goes wrong.

Notice that the “cannot be undone” list is short, and that keeping it short is an architecture decision.

4. Environments are ephemeral, and every agent gets its own

#

Shared, long-lived environments are where agent operations go wrong in ways that are miserable to debug. Two agents in one staging environment get in each other’s way, and it looks exactly like a bug in the code. Neither agent knows the other exists.

The fix is not coordination, it is isolation. Short-lived, on-demand, one-per-lane environments, built from declared state, with production-shaped data (fake or masked), and torn down when the run finishes. An agent with its own world can be given far more freedom inside it, and freedom inside a sandbox is where the real leverage sits. An agent that can break a disposable environment freely will find things no read-only analysis ever would.

This is also the cleanest answer to “how do we let agents test infrastructure changes?” You don’t read their plan and hope. You let them apply it somewhere real and throwaway, then require the evidence from that run as part of the change.

That makes short-lived environments a hard requirement, not a nice platform feature. If building a realistic environment takes your team two days and a ticket, your agents will never verify infrastructure changes, and you will be reading plans by eye forever.

5. Policy-as-code is the approval boundary, and it must fail closed

#

The last property is where governance stops being a document.

Every constraint that lives in a wiki page, an unwritten Slack rule, or a senior engineer’s memory has to become a policy that runs on every change and can refuse it:

• No public ingress on resources tagged internal.
• No IAM policy with a wildcard action on a production account.
• No unencrypted storage. No unencrypted transit.
• No resource without an owner tag and a cost-center tag.
• No destructive migration outside a declared window.
• No new outbound network egress from this service tier.
• No change touching more than N resources without human authorization.

Two rules make this trustworthy. Policies fail closed: if the policy engine is down, or the answer is unclear, the change is refused. A policy layer that fails open is worse than none, because it creates false confidence. And exceptions are code with expiry dates — a named person, a recorded reason, an automatic revert. Permanent exceptions are how policy layers die.

This is where I would challenge how platform teams see themselves. Writing the policy that says what may exist in production is not infrastructure maintenance. It is writing the rules a workforce operates under. That is a different job, and the teams that see it early are the ones who will be running the show.

The console is now the most dangerous tool you own

#

One specific recommendation that will be unpopular, and that I would defend anyway.

Human-facing management consoles — AWS, GCP, Azure, your Kubernetes dashboard — are the worst possible interface in an agentic operation. They have no plan, no diff, no dry run, no undo, no code review, and no lasting record of what anyone intended. Everything they do creates drift. They exist because they are convenient for humans in a hurry.

They should be read-only for everyone, with write access only through a break-glass path — an emergency door that expires on a timer, needs a second person, announces itself loudly, and forces a postmortem entry. Not because people are careless, but because a console change is an unreviewed production change, and we stopped accepting those in code a decade ago.

The same logic applies to production shell access, kubectl exec in production namespaces, and any credential that lets a process do more than one thing. I made a cruder version of this argument a while back about not letting the monkeys touch production. The agentic version is not crude at all. Every direct path with no gate on it is a lane your fleet will find sooner or later, because agents explore the tools you actually gave them, not the ones you meant to.

Six moves

#

1. Inventory every credential your agents can reach, and what it permits. Not what it is for — what it allows. It takes half a day, it frightens people, and it is the only honest place to start.
2. Cut the destroy permission. Take delete rights away from every agent lane that cannot prove it needs them. This one change removes most of the disaster cases for most teams, and it costs almost nothing.
3. Make consoles read-only, with a break-glass path. Measure how often the emergency door gets used. That number is how much you depend on escape hatches, and it is your real automation backlog.
4. Require an undo path in every infrastructure change. Add it to the template. If the reversal isn’t stated, the change isn’t reviewable.
5. Move three tribal rules into policy-as-code this sprint. Pick the three most-violated ones. Make them fail closed. You’ve just converted three pieces of invisible senior judgment into infrastructure.
6. Time-box every credential. Short-lived, tied to a lane, created fresh for each run. If you do nothing else on this list, do this one. It puts a limit on every mistake you have not made yet.

Operations was always about limits

#

The thing I keep coming back to, from my NOC years onward, is that operations was never really about knowing how to fix things. Plenty of people know how to fix things. Operations is knowing what you are allowed to do at 3 AM, what you must never do without waking someone, and how far the damage can spread if you are wrong.

We wrote almost none of that down. We hired for it, we trained it through scar tissue, and we counted on it living inside the heads of the people holding the pager.

Handing the operator’s chair to agents doesn’t eliminate that knowledge. It forces us to finally write it down — as budgets, policies, reversal plans, and tiers. And here is the part I find genuinely encouraging. An organization that does that work ends up safer than it was with humans alone, because those limits were never reliable while they lived in people’s memories. Tired humans at 3 AM break them too.

The agent runs the infrastructure. The engineer sets the limits it runs inside. Writing those limits down is the longest-lasting engineering work available right now, and almost nobody has it on a roadmap.

So here is the question for your team. If an agent with your current credentials decided tonight, confidently and wrongly, to clean up unused resources — what stops it? Name the mechanism, not the good intention.

If the answer is “it wouldn’t do that,” you’ve described a hope. Go find the credential.

I lead AI transformation for a global SaaS platform, and the credential-and-budget model above is the part of this work I’d least want to skip. If you’ve built lane-scoped credentials or admission policy for agent operations, I want to hear where it bit you. Find me on X, LinkedIn, or Telegram.