GitHub README Prompt Injection: The File Every Coding Agent Reads First

Your coding agents run overnight on cloud dev boxes, with auto-approve on and an organization token in the environment, and the only thing standing between a public repository and that token is whatever the repository’s README tells the agent to do.

The agent reads that file first, before its task, on every repository, and it holds the permission for everything the README could ask: run the setup target, read the environment, push. A README that says “run make bootstrap before making changes” is the same sentence your own repositories contain, and the agent obeys it for the same reason. When one of those runs leaks the token, the transcript will show an agent that followed setup instructions and pushed a branch, and every step in it was allowed.

Scanning READMEs for hidden text does not catch this, because nothing is hidden. The permission prompt does not catch it, because nobody was there to read it. What is left is the agent’s own behavior, and a coding agent’s behavior is narrow enough that the four steps after the README read stand out in its record.

This article shows why the README is the one document a coding agent reads before its task, walks the coercion in five allowed steps, marks where README scanning and permission prompts stop, and reads what a coding agent’s runtime baseline shows at each step.

Why the README Is the One Document a Coding Agent Reads Before Its Task

Two mechanisms put the README in front of a coding agent before its task.

The first is specification: coding agents load a repository’s rule files, CLAUDE.md, AGENTS.md, the Cursor rules directory, when a session opens and before the task prompt arrives. The second is practice: the README is the first file the agent opens to orient itself, on nearly every task, because it is the first file a person would open too. One path is by design and one by habit, and both land the file in context ahead of the work.

The README also arrives with company. It sits beside CLAUDE.md, where “always run the linter before committing” is an instruction the agent follows as part of its job. The README gets no separate register, so “run the bootstrap target before making changes” one directory entry away carries the same weight. Inside a repository the boundary between data the agent reads and instructions it follows is gone by design, and the delivery path that makes this injection indirect keeps it away from anything watching the user’s prompt.

The researchers who first demonstrated injection through retrieved content in 2023 described the attacker’s position as remote: no access to the model’s interface, only to something the model would later read. A repository is the purest case of that position, since anyone can publish one and coding agents are built to read them. The same shape appears in tool descriptions an agent loads at startup, and a 2026 systematization of 78 coding-assistant studies reports attack success above 85% against current defenses once the attacker adapts.

So the line the agent can still hold is a different one. It cannot tell repository data from repository instructions. It can be held to what a repository may make it do.

How a README Coerces a Coding Agent in Five Allowed Steps

The attack is five steps, and the agent holds the permission for each one before the README is written.

Take a coding agent in a cloud dev environment, provisioned per task so that agents run in parallel. It has a workspace, a shell, a package manager, a git token scoped to the organization, and often a registry credential or a cloud role left over from the environment image. Its task is to fix a failing test in a repository it has never seen. It clones the repository and reads the README.

Read the middle column as a person would. Every sentence is one a well-maintained project could contain, and step two is one most do. The README needs no override phrase, because the agent has no refusal to argue with. It has permissions. The bootstrap target itself lives in a Makefile the README points to, a file no reviewer reads and no scanner parses.

Compare the case that reached the public record. The agent that leaked private repositories in 2025 was steered by a public issue, a document it read because a user asked it to review issues. The README needs no user request. The agent reads it to begin.

Step five is where the definition of prompt injection completes: an instruction from a source trusted for content, followed by a model that took it as an instruction, acted on by an application with borrowed authority, a token, against a destination. The push is the incident. The four steps before it are the sequence that made the push look like work.

What README Scanning and Permission Prompts Catch, and Where They Stop

The README payloads on the public record produced two controls, README scanning and the permission prompt, and each stops one step short of the attack above.

Scanning the README catches the wrapper. HTML comments, zero-width characters, “ignore previous instructions”: a scanner built for the demo payloads finds them, and it should stay on, because it removes the cheap version of the attack. It then passes the table’s middle column without a mark. A sentence asking the agent to run the setup target is what a README is for, and the Makefile it points to is outside the scanner’s scope.

The permission prompt catches the step, if someone is reading it. On a laptop, “run make bootstrap?” is a question a developer sees and can decline. In a remote dev environment the same question is answered by configuration: teams move agents to cloud dev boxes so that ten can run overnight, an agent that stops to ask ten times an hour defeats the purpose, and auto-approve is set at the environment level. GitHub’s own guidance for VS Code describes the prompt as one layer among several, lists file reads among the tools that run without one, and names the token exposure that remains.

