AI coding agents are already doing real enterprise software development work. They write code, read repositories, run tests, open pull requests, and help engineering teams move faster. In some organizations, a human reviews agent-written code before it ships to production.
That’s a big shift, and the productivity gains are real. Yet many companies still govern agents like software features, even as those agents start behaving more like autonomous users.
An agent that works across code, APIs, documentation, and internal tools has a real operational footprint. It can make useful decisions. It can also leak credentials, reach data it shouldn’t touch, hard-code secrets, or create downstream risks.
Most of these exposures come from ordinary execution. Agents want to make you happy, so they will complete the task at almost any cost. If the environment presents risky options, the agent may take them. That’s why the conversation around AI agents has to move from demos to infrastructure.
Limit the blast radius: Restrict what AI agents can access
Engineering organizations are usually good at managing their people, systems, and production environments. They run mature processes for identity control, network policies, audit logs, role-based permissions, review workflows, and cost controls. Then agents arrive, and teams forget half the processes they already had in place.
The biggest early mistake is giving agents too much room to roam.
Network access is the clearest example. These agents generally don’t need to search the internet. They may need to reach a repository, a package source, a documentation site, or a build system. So deny everything by default, then add back only the paths and tools the agent needs.
This single change eliminates much of the risk. An agent with unrestricted internet access can leak data in more ways, download untrusted packages, or connect to tools no one intended it to use. An agent with restricted network access has fewer risky paths in front of it. Good governance feels boring, and that’s the point.
The same logic applies to where agents run. Running them directly on a developer’s laptop is usually a terrible idea. That machine may hold cached tokens, local secrets, SSH keys, source code, and configuration files scattered across the system. When the agent runs there, it inherits far more privilege than the task requires.
A better approach gives agents temporary, controlled environments. The agent gets what it needs to do the job, and once the work is done or a human has reviewed the output, the platform tears the environment down.
Give AI agents delegated authority, not their own identity
Many teams still treat agent access as a set of API keys, which gets complicated fast.
I’ve seen teams hand out hundreds of keys to access the same model. That creates unnecessary operational complexity, and it creates governance gaps. You need to know who used each key, which agent did the work, which model it reached, which tools it called, and who approved it. If you can’t answer those questions, you don’t have agent governance. You have agent activity.
Agents need identity-aware routing, because the organization has to know which human delegated the task, which agent did the work, and which systems it touched along the way. That gives platform and security teams a clean way to grant access, revoke access, enforce policy, monitor behavior, and investigate incidents.
Here the industry needs to choose its language carefully. I don’t love the idea that agents belong on the org chart as if they were independent employees. That framing hands agents too much autonomy and pulls accountability away from the person who invoked them.
A better model: every individual contributor is now a team manager who delegates work to agentic teammates. You can evaluate the agent for quality, while the human still owns the outcome.
Establishing that ownership matters because trust erodes quickly without a clear way to identify the source of the work. Security teams need confidence that the agent never touched sensitive systems. Engineering leaders need to know that a human properly reviewed AI-generated code before it moved forward. Developers need to know whether a person or an unchecked agent created the pull request waiting on their approval.
The model should stay simple. An agent proposes a change, a human verifies it, and the record shows both. That makes agent-generated work easier to trust, because it shows who contributed, who reviewed it, and how it became part of the final output.
Control AI agent tool access with least privilege
Agents get much more useful when they can use tools. They can work with repositories, ticketing systems, documentation platforms, databases, cloud services, and internal APIs. That’s when they start doing meaningful work instead of just generating suggestions.
It’s also when the risk changes. Tool access can’t be a free-for-all. An agent shouldn’t get to discover and connect to every available tool just because a service exposes an interface. In practical terms, you firewall the agent and proxy its traffic.
That layer should authenticate requests, restrict access, monitor behavior, and block unsafe calls. It should also audit tool use at the agent level. Logging that a developer opened a workspace isn’t enough. Teams need to know which prompt the developer issued, which model responded, which tool calls the agent made, which identity it used, and what changed as a result.
Least privilege matters here too. A developer may have access to dozens of repositories and systems. The agent working on a single task usually needs far less. Give it the repository, branch, files, tools, and data the task requires. Nothing more.
Treat AI agents as production infrastructure, not experiments
AI agents are becoming a major part of how teams build software, and more companies now run them as part of their production infrastructure. Organizations that adopt them well can ship new applications much faster without treating every agent deployment as a security exception. Organizations that get it wrong will learn the hard way that productivity without governance is just a bigger blast radius.
