MCP servers create a permanent, largely unaudited attack surface for AI agents

One approval, permanent trust

A post on dev.to argues that MCP servers, the integrations that connect AI agents to external tools and data, have quietly become one of the least audited parts of the AI stack. The author, who spent several weeks examining MCP server security, frames the core design problem simply: a server is approved once and then trusted indefinitely, with no re-authentication and no periodic review of what it can reach. From that point on, the server holds access to the agent's tools, prompts and data for as long as it remains in the configuration.

A supply-chain kill chain

The most detailed section of the post lays out an attack sequence targeting AI coding tool repositories. According to the author, an attacker opened 23 pull requests across those repositories within 75 minutes, with each change adding a malicious MCP server to a project's configuration.

The malicious server is built to look harmless at first. During its first three calls it performs the expected work, such as formatting or summarising. On the fourth call a counter trips and the payload activates: the server starts rewriting its own responses and directs the agent to search the environment for SSH keys, AWS credentials, Kubernetes configurations and shell history, then exfiltrate the results to an attacker-controlled host.

The author reports that in tests this chain succeeded roughly 90 percent of the time against a leading coding agent. Those figures come from the post alone and are not independently verified, but the mechanics require no exotic capability, only patience and a merged pull request.

Invisible to standard scanners

A second claim in the post is that conventional supply-chain defences do not catch this pattern. Software bills of materials, code review and static analysis all come back clean, the author writes, because the malicious behaviour ships in the initial code and executes only after a call threshold is crossed. With no suspicious fetch and no anomalous dependency to flag, scanners have little to key on; the server simply changes its behaviour over time.

Firewall logs as an instruction channel

The post also describes a variant the author names "GhostJacking," which abuses the habit of letting agents read operational logs. In the described flow, an attacker sends a crafted request to the victim's domain. The firewall blocks it and records a log entry. When the agent is later asked to troubleshoot and reads those logs, instructions hidden inside the blocked request are treated as the fix. The agent rewrites DNS to point at the attacker's server and reports the incident as resolved.

No perimeter is breached in the process. The log entry itself is what carries the attack in, which is bad news for any team piping firewall, CDN or application logs straight into an agent's context.

Recommended mitigations

The author's recommendations apply standard privilege hygiene to the new surface. Treat every MCP server as a standing privilege and review it with the same rigour you would apply to a senior engineer's access. Never feed raw logs to an agent, since logged text is now an injection vector. Keep DNS and production configuration writes behind human approval rather than letting an agent change them autonomously. Watch for brand-new repositories that open many pull requests across projects in a short window, which the author identifies as the fingerprint of this supply-chain approach. And rotate credentials regularly, on the assumption that any server sitting in a config for months may already be compromised.

Why it matters

MCP is on its way to becoming the default way agents gain real-world reach, and each server approved into a config inherits a level of trust that most teams never re-examine. The specific numbers in the post are anecdotal, but the structural point holds regardless: a compromised MCP server is not a broken dependency, it is a trusted participant that can steer the agent's decisions and read its context. Combine that with agents that autonomously read logs and edit configuration, and a single malicious integration can turn ordinary operational data into an attack channel. The mitigations cost little, and the alternative is finding the gap only after credentials have already left the building.