For a platform team this is a cost question, and pipeline controls do not answer it: they see the merge, and the dev box where the agent already ran is outside their view. Any control that re-inserts a person per step returns the agent to laptop speed, which the environment exists to escape. Any control that works without a person has to work from something other than the text, because the text is clean.

That something is the agent’s own behavior.

What a Coding Agent’s Runtime Baseline Shows at Each Step

A coding agent has one of the narrowest behavioral profiles of any workload you run.

Across every task it reads and writes inside the workspace, runs git, the package manager and the test runner, and reaches the registries and the model endpoint. Task to task, the process tree, the file paths and the destinations repeat. That regularity makes the five steps legible once they are recorded at the kernel, below the text the agent read, and compared with what this agent did on every previous task.

The right-hand column is the eight-stage chain any injected agent follows, compressed into the minutes a coding task takes. The text was present at step one. The evidence is at steps two through five, and none of it requires knowing what the README said.

ARMO records what each agent does in execution with a kernel-level sensor and builds a per-agent behavioral profile from it, Application Profile DNA (APD™). Each new action is evaluated against that agent’s own history, which is why a credential read that is routine for a secrets-rotation job is a deviation for a code-review agent. The case the profile exists for is coercion, where every step is permitted and the sequence is the attack, and the README case is coercion in its plainest form.

Turning the profile into a bound follows the Audit and Enforce sequence: the sensor records first, the team reviews what a per-agent policy would have blocked against real tasks, and the policy arms once the record shows the boundary is right. Credential isolation adds an outcome on top. The agent works with placeholder credentials and the real ones are substituted outside its reach, so the token the README asked for at step three opens nothing. The coercion still happens. The reach it borrows is smaller, and the run lands as one Attack Story from README read to push, four deviations on one timeline.

ARMO’s runtime security for AI workloads covers the right-hand column: what the agent did, measured against what it does.

Every File the Agent Reads Unasked Belongs in the Threat Model

The README is the first entry in a short list, and the list is the threat model for a coding agent.

There are four kinds of file. The README, read to orient. CONTRIBUTING and SECURITY, read when the task touches process and scrutinized less because they look like policy. The rule files, CLAUDE.md, AGENTS.md and the Cursor rules directory, read and obeyed by design, which makes them the channel left open once the README is scanned; one evaluation of 314 payloads placed in rule files had coding editors running attacker commands across 70 ATT&CK techniques. And the setup scripts those files invoke, the Makefile, the bootstrap script, the package manifest with its post-install hooks, where an ask can live without appearing in any markdown at all.

Treat the four as one surface with one test. One plain ask per permission the agent holds, placed in each file and run against a scratch repository, tells you which of the five rows your agent will complete. Record a week of the agent’s normal tasks before you enforce anything, then arm per agent on the deviations the record shows. Bring one coding agent and its environment to a working session and the table gets filled in from its actual runtime record.

FAQ

How do I test whether my coding agent obeys a README? Create a scratch repository whose README asks for one action per permission the agent holds: run a named target, write the environment to a file, contact a marked host, push to a named branch. Give the agent an unrelated task there and read the runtime record afterwards. Each row it completed is live against you today; each row it refused tells you which control held.

Should I strip or scan READMEs before the agent reads them? Scan, and keep scanning, because it removes hidden comments and override phrases at near-zero cost. Do not expect it to catch the attack that matters, which is a plain sentence pointing at a setup target. Stripping the README breaks the agent’s ability to orient and moves the ask into CONTRIBUTING or the rule files.

Does AGENTS.md or CLAUDE.md make this worse? Yes. Those files are read automatically and obeyed by design, so an instruction in them needs no disguise. Review changes to rule files with the same rigor as CI configuration, and treat a rule file in a third-party repository as untrusted input the moment the agent clones it.

What should a coding agent in a remote dev environment be allowed to reach? A git token scoped to the repositories the task names, an egress allowlist of registries and the model endpoint, and writes confined to the workspace. Anything the environment image leaves behind, cloud config, registry credentials, kubeconfig, is reach the README can borrow. Where credential isolation is available, give the agent placeholders and let the substitution happen outside its process.

Which signals should I look for first in a coding agent’s runtime record? Reads of credential paths the agent has never opened, a first-seen outbound destination that is not a registry, a process lineage the agent has never produced, and a push to a branch the task did not name. Any one of them is a deviation against a coding agent’s narrow baseline; two in the same run, in that order, are the attack above.