Who gave that downloaded instruction file permission to change your agent?

Imagine you download a few files for a project, open an assistant in that folder and ask it to help sort them. One file looks like ordinary engineering notes. A paragraph near the end asks the assistant to register a helper server before doing any work.

Before the assistant treats that paragraph as setup, someone needs to establish where the file came from and whether it has authority to change the environment. A plausible filename doesn’t settle either question.

The observed file and the reproduction are different evidence

In an October 22 report, Forever Security describes finding a malicious AGENTS.md file in a customer’s Downloads folder, then reproducing attacks involving coding agents in a laboratory environment. The researchers say they didn’t know how the observed file reached that machine. Their demonstrated delivery route and their reproduction results should be read as researcher evidence, rather than a measured success rate for every agent or browser.

The useful question for an ordinary project is smaller: which files can supply instructions, and what happens when one asks for a change beyond the project?

Review the requested effect before accepting the explanation

An instruction that calls itself routine setup can still request a consequential action. Adding a server, installing a dependency or changing a global configuration affects what later sessions can do. Ask the assistant to show the proposed effect, its scope and the source of the request before authorizing it.

For the hypothetical folder above, start by treating the downloaded notes as material to inspect. Use a deliberate project workspace whose instruction files you’ve reviewed. That choice helps make provenance visible; it doesn’t guarantee that every agent discovers instructions the same way or that a dedicated directory is a complete defense.

Keep a small record of the files being reviewed, their source and revision, and any configuration changes they request. If the assistant can’t explain why an external file should control its tools, leave the change unapproved and return to the original task.

Use the right review tool for the file

Our AGENTS.md Linter is a relevant starting point for reviewing instruction files for the issues listed on its product page. For a separately obtained SKILL.md package, Skill Injection Scanner provides heuristic findings for a human review. These are different file-review jobs. Neither link establishes that the tool prevents the reported attack or that a clean report makes an instruction trustworthy.

The scanner’s current page also distinguishes its bounded earlier Agensi test from the updated package version’s unverified replay. Check the current prerequisites and compatibility evidence at the destination before buying or running a tool. Don’t let an article turn that limitation into a universal “works with your agent” claim.

Test a harmless boundary

If you build instruction-review workflows, use inert fixtures. Include an ordinary project note and a clearly labeled fictional request for a global configuration change. Check whether the workflow preserves the distinction, reports missing authority and leaves the environment untouched. There’s no need to include a working malicious package or live callback to test that handoff.

A useful review ends with a specific decision: this instruction was approved for this workspace, that change needs the owner, and these files are still unreviewed. That gives the next session something better to inherit than a filename and a guess.

No attack payload was run for this article. Tool descriptions were checked against current owned pages; this article doesn’t establish their detection quality or a new compatibility result.