When the agent logs in on its own

What happens when an AI agent changes production on its own?

If an agent does most of the coding, if not all of it, understands what you want and can carry it out itself, why keep infrastructure as code at all?

I want to turn the question around. What actually happens when the agent simply logs in and makes the changes itself?

There is no diff. You cannot see what it intends to do until it has done it, and afterwards you only see the result, not how it got there. There is no review. Nobody looked at the change before it hit the environment, and nobody approved it. There is no rollback plan. If it goes wrong, you are left with an environment that looks different from a moment ago, and nothing but the hope that the agent remembers what it did and what the previous state was.

And there is often no audit trail showing that an agent did the work. It logs in with your credentials, so the log shows your name. When someone investigates who deleted the business-critical production database, the answer is: you did.

So the moment an agent logs in to your cloud environment by itself, the question is not whether IaC is dead. The question is whether you have done away with the one place where a person can still say no before something changes in production.

In April this year it took an AI agent just nine seconds [1] to delete a production database and its backups at a US software company, because it believed it was working in a staging environment. It did not make that mistake because it was stupid. It made it because it had access.

IaC is not dead. At Capacit we use Terraform, and the agents write a growing share of the code. That is fine. What makes us willing to let code change production at all has never been who wrote it. It is the workflow around it: a plan that shows the diff before anything happens, a review where a person says yes, and a Git history that lets us roll back. The agents do not make that workflow redundant. They make it the only thing standing in the way.

What the files are for

Say IaC and most people think of the files. The Terraform code, the modules, the state file sitting in file storage. Infrastructure described as text in a repository.

If that is what IaC is, it is easy to see why agents would make it redundant. Why should an agent first write text describing a server and then have a tool translate that text into API calls, when it can make the API calls itself? The files become a middleman, and middlemen get cut out.

It is a fair argument. It just rests on a wrong assumption about what the files are for.

The files are not the point. They are how we get four properties that we now take so much for granted we have forgotten why they are there.

The first is that the change exists before it happens. A plan describes what is going to happen, and it can be read, discussed and rejected without anything in the environment being touched. That sounds minor, but it is the only reason a change to production can be reviewed at all.

The second is that there is one place where a person says yes. Not a Slack message, not a spoken “just run it”. An approval on a pull request, with a name, a timestamp and the exact diff that was approved.

The third is that there is a way back. Git knows the previous version of the code, and a revert followed by an apply puts the environment back where it was. If something goes wrong, rollback is a procedure, not a memory exercise.

The fourth is that all of it can be proven afterwards. Who changed what, when, who approved it, and what the environment looked like before and after. For the clients we work with at Capacit, typically in regulated industries such as pharma, finance and law, this is not a nice extra. It is the requirement. An auditor does not ask whether your infrastructure is good. The auditor asks whether you can document who changed it, and with what approval.

None of these four has anything to do with the Terraform code. They come from the change going through Git and a pipeline, and from the pipeline, not the developer and not the agent, being the only thing with access to change production.

That is the list to hold the agents up against. Not “can the agent write Terraform”, but: does it still give us a change that exists before it happens, a person who says yes, a way back, and proof afterwards? And this is where it gets interesting. The answer does not depend on how good the agent is. It depends on where it logs in.

Where does the agent log in?

There are basically two ways to let an agent change infrastructure.

One is to give it access. A token, a role, a service principal, or simply the developer's own session on their laptop. The agent reads the environment, decides what should happen, and does it. It is fast, it is flexible, and it is how most teams start, because it is how the developer works too.

The other is to let the agent propose. The agent writes the change as code and opens a pull request, and from there the same rules apply as for everyone else: plan, policy checks, review, and only then a pipeline that carries out the change with its own credentials. The agent never holds access that can reach production.

Hold the two up against the list. With direct access, the change does not exist before it happens. Nobody says yes. There is no way back except the agent's own memory. And the log shows your name. All four are gone, not because the agent is bad, but because we have routed it around the place where they come from.

That is exactly what happened at PocketOS in April. An agent in Cursor, an AI-based code editor, was running on a developer's laptop. Along the way it found a token in a file that had nothing to do with the task. The token had been created to manage domains, but the platform could not limit it to specific actions, so it could do anything. The agent believed it was working in staging, called a delete endpoint, and nine seconds later the production database was gone. The backups were on the same volume, so they went with it. The company ended up rebuilding bookings from Stripe and old emails. The post-mortem is worth reading [2], because its conclusion is not that the agent made a bad call. Its conclusion is that a token sat on a laptop and could reach production. That was the root cause. The rules in the repo forbidding destructive commands did nothing.

