AI agent has more production access than your senior engineers
2 comments
This is exactly the problem. The blast radius question is real. One pattern I've been exploring is a deterministic governor that sits between the agent loop and the tools. Before any tool executes, it checks: is this a repeat? Is this tool quarantined because it's been failing? Is this a side effect that already fired? Have we exceeded the cost budget? The decision is pure computation, no LLM calls, just counters and signatures. It won't solve the permissions problem, but it limits how much damage an agent can do once it has access.
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.