AI coding agents can be tricked into running malicious commands hidden in repo files

A README written for the agent, not the developer

A recent dev.to article walks through a scenario that starts innocently: a developer clones an open-source project that looks legitimate — a reasonable README, some stars, active issues — and asks an AI coding assistant to track down a bug. The assistant reads files, checks documentation, runs commands and starts proposing fixes within a minute or two. The problem, the article argues, is that somewhere in the material the agent retrieves, there may be text written for the agent rather than for the human.

The distinction between a chatbot and an agentic coding tool matters here. According to the article, an agent typically runs in a loop: it receives the user's goal along with descriptions of its available tools, calls one, reads the result, and continues until the task is done. Crucially, most of the text the model consumes during this loop is not typed by the user. It consists of file contents, command output, search results and dependency documentation the agent fetched itself, and all of it becomes context the model uses to decide its next action.

The two-step chain from text to action

The dev.to piece offers a concrete payload: an HTML comment buried in a long README setup section, framed as a note for AI agents, instructing them to download a remote setup script and pipe it directly into the shell before running tests. A human skimming the documentation might miss it. An agent scanning the README for guidance may treat it as a legitimate step and, if it can run terminal commands without confirmation, execute it.

The same trick can live in source-code comments, docstrings, configuration files, or the text of an issue the agent has been asked to read. The attacker needs no access to the developer's machine — only a place to plant content where the agent is likely to encounter it.

Importantly, reading hostile text does not execute anything by itself. As the article breaks it down, the attack requires the agent to first interpret the text as an instruction and then choose to act on it with one of its tools; either step can be interrupted. A second example shows the subtlety: a note telling automated tools to seed the test database, where the suggested command actually targets a production environment. If the agent obeys without checking relevance or safety, it has crossed from reading untrusted input to taking a real action. Three things must align: content controlled by someone else, an agent willing to treat it as valid, and enough permission to act on it.

Tool access multiplies the damage

The same manipulation that would merely produce a misleading chat reply becomes materially worse when the agent holds a terminal, file-write access, credentials or network reach. Development environments often expose API keys and cloud credentials through environment variables or configuration files; if an agent can read those values and make network requests, injected instructions could persuade it to send secrets somewhere they should not go. The article is careful to note that not every agent has such broad access — some require approval for each command, restrict filesystem access or run inside isolated environments — and that granting an agent more access than the task needs is what turns a bad answer into a larger incident.

Why system-prompt warnings are not a security boundary

A natural defence is a line in the system prompt telling the agent never to follow instructions found in comments or documentation, and some tools include such guidance. The dev.to author argues this is an instruction, not a control: the model still has to judge which text is trustworthy, and malicious text is written to resemble ordinary project guidance. Enforced restrictions behave differently. If network access is disabled at the environment level, or a sensitive command requires human approval before running, the model cannot bypass that requirement merely by deciding the command seems appropriate. One approach asks the model to choose correctly every time; the other limits what happens when it chooses wrong.

Safeguards that interrupt the chain

Measures the article highlights include command approval steps that let the developer inspect what is about to run, and restricted or sandboxed environments that block access to production resources even if a malicious command executes. Limiting tool access to what the task actually requires reduces both the chance of success and the damage if an attack succeeds. None of these measures eliminates risk entirely, the article concedes, but they break the chain without depending on the model correctly identifying every hostile instruction.

Why it matters

This affects every developer who points an AI assistant at unfamiliar code. Traditional repo hygiene focuses on malicious code that runs when executed; here the payload is prose that executes only when an agent decides to obey it. As agentic assistants become default fixtures in editors, every cloned repository, dependency document and issue thread becomes an input channel to a system that may hold shell access and credentials. The practical takeaway is to treat content an agent retrieves as untrusted input — the way a web application treats user input — and to rely on mechanical controls such as approval gates and sandboxing rather than on promises written into a prompt.