So should direct access simply be banned? No. There are two places where it makes sense. One is troubleshooting, where the agent may read everything but change nothing. The other is temporary environments: a test or development environment created for a single task and deleted again afterwards, with nothing in it to protect. What the two have in common is that the access is either read-only or short-lived, and that it never reaches into production.

And review is not magic. It is exactly as good as the person doing it. When agents multiply the number of pull requests by ten, review turns into a rubber stamp, and then you have direct access with extra waiting time. That problem is real, and I will come back to it.

But it does not change the ground rule: the agent must not hold credentials that reach further than the task it is working on, and it must never hold credentials that can reach production. Production is changed by the pipeline. And the pipeline only does what a person or a policy has said yes to.

Who says yes?

Back to the rubber stamp. Here is the problem.

Review processes before AI were sized for the speed at which people write code. A developer might open two or three pull requests a day, and a colleague has time to read them properly. An agent can open twenty.

The first thing that happens is that reviewers drown. The second is more insidious. When nobody writes Terraform by hand any more, you slowly lose the ability to read it critically. You can still see that a pull request changes a security group. You just no longer notice that the rule is slightly too broad, or that the module being called has a default that does not suit production. Those are the mistakes that bring nothing down today but sit there waiting.

This is not just a hunch. DORA, Google's DevOps Research and Assessment programme, studies every year what separates strong software delivery organisations from weak ones. And no, not the EU regulation of the same name. Their latest report [3] draws on responses from nearly 5,000 professionals and finds that more AI use goes with higher throughput, but also with less stable delivery. It is the second year in a row they have seen that link. In their ROI report from May this year [4], they put numbers on it.

5 → 6%

change failure rate in DORA's model when an organisation adopts AI. The share of changes that fail in production.

approx. DKK 2.3m

in downtime in DORA's worked example for 500 people. It sounds like nothing, until it is your downtime.

The tempting fix is to have an agent review the agent's pull requests. That handles the volume. It does not solve the problem, because it only moves the trust one step further out. If the review agent says yes, who has actually said yes?

And that is the real point. A review is not a quality check. It is the moment responsibility changes hands. The person who approves a pull request is not saying “I have read this”. They are saying “this is my change now”. That is what made the pull request model more than bureaucracy, and it is what is at stake when review becomes a rubber stamp. You still have a name on the approval. You just no longer have anyone who means it.

So when an agent-written change takes something down at three in the morning, the question is not who wrote it. The question is who said yes, and whether they knew what they were saying yes to.

What I would do first

None of the following needs new tools. It needs a decision.

Give the agent its own identity. The first thing to go is agents that log in as you. Microsoft and AWS both now build agent identities into their identity platforms [5] [6], and in Microsoft's version the agent has no credentials of its own at all; it is issued short-lived tokens through a blueprint. The vendor is not the point. The point is that the log must show that it was an agent, which agent, and who started it. Nothing else makes the audit trail useful again.

No standing access to production. Not for the agent, and ideally not for the developer either. The only identity that can change production is the pipeline, and it has its credentials issued at the moment it runs, not stored in a variable. A token sitting in a file on a laptop is exactly what deleted PocketOS's database, and there is one in most of the repos I have seen.

Deletion is a platform decision, not a prompt. Repo rules that say “never make destructive changes” are a wish. Deletion protection on the database, a mandatory waiting period before a volume disappears, and backups in a different account from the one they protect are controls. If a control can be bypassed by phrasing the request differently, it is not a control.

Let the machine review what the machine can. Policy checks, cost estimates, security scanning and a rule that the plan may only contain changes in the environment the PR is about should all run before a person even sees the pull request. Not to replace the review, but so the reviewer spends their time only on what the machine could not decide. A destructive change in production needs a yes from two people, not one.

Review the plan, not the code. The diff that matters is not the lines of Terraform the agent changed. It is the list of what is going to happen in the environment: what gets created, what gets changed, what gets deleted. Someone who has not written Terraform in a year can read that list, and it catches the security group that ended up slightly too broad. Make it the rule that review is about the plan, and that a pull request without a readable plan cannot be approved. And let the person who approves the change be the one on call when it rolls out. That turns “this is my change now” into something people mean.

Before the next agent logs in

Hand-written IaC is on its way out, and that is perfectly fine. What is not fine is letting the workflow around it die along with it. Plan, review, rollback and an audit trail are not things we got because we wrote Terraform. We got them because we decided that production may only be changed in one place, by one identity, after a person has said yes. The agents have not changed that decision. They have made it matter more.