When the agent rewrites its own configuration

Newly reported research shows how the assumption can fail without a person changing anything, because in the researchers’ tests a plain Markdown file containing no code was enough to get an agent to edit its own machine-wide configuration, and the edit then carried into later sessions in other directories, which leaves security teams with the challenge of keeping an accurate picture of what an agent is configured to do, and what it did next, once the agent can change that picture itself.¹

Why a plain text file can change an agent’s setup

Coding agents read instruction files such as AGENTS.md and CLAUDE.md from whichever directory they’re working in and treat the contents as legitimate direction. So anything able to place a file in the right folder can shape what the agent does with permissions it already holds, including changing the configuration a security review approved. Security programs for these agents rest largely on settings such as sandboxes, approval prompts and MCP server lists, and they assume those settings stay where they were left.

New research reported by CSO Online shows how this plays out. Forever Security said it blocked an attempted attack on a customer’s machine in which an AGENTS.md file in the Downloads folder told a coding agent to install an npm package called function-color, and the installation was stopped before the package could run. The researchers could not establish how the file got there, but they showed that a malicious website could trigger a similar download without a separate approval prompt, and they tested the technique against two widely used coding agents, one reading AGENTS.md and the other CLAUDE.md. The files contain no executable code, so everything that follows is the agent carrying out instructions as written.

In tests using the recovered file, most of which used a harmless stand-in for the malware, the agent followed the planted instructions more than 90% of the time, modifying its machine-wide MCP server configuration and launching another session with approvals and sandbox restrictions bypassed, and because the malicious server was registered in that configuration it loaded again in later sessions even after the developer moved to a different directory. A separate test used a CLAUDE.md file to redirect the second agent’s API traffic to a server the researchers controlled, which exposed authentication tokens and let that server supply commands for the agent to run. The change took hold in roughly half of the attempts, and the researchers then replayed a captured OAuth token against the legitimate API to show how account compromise could follow.¹

What agents can and can’t change about their set up

The analysts CSO Online spoke to recommended treating instruction files like source code, with named owners reviewing changes to AGENTS.md, CLAUDE.md and the configuration directories around them, alongside keeping sandboxes enabled, restricting network access, routing installs through a scanning proxy or internal registry, using shorter-lived tokens and disabling the flag that bypasses approvals and the sandbox.¹

Each of these measures is a setting, or a review of a setting, applied ahead of time to an agent whose configuration is expected to stay as it was left. In the tests on the recovered file that expectation did not hold, because the agent made the change itself on the instruction of a file it had been told to read, and the setup a reviewer approved was no longer the setup running. The advice remains useful, and since it rests on settings an instruction can move, teams also need a way of knowing what those settings have become.

Why a snapshot and a traffic view both miss this attack

A configuration review is a photograph of the agent at the moment someone looked, so a machine-wide MCP configuration that gained a server afterwards simply reads, at the next review, as a configuration with a server in it, with no account of which session added the entry, on whose instruction, or what the agent did next. Controls built around traffic face a different difficulty, because reading an instruction file and editing a local configuration are events on the machine rather than traffic crossing a gateway, and by the time the new server is called the question has become why the agent is talking to it at all, which the traffic does not answer. Persistence raises the stakes of the first step, since a change made once, in one directory, shaped every later session in every other.

What teams can do now

The first step is an inventory of which coding agents run in the organization, which instruction files each one reads and which machine-wide configuration each one can write to, because the exposure comes from a trusted reader combined with a writable configuration and most teams have mapped neither half. Writes to machine-wide MCP configuration and launches with approvals or the sandbox bypassed are then worth treating as events a human should be able to explain, since both are unusual enough in ordinary development to merit review and both appeared in the attack chain.

Teams can also check whether a new MCP server registration traces back to the session that made it and the instruction behind it, because if they would only see it at the next review they are relying on a snapshot, and they can ask each agent vendor whether following an instruction file and changing the agent’s permissions can be separated.

A record that sits beyond the agent’s reach

Each of those checks depends on a record the agent cannot edit, since not every agent produces logs and those that do often allow sessions to be rewritten, so configuration, sessions and context are better collected from the endpoint, cloud, code and browser than taken from what an agent reports about itself. Every step in the chain is unremarkable alone, because developers read instruction files, edit MCP configuration and start new sessions every day, which is why drift shows up in sequences rather than single events: an instruction file in an unexpected folder, a change to machine-wide configuration, a session started with approvals bypassed, and a server that later sessions load elsewhere. A team that sees those four steps in order and tied to one agent can tell a legitimate change from a hijack, where a team seeing separate entries in separate tools usually cannot.

Such a record has already mattered in a case that shares the attack’s final step: when a compromised package triggered a critical incident at a large consumer marketplace, the EDR recorded nothing, and the record of the agent session gave the response team the exact commands and tool calls. We build Geordie around this reasoning, with an immutable audit trail that feeds a SIEM.

Controls that apply the same way every time

A deterministic rule applies the same way every time and does not depend on a model judging whether an instruction looks legitimate, which is the judgment a planted file is written to exploit. Beam, our inline remediation engine, escalates from Monitor and Guide through Confirm, which pauses the agent until its operator decides whether to continue, to Enforce, so a change to machine-wide configuration can be treated differently from an ordinary edit without stopping the work around it.

The hardening CSO Online’s analysts describe stays valuable, and teams should apply all of it. A setting the agent can edit holds only until an instruction persuades the agent otherwise, so the dependable parts of an agent security program are the ones that record what changed and apply the same rules whatever the agent has been told.

References

1. Prasanth Aby Thomas, Malicious downloads can trick AI coding agents into compromising themselves, CSO Online, October 26, 2026.
2. Forever Security, Hijacking AI agents via Downloads folder, original research report, as linked from reference 1.