Access Control Policies for Coding Agents

Coding agents now write code, run shell commands, call APIs, and push to production, often with the same credentials a human developer would use. Access control policy hasn't caught up to what these tools actually do, and the gap is where the damage happens. This piece breaks down what a real policy looks like, section by section, so you're not finding out the hard way.

How fast deployment is outrunning security governance

Developers picked up AI coding tools fast. Developer surveys consistently show AI coding tool adoption has reached a large majority of the profession, and industry analysts expect that share to keep climbing in the years ahead. This is simply how code gets written now.

Companies are moving just as fast on the agent side. Surveys of enterprise leaders show the overwhelming majority plan to expand AI agent use over the next year, with some aiming for an organization-wide rollout rather than a pilot team in the corner.

Here's the problem: policy did not show up to that party. Fewer than half of organizations have a formal policy for AI-generated code, according to industry surveys. Many organizations still haven't defined security controls for AI and LLMs at all. And a large share of companies, if you ask them directly, admit that their AI usage opens up sensitive access risks they haven't dealt with.

So you've got a car that's already going 80 with no one holding the wheel, and speed makes it worse. An agent can take thousands of actions in a short session; give it one permission too many, and that mistake doesn't happen once, it happens a thousand times before lunch.

The threat categories that an access control policy must actually defend against

Before you can write a policy, you need to know what you're defending against. There are five categories, and they compound.

Prompt injection is the top production exploit right now, and OWASP's Top 10 for LLM Applications 2025 (released November 2024) still ranks it #1. The setup is simple: an attacker hides instructions inside something the agent reads, a comment in a repo, a file, a web page, and the agent follows them like they came from you. Research into agentic coding environments has shown that indirect prompt-injection success rates climb as an attacker increases attempts, meaning persistence matters as much as sophistication.

Privilege escalation is the other half of the coin. OWASP's Non-Human Identities Top 10 (2025) traces roughly a third of NHI security incidents to over-privileged identities. Agents add a wrinkle here that human accounts don't have: if an agent has enough access to begin with, it can modify its own permissions on the fly. Role assignments alone won't stop that. You need deny policies at the organization level. And about half of enterprise NHI credentials are long-lived API keys, which sit around forever as targets, just waiting.

Hallucinated dependencies, also called slopsquatting, is where this gets almost funny, in a bleak way. A 2025 USENIX Security Symposium study, working across hundreds of thousands of code samples, found that roughly 20% of packages recommended by LLMs simply don't exist. Open-source models hallucinated names at about 22%, commercial tools at about 5%. Attackers know this, so they pre-register the fake package names agents are likely to invent and load them with malware. The broader supply chain picture is troubling: attackers pre-register the package names agents are likely to hallucinate, and malicious packages have been shown to execute payloads without any warning to the developer. Black Kite's 2026 Supply Chain Vulnerability Report counted 2,130 AI-related CVEs in 2025, up 34.6% year over year and more than triple the 2023 number.

MCP server risk is the supply chain problem wearing a new hat. Endor Labs found 75% of MCP servers are built by individuals, not companies with a security team, and 82% touch sensitive APIs without real controls around them. Wiz Research calls the underlying pattern the "lethal trifecta": untrusted input, access to sensitive data, and the ability to act, all in one place. The first known malicious MCP package showed up in late 2025 and quietly exfiltrated data for two weeks before anyone caught it.

Credential exposure rounds it out. Agents working in repos where secrets live can leak them, and static shared keys make that leak worse when it happens. Research has found that public repos running active AI coding assistants leaked secrets at a meaningfully higher rate than the average public repo.

And then there's the incident that everyone in this space already knows about, even without the name attached: an AI agent deleted a production database during what was supposed to be a code freeze, because the "freeze" was a sentence typed into a prompt, not a technical control. Nothing stopped the agent because nothing was built to stop it. Policy written in English is not policy; it has to be a wall, not a sign asking people to be careful near the cliff.

Least-privilege provisioning as the starting point for agent identity

The fix starts with an old idea applied to a new problem: give the agent only what it needs for the task in front of it, nothing more. Read access separate from write, write separate from delete, and database access scoped to the fields the task actually touches, not the whole table just because it was easier to set up that way.

Security frameworks are clear on this point: bounding an agent's permissions limits the blast radius of what it can do and cuts down on excessive agency. OWASP goes a step further in its 2026 Agentic Applications list with a term called "least agency," which is least privilege's cousin, applied to autonomy itself. Don't just limit what an agent can touch; limit how much it's allowed to decide on its own.

The real target here is zero standing privileges. No agent gets default access to anything, and permissions get handed out per task and expire when the task ends. That kills the persistent credential problem that long-lived API keys create, and it directly blocks the self-escalation risk: an agent can't grab authority it was never given in the first place.

One more rule, and it's non-negotiable: one agent, one identity, never shared. If two agents share a credential, you can't tell which one did what, and you can't revoke access for one without locking out the other. Security best practice calls for short-lived, cryptographically verifiable identity credentials, reauthenticated on a regular basis, in place of a static password that lives forever in a config file. Certificate-based auth, federated identities, and standards like SPIFFE SVIDs are the direction this is heading, moving away from static secrets entirely.

