There’s a pattern I keep seeing across teams adopting AI agents for infrastructure, and it’s starting to scare me.

A team sets up an agent to help with Terraform, Kubernetes configs, or cloud deployments. To make it useful, they give it cloud credentials, state files, sometimes CI/CD pipeline access. They test it in staging. It works. They move it to production. Nobody asks: what’s the blast radius if this thing gets prompt-injected?

Coding agents are not infrastructure agents.

The industry is conflating these two categories. We treat all AI agents as “AI-assisted development” and apply the same security model. But the threat surfaces are completely different.

A coding agent operates in a sandbox (your IDE), produces artifacts that get reviewed (PRs), and has a natural checkpoint (CI/CD). An infrastructure agent operates on live systems, produces changes that take effect immediately, and often has no checkpoint at all.

Using the same word “agent” for both is making us less safe. It lets teams apply their comfort with Copilot to justify comfort with an agent that has kubectl apply access to production.

The superuser-by-default problem.

In most setups I’ve seen, the AI agent inherits whatever credentials the developer has. Broad IAM roles created for human operators who exercise judgment. The agent doesn’t exercise judgment. It exercises permissions.

Your senior engineer has admin access but uses it carefully. Your AI agent has the same access and uses it indiscriminately. No concept of blast radius, no intuition about risk, no career on the line.

From a MITRE ATT&CK perspective, a single prompt injection on an infra agent with broad permissions gives you: credential access (read env vars), lateral movement (access other services), impact (modify/delete resources), and exfiltration (make network requests). Four major tactics from one vulnerability.

The convergence gap.

Even when an agent does the right thing, there’s a gap between the mutation it performs and convergence to a known-good state. Kubernetes controllers reconcile. Terraform plans drift. During that window, your infrastructure is in an unknown state, and the only entity that knows the intended state is the agent that made the change.

If the agent hallucinated, nobody knows intended state. If the agent got injected, the attacker knows and you don’t. This is the unsolved hard problem in agentic infrastructure.

What works: constrain before you automate.

Teams handling this well define explicit permission boundaries: which resources, which actions, which conditions. They require human approval for irreversible actions. They log every mutation with intent alongside action. They continuously compare actual state to intended state.

The exercise: if your agent got prompt-injected right now, what is the worst thing it could do with the credentials it actually has?

If the answer scares you, you have a permissions problem. The solution is not to stop using agents. It is to constrain them like any other service with production access: least privilege, audit trails, blast radius containment.

We are building tools for this at Stakpak (stakpak.dev). But even before tooling, just asking that question is the most important first step.

user:	aura-guard
created:	February 9, 2026
karma:	1
about:	Working on Aura Guard (OSS)

1.	1 points by aura-guard 93 days ago \| discuss
2.	Show HN: Aura Guard – stop agent tool loops and duplicate side effects(github.com) 3 points by aura-guard 97 days ago \| 2 comments