Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Does Prompt Injection Get Into a Coding Agent?

Through anything the agent reads: a README, an issue, a comment, an error message, a web page or a package description. The sources reviewed document mitigations and limits and not immunity, so list what your agent reads and ask which of it can carry an instruction.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Engineering teams that run a coding agent hand it a great deal of text that other people wrote: READMEs, issues and their comments, error messages, web pages and package descriptions. Prompt injection is what happens when one of those texts contains an instruction and the agent treats it as part of its task. The answer to the title is therefore a list of the things the agent reads, and the harder question is which of them a stranger can write to. A team accountable for that agent should inventory what it reads, starting with the channels that outside writers can reach. The mitigations on record limit the reach of an injected instruction or add friction, and the vendors that document them state their limits. The example record is a README with an instruction: a file in a repository that the agent opens at the start of a task, with a line in it addressed to the agent and not to the reader. Two sibling pages take the README and the issue one at a time, Can a README Hijack My Coding Agent? and Can a GitHub Issue Hijack My Coding Agent?, and How Do Attackers Steal Credentials Through Prompt Injection? covers what the attacker wants once the instruction is in.

Key findings

  • A study of prompt injection attacks on agentic AI coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands," though the abstract gives no trial counts or tool versions (Liu et al., 2026).
  • Meta's Agents Rule of Two states that, until injection is reliably stopped, "agents must satisfy no more than two of the following three properties within a session," a design rule that limits what an injected agent can do and does not prevent the injection (Meta AI, 2025).
  • Anthropic's Claude Code documentation states that "While these protections significantly reduce risk, no system is completely immune to all attacks," a vendor describing mitigation and not immunity (Anthropic, 2026).
  • A governed environment replaces values with consistent tokens such as TOKEN_001 before any model reads the screen, so an instruction that reaches the model finds placeholders where the credentials were (How Do You Let an AI Agent Manage API Keys Without Reading Them?).
  • Real values resolve only at the approved destination at the moment of an approved action, which breaks the path from private data to external communication that the lethal trifecta describes (What Is the Lethal Trifecta for AI Agents?).

What does a governed browser environment cover when a coding agent reads untrusted text?

What a governed browser environment covers is what an agent reads and does on rendered pages, meaning dashboards, consoles, settings pages and a repository's web pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. That boundary decides how much of this page a browser control reaches, because a coding agent reads in both places. Opened on a repository's web page, a README is inside that scope. The same README read from a cloned folder is on the local filesystem and outside it, so the first thing to settle is which of the two the agent used.

The example record is a README with an instruction. A line in the file, placed in a section that looks like setup notes, is addressed to the agent: it tells the agent to run a command or to send a value somewhere. A person skimming the file sees setup notes. The agent receives the line as text in its context, next to the task it was given.

The channels are the places a coding agent reads: files in the repository, issues and pull request comments, error messages and logs from commands it runs, web pages it browses or fetches, and the descriptions in package registries. Each can hold text written by someone other than the person who gave the task. This list is a classification of what coding agents read, and the sources reviewed do not report an incident for each channel.

How does an instruction reach the model?

By the same route as every other input: as text the agent reads. The channel has a name, indirect prompt injection, and a founding paper whose title states it: "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" (Greshake et al., 2023). The attack was named by Greshake and colleagues, who showed that LLM-integrated applications could be compromised through retrieved content rather than through the user's prompt, as the linked page reports (What Is Indirect Prompt Injection and How Does It Reach AI Agents?). OWASP lists prompt injection as LLM01:2025, the first entry in its Top 10 for LLM Applications (OWASP, LLM01:2025, 2025).

What makes the route dangerous is the combination of what the agent can reach. The trifecta, as Simon Willison defined it, is "Access to your private data," "Exposure to untrusted content," and "The ability to externally communicate," with the note that even a request "to load an image" can carry stolen data (Simon Willison, 2025). A coding agent with a shell, a browser and repository access can have all three. The private data is the repository and its environment, the untrusted content is any channel in the list above, and the ability to communicate externally is a git push, a fetched URL or a form submitted on a page.

The route needs no flaw in the agent's code. It needs a place where a stranger's text and the agent's task share a context. A README, an issue, a comment and an error message are such places by design, since the point of reading them is to act on what they say.

