mcpgawk: A Security Tool That Catches MCP Servers Changing Behavior After Approval

The Hidden Security Gap in MCP: Changes After Approval

When you connect an MCP (Model Context Protocol) server to your AI Agent workflow and click "Approve," most people assume the security review is done. But that's not the reality — an MCP server can quietly change its tool behavior after you've approved it. Your Agent will call this "new version" without hesitation, and you'll have no idea it happened.

This is the core problem that developer Neelagiri Chettiyar's tool mcpgawk aims to solve. It landed 15th on Product Hunt with 69 upvotes, tagged under Developer Tools, GitHub, and Security. For AI developers increasingly relying on the MCP ecosystem, this tool addresses a long-overlooked blind spot in the trust model.

Why "Approve Once" Isn't Enough

The MCP protocol was designed to let AI Agents connect to external tools and data sources in a standardized way. When you approve a server, you're essentially trusting its currently declared tool descriptions and permission scope. But a server can modify those tool descriptions and capabilities at any time — and most Agents don't re-examine these changes on every call.

In other words, the attack surface lives in the time gap: approval happens at one point in time, but the tool's actual behavior can be tampered with at any moment afterward. A tool that originally only reads files could be changed to execute arbitrary commands — and the Agent will comply without raising any flags. This "post-approval bait-and-switch" attack pattern is especially dangerous for highly automated Agent systems.

MCP (Model Context Protocol) is an open standard proposed by Anthropic in late 2024, designed to provide a unified interface for interactions between AI models and external tools and data sources. Its architecture has three layers: the MCP Host (AI applications like Claude Desktop or Cursor), the MCP Client (which maintains connections to servers), and the MCP Server (lightweight services that expose specific tools and resources). When an Agent first connects to an MCP server, the server returns a "tool manifest" describing its capabilities, which the Host uses to present a permission request to the user. The problem is that the MCP protocol itself doesn't mandate that tool descriptions remain immutable — servers can dynamically modify a tool's description field or even its parameter structure at runtime, while most existing client implementations only display this information once at initial connection and don't warn about subsequent changes. This is fundamentally a trust assumption baked into the protocol design: it defaults to servers being honest and stable.

How mcpgawk Builds Its Defense

mcpgawk uses a three-layer mechanism to close this gap, centered on the concept of "baseline recording + sandbox verification + call-path interception."

Baseline Recording and Sandbox Detection

The tool records a behavioral baseline for every MCP server your Agent uses, locking in tool descriptions and permission states as a trusted reference point. It then tests the server's actual behavior in a sandbox environment, rather than simply trusting what the server claims about itself. This "verify, don't trust" approach lets it detect discrepancies between what a server declares and what it actually does.

Forced Interception Sitting in the Call Path

mcpgawk's most critical design choice is that it sits in the call path. The moment a tool's description or permissions change, any related calls are blocked until you personally confirm whether to accept the change. More importantly: the Agent cannot approve the change on its own behalf. This prevents a compromised Agent from self-authorizing, keeping the final decision firmly in human hands.

This enforced "human-in-the-loop" design is what sets it apart from passive monitoring tools. It doesn't alert you after the fact — it blocks execution before the risky action occurs.

Human-in-the-Loop (HITL) is one of the core design principles in AI safety, referring to the mandatory introduction of human judgment at critical points in automated workflows to prevent systems from making high-risk decisions without supervision. For AI Agent systems, HITL is especially important: a highly autonomous Agent might make dozens of tool calls during a single task execution, and if one link in that chain is maliciously tampered with, the Agent could complete an entire attack sequence without the user ever knowing. mcpgawk places the HITL intervention point precisely at the "tool description change" event rather than broadly monitoring all calls, achieving a good balance between interception granularity and the burden placed on user review. Notably, the constraint that "Agents cannot approve their own changes" specifically targets prompt injection attack scenarios — where an attacker might feed malicious instructions to the Agent, tricking it into calling a tampered tool and endorsing its own actions.

A Local-First Privacy Commitment

In an era of growing data privacy concerns, mcpgawk emphasizes that all detection runs entirely on your local machine with no data uploads. For development teams working with sensitive codebases or internal enterprise data, this eliminates the concern of handing MCP traffic to a third-party cloud service for inspection.

Multiple Delivery Formats: CLI, VS Code Extension, and MCP Server

mcpgawk offers a free command-line tool, a VS Code extension, and an MCP server form factor, covering different workflows from terminal operations to IDE integration. This multi-entry-point design lowers the barrier for developers — whether you prefer working in the command line or your editor, you can plug it into your existing workflow.

The free tier already covers the core baseline recording and interception features, while a more advanced gateway tier offers a 7-day trial for teams with more complex needs.

What This Means for the MCP Ecosystem

mcpgawk's emergence reflects a maturation in the MCP ecosystem — a shift from "it works" to "it works securely." As more Agents connect to external tools, supply-chain-style trust problems will only grow more pronounced. You're not just trusting what a server looks like right now — you're trusting that its behavior will remain consistent with every future interaction.

Similar "behavioral drift detection" thinking has solid precedents in traditional software supply chain security (like dependency locking and integrity verification). mcpgawk essentially transplants that philosophy to the interaction layer between AI Agents and MCP tools. For developers building production-grade Agent systems, tools like this may gradually shift from "nice to have" to "baseline requirement."

Of course, as a newly launched tool, its actual detection accuracy, the edge cases at the boundaries of its sandbox coverage, and its performance impact in high-frequency call scenarios all still need validation from real-world usage feedback. But at minimum, it puts a long-neglected problem squarely on the table.

Dependency locking mechanisms in software supply chain security — such as npm's package-lock.json or Python's hash-locked requirements.txt — are the mature precedents mcpgawk draws from: by locking in the exact version and integrity fingerprint of a dependency at a trusted moment in time, any subsequent silent updates trigger an alert. AI Agent toolchains currently lack an equivalent mechanism — MCP servers typically run as persistent connections or on-demand fetches, with no enforced versioning identifier analogous to a "package version number." mcpgawk's baseline recording essentially fills this gap at the application layer, using a snapshot of tool descriptions as a "version anchor point." As the MCP ecosystem expands, more native tool-signing or version declaration standards may eventually emerge at the protocol level, but until then, application-layer behavioral monitoring remains the most viable protection path.