The race to secure AI coding: 4 steps to rein agents in

The rapid adoption of AI coding agents is outpacing the security controls organizations have put in place to govern them.

According to JetBrains’ 2025 Developer Survey, 85% of developers now regularly use AI tools for coding and development, and 62% use at least one AI coding assistant. Gartner projects that figure will reach 90% of enterprise software engineers by 2028.

The security implications are significant. Coding agents have broad access to source code, repositories, credentials, and CI/CD pipelines, all of which are increasingly being targeted by attackers. 

Despite those risks, only 41% of organizations have a formal policy and guidelines for AI-generated code, according to JetBrains.

Here’s how to begin to shape the governance structures that will help you manage the risks associated with AI coding agents.

[ Join webinar: Forrester discusses top Agentic Development Security Tools]

1. Treat coding agents as an insider threat

Coding agents are often seen merely as productivity tools, but they are really highly privileged insiders, said Ram Varadarajan, CEO at Acalvio. 

“Once compromised through prompt injection or malicious content, they can become a direct pathway to source code theft, credentials exposure, cloud compromise, and supply chain attacks.”
—Ram Varadarajan

And coding agents don’t just execute predefined instructions; they can also read, interpret, and act on whatever content they encounter. That means that even an agent acting in good faith could introduce unexpected problems, said Jeff Williams, CTO at Contrast Security. 

“AI coding agents are not evil, but they are powerful, naive, and opaque.”
—Jeff Williams 

They are especially dangerous in development environments. Coding agents read untrusted code, documentation, tickets, comments, data files, logs, tool output, dependency metadata, and build results, Williams said. “The challenge is not simply using AI,” he said. “The challenge is constraining a deputy that already has access to the software factory.”

Addressing those risks starts with ensuring that coding agents operate with only the access they absolutely need to do their job.

2. Implement least-privilege access for coding agents

Organizations need to enforce strict access controls for coding agents because the tools often operate with broad visibility into source code, repositories, credentials, and development workflows. Limiting access to only the resources necessary for a specific task can reduce the risk of accidental exposure, misuse, or compromise.

Overly broad permissions can quickly turn a coding assistant into a privileged actor inside the software delivery lifecycle, said Ryan McCurdy, vice president at Liquibase. 

Agents should be able to read what they need, suggest changes, and open pull requests, McCurdy said, but they should not have standing production access, direct database credentials, or the ability to bypass approvals. 

“The pipeline should be the control point, not the agent.”
—Ryan McCurdy

The most effective control is enforcing least privilege programmatically rather than relying on the model to make security decisions, said Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs. 

“LLMs are non-deterministic by nature, which means they can be influenced by prompt injection or malicious context.”
—Jacob Krell  

Security boundaries should be enforced through external controls such as permission systems, allowlists, parameter validation, and policy engines that cannot be bypassed through conversation alone.

Don’t just give a coding agent developer access and hope for the best, Williams said.  Least privilege has to be task-specific: one repo, one branch, one job, one set of approved tools, and short-lived credentials, said Williams who is also one of the founders of OWASP. 

Read-only should be the default for agents. If the agent writes code, he said, it should create a branch and open a pull request and not be allowed to commit the code to main or to approve its own pull requests, change CI/CD, retrieve production secrets, or deploy.

“Zero trust was about admitting the network perimeter was dead. Coding agents force us to admit the development perimeter is dead. Once an agent is inside, reading untrusted code, tickets, docs, logs, and tool output, you can’t treat the dev environment as trusted anymore. You have to re-establish trust around every action the agent takes.”
—Jeff Williams

3. Augment — don’t dump — traditional AppSec practices

Organizations using coding agents still need traditional application security practices because AI-generated code can contain the same vulnerabilities, logic flaws, and insecure configurations as code written by humans. Security testing, code review, dependency analysis, and secrets scanning remain essential for identifying issues before software reaches production.

However, organizations need to augment traditional AppSec programs with controls tailored to AI coding agents, including safeguards against prompt injection, model manipulation, excessive permissions, hallucinated dependencies, and unauthorized access to sensitive code, data, and development infrastructure.

