AGENTS.md Poisoning: Why Your Downloads Folder Is a Security Boundary for Coding Agents

Your coding agent trusts one file by design: the instruction file in its working directory. AGENTS.md for Codex, CLAUDE.md for Claude Code, the same pattern across harnesses. That trust is the feature. It is also an attack surface.

On October 22, 2026, Forever Security reported a case where an AGENTS.md file in a customer’s ~/Downloads folder instructed a coding agent to install the npm package function-color. Their monitoring blocked the install before code ran. They could not determine how the file arrived.

Two properties of everyday computing make this possible without exploiting any vulnerability:

A web page can write a file into Downloads on its own. BleepingComputer verified a proof-of-concept page that drops a harmless AGENTS.md there. Chrome, Edge, and Firefox save downloads to that folder by default with a notification but no location prompt. Brave asked for approval.
People launch agents from Downloads. Forever’s telemetry says hundreds of their customers start agents from that folder, often to tidy it or act on something just downloaded.

There is no patch to wait for. An agent that follows the instruction file in its folder is doing exactly what it was built to do. The fix is behavioral, and it fits in thirty seconds per session.

The Attack Vector

Coding agents scan the working directory for context files at startup. The scanning heuristic is simple:

Look for known filenames: AGENTS.md, CLAUDE.md, .cursorrules, or similar.
Parse the file as authoritative configuration.
Execute instructions without verifying provenance.

The agent does not distinguish between a project-specific instruction file and an ambient file that happened to be in the directory when you launched. If you start the agent from ~/Downloads, it will read ~/Downloads/AGENTS.md with the same trust it would give to ~/my-project/AGENTS.md.

A malicious instruction file can:

Redirect API traffic to a logging endpoint.
Install packages from compromised registries.
Modify environment variables or shell configuration.
Exfiltrate credentials or source code.

The attack requires no exploit. It requires only that a user launches their coding agent from a directory containing a malicious context file.

Filesystem Trust Boundaries

Most coding agents treat the working directory as the project root. They assume:

The user intended to work in this directory.
Files in this directory are part of the project.
Context files in this directory are authoritative.

These assumptions break down in ambient directories like ~/Downloads, ~/Desktop, or ~ itself. These are not project roots. They are staging areas, dumping grounds, and default save locations. Files arrive there without user intent.

Agent runtimes do not establish trust boundaries between user-intended project roots and ambient system directories. They do not:

Verify that the working directory contains a .git folder or other project markers.
Warn when context files are found in non-project directories.
Require explicit confirmation before reading instruction files.

The result is that any directory can become a project root, and any file in that directory can become configuration.

Pre-Flight Security Check

Run these before you start an agent session. Two of them are one-liners.

1. Check where you are

pwd

If the output ends in Downloads, Desktop, or your home directory, move. cd into the actual project folder before launching the agent.

2. Look for instruction files

find . -maxdepth 1 -type f \( -iname "*.md" -o -iname ".*rules" \) -print

This lists markdown files and dotfiles with “rules” in the name. If you see AGENTS.md, CLAUDE.md, or .cursorrules and you did not put them there, inspect them before proceeding.

3. Inspect the file

cat AGENTS.md

Look for:

Package installation commands.
API endpoint overrides.
Shell commands that modify configuration files.
Requests to disable security features.

If the file contains instructions you did not write, delete it.

Trade-Offs in Mitigation Strategies

Approach	Upside	Downside	Implementation Effort
Manual pre-flight check	Works immediately, no tooling required	Relies on user discipline, easy to skip	Low (copy-paste commands)
Directory allowlist	Prevents agent launch outside approved paths	Requires configuration, breaks ad-hoc workflows	Medium (shell wrapper or config file)
Context file verification	Detects unexpected instruction files	False positives in multi-project directories	Medium (hash database or signature check)
Runtime sandboxing	Limits damage from malicious instructions	Complex to implement, may break legitimate workflows	High (OS-level isolation or container runtime)
Agent-side provenance check	Verifies file origin before reading	Requires agent vendor support, not available today	High (requires upstream changes)

The manual pre-flight check is the only option available today that works across all agents. The other approaches require either custom tooling or changes to agent runtimes.

What Agent Vendors Could Do

Agent runtimes could establish trust boundaries without breaking existing workflows:

Warn on ambient directories. If the working directory is ~/Downloads, ~/Desktop, or ~, show a warning and ask for confirmation before reading context files.
Require project markers. Only read instruction files if the directory contains a .git folder, package.json, pyproject.toml, or other project markers.
Verify file provenance. Check file creation time and source. If a markdown file was created in the last hour and has no associated editor metadata, flag it.
Sandbox file reads. Prevent agents from reading files outside the project root without explicit user approval.

None of these changes would prevent users from working in arbitrary directories. They would only add friction when the directory does not look like a project.

Failure Modes

Even with pre-flight checks, several failure modes remain:

Nested directories. If you launch an agent from ~/Downloads/my-project, the agent may read ~/Downloads/AGENTS.md before it reads ~/Downloads/my-project/AGENTS.md. The priority order depends on the agent’s scanning heuristic.
Hidden files. Instruction files with leading dots (.cursorrules, .agentic) are easy to miss in a manual scan.
Legitimate ambient files. If you keep a global AGENTS.md in your home directory for cross-project defaults, the pre-flight check will flag it as suspicious.
Timing attacks. A malicious file could be written to the directory after the pre-flight check but before the agent starts.

The pre-flight check reduces risk. It does not eliminate it.

Technical Verdict

Use this approach if:

You launch coding agents from multiple directories throughout the day.
You work in environments where files appear in ~/Downloads without your explicit action.
You need a zero-dependency mitigation that works today.

Avoid this approach if:

You already use a directory allowlist or container-based isolation.
You only launch agents from version-controlled project directories.
You need automated enforcement rather than manual discipline.

The pre-flight check is a stopgap. The real fix is for agent runtimes to treat filesystem boundaries as security boundaries. Until that happens, the thirty-second check is the best defense available.

Agentic AI, minus the noise.