MCP Config Tampering (Instance-Resolved)

How the attack works

An AI agent session (Claude Desktop, Cursor, VS Code, Cline, Gemini, etc.) is running and has an active process lineage tied to that session. During the session, something in that lineage writes to the agent's MCP server configuration file - the file that defines which tools/servers the agent can call. The rule confirms the write came from a process actually belonging to that specific agent session, not a coincidentally similar PID. Because MCP configs are read on startup, a tampered file grants the agent new tools or servers on its next launch, giving the change persistence that outlives the current session.

Netzilo detection

Why it matters

An attacker who can get one write into this file gains a standing backdoor: new tools, servers, or capabilities are silently added to the agent's permissions and reappear every time the agent restarts, until someone notices and reverts the file.

What you can do

• →Treat MCP config files (claude_desktop_config.json, .mcp.json, .cursor/mcp.json, .vscode/mcp.json, cline_mcp_settings.json, .gemini/settings.json) as sensitive - put them under version control or file integrity monitoring so unexpected writes are visible.
• →Review any MCP server entries you don't recognize, especially ones added outside an explicit user action like `claude mcp add` or the editor's 'Add MCP server' flow.
• →Restrict write permissions on these config files to the user account, not to arbitrary child processes spawned by the agent.
• →When using provisioning tools (ansible, chezmoi, make, stow) that template MCP configs, run them outside live agent sessions where possible, since these writes will otherwise show up as flagged events.

Known benign look-alikes

• User explicitly asked the agent to install or configure an MCP server ("claude mcp add", Cursor/VS Code "Add MCP server" flow). Suppressed unless a corroborator fires - the editor/agent process writing its own config from inside its own lineage with a benign server definition returns allow and produces no event at all.
• Dotfile managers and provisioning scripts (chezmoi, ansible, make, stow) run from inside an agent session that template MCP configs through sed/tee/jq. These DO match the "spawned utility" corroborator and will be reported once per write; report-only by design.
• git checkout / git stash restoring a project-scoped .mcp.json - the writer basename is "git", which is not in the spawned-utility set, so it is not corroborated.
• CI or test fixtures that generate mcp_settings.json under an agent-driven build.
• Multi-product config sync tools that legitimately write two or more MCP configs in one run will trip the fan-out corroborator.

References

• https://modelcontextprotocol.io/docs/concepts/architecture
• https://attack.mitre.org/techniques/T1546/
• https://attack.mitre.org/techniques/T1554/