Traditional AppSec is necessary, but not sufficient, Williams said. “Coding agents change the problem because tools are now making changes, and humans are trying to keep up,” he said.

Security teams need governance for the agent itself: which repos it can touch, which tools it can invoke, which changes require approval, what evidence it must produce, and who is accountable when it makes a bad change. 

“The old question was, ‘Did this code pass the scanner?’ The new question is, ‘Should this agent have been allowed to make this change at all?’”
—Jeff Williams

Organizations should develop policies to define what agents are allowed to do, and the technological enforcement of those policies should happen outside of the agentic system, said Noelle Murata, chief operating officer at Xcape. 

Enable monitoring into agent operations to determine what additional controls or prompt adjustments are needed to corral potentially rogue or drifting agents.

“Continuous testing against a gold standard of behavior should be a key part of the CI/CD pipeline. These test suites should include both ‘happy path’ and ‘not-happy path’ tests for additional robustness.”
—Noelle Murata

Vineeta Sangaraju, AI research engineer at Black Duck, recommends implementing continuous AI observability in the form of prompt-to-output mapping, version control, decision boundaries for AI agents and their tools, and limited agency for high-risk agents, for example. 

“The challenge is that coding agents operate with varying degrees of autonomy and can influence multiple stages of the software delivery lifecycle. As a result, organizations need both traditional application security controls and AI-specific observability and governance to create an auditable and accountable development pipeline.”
—Vineeta Sangaraju

4. Treat all agent-affected code as untrusted

Coding agents can be extremely quick at generating code, but that doesn’t always translate into correct, secure, or production-ready output. This is especially the case when the code contains complex logic, ambiguous requirements, or security-sensitive functions.

A CodeRabbit analysis last December of 470 real-world pull requests showed that AI-generated code introduced 1.7 times more issues overall than human-written code. Logic and correctness problems occurred 75% more frequently than with human-written code, and security vulnerabilities were two times more prevalent. 

Another study, by Aikido, showed that about 20% of LLM-generated code referenced non-existent and completely hallucinated packages, leading to a new class of typosquatting attacks that some have begun referring to as “slopsquatting.”

Contrast Security’s Williams advises treating agent-written code like code from a very fast, very confident junior developer. “It might be useful, but it should not be trusted by default.” 

Every code change, such as a commit or pull request update, should go through security testing, secrets detection, dependency review, and policy checks. Extra scrutiny is needed around authentication, authorization, crypto, command execution, file access, secrets, logging, data access, and CI/CD, Williams added. “Backdoors are extremely difficult to detect. They can look like refactors, helpers, test changes, and small relaxations of security checks,” he said.

Move to zero trust for all AI coding agents

Liquibase’s McGurdy said such scrutiny is especially critical at the database layer. “An agent can generate a schema or data change that looks valid but still drops a critical column, deletes production data, weakens a constraint, exposes sensitive data, or creates drift between environments,” he said.  

Traditional code scanning may not always catch these issues because the risk is not always in the application code but in the structure and integrity of the underlying data, McGurdy said. “The right model is zero trust for AI-assisted development. Do not assume the agent’s output is safe because it looks right,” he said. 

Organizations should verify the code and route AI-driven changes through governed pipelines. Also key are policy checks, separation of duties, audit evidence, and monitoring for drift, McGurdy said.

The only assumption should be that every line of agent-generated code is untrusted until proven otherwise, requiring rigorous review, automated security testing, provenance tracking, and independent validation before it reaches production, said Acalvio’s Varadarajan.

“There’s also the cold reality that complex systems are ultimately unverifiable. If we want AI safety and security, we also have to implement model-aware defense-in-depth. Mere code verification presents false comfort today.”
—Ram Varadarajan

The strongest defenses don’t rely on the agent making the right decision, Varadarajan said. “They enforce hard system boundaries that separate instructions from untrusted data, sandbox tool access, verify every action against policy, and prevent sensitive information from flowing to unauthorized destinations,” he said.