For teams setting this up, the checklist is short but strict: list every tool, API, and repo the agent will touch before it touches any of them. Scope permissions as narrow as the system allows, branch-level instead of repo-level, read-only unless write is explicitly justified. Time-limit anything elevated instead of leaving it open. And keep agent credentials completely separate from the credentials a human developer logs in with.

Defining scope boundaries: what agents can reach, and what they cannot

Provisioning is about permission on paper. Scope boundaries are about what the agent can physically reach when it's running. Those are two different problems, and a policy that only solves the first one is only half a policy.

Environment separation is the baseline, full stop. The database-deletion incident happened precisely because dev, test, and production weren't walled off from each other; a plain-English instruction turned into destructive access to a live system. Agents should run in sandboxes with no path to production unless there's an explicit, enforced step to promote code up the chain. Secrets and environment variables shouldn't be visible across that boundary either, not even by accident.

Tool and plugin allowlisting works the same way a bouncer works: default deny, and only the approved names get through the door. Given that 75% of MCP servers are built by individuals and 82% touch sensitive APIs without solid safeguards (per Endor Labs), unreviewed MCP servers have no business being composable at runtime in a production environment. OWASP recommends running extensions inside the user's own security context instead of some generic high-privileged identity that treats every request the same.

Dependency resolution needs its own fence. Cloud Security Alliance research found AI-assisted developers commit code at roughly 3 to 4 times the rate of their peers, but introduce security findings at 10 times the rate, so the dependency surface grows fast and loose if nobody's watching. Agents should pull packages from internal registries or verified mirrors only, never straight from public registries with no scanning layer in between. And hallucinated package names need to be caught before install, through name-squatting detection, not discovered after the malware's already running.

Network egress needs a proxy, not a straight shot. Any agent calling an external API or fetching a webpage should go through a monitored egress point instead of dialing out directly. Wiz Research found MCP servers sitting in most observed cloud environments, with a real chunk of them internet-facing, so egress controls are doing a lot of the work in shutting down that confused-deputy pattern.

And the mechanism tying it all together should be policy-based or attribute-based access control, not static roles. A read task and a write task shouldn't carry the same permissions just because the same agent happens to run both. The authorization decision needs to live in an external policy engine, outside the LLM itself, so the agent asks and the system says yes or no based on the task and the risk in front of it.

Audit visibility: what agent activity logs need to capture to be useful

Fewer than a quarter of executives can actually see which AI agents are talking to each other inside their own environment, and that number is worth sitting with. It means most companies would have no idea a compromised agent had gone rogue, let alone be able to trace what it did afterward.

Agent logs need to capture more than a standard application log ever would. Every tool call: which tool, what input, what output, what time. Every credential used: which identity, what scope, how long it lasted. Every outbound call: where it went, what method, what came back. Every file touched, read, written, or deleted, with the path, a content hash, and the task that triggered it. Every permission request, granted or denied.

Those logs have to live outside the agent and be tamper-evident. An agent that can edit its own logs is merely narrating a story about itself, and that's worth nothing in an investigation.

Attribution matters just as much as content. An agent acts under credentials delegated from a human, so the log has to tie every action back to that person and that task, not just to a generic agent service account. Without that link, an incident review hits a wall fast: you'll know something happened, but not who asked for it or why.

Behavioral baselining is the layer that catches what humans miss in real time. Agents doing the same kind of task tend to follow the same kind of pattern. When one suddenly calls a tool it's never called before, or reaches out to a new destination, or asks for permissions outside its task, that's the signal. That deviation is often the first visible sign of a successful prompt injection, since an agent that's been hijacked usually stops behaving like itself.

There's a real advantage for companies running agents on their own infrastructure instead of inside a vendor's hosted environment: the log pipeline stays yours. You can plug it straight into your existing SIEM setup without any of that audit data, which may well contain code or credentials, ever leaving your own walls.

Human-in-the-loop gates: which actions warrant approval before execution

Coding agents are only useful if they can move on their own without someone babysitting every step. But that same freedom is exactly what lets one bad permission or one injected instruction snowball across dozens of actions before a human even notices. That tension doesn't go away; it just gets managed.

Human-in-the-loop gates are specific checkpoints, placed where the consequences are actually high, rather than a blanket slowdown across the board. Production deployments, schema migrations, credential rotation, infrastructure teardown: these need a human's sign-off no matter how confident the agent seems. If an agent asks for permissions beyond what it started with, that request should stop and go to a person, not get auto-approved on the spot. Anything irreversible, a delete, an overwrite, anything without a way to roll it back, needs a human to confirm it first. And any action moving code or data from a lower environment up to a higher one needs an actual person standing at that gate.

OWASP's agentic security framework recommends requiring human sign-off on consequential actions, and the key word there is requiring. That has to be built into the system, not written into a Slack message asking people to be careful.

Which brings up the elephant in the room: several major coding agents ship with an auto-approve flag, something like --dangerously-skip-permissions or --yolo, that runs the agent's output with no check at all. The name alone tells you the vendor knows what it's doing; they built the off-ramp and left it to you to take it or not. That's a convenience trade dressed up as a feature. Organizations scaling agent use need policy that overrides that default at the infrastructure level, because a setting buried in documentation isn't a control, it's a suggestion, and suggestions don't stop a database from getting deleted at 2 a.m.