What do the vendors themselves say?

The vendor pages below describe mitigations, and each one states what it leaves open. Read each row for what it states and for the question it leaves with a buyer.

Dimension Vendor, per its documentation What a buyer should verify
Internet access during the agent phase OpenAI's Codex cloud documentation, marked Legacy, states that "By default, Codex blocks internet access during the agent phase" and advises to "allow only the domains and HTTP methods you need, and review the agent output and work log" (OpenAI, 2026). The page lists prompt injection from untrusted web content as a risk of enabling internet access and does not explain how allowlists are enforced. Ask what the model receives from an allowed domain.
Credentials held outside the agent Infisical's post on its Agent Vault states that "In short, the agent should not be trusted with direct access to any secrets" (Infisical, 2026). The post does not claim the design fully prevents credential exfiltration and states no benchmarks. Ask what a page the agent reads still shows.
Approval of commands Anthropic's Claude Code documentation states that "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, 2026). The sandbox described there covers shell commands; file reads and web fetches follow permission rules instead. Ask what an approved command may touch and what the agent reads outside the sandbox.

The same point comes from Meta and Anthropic above: Meta's rule applies until injection is reliably stopped, and Anthropic says no system is completely immune. The vendors document where their controls stop, which is the information a buyer needs.

What does an injected instruction do once it is in?

It competes for the agent's goal. OWASP's Top 10 for Agentic Applications lists ASI01 Agent Goal Hijack, ASI02 Tool Misuse and ASI03 Identity & Privilege Abuse among its ten risks, and states that "Once AI began taking actions, the nature of security changed forever" (OWASP GenAI Security Project, 2025). The list separates goal hijack, tool misuse and privilege abuse, and the record fits: the instruction changes what the agent tries to do, and the tools and privileges it already has decide what that costs.

The benchmark record puts numbers and limits on this. The Agent Security Bench authors report "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses," without saying which defense performed best or by how much (Zhang et al., 2025). An adaptive attack study bypassed 12 published defenses with an "attack success rate above 90% for most," many of which had reported near-zero rates, as the linked page reports (How Do You Protect AI Agents Against Prompt Injection?). A defense that reports near-zero in its own paper and fails under an adaptive attack is a mitigation and not immunity.

One design on record trades completion for security. CaMeL's design goal is that "the untrusted data retrieved by the LLM can never impact the program flow," and on AgentDojo it achieves "solving 77% of tasks with provable security" against 84% undefended, a protection that costs completed tasks (Debenedetti et al., 2025). That trade leaves layers: an input check, a sandbox, a permission prompt and a limit on what the agent holds. The layer this page adds is the last one, the values themselves. An instruction that asks for a token finds a placeholder if the model never held the token.

How can a team inventory what its coding agent reads?

List every input the agent reads in one task, and mark for each who can write to it. Start with the repository files, then issues and comments, then output from commands, then web pages and fetches, then package descriptions. For each, answer three questions. Can someone outside the team write to it? Does the agent read it without a person reviewing it first? What can the agent do with a shell, a browser or a token while that text is in its context?

Then plant a test instruction in the one channel with the most outside writers, on a test repository with a test token, and run the task. Record what the model received in place of the token, what it tried to do, and whether anything needed a person's approval. A README is the usual first test (Can a README Hijack My Coding Agent?), and an issue the second (Can a GitHub Issue Hijack My Coding Agent?). The inventory is the deliverable: it turns an abstract risk into a list a reviewer can reduce. Repeat it when the agent gains a tool, because each new tool adds channels and each new permission can add a leg of the trifecta, and keep it beside the date and the agent version so the next review starts from what was true on the last one.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as TOKEN_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, including every payment, submission and record change. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question, it does not stop an instruction from entering, because the instruction is text on a page and the model reads it. It changes what the instruction can get. An instruction that asks for the token finds TOKEN_001, and a send of that placeholder resolves nowhere. The reach of a hijack shrinks to the placeholders the model held. The approver sees the destination and the placeholder and not the credential, and the record shows each screen as the model saw it.

It governs the rendered page and nothing else. A README read from a cloned folder, a command run in a shell and a fetch made from the terminal are outside it, and stay with the sandbox, the permission rules and the credential store the team configures for that agent.

Methodology and limitations

