Your README Has Other Plans

I love the prospect of delegating work. Give a bug report to an AI coding assistant and it will go about examining the repository, modifying files, and running tests while you attend to other matters. What I'm less enthusiastic about is giving it unrestricted access to the environment where it happens.

We've spent years worrying about poisoned dependencies and compromised build pipelines. AI coding agents introduce a peculiar new vulnerability: software that interprets external information and decides how to act on it, sometimes with the full permissions of a human developer.

An attacker doesn't necessarily need to compromise a package or infiltrate a repository to interfere with development. Under the right circumstances, a few instructions hidden in a README file will do.

An Unexpected Promotion

AI coding assistants have evolved dizzyingly fast. We've gone from autocomplete suggestions to agents capable of independently navigating codebases, debugging applications, and executing terminal commands.

With Claude Code, Cursor, and similar environments, the developer defines an objective while the assistant works out how to accomplish it. This introduces an obvious security concern, since the agent routinely encounters material written by people other than its legitimate user.

Imagine you ask an assistant to update an application's authentication module. While examining the repository, it finds a README containing a supposedly mandatory setup procedure: download a diagnostic script and execute it before making any changes.

The script's actual purpose is to collect credentials. If the agent accepts the instructions as legitimate and has sufficient permissions, it ends up executing attacker-controlled code in the name of completing your request.

This is indirect prompt injection, in which malicious instructions reach an AI system through material it encounters during an authorized task.

The attack works by exploiting a confusion between information and authority. A README should help the agent understand a project, just as an issue description should help it understand a bug. Neither should have the authority to redirect its behavior toward unrelated operations.

OWASP's secure coding guidance for AI identifies these development workflows as vulnerable to indirect prompt injection. The list of possible entry points is extensive, including external documentation and seemingly innocent repository comments.

The Bot Took the Bait

By now, these vulnerabilities have escaped the realm of hypothetical security discussions. In June 2026, Microsoft published an investigation into prompt injection attacks against AI agents operating inside GitHub workflows.

One example involved an automated issue-triage bot in a fork of an open-source documentation project. An attacker disguised malicious instructions as a request for diagnostic telemetry, persuading the bot to append a hidden cross-site scripting (XSS) payload to a documentation file.

The attack succeeded in getting the bot to introduce the malicious code into a proposed change. Had that change been merged and published, visitors to the documentation website could have had their session tokens stolen.

Microsoft also demonstrated a separate vulnerability in Anthropic's Claude Code GitHub Action. In a controlled test, researchers manipulated the assistant into reading sensitive environment information from a CI/CD runner, exposing an API key that should have remained protected. Anthropic patched the vulnerability in version 2.1.128.

Both examples illustrate an uncomfortable possibility: an attacker without the necessary permissions persuades an authorized agent to perform the forbidden operation.

There's something almost embarrassingly simple about that arrangement: the attacker supplies the instructions, the assistant supplies the access, and the legitimate developer unknowingly supplies the infrastructure.

Too Many Keys

The growing adoption of Model Context Protocol (MCP) introduces another layer of complexity, since it provides a standardized way for AI applications to connect with external tools. Through MCP servers, an assistant gains access to services such as GitHub or cloud infrastructure, extending its capabilities beyond the local development environment.

Naturally, these integrations also expand the opportunities for malicious interference. In a tool poisoning attack, an adversary plants instructions inside an MCP tool's description or response. If the assistant follows them, a supposedly harmless integration becomes an avenue for unauthorized activity.

For example, a compromised documentation tool could instruct an agent to retrieve confidential data through a separate, legitimate integration. The problem grows worse when tools possess excessive permissions or change their behavior after installation.

According to research published by Snyk in June 2026, 50.8% of developers in its sample of nearly 10,000 environments had at least one MCP server installed. Researchers identified 392 confirmed prompt injection findings in MCP tool descriptions, while approximately one in seven developers using MCP had at least one security finding in their configurations.

I suspect many teams have a better inventory of their application dependencies than of the permissions granted to their coding assistants. We're giving these agents increasingly sophisticated capabilities without always applying the scrutiny we'd demand of conventional third-party software.

Keep the Keys

I wouldn't advocate slowing down AI-assisted development with endless approval dialogs. If automation becomes more cumbersome than doing the work manually, developers will eventually find ways around the restrictions.

Instead, I'd start by treating coding agents as privileged components whose access needs to be deliberately designed.

Least privilege is essential. An agent working on a frontend component has no business accessing production credentials. Permissions should reflect the immediate task, preferably through narrowly scoped, short-lived credentials rather than unrestricted access inherited from the developer.

Isolation provides another line of defense. Running agents inside restricted containers or sandboxes helps contain the damage if malicious instructions succeed. Filesystem permissions and outbound network access deserve particular attention, since preventing an agent from reaching sensitive resources is generally more reliable than hoping it refuses to misuse them.

External integrations need continuous scrutiny. MCP servers should come from verified sources, with tool definitions reviewed for unexpected changes. OWASP's MCP security recommendations also emphasize validating tool inputs and outputs, enforcing permissions at execution time, and monitoring tool activity.

Finally, consequential operations should retain a human checkpoint. Changing security configurations or deploying to production deserves explicit authorization, accompanied by an understandable record of the agent's actions.

These precautions won't eliminate prompt injection, but they reduce the damage caused by a successful attack. That's a far more dependable security strategy than trusting the model to recognize every malicious instruction it encounters.

The Price of Independence

I expect coding agents to become increasingly autonomous, and I welcome much of that progress. Eliminating repetitive tasks and accelerating development should leave engineers with more time for thoughtful decisions, provided we remain conscious of the responsibilities we're delegating.

After decades of learning to distrust executable code from unknown sources, we now need to extend that skepticism to the instructions our tools encounter. A README file may look perfectly harmless, but whether an AI agent treats its contents as documentation or as orders makes all the difference.