Forever Security says it blocked a coding agent from installing a malicious npm package after the agent followed an AGENTS.md file in a customer's Downloads folder. Its October 22, 2026 research makes instruction-file provenance a practical security question for teams importing projects into coding assistants. The company did not establish how that customer file arrived, and its later demonstrations should be kept separate from the observed blocked attempt.
For developer-platform and endpoint-security owners, the useful response is to review which imported text can influence an agent's configuration. Maetra's recommendation is to treat an instruction file that requests persistent settings changes as part of the software intake review.
What the research supports
In its primary report, Forever describes a customer attempt involving the malicious package function-color. It then reports controlled tests with Codex and Claude Code: instructions could induce configuration changes leading to code execution or token exposure. Its Codex scenario required a trusted folder. Most testing used a harmless stand-in, with the real malicious package run once in an isolated virtual machine.
Help Net Security's October 26 coverage reports the same research. It is additional reporting, not an independent reproduction. The evidence does not show that every agent or configuration behaves alike, or that a website delivered the file found on the customer's machine. Forever's assertion that vendors have nothing to patch remains the researcher's opinion.
Put instruction files into the intake review
The following is Maetra analysis for teams managing coding assistants. A repository or archive intake process should identify files that an assistant may interpret as project guidance. Review them before granting a newly imported workspace the authority to change the developer environment. A familiar filename does not establish who wrote the contents or which changes the user intended to authorize.
Start with the requested task. If an employee asks an assistant to inspect an example application, a request inside that application to register a persistent tool server deserves separate scrutiny. The reviewer should identify the server, its source and the reason it is necessary. A statement that installation is routine does not answer those questions.
This need not become a ban on useful project instructions. Teams can maintain known instructions alongside their own repositories and record how changes are reviewed. The risky transition to examine is imported text gaining authority over settings or credentials beyond the project being inspected.
Keep project guidance from silently changing shared settings
For a controlled evaluation, use a disposable workspace without production credentials. Prepare a benign instruction file that requests a settings change outside that workspace. Agree on the expected outcome before running the test, then inspect both the assistant's response and the resulting configuration. Do not use a malicious package to test this boundary.
The acceptance question is whether the actual configuration stayed within the authorized scope. A reassuring explanation is insufficient if a new server or endpoint appeared anyway. Preserve the before-and-after settings and the relevant action record so that the security owner can assess what happened.
Also test an interrupted or restarted session. If a legitimate tool registration is permitted, determine where it persists and which later sessions inherit it. Record the owner of that configuration and how it can be removed. These are recommended checks, not claims about an unreported product feature or a test Maetra has performed.
Investigate the effect of a suspicious file
Finding unexpected instructions should lead to a scoped investigation. Establish whether the assistant read the file, attempted a command, changed settings, installed a package or sent credentials to an unfamiliar destination. Those observations describe different levels of exposure and may require different recovery actions.
Preserve evidence without copying live secrets into a ticket or shared report. Have the security owner assess affected sessions, credentials and persistent integrations. A blocked installation can still warrant checking earlier configuration changes; a suspicious text file alone does not prove that every possible downstream action occurred.
Forever recommends inspecting unexpected instruction files, reviewing agent settings and retaining approval and sandbox controls. For managed environments, the additional operational task is to make the source of those instructions and the resulting effects visible to the people responsible for the assistant.
Review one imported workflow
Choose one common developer workflow, such as inspecting a downloaded example project. Identify the instruction files it imports, the tools the assistant can invoke and the settings it can change. Assign an owner to each persistent integration before expanding the workflow's permissions.
Maetra Secure can support review of prompts, messages, tool calls and outputs for runtime threats. That scanning does not establish a file's provenance or replace endpoint permissions. The useful starting point is one specific configuration-changing action and evidence that it stayed within the task the user authorized.
Maetra's coverage of coding-agent sandbox escapes addresses the related question of execution boundaries.