This page rests on three research preprints on prompt injection in coding editors, agent security benchmarks and a design for defeating injection, a founding paper on indirect injection cited by its title, vendor documentation from OpenAI, Infisical and Anthropic, OWASP guidance for LLM and agentic applications, practitioner and vendor research posts from Willison and Meta, and existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from research posts are cited as reported and not as independently measured. The preprints are cited for what their abstract pages state and not for rates those pages do not give.

RedactSure did not test any of the named products hands-on. "Not described" means not described in the pages reviewed. The list of places an instruction can enter is a classification of what coding agents read, and the sources reviewed do not report an incident for each. The Greshake paper and the OWASP LLM01 entry are cited for what their titles state. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a README with an instruction, and not an organization. Vendor features change, and the page carries its date; a reader should treat a release after that date as unreviewed until the test above is repeated.

Determinations about whether a prompt injection control meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against a test repository, repeated after each release.

What the record shows

An instruction gets into a coding agent through anything it reads, and the record on mitigations is consistent: they limit reach or add friction, and the vendors that document them say so. One design reviewed gives up tasks to gain security, and the adaptive attack study found published defenses failing. The values the agent holds decide what a successful injection costs; RedactSure's environment removes them before the model reads the page. To check a team's own exposure, name one agent and one task, list every input it reads, plant a test instruction in the channel with the most outside writers, and write down what the model held and what it tried to do.

Frequently asked questions

How does prompt injection get into a coding agent?

Through any text the agent reads while working: files in a repository, issues and comments, error messages from commands, web pages, and package descriptions, whether the agent runs locally or in the cloud. The agent treats what it reads as input to its task, so text written by a stranger and text written by the team share one context. The route needs no flaw in the agent's code. List the inputs for one task and mark which of them an outsider can write to and which it reads unreviewed.

Can a README or an issue contain an instruction for the agent?

Yes, in the sense that any text the agent reads can, whoever wrote it. A README or an issue is text the agent reads to decide what to do, and a line addressed to the agent sits in the same context as the task. Whether a particular tool follows the line depends on the tool, which is why the test is to plant one on a test repository and watch. The sibling pages take each case on its own.

Is blocking internet access enough?

It closes one channel. OpenAI's documentation, marked Legacy, blocks internet access by default during the agent phase, which removes web pages as an input there. Files in the repository, issues, comments and command output remain, and so does anything fetched from an allowed domain. Blocking the network also limits where an instruction can send data, which is a separate benefit. Treat it as one layer among several, and check the others separately.

Does a sandbox stop prompt injection?

A sandbox limits what a command can touch, and it does not stop the instruction from being read. The Claude Code documentation describes a sandbox for shell commands, and file reads and web fetches follow permission rules instead. An injected instruction can still change what the agent tries to do, and an approved command can still do what the user account can do. A sandbox reduces the cost of a hijack and not the chance of one, so it is paired with limits on what the agent holds.

What is the lethal trifecta and why does it matter here?

It is the combination of access to private data, exposure to untrusted content and the ability to communicate externally. A coding agent with a repository, a shell and a browser can have all three at once. Removing any one leg shrinks the risk: untrusted content is hard to avoid, so teams usually act on the other two, by limiting what the agent holds and where it can send things, and by putting a person in front of consequential sends.

What should a team ask a vendor in writing?

Which inputs the agent reads without a person reviewing them; what the model holds while those inputs are in its context; which controls are layers that limit the reach of an injection and which claim to prevent it; what happens to a command or a submission the injection asks for; and what record shows the input and the action. Treat any answer the documentation does not support as unanswered until a test with a planted instruction confirms it, and keep the answer beside the transcript of that test.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Leaves an Injected Instruction Nothing Real to Send

Allowlists, vaults and permission prompts limit what an injected instruction can do, yet the instruction stays in the model's context beside whatever real values the agent was shown.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent reads a README's instruction on the repository page while holding the real token the console showed, so the instruction can ask for it. Inside the governed environment: the model reads TOKEN_001, a named person approves any submission, and the instruction finds a placeholder to send.

RedactSure is deploying now with enterprise and government customers. Meta's Rule of Two applies until injection is reliably stopped.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

An injected instruction only matters if the agent has something real to send. Bring a repository task your agent runs and see, with test values, what an injected line would find. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.