AI Agents Need IAM More Than Prompts
Better prompts won't save you. Better permissions might.
In July 2025, an AI coding agent inside Replit deleted a production database. Real records: over 1,200 executive contacts, spanning nearly 1,200 companies. The team had put the system into a twelve-day code freeze and told the agent, in plain language, not to touch production. The instruction existed. It just existed as text in a prompt, not as anything the agent's execution path actually enforced.
That distinction is the whole article.
One incident is an accident. Two is a pattern.
Weeks earlier, the Amazon Q extension for VS Code shipped an update, version 1.84.0, straight to official users with a malicious prompt buried inside it. An attacker had found a GitHub token with more scope than it needed, inside the extension's own build pipeline, opened a pull request, and slipped in an instruction telling the agent to wipe local files and cloud resources back to a near-factory state. It only failed to run because of a syntax error in the payload. The company building a coding agent got compromised through its own CI/CD, by the same class of attack the agent itself is now exposed to on every repo it touches.
By 2026 this had a name: TrustFall. Claude Code, Cursor, Gemini CLI, and GitHub Copilot CLI all auto-execute MCP servers defined inside a project the moment a developer clicks "yes" on the generic "trust this folder" prompt, a prompt that never mentions MCP at all and defaults to yes on every one of them. A worm called Miasma had already used exactly that opening by mid-2026. Add servers that quietly poison their own tool definitions (Trend Micro found over 1,400 MCP servers exposed with no authentication at all) and packages that don't exist yet, because an agent hallucinated the name and an attacker registered it first, and the pattern repeats everywhere: the agent trusted something it should have treated as untrusted input.
The industry stopped pretending this was a tooling detail
AWS's security team published a formal control framework for AI coding agents on July 30, 2026, splitting controls into what happens at "authoring time" inside the IDE and "build time" inside the pipeline, and marking each one by whether it can be checked by a machine or needs a person to sign off. Buried in it is the sentence that matters most. The agent that wrote the code should not be the agent that reviews it. The framework also does something simple and overdue: an MCP server gets a scoped, dedicated credential, and autoApprove: ["*"] stops being a configuration option.
OWASP moved in parallel, publishing a Top 10 for Agentic Applications separate from its LLM Top 10 in December 2025. The distinction is the point. A model that returns text has one risk profile; an agent that can chain actions, hold credentials, and remember across sessions has another. Excessive Agency climbed the ranking on the back of incidents like the two above, not hypothetical ones.
This is not a new question. It just has a new subject.
Strip away the AI framing and everything above is an identity and access problem. Okta and AWS are both shipping primitives for agent identity now. A coding agent gets its own session-scoped token and a task-scoped IAM role instead of borrowing a developer's, its credentials expire on a timer instead of sitting in a .env file, and every action it takes lands in an audit trail a human can't quietly edit. AWS's own materials cite non-human identities already outnumbering human ones 25 to 50 times over inside a typical enterprise. The subject changed. The discipline didn't.
Key trade-off: scoping an agent's access does not stop it from doing damage inside the scope you gave it. Take a task-scoped IAM role with write access to one S3 bucket. It can still corrupt everything inside that bucket if the agent misreads the task. Least-privilege shrinks the blast radius. It doesn't replace review, and review has its own ceiling now.
Here's where I land personally: reviewing all of AI-generated code was never a real option. PRs with heavy AI involvement run 51% larger and carry 54% more bugs than the ones before them, while still reading clean enough to slip past a tired reviewer. Uncle Bob, who spent decades teaching a generation of engineers to treat every line as something they own, now argues the only way to profit from an agent is to stop reading its code at all and let a harder automated gauntlet do the judging instead. I made a version of this same argument in an article about Harness Engineering: a pipeline alone only ever catches what happens after the code already exists. If neither scoped access nor a review queue can cover everything, the only thing left to scale is judgment about where to spend it.
There's a limit to "stop reading entirely," though. Take a change that deletes production data or rewrites an IAM policy. It shouldn't get to hide inside an ordinary feature diff, waved through by the same gauntlet that clears everything else. That code needs to be visibly separated at the architecture level and routed to a human every time, while the agent runs unsupervised everywhere the blast radius is small. It's the same instinct as treating who, or what, wrote a PR as an input to review, just aimed at what the PR can actually reach instead of who opened it.
I've written before about agent identity from the other direction, where standards like ERC-8004 try to give autonomous agents a verifiable identity on-chain. What AWS and OWASP are converging on now is the infrastructure-side mirror of that same question: how a system decides who, or what, is running it, and what it's allowed to reach.
The Replit incident wasn't a prompt failure. The instruction was right there in plain English. It was an identity failure. Nothing in the execution path knew the difference between the agent talking to itself and the agent about to run a delete on a production table. Fix that layer and the prompt stops being the last line of defense.
If you're rolling out agent-driven development on your own team, I'd like to hear how you're scoping what it's actually allowed to touch.
Written by Gil, a Principal Software Engineer with 19+ years of experience, focused on shipping AI-driven backends that hold up in production.