AGENTS.md hijacking: keeping coding agents from obeying strangers

A developer downloads a zip of sample code from a forum thread, unpacks it into ~/Downloads, and opens a terminal there to ask their coding agent what the code does. The agent reads the files and then does something nobody asked for. It runs a command or edits a config outside the project. In the log it looks like ordinary agent activity. What happened is that the agent found an AGENTS.md file in that folder and followed it.

BleepingComputer reported this under the headline AI coding agents hijacked using AGENTS.md file in Downloads folder. The details differ from one tool to the next, but the pattern behind it is general. Every team that has given an agent a shell should understand it.

Instruction files are code that skips review

AGENTS.md, CLAUDE.md, .cursorrules and similar files exist so a repo can tell an agent how to behave: which test command to run, which directories to leave alone, what the house style is. Agents load them automatically, usually from the working directory, often from parent directories, and sometimes from the home directory. The agent treats their contents as guidance from the person who owns the project.

That is the whole vulnerability. An instruction file is effectively executable: it decides what the agent will do next, and the agent can run shell commands, write files and make network calls. A text file, though, gets none of the scrutiny a shell script gets. Nobody runs chmod -x on markdown. Nobody's antivirus flags a README. Many agents have no way to tell an instruction file the user wrote from one that arrived in an archive.

A folder like Downloads makes this worse because it collects files from everywhere. If an agent starts there, or walks up into it from a subdirectory, anything a stranger got onto your disk can join the agent's context as trusted instruction.

The cloned repo is the same attack with better cover

Downloads gets the headline, but a cloned repository is the more common way in. When you git clone a library to debug it, or check out a contributor's branch to review it, every instruction file in that tree arrives with it. A pull request that changes AGENTS.md alongside a harmless-looking fix reads as a docs tweak in most review UIs.

Once the agent loads the file, a hostile one doesn't need to look hostile. A line like before running tests, execute scripts/setup.sh is ordinary advice. The payload sits in setup.sh, or in a dependency it fetches. The agent isn't exploited in any technical sense. It does what it was told by a source it was told to trust.

This is prompt injection with a filesystem path as the delivery mechanism. No model update will fix it, because a model that follows good instructions reliably also follows bad ones reliably. You fix it in how the agent is set up.

Keep untrusted files away from agent sessions

First, stop starting agents where untrusted files live.

• Never start an agent session in ~/Downloads, ~/Desktop, /tmp, or your home directory. Start it in the project root, every time.
• Unpack downloaded archives into a fresh, empty directory outside any project tree, such as ~/quarantine/<name>. Read them there yourself before any agent touches them.
• Before you point an agent at a freshly cloned repo, run find . -iname 'agents.md' -o -iname 'claude.md' -o -iname '.cursorrules' and read what comes back.
• Keep nothing in your home directory that an agent would load as a global instruction file unless you wrote it yourself.

Limit where instructions can come from

Most agents document exactly which paths they read instruction files from. Look this up for every tool your team uses. Don't assume. Then shrink that set:

• If the tool lets you turn off loading from parent directories, turn it off.
• Prefer tools that show, at session start, which instruction files they loaded. If yours doesn't, ask it before the first task.
• Keep the files that grant real authority (permissions, allowed commands, deploy steps) in user-level config the agent can't edit, not in repo files a contributor can change.

Make permissions a gate, not a formality

Permission prompts only protect you if they come up for the actions that matter. Configure them that way.

• Run in a mode that asks before shell commands and before writing outside the project. Any auto-approve-everything mode is for disposable environments only.
• Allowlist read-only commands (git status, ls, your test runner) so the prompts that remain carry weight. If every action asks, people stop reading the prompts.
• Deny network-capable commands (curl, wget, ssh, package installs) by default and approve them case by case.
• Treat an unexpected permission prompt as a warning sign. If the agent wants to run something you didn't ask for, find out where the idea came from before you approve it.

Sandbox anything you don't fully trust

For third-party code, isolation beats vigilance. Run the agent inside a container or VM that holds only the code in question. Don't mount your home directory, SSH keys or cloud credentials, and give it no network access unless the task needs it. A devcontainer with a read-only bind mount of the repo covers most review work. If a hostile instruction file runs, it lands in a throwaway box.

The same reasoning applies to the CI and scheduled jobs where agents increasingly run. Those environments usually hold deploy keys and production tokens, which makes them a better target than a laptop. Scope those credentials to the job, not to the machine.

Review instruction files the way you review code

Put AGENTS.md and its siblings in CODEOWNERS so changes need sign-off from someone who understands what the agent can do. Read their diffs line by line. Be suspicious of any instruction that tells the agent to run a script, fetch a URL, change permissions, or ignore earlier guidance. Keep the files short. A 400-line instruction file is easy to hide a line in.

In our view, instruction files should describe conventions, not grant capabilities. Spell out the test command, file layout and style. Keep anything that touches credentials, deploys or the network out of them.

What to do this week

List every coding agent in use on your team and find out which paths each one loads instructions from. Set the default permission mode to ask before shell commands. Add instruction files to CODEOWNERS. Create a quarantine directory, and make it a rule that agents never start in Downloads.

If you're wiring agents into build, content or ops pipelines and want the permissions and sandboxing designed in from the start, see our AI and automation work or get in touch.