Coding assistants increasingly look beyond a developer’s chat message for context. They may read project documentation, repository rules, and dedicated instruction files before editing code or running tools. That convenience creates an opening for AI agent prompt injection: an attacker can place deceptive instructions in content the agent treats as authoritative, potentially steering it toward actions the developer never intended.
An October 2026 investigation reported by Forever Security brought this risk into focus. Researchers examined a malicious AGENTS.md file discovered in a customer’s Downloads directory after a coding agent attempted to install an untrusted package. The incident illustrates an important security boundary: Markdown is only text, but an agent capable of executing commands, installing dependencies, accessing files, or using the network can turn text into consequential action.
What Forever Security Reported
According to BleepingComputer’s report on the investigation, Forever Security found that a customer environment contained an unexpected AGENTS.md file in the Downloads folder. When a coding assistant was launched from that location, the agent read the file and attempted a package installation described by the researchers as malicious.
The reporting indicates an attempted installation in a real customer environment. It does not establish that every additional effect explored by researchers occurred there. Forever Security’s controlled demonstrations involving OpenAI Codex and Claude Code examined broader potential outcomes when agents encountered poisoned instruction files. Those tests showed how hostile text could try to influence an agent’s command execution, configuration changes, handling of credentials, and disclosure of information.
That distinction matters. The customer finding involved a reported attempted package installation, while additional outcomes were demonstrated under researcher-controlled conditions. They should not be presented as independently verified, widespread compromises. The investigation instead provides a practical case study of a broader class of coding agent vulnerabilities documented in an October 2026 Cloud Security Alliance research note on agent instruction file poisoning.
How Markdown Prompt Injection Works
Many coding agents support files that provide persistent project context. Depending on the product and configuration, examples may include:
AGENTS.mdCLAUDE.md- Rules stored under
.cursor/rules .github/copilot-instructions.md
These files can contain legitimate guidance about coding conventions, testing commands, repository structure, or project-specific constraints. An agent may automatically discover applicable files based on its working directory, the repository hierarchy, or product settings. This behavior helps the assistant work consistently without requiring the developer to repeat instructions in every session.
Markdown prompt injection abuses that trust. If an attacker can place or modify an instruction file where the agent will load it, the attacker can write language that impersonates normal project guidance. The file might tell the assistant to install an unfamiliar dependency, run a shell command, weaken a security setting, modify unrelated files, conceal changes, or transmit sensitive data.
Markdown is not executable by itself. Opening or storing a Markdown file does not inherently run its contents. The danger arises when an AI agent interprets the text as trusted instructions and then acts through tools available to it. The effective impact therefore depends on the agent’s behavior, approval model, working directory, network access, filesystem permissions, and access to credentials.
Nor does every instruction-file attack require a conventional software vulnerability. Some attacks exploit an unsafe trust decision rather than a memory-corruption bug or authentication bypass. The product may be functioning as designed—reading instructions and using approved tools—while still being manipulated by untrusted content.
Direct and Indirect Prompt Injection
Direct prompt injection occurs when a user deliberately enters hostile or conflicting instructions into the assistant’s prompt. The suspicious content is visible in the conversation, making its source relatively clear.
Indirect prompt injection arrives through material the model is asked or configured to process. Sources can include repository files, documentation, issue text, webpages, code comments, tool output, or downloaded archives. A poisoned AGENTS.md file is an indirect prompt injection because the developer may never knowingly submit its instructions.
This separation is central to AI coding assistant security. Agents must distinguish trusted developer policy from untrusted project content, even though both may be expressed in natural language.
Non-Operational Example: An Unexpected File in Downloads
Illustrative example only: A developer downloads a project archive and starts an assistant from the Downloads folder to organize its files. An unexpected instruction file in that directory claims to contain required setup steps. It tells the agent to install an unfamiliar package and send authentication information to an external server.
The developer did not request either action. A poorly constrained agent might nevertheless treat the file as project policy. A safer system would flag the untrusted dependency, require separate confirmation before accessing credentials or using the network, and refuse to transmit secrets. This example intentionally omits operational commands, package names, server details, and any copy-and-paste exfiltration payload.
Merely visiting a website does not always place such a file in an agent’s path. An attacker still needs some way to deliver or alter content—for example, through a downloaded archive, compromised repository, malicious contribution, unsafe extraction process, or another foothold. Whether the file is loaded also depends on the assistant and where it is launched.
What a Poisoned Instruction File Could Attempt
The consequences of malicious instruction files are bounded by the access available to the agent, but coding assistants can hold meaningful privileges. A successful injection may attempt to:
- Install typosquatted, compromised, or otherwise untrusted packages.
- Execute shell commands under the developer’s account.
- Alter build scripts, security controls, tests, or agent configuration.
- Hide modifications among large or generated changes.
- Read environment variables, tokens, SSH material, or cloud credentials.
- Send source code or authentication data over an allowed network connection.
- Delete files or make destructive repository changes.
These are possible objectives, not proof that every product will comply. Assistants differ in instruction precedence, file discovery, sandboxing, permission prompts, and tool controls. Product updates can also change behavior. Security assessments should therefore test the exact assistant, version, configuration, and operating environment in use.
How to Reduce AI Agent Security Risk
Control the working directory
Launch agents only from trusted project directories. Avoid starting them in Downloads, temporary extraction locations, shared folders, home directories, or other places containing unrelated and uncontrolled files. Move an unfamiliar project into an isolated workspace, inspect it, and establish the intended repository root first.
Inspect every source of agent instructions
Before enabling an agent, search for AGENTS.md, CLAUDE.md, Cursor rules, Copilot instruction files, and product-specific equivalents. Read them as security-sensitive configuration, including files in parent directories that might apply to the workspace. Scan for suspicious hidden Unicode, bidirectional text controls, zero-width characters, encoded content, and instructions designed to discourage review.
Require confirmation for high-impact actions
Configure the assistant to request explicit approval before package installation, shell execution, credential access, network transmission, configuration changes, and destructive operations. Approval dialogs are useful only when they show the complete command, destination, affected files, and reason for the action. Do not approve a batch merely because most changes appear routine.
Verify dependencies and review output
Check package names for typos, confirm publishers, inspect release history, and pin or verify expected versions. Review diffs, newly created files, lockfile changes, scripts, and shell commands before accepting them. Pay particular attention when an agent modifies its own rules, disables tests, edits ignore files, or generates unusually large changes.
Reduce privileges and isolate execution
Run coding agents under least-privilege accounts and use containers, virtual machines, or dedicated development environments where practical. Restrict outbound network access and mount only necessary directories. Keep production secrets out of agent-readable environments; use short-lived development credentials with narrow scopes instead.
Protect instruction files as code
Store legitimate agent rules in version control. Require review through code ownership for changes to AGENTS.md and related files, and alert on unexpected additions or modifications. Repository protections should cover instruction files even when they contain no executable code.
Monitor agent activity, including command execution, dependency installation, network destinations, and sensitive-file access. Built-in safety features can reduce risk, but they do not eliminate ambiguous instructions, approval fatigue, compromised dependencies, or configuration mistakes. Human review and sandboxing remain necessary.
Checklist Before Enabling an Agent on an Unfamiliar Repository
- Move the repository out of Downloads or other uncontrolled directories.
- Inspect all agent instruction and configuration files, including hidden files.
- Check instruction text for suspicious Unicode or concealed content.
- Confirm the agent cannot read production credentials or unrelated directories.
- Enable approval for commands, packages, network access, and destructive changes.
- Use an isolated, least-privilege development environment.
- Verify dependency names, publishers, versions, and installation scripts.
- Review proposed commands and diffs before accepting them.
What to Do If Compromise Is Suspected
Stop the agent session and preserve relevant logs before cleaning the environment. Disconnect network access if active exfiltration is possible. Review executed commands, installed packages, changed files, network connections, and agent transcripts. Remove untrusted instruction files only after recording their contents and origin for investigation.
Assume any readable credential may have been exposed. Revoke and rotate API keys, access tokens, cloud credentials, signing keys, and other secrets as appropriate. Rebuild from a known-good environment when integrity cannot be established, and examine how the file entered the workspace so the delivery path can be closed.
Frequently Asked Questions
Can a Markdown file execute commands on its own?
No. Markdown is a text format and is not inherently executable. Risk appears when an agent reads the text as instructions and uses its command, filesystem, package-management, credential, or network tools to carry them out.
Are all coding assistants vulnerable to the same attack?
No. Exposure varies by product, version, settings, instruction hierarchy, available tools, and operating-system permissions. Some assistants require approval or apply sandboxing, while others may have broader autonomy. Even strong safeguards should be paired with restricted privileges and human review.
Is an AGENTS.md file automatically malicious?
No. These files can provide valuable, legitimate project guidance. The concern is provenance and trust: who created or changed the file, where it was discovered, what scope it controls, and whether its requests match the developer’s intent.
What is the most effective immediate defense?
Do not launch an agent from an uncontrolled directory. Inspect instruction files first, isolate the workspace, remove access to production secrets, and require explicit approval for high-impact operations. These controls limit both the chance of manipulation and the damage an injected instruction can cause.
Treat Natural-Language Rules as Security-Sensitive Configuration
AI coding agents blur the line between documentation and operational control. The Forever Security investigation shows why a seemingly ordinary Markdown file deserves scrutiny when an agent can translate its language into action. Developers should treat instruction files like code, constrain agent permissions, verify every sensitive operation, and assume that unfamiliar repository content may be adversarial until reviewed.
