Coding Agent Security: Start With What Agents Can Reach

TL;DR

Coding agent security extends beyond generated code: Agents can read local files, use credentials, call APIs, and interact with systems that may never appear in a diff.
Reach determines blast radius: A forgotten or over-scoped credential can give an agent far more authority than the task requires.
Written rules need technical enforcement: Policies and rules files help shape agent behavior, but team-wide security needs boundaries that still hold when the model makes the wrong decision.
AppSec needs a team-level approach: It’s important to understand how to evaluate agent risk and standardize protections without making developers solve the problem alone.

Developers pushed 1.94 billion commits to public GitHub in 2025, up 43% year over year. Coding agents are contributing to that acceleration, while also giving security teams new ways to review code at scale.

But code review only sees what makes it into code. A coding agent running on a developer machine may also have access to environment variables, cloud configuration, shell history, local credentials, Model Context Protocol (MCP) configurations, and the tools connected to its session. It can read information, make decisions, and act on systems before anything reaches a pull request.

For AppSec teams, that changes what needs to be secured.

Coding agents bring the developer environment into scope

The PocketOS incident is a useful example. In April 2026, a coding agent working on a staging problem found an unrelated Railway API token and used it to delete the company’s production database and volume-level backups. The sequence took about nine seconds. There wasn’t an exploited software vulnerability; the agent found a valid credential, and that credential carried enough authority to make the API call.

That is the security problem AppSec teams now have to account for. We have moved beyond “is this code vulnerable?” Teams also need to understand what agents can read, what actions they can take, which systems they can communicate with, and which credentials sit within reach.

The environment around the model determines how much a mistake can cost.

Written rules need an enforcement layer

Most organizations already have rules for AI use. Teams define approved tools, write instructions for coding agents, require confirmation before destructive actions, and tell developers where sensitive data should never go.

Those rules are useful. They set expectations and shape some behavior. But they are instructions, not enforcement. At team scale, security needs another layer: controls that continue to hold when an agent makes a bad assumption, encounters hostile content, or simply does something nobody expected. And those boundaries have to be usable. A security control developers disable the first time it interrupts work is not much of a control.

Coding agent security has to work across the whole team

There is another complication: coding agents do not run in one place. They operate on developer machines, connect to external systems through MCP servers, and can run unattended inside CI/CD pipelines. Each surface gives the agent a different combination of data, credentials, tools, and authority.

That makes per-developer advice a weak foundation for a team-wide program. AppSec needs defaults that can be standardized, deployed, and checked without relying on every developer to make the right security decision every time.

Get the full coding agent security playbook

We wrote Securing Coding Agents Across Your Team for AppSec leads who need to support coding-agent adoption without turning security into another manual review bottleneck.

The guide covers how to assess a coding-agent setup quickly, what the major model providers are doing in their own environments, where controls need to sit, and how the answer changes across developer machines, MCP servers, and CI/CD.

It also includes a team security checklist you can use as new agents, integrations, and pipelines enter the engineering workflow.

Download the ebook

FAQ

What is coding agent security?

Coding agent security covers the risks created when AI coding agents can read data, execute commands, use credentials, connect to tools, and take actions on behalf of developers. It includes the code an agent generates, but also the environment and permissions available while the agent works.

How is coding agent security different from AI code security?

AI code security focuses on the security of code produced or modified with AI. Coding agent security has a wider runtime scope, because an agent can interact with files, credentials, APIs, development tools, and infrastructure while completing a task.

Why are credentials important to coding agent security?

Credentials turn access into authority. If an agent can reach an API key, token, or other secret, it can act with whatever permissions that credential carries. The credential therefore defines the blast radius of an agent mistake or compromise.

Are AI policies enough to secure coding agents?

No. AI policies and rules files shape agent behavior, but they are instructions, not enforcement. AppSec teams also need technical controls that constrain what agents can access and do when instructions fail or unexpected behavior occurs.

Should security teams block coding agents?

Blocking coding agents is rarely necessary, since their productivity benefits are real. The goal is to make their use safer at team scale by giving agents the access they need while constraining unnecessary reach to credentials, tools, and systems.