Every platform team is having some version of this argument right now.
One side: we already let an AI write application code, and that ships to production. Infrastructure is just more code.
The other side: a bad function throws a 500. A bad terraform apply deletes the database.
Both are right, which is why the argument doesn't resolve. And it doesn't resolve because the question is wrong.
"Can you let an AI agent touch production infrastructure?" treats this as a property of the model, as though there is a capability threshold, and once GPT-N crosses it the answer flips to yes. That's not where the risk lives.
The real question is: what stands between the agent's output and the cloud API?
In most setups being demoed today, the honest answer is nothing. An agent holds credentials, decides what to do, and does it. That is not an AI problem. You would not give a new hire that on day one either, and the new hire can be fired.
Here are the five conditions that actually decide it.
1. The agent proposes. Something else applies.
This is the load-bearing one. Everything else is detail.
An agent that generates a change and an agent that executes a change are different systems with different risk profiles, even when they run the same model with the same prompt. The generating agent can be wrong a hundred times a day at zero cost. The executing agent is one bad inference away from an outage.
So separate them. The agent writes infrastructure code and opens a pull request. The PR runs a plan. A human reads the plan and merges. The pipeline applies.
That flow already exists at most companies. The agent slots into the position a human engineer occupied (author of a change) and inherits every control that was already wrapped around that position.
What you must not do is give the agent a shortcut past the pipeline because it's "just a small change." The value of the boundary is that it has no exceptions. The moment there's an emergency path, the emergency path becomes the normal path.
If your answer to "how does the agent apply changes?" is anything other than "it doesn't, it opens a PR", then you don't have guardrails. You have a hope.
2. Every change is a diff a human can actually read
A PR boundary is worthless if nobody reads what's in it.
This is where AI-generated infrastructure gets quietly dangerous, because agents are verbose. Ask one to add a queue and you may get the queue, plus a reformatted module, plus three unrelated attributes it decided were missing, plus a provider version bump. Every line is defensible. The diff is 300 lines and the reviewer approves it in eleven seconds.
Two things fix this, and both are mechanical:
Scope the agent's output. One task, one PR. If the agent wants to reformat, that's a separate PR. Reviewers can hold a 20-line diff in their head. They cannot hold 300.
Keep plan output clean. This is the connection people miss between drift and AI safety. If your terraform plan already shows forty pre-existing diffs from configuration drift, nobody is reading plan output carefully; they scroll past it as routine. An agent's change then arrives into a review process that has already stopped functioning. Clean plans are a prerequisite for AI-authored infrastructure, not a nice-to-have.
3. Blast radius is bounded before the plan runs
Some changes are recoverable. Some are not.
Adding a security group rule is recoverable: you remove it. Adding a tag is recoverable. Scaling a node group is recoverable.
Destroying an RDS instance is not. Deleting a stateful volume is not. Replacing a resource whose identity other systems depend on is not.
A plan that contains destroy or replace on a stateful resource should not be treated as a normal review. It should stop, loudly, and require a different class of approval than "someone clicked merge." Not because the agent is more likely to propose it than a human, but because the cost of a wrong approval is asymmetric, and asymmetric costs deserve asymmetric friction.
# Machine-readable plan: the input to a policy check, not a human read
terraform plan -out=tfplan
terraform show -json tfplan > plan.json
# Anything being destroyed or replaced, by resource address
jq -r '.resource_changes[]
| select(.change.actions | inside(["delete"]) or index("delete"))
| .address' plan.json
Wire that to a check that fails when a stateful resource appears. The point is not the specific jq. It's that a machine reads the plan before a human is asked to approve it, and the machine's answer changes what approval is required.
This is also the honest test of whether you trust your own process: if you would not let a junior engineer merge a plan that destroys a database on a single approval, the agent shouldn't get one either.
4. The identity is the human's, not a shared robot account
When an agent acts, whose permissions is it using?
The convenient answer is a service account with broad access, shared by everyone who uses the tool. It's convenient because it works immediately and nobody has to think about scoping.
It's also the answer that destroys your audit trail. Six weeks later, when you're reconstructing an incident, every entry in CloudTrail says the same principal. You can see what happened. You cannot see who asked for it, which is the only part that matters when the question is whether it was authorised.
The alternative is that the agent acts on behalf of the person driving it, and inherits that person's permissions. If a developer cannot delete production databases, the agent cannot delete production databases while working for that developer, not because the agent was told not to, but because the credential doesn't allow it.
Two consequences worth being clear about:
- Your existing IAM roles become the safety boundary. If they are over-broad today, an agent makes that visible fast.
- Authorisation belongs at the identity layer, not in the prompt. A system prompt saying "never delete production resources" is a suggestion. An IAM policy is a rule. Only one of them survives a jailbreak, a confused tool call, or a model update.
5. Everything is reconstructible afterwards
Assume something goes wrong. It will; that's true of human-authored changes too.
The question is what you can reconstruct at 3 a.m.:
- What was requested, in the user's own words
- What the agent proposed, exactly
- What the plan said would happen
- Who approved it, and when
- What actually changed
If you have all five, an incident is a normal incident. You find the decision point, you fix it, you write it up.
If you're missing the first two (if the prompt and the proposal weren't retained), you have infrastructure that changed for reasons nobody can explain. That is a much worse position than an outage, because you cannot rule out that it will happen again.
Log the conversation, not just the commit.
The uncomfortable part
Read those five again with the AI removed:
- Changes go through review, not direct console access
- Diffs are small enough to actually read
- Destructive changes require heavier approval
- Every action ties back to a named person
- The decision trail survives
That's just competent change management. None of it is new, and none of it was invented for agents.
Which means the teams asking "is AI safe enough for production infrastructure?" are usually asking the wrong question about the wrong system. If your current process fails these five, you already have the problem. Engineers with console access and no review make the same mistakes an agent would, just more slowly and with better excuses.
The agent doesn't introduce the risk. It removes the delay that was hiding it.
So the honest answer to the title is: yes, if all five hold. And if they don't, your problem is not the agent.
Where to start
Don't start by evaluating models. Start by asking, for your current setup:
- Can anyone apply infrastructure changes without a PR? (If yes, fix that first: it's the whole boundary.)
- Does a plan with a destroy in it look any different from one without? (If no, add the check.)
- Does your cloud audit log tell you which human is behind each action? (If it says the same service account every time, that's the gap.)
Fix those three and you can adopt an agent tomorrow. Skip them and no model, however good, makes it safe, because the model was never the thing keeping you safe.
DevLift's agents are built on exactly this boundary: they generate infrastructure as code and open a pull request, and they never apply. Changes carry the requesting user's identity rather than a shared service account, plans are checked for destructive operations before review, and the full request-to-apply trail is retained. Book a walkthrough to see it against your own account.