A README file can hijack your AI coding agent

A README can contain more than setup instructions. If an AI coding agent mistakes attacker-written text for an instruction it should follow, reading that file can redirect its work. The risk depends on what the agent reads, how it handles instructions, and what tools it can use. The practical takeaway: review project instruction files and limit what an agent can do without approval. The attack, demonstrated In April 2026, NVIDIA's AI Red Team published a step-by-step demonstration against OpenAI Codex. They built a malicious Go library that detected when it was running inside a Codex environment, then wrote its own AGENTS.md file into the project. AGENTS.md is the file Codex reads as trusted project instructions, so the agent obeyed it. The planted file told Codex to inject a five-minute sleep into any Go main function and, more importantly, to never mention it: not in reasoning, not in summaries, not in the pull request. The agent complied. The malicious change arrived wrapped in a clean PR that described only what the developer had asked for. To be fair to the nuance here: the attack started from a compromised dependency, and OpenAI's response was that this does not significantly raise risk beyond what a compromised dependency already allows. But the demonstration shows something new. A poisoned dependency no longer has to hide its payload in code you review. It can use instructions to redirect the agent and influence the summary. The code diff still matters: a clean-looking summary is not evidence that the underlying change is safe. It is not one tool and not one bug The Cloud Security Alliance's March 2026 research note describes several routes into an agent's context. Depending on the tool and workflow, these include project instruction files such as AGENTS.md and CLAUDE.md, rules files, READMEs, issues and pull request descriptions. They are not all loaded in the same way, and reading a file does not mean an attack will succeed. The CSA note reports the following research results. These describe particular test setups, not the probability that your current tool will be compromised: The IDEsaster disclosure catalogued more than 30 vulnerabilities across AI IDEs, with 24 CVEs assigned. Every AI IDE tested contained at least one working attack chain. The ReadSecBench study tested 500 real README files against Claude, GPT-4, and Gemini. Direct commands embedded in a README worked about 84% of the time. Instructions buried two document links deep worked about 91% of the time. In a small evaluation of 15 human reviewers shown flagged documents, 53.3% raised no concerns. That sample is too small to generalize to developers overall. The AIShellJack framework ran 314 attack payloads against coding assistants and measured success rates between 41% and 84% depending on the platform and configuration. OWASP's Secure Coding with AI guidance treats repository content as untrusted input. The failure to avoid is promoting text from a file into authority over the developer's actual request. A familiar filename does not establish who wrote the content or whether it is safe. What you can actually do None of this means stop using AI coding tools. It means treating their inputs with the same suspicion you already apply to code you did not write. These mitigations come from OWASP's Secure Coding with AI cheat sheet, the CSA research note, and NVIDIA's writeup: Treat agent config files like CI/CD pipeline definitions. AGENTS.md, CLAUDE.md, .cursorrules and friends are privileged execution artifacts. Require review and explicit approval for any change to them, especially from external contributors. CSA's framing is blunt: same controls as shell scripts. Do not run auto-accept mode on codebases you do not trust. Auto-approval gives the agent your full permissions with minimal oversight. On an unfamiliar repo, read the instruction files yourself before letting the agent touch anything. Pin your dependencies. The NVIDIA attack entered through a library. NVIDIA recommends pinning exact versions, scanning packages, and monitoring unexpected file changes. These reduce risk; pinning a version that is already malicious does not make it safe. Check the diff after the agent reads anything external. OWASP's guidance: review agent output for unexpected changes after it processes issues, PRs, comments, or documentation. The instruction you never typed can still land in the change. Keep a human between the agent and irreversible actions. Shell commands, network calls, pushes, and package installs deserve an approval step, not a bypass flag. The takeaway AI coding agents are useful because they read your project and act on it. The risk appears when attacker-controlled text becomes an instruction the agent follows. Treat instruction files as security-sensitive configuration, review the full diff rather than only the summary, and keep tool permissions narrow. These checks reduce the possible damage. They do not guarantee an agent will resist every injection. Cover photo by Sasun Bughdaryan via Unsplash. Code photo by Daniil Komov via Unsplash. I write about startups and shipping at StartupWiki.