Your agent has read access to your repository, issue tracker and web returns. Each of these is a place a stranger can put a sentence, and your agent won't be able to tell yours from the outsider's. This is the thread of prompt injection in coding agents.
What is prompt injection against a coding agent?
Prompt injection in coding agents is when attacker-controlled text, hidden in content the agent reads, gets treated as a trusted instruction. That content can be a file, a web page, a pull request comment, or the output of a tool. The agent cannot tell the difference between data and commands, so it follows the hidden order.
Because AI coding agents are powered by large language models (LLMs), this matters more for coding agents than for chatbots. A chatbot that is tricked mostly returns bad text. A coding agent can act on the trick by writing code, running commands, or reaching into connected systems.
Direct vs. indirect prompt injection
Direct prompt injection is when an attacker types the malicious instruction straight into the agent. An example is pasting a crafted request that tells the agent to ignore its own rules.
Indirect prompt injection is the bigger worry for coding agents. It hides inside content the agent reads on its own, such as a README file or a tool result.
The National Institute of Standards and Technology (NIST) offers a clear definition. Its NIST guidance on prompt injection explains that indirect prompt injection attacks "occur when adversaries remotely (i.e., without a direct interface) exploit LLM-integrated applications by injecting prompts into data likely to be retrieved." Moving from prompt-engineering to context engineering is the broader discipline of assembling everything the LLM sees during inference, as explained in this whitepaper.
Why coding agents raise the stakes
The stakes rise because coding agents do far more than chat. They act inside your environment, often with broad permissions. An agent that reads files, runs commands, and calls tools can turn a text trick into real damage. Auto-run and auto-approve settings let an agent act before a human reviews the step.
This is why Endor Labs frames security for coding agents and workstations around the agent's actions, not just its prompts.
For a business leader, the math is simple. A wider blast radius means more exposure per incident, and more exposure means higher risk to customer trust and compliance standing. Controlling agent actions keeps that exposure in check while teams keep shipping.
How prompt injection attacks reach your coding agent
Almost every real attack is indirect. The payload rides inside content the agent already trusts, so no one has to type it in.
Poisoned repositories and rules files
Agents read READMEs, code comments, and rules files such as .cursor/rules to understand a project. Hidden instructions placed in those files get read as commands.
Researchers have measured this. A large-scale empirical study tested 314 attack payloads covering 70 techniques from the MITRE ATT&CK framework against the agentic coding editors Cursor and GitHub Copilot, with auto-approve and auto-run enabled. It found that attack success rates "can reach as high as 84% for executing malicious commands."
Malicious and untrusted MCP servers
Many agents connect to outside tools through MCP (Model Context Protocol), a standard way for agents to call external services. A malicious tool can hide instructions in its response that the agent then treats as trusted.
OWASP describes MCP tool poisoning as "an indirect prompt injection attack targeting AI agents that connect to external tool servers via the Model Context Protocol (MCP)."
The MCP ecosystem is young and uneven. In our State of Dependency Management 2025, we found that 75% of MCP servers are built by individuals, and 82% use sensitive APIs. We also counted more than 10,000 MCP servers created in under a year.
Web pages, search results, and issue comments
Agents that browse the web or read pull-request and issue comments can pull in instructions from those sources. This is not only a lab problem.
Palo Alto Networks Unit 42 studied indirect prompt injection, which it abbreviates as IDPI, and documented indirect injection in the wild. It reported that its "analysis of large-scale real-world telemetry shows that IDPI is no longer merely theoretical but is being actively weaponized." Unit 42 also catalogued 22 distinct techniques attackers used in the wild.
What attackers can do once an agent is compromised
Once an agent follows a hidden instruction, the outcomes are concrete:
- Exfiltrate secrets, tokens, and source code.
- Run shell commands, which can lead to remote code execution (RCE).
- Commit insecure or backdoored code into the project.
- Keep persistence by poisoning config or rules files.
CVE-2025-52573 shows how this plays out. It is a compound issue: a command injection flaw (CWE-78) with prompt injection as the delivery mechanism.
As a documented MCP server CVE explains, when an LLM is "tricked through prompt injection (and other techniques and attack vectors) to call the tool with input that uses special shell characters such as ; rm -rf /tmp;#," the shell runs those commands on the host running the MCP server (fixed in v1.3.3).
The impact grows because AI-written code is often insecure to begin with. Our review of the most common vulnerabilities in AI-generated code shows how injected or hallucinated code or packages widens the damage.
Each outcome maps to a business cost. Leaked secrets can trigger breach notifications, backdoored code can reach production, and a single compromised build can slow every release that follows. That is why this belongs on the risk register, not just the engineering backlog.
How effective are these attacks?
The honest answer is that these attacks work often, and defenses trail behind. The point is not to alarm anyone. It is to plan with real numbers.
A 2026 research synthesis is a meta-analysis across studies using adaptive attacks. It found that "attack success rates against state-of-the-art defenses exceed 85% when adaptive attack strategies are employed." Most defenses, it added, "achieve less than 50% mitigation against sophisticated adaptive attacks."
The controlled study noted above logged success rates up to 84% with auto-approve enabled. Read together, the evidence points one way: treat prompt injection as a first-class risk, not an edge case.
These numbers also set expectations for leadership. No single control will stop every attempt, so the goal is to lower success rates and contain the blast radius when an attempt gets through. That is a measurable program, not a one-time fix.
Why model-level defenses are not enough
Prompt filtering and stronger system prompts help, but they cannot be the whole plan. The attacker always moves second, and as OWASP notes, fool-proof prevention is unclear.
The control that matters sits outside the model. It should be deterministic, meaning it makes the same decision every time. The control should be auditable. You need a record of what the agent did across their coding lifecycle, and why it was allowed or blocked.
This is why hooks are a critical security control point. This sit directly inside the agent loop.
How to defend coding agents against prompt injection
Defense works best in layers. The layer that matters most controls what the agent can do, not just what it reads.
Enforce policy on Agent actions, not just prompts
Enforcement at execution time is the layer an attacker cannot talk past. You can block destructive shell commands, sensitive-file reads such as .env files and private keys, and unauthorized MCP servers, no matter what the model decides.
Endor Labs built its ability to govern AI coding agents around this idea: deterministic allow, deny, and audit decisions on agent actions.
Get visibility across every agent, model, and MCP server
Governance starts with an inventory. Catalog every agent, model, MCP server, and skill running across developer workstations and cloud environments, including the ones nobody approved. More than 10,000 MCP servers appeared in under a year, and most security teams have no reliable way to know which ones their developers have installed. Once you have that inventory, log the activity in a form auditors can use. Frameworks like the EU AI Act and ISO 42001 want evidence that you know what AI is in use and how it behaves, and audit-ready logs give you exactly that.
Review the code your agents write
Injected or hallucinated code should be caught before it ships. Pair AI-powered code review with full stack reachability so teams fix what is actually exploitable.
Full stack reachability is like worrying about unlocked doors instead of every door in the building. It ranks findings by whether an attacker can actually reach them. Reviewers then spend time on real exposure, not noise.
Harden the agent and keep humans in the loop
Reduce the blast radius with least privilege and sandboxing, which isolates the agent from the wider system. Turn off risky auto-run and require approval on high-impact actions.
For agent-specific steps, our guide to securing Cursor walks through practical hardening you can apply today.
Human approval does not have to slow teams down. Reserve it for the small set of high-impact actions, and let routine work flow through untouched. The result is a lighter touch that still catches the moves that cause real harm.
Prompt injection for coding agents: a practical security checklist
Use this checklist to turn the layers above into controls you can put in place.
Frequently Asked Questions
How is prompt injection in coding agents different from a chatbot jailbreak? A jailbreak mostly changes what a model says. Prompt injection in a coding agent can trigger real actions like running commands or reading secrets, widening the blast radius.
Does upgrading to a newer model fix prompt injection? No. Newer models reduce some attacks, but adaptive attacks still beat strong defenses, so treat this as a system risk, not a model setting.
Does sandboxing alone stop it? Sandboxing limits the damage but does not stop the injection itself, so pair it with action-level policy and code review.
How do I know if my coding agent is exposed? Inventory every agent, model, and MCP server in use, then check whether auto-run and sensitive-file access are enabled without approval gates.
Are MCP servers safe to install? Not by default, since many are built by individuals and use sensitive APIs, so allow-list vetted servers and block the rest.
Secure coding agents without slowing developers down
Coding agents are here to stay, and they help teams ship faster. The answer is to secure the code agents write, not to block them. It is to govern their actions with an independent, verifiable layer so teams move quickly with confidence.
That approach connects security to business outcomes. It lowers risk, strengthens compliance posture, and keeps delivery fast.
What to do next:
- Inventory every coding agent, model, and MCP server your teams use.
- Enforce policy on agent actions, blocking destructive commands and sensitive-file reads.
- Allow-list vetted MCP servers, and block the rest.
- Review AI-written code with full stack reachability so you fix what is exploitable.
- Book a demo if you want help putting these controls in place.
Book a Demo to see how Endor Labs governs AI coding agents across your stack.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help:
