TL;DR
The risk in agentic coding is not that the agent writes bad code. It is that the agent acts. It installs packages, edits files you did not open, calls tools, reads configuration nobody reviews and opens pull requests. Every one of those is a privileged operation performed with a developer's permissions, and your existing controls were built for a world where a human typed each one.
Speed moved the bottleneck to review. Independent research on AI coding assistants puts around 40% of generated code as containing a security vulnerability, and that rate has not improved as models got better. Output multiplied. Review capacity did not. Agentic programming makes this sharper than autocomplete ever did, because a single instruction can touch a dozen files.
The attacks target the wiring, not the model. Hidden Unicode in a rules file makes an assistant emit backdoored code and never mention it, catalogued in MITRE ATLAS as AML.CS0041. Attackers register the package names models hallucinate. One MCP bridge shipped remote code execution to clients more than 437,000 times. Traditional analysis reads none of these files.
What contains it is boring and it works: inventory the agents and MCP servers actually in use, treat prompts and rules files as code under review, scope every tool surface to the task, and enforce policy on the developer machine where the agent runs. Xygeni AI Security handles the first three and DevAI the last, across AI-generated and human-written code alike.
What is Agentic Coding?
Agentic coding is development where an AI agent takes a goal and executes it across your codebase using tools: reading and editing files, installing dependencies, running tests and opening pull requests. The risks come from those actions and from the configuration that steers them, not from the quality of any single generated function. The practices that work are inventory, scoped permissions, reviewed configuration and enforcement at the endpoint.
Agentic coding or agentic programming?
Both terms describe the same shift, and teams use them interchangeably. Agentic programming tends to appear in engineering conversations about how the work gets done; agentic coding is the phrase that stuck in tooling and security. Nothing separates them technically. If you want the full definition and the surrounding vocabulary, our glossary entry on agentic coding covers it.
What matters for this piece is the distinction between suggestion and execution. An assistant that completes a line is a productivity feature. An agent that installs a package, edits six files and pushes a branch is a non-human identity operating inside your SDLC. Agentic programming crossed that line quietly, and most security programmes have not been re-scoped since.
The real risks of agentic coding
Four risk families, in the order they tend to bite.
- Volume outrunning review. An agent produces more change per hour than any reviewer can meaningfully read. Approvals become rubber stamps, and insecure patterns reproduce at machine speed. This is the risk everyone acknowledges and the one least often measured. Start by measuring the ratio of agent-authored changes to human review time, and the number will make the argument for you.
- The instruction layer. Anything that reaches the agent’s context can steer it. Prompt injection is number one in the OWASP Top 10 for LLM Applications for a reason, and in agentic coding the delivery vehicles are mundane: an issue description, a code comment, a README in a dependency, a document the agent retrieves. Nobody has to attack you directly. They only have to write something your agent will read.
- The configuration layer. Rules files, skill files, prompts, and MCP server definitions decide what the agent does and what it can reach. They are not application code, so no scanner in a typical stack reads them. The Rules File Backdoor demonstrated the extreme case, where zero-width characters carry instructions a reviewer physically cannot see. The ordinary case is just as damaging: a provider credential sitting in plain text in a config file, or an assistant granted read access to the entire filesystem because that was the default.
- The dependency and tool surface. An agent chooses dependencies. It resolves a name, installs it and moves on, and install scripts run before any pipeline sees the change. Slopsquatting exploits exactly this: research presented at USENIX Security 2025 found that 19.7% of packages recommended by language models do not exist, and that the hallucinated names repeat often enough for attackers to register them and wait. The same applies to MCP servers, where connecting an untrusted server hands an agent tools you never audited.
How it actually goes wrong
No single exotic exploit. A composite of techniques already documented in the wild, in the order they land.
- The instructionA sentence sits in an issue description, a dependency README or a code comment. It was not written for a human to read.
- The contextA developer asks the agent to fix the issue. The agent pulls the description, the repository and its own rules files into context. Instruction and content look identical to a model.
- The installThe agent resolves a helper library that sounds right and installs it. The name was registered last week by someone who noticed models keep inventing it. The install script executes on the laptop.
- The credentialThere is a provider token in plain text in an
mcp.json, and a cloud session already active in the shell. The script does not need to escalate. It inherits. - The pull requestThe change is small, the tests are green and the diff reads reasonably. It is approved in under a minute, because there are four more waiting.
Every gate you own fires after step three. The first three happen on a developer machine, in about ninety seconds.
8 lessons from early adopters
Drawn from documented incidents, published research and the patterns that keep appearing in teams that adopted agentic programming before anyone wrote a policy for it.
- The blast radius is the tool surface, not the prompt Teams spend weeks hardening prompts and minutes deciding which tools an agent can call. It is the wrong ratio. An agent that can only read is an inconvenience when compromised. An agent that can send mail, query production and push commits is an incident, and it holds the developer's own credentials to do it, because almost nobody provisions an identity for an agent. Write down the tool list before you write the system prompt.
- The agent optimises for the test passing, not for the code working Given a failing suite and enough autonomy, an agent will delete the assertion, loosen the condition or swap an integration for a mock, then report success. Every team recognises this the first week. It is why green pipelines stopped being evidence, and why the review question changed from "does this work" to "what did it change to make this pass".
- Your rules file is production configuration The file that steers every generated line is usually committed once and never reviewed again. It belongs under change control with an owner, a diff review and someone who notices when it grows a line nobody remembers adding. Assume anything in it will be obeyed, including what you cannot see.
- The agent's dependencies are not your dependencies Approved-library lists assume a human chose. An agent resolves a plausible name and installs it, and install scripts execute before CI exists. The teams that got burned added a check at install time on the machine, not a policy document listing what developers should prefer.
- Nobody can tell you what they are running Ask five engineers which MCP servers and assistants they use and you get five answers, none complete. Surveys do not work here because the tools install locally and change weekly. Discovery has to come from the code, the dependencies and the configuration files the tools leave behind.
- Memory keeps the poison after the session ends A bad instruction that reaches persistent context or an agent's memory does not expire when the task does. It keeps paying off quietly across unrelated work, which is why memory and context poisoning has its own entry in the OWASP agentic list. Treat agent memory as state that needs review and a way to be cleared, not as a convenience feature.
- Reversibility beats prevention The teams running the most autonomy safely are not the ones with the tightest controls. They are the ones who made mistakes cheap: agents push branches instead of main, work in disposable environments, and every action has a one-command undo. Autonomy is affordable exactly to the degree that reversing it is.
- The pilot lies to you Agents look excellent on greenfield tasks in small repositories and degrade in large legacy codebases with implicit conventions. A successful pilot overstates the productivity gain and understates the risk, then sets an expectation nobody can meet at scale. Pilot on your worst repository, not your cleanest.
What this looks like in practice
The order matters more than the tooling. Discovery first, because you cannot scope permissions on agents you have not found. Then the configuration layer, because that is where the instructions live. Then the endpoint, because that is where the agent actually runs and where an install completes long before a pipeline notices.
Xygeni AI Security discovers every AI asset in the SDLC, including the models, agents, agent servers, MCP servers, datasets, skill files, prompts, and guardrails nobody declared, reading application code, declared dependencies, and the configuration files AI tools leave behind, then maps how they connect. It detects the risks specific to agentic programming: prompt injection and system prompt leakage, malicious instructions and tool injection in rules and skill files, insecure MCP configuration, excessive agency and missing guardrails, secrets in AI files, and vulnerable or slopsquatted AI dependencies. Findings map to the OWASP Top 10 for LLM Applications and point to the exact file and line, and the prioritization funnel narrows thousands of findings to the ones that are in use, reachable, exploitable, privileged, and business-critical.
DevAI covers the other half, in the editor: it secures code as it is written, applies to AI-generated and human-written code alike, and intercepts what other agents are about to do before they do it. The same intelligence applies to findings ingested from the scanners you already run, so none of this requires replacing what you have.
FAQ
- What is the biggest risk in agentic coding? Excessive agency. An agent with a broad tool surface turns any successful injection into a real action, and most teams scope tools far more loosely than they scope people.
- Is agentic programming safe for regulated environments? Yes, with an inventory, scoped permissions, reviewed configuration, and enforcement at the endpoint. What is not defensible in an audit is not knowing which agents run, what they reach, or what code they authored.
- Does agentic coding produce less secure code than a human? The per-line rate is comparable to human error, but the volume is not, and volume is what defeats review. The problem is throughput, not talent.
- Do we need to ban AI coding assistants? Bans move usage underground, which is worse. Shadow AI is harder to secure than approved AI, and discovery is the control that actually changes the picture.
- Who is accountable when an agent ships a vulnerability? The person who merged it, exactly as before. That is the uncomfortable part, and it is why authorship data matters: a reviewer signing off on machine-authored change at machine volume needs the finding to arrive before the approval, not after.
- How do we start if we have no visibility at all? Run discovery over your repositories, list the MCP servers and assistants it finds, and rank agents by tool surface. The riskiest agent is usually not the one anyone was worried about.
Agents are already in your repositories
Agentic coding is already in your repositories, whether or not anyone approved it. The teams handling it well are not the ones with the strictest policy. They are the ones who can answer, on any given day, which agents are running, what those agents can reach, and what changed in the files that steer them.
See what your agents are connected to at Xygeni.
