Prompt injection in coding agents: repos, issues, and web pages as attack surface

01Where does prompt injection reach a coding agent?

Indirect prompt injection means the instructions arrive in content the agent retrieves rather than in what the user typed. For a chatbot that might be one web page. For a coding agent it is most of the job: the agent's work is reading text written by other people and acting on it with a shell, a file system, a network connection and often a set of tool servers. OWASP keeps prompt injection first in its 2026 Top 10 for LLM applications, and its Top 10 for Agentic Applications lists the agent version as ASI01, Agent Goal Hijack.

It helps to list the surfaces concretely, because each one arrives through a different door and is trusted for a different reason.

• The repository: README files, code comments, test fixtures, and instruction files such as AGENTS.md or CLAUDE.md that agents load automatically.
• Issues, pull requests and review comments, often written by anyone with a GitHub account.
• Web pages and documentation the agent fetches while researching an error or an API.
• Dependencies: package READMEs, install scripts and error messages printed by third-party code.
• Tool output and tool descriptions from MCP servers, which the model reads as text.

02How does a GitHub issue turn into a data leak?

Invariant Labs published a clear example in May 2025. An attacker opened an issue containing a prompt injection on a public repository. The repository's owner, who also had private repositories, asked an agent connected through the GitHub MCP server to look at the open issues. The agent read the issue, followed it, pulled information from a private repository into its context and published it in a new pull request on the public repository, where the attacker could read it.

Three details matter. The tools were not compromised; Invariant stressed that the problem arises with fully trusted tools. The model was a current frontier model, which Invariant said was still open to relatively simple injections. And the owner's token reached every repository, public and private, so the agent could carry data across a boundary the person would never have crossed by hand. Invariant's conclusion was that security has to be enforced at the system level, for example by limiting a session to one repository, rather than left to the model.

03Is prompt injection solvable?

Not with filters alone, on current evidence. In October 2025 Milad Nasr, Nicholas Carlini, Florian Tramèr and colleagues published The Attacker Moves Second. They took 12 recent defences against jailbreaks and prompt injection, most of which had reported near-zero attack success, and bypassed them with adaptive attacks, with success above 90% for most. Their argument is about method: a defence tested against a fixed list of attack strings tells you little about an attacker who adapts to that defence.

The more promising results change the architecture instead of the model. CaMeL, described by Edoardo Debenedetti and colleagues in 2025, derives the program's control flow from the trusted user request, so data retrieved later cannot change which actions run, and it attaches capabilities to data to stop private values flowing to unauthorised tools. On the AgentDojo benchmark it solved 77% of tasks with provable security, against 84% for an undefended system. A companion paper, Design Patterns for Securing LLM Agents against Prompt Injections, catalogues similar patterns and their trade-offs between usefulness and security.

For a general-purpose coding agent with a shell, those patterns are hard to apply in full, because the task itself is open-ended. What carries over is the principle: decide in advance, outside the model, what the agent is able to do, so it does not matter which text persuaded it.

04How do you design for an injection that succeeds?

Ask three questions about the agent's environment as if the attacker is already giving the orders. What can it read? What can it send, and to where? What can it change that is hard to undo? Each answer should be as small as the task allows, and each limit should be enforced somewhere the agent cannot edit.

Our earlier post on egress brokers covers the key question in depth: if the real API key is never in the agent's environment, no instruction can read it out. The same thinking applies to everything else the agent could carry. A token that covers one repository cannot leak another. A machine that sees one folder cannot read your SSH keys. A network closed to an allow-list gives a stolen secret nowhere obvious to go.

• Read: one workspace folder, no home directory, no Git credential helper or SSH agent forwarded in.
• Send: network closed except named hosts; keys added outside the sandbox; no broad upload destinations.
• Credentials: a token scoped to the one repository or project the task needs.
• Change: a checkpoint or snapshot before risky steps, so damage inside the machine can be rolled back.

05Where does human approval help, and where does it fail?

Approval prompts are a real control, and OWASP lists human approval for high-impact actions among its mitigations. They are weakest when they are frequent. Invariant noted that many users choose Always Allow for tool calls, which is how its GitHub demonstration ran without review. OWASP's agentic list names the other failure as ASI09, Human-Agent Trust Exploitation: confident, polished explanations that lead people to approve harmful actions.

So spend approvals where they count. Let the sandbox absorb routine commands without asking, and hold the few actions that cross a boundary: pushing, merging, deploying, sending, paying, or reaching a host that is not on the list. An approval that comes up rarely, names the exact action and cannot be granted by the agent itself is worth far more than one that appears for every ls.