You installed an MCP server from a reputable GitHub account. The namespace checks out. The source code looks clean. You feel safe.
You shouldn’t.
Someone just ran 70 MCP servers in a sandboxed environment and logged everything they actually did at runtime. The results expose a blind spot that nearly every developer shares: we’ve built an entire trust model around who published something and almost zero tooling around what it does once it runs.
Identity is not behavior. A signed package from a trusted author can still exfiltrate your data at 3 AM.
Here’s the uncomfortable reality. The MCP registry verifies namespace authentication — your GitHub account, your domain. Static analysis tools scan source code and metadata for known patterns. Both approaches share a fatal assumption: that what a server is tells you what a server does.
It doesn’t.
The gap between static inspection and runtime behavior is where the real threat lives. A server can pass every code scan, carry a verified publisher badge, and still execute behavior at runtime that no static tool would ever catch. Dynamic imports. Environment variable reads. Outbound network calls triggered by specific input patterns. Output manipulation that only activates under certain conditions. None of that shows up in a source code review.
Static analysis is a locked front door on a house with no back wall.
Think about what an MCP server actually does. It sits between your AI agent and your tools, your files, your APIs. It mediates access. It reads context. It executes actions. Now think about the fact that the entire trust mechanism boils down to: “Did this come from a GitHub account we recognize?”
That’s not a security model. That’s a vibe.
The developer who ran this audit — Bhavesh Thapar — built the tooling specifically because he couldn’t find anything that answered the question that actually matters: what does this server do when you run it? Not what does it claim to do. Not what does the README say. What functions does it call, what data does it touch, what network requests does it make, and what does it do with the outputs before handing them back to your agent?
The answer, in many cases, is unsettling. Servers that read environment variables they have no business touching. Servers that make outbound calls to endpoints not mentioned anywhere in their documentation. Servers that alter response payloads in ways that could subtly manipulate what your AI agent sees and does.
You don’t need a zero-day when users will happily run your code with full privileges because your GitHub profile looks legitimate.
And here’s the twist nobody wants to hear: this isn’t a bug in the MCP ecosystem. It’s a feature of how we think about software trust in general. We’ve been doing this for decades. npm packages. PyPI modules. Docker images. We verify provenance, scan for known vulnerabilities, and then grant runtime permissions with a confidence that the verification never actually earned.
The MCP ecosystem just makes the problem more dangerous because the stakes are higher. These servers don’t just run code — they shape what your AI agent perceives and decides. A compromised MCP server isn’t just a data breach. It’s a manipulation layer between you and your most powerful tools.
So what changes? Runtime auditing needs to become the default, not the exception. Every MCP server should be observable at the syscall level before it ever touches production data. Sandbox first. Log everything. Then decide if you trust it.
Trust should be earned by behavior, not inherited by reputation.
If you’re building MCP servers, this means your users need visibility into what you’re doing — not just assurance about who you are. If you’re consuming them, this means you need to stop treating publisher verification as sufficient and start demanding runtime transparency.
The tools for this barely exist yet. That’s the point. The gap is real, the threat is live, and most people don’t even know it’s there. Now you do.
FAQ
Q: Isn't static analysis enough if the source code is open and clean?
A: No. Static analysis catches patterns it's been trained to recognize. It misses dynamic imports, conditional behavior triggered by specific inputs, environment variable reads, and runtime network calls that only activate under certain conditions. Clean source code doesn't guarantee clean runtime behavior.
Q: What should I actually do before running an MCP server?
A: Sandbox it first. Run it in an isolated environment with syscall logging and network monitoring. Watch what it touches, what it reads, where it calls out to. Only grant it access to production data after you've observed its actual behavior under realistic conditions.
Q: Is the MCP registry's trust model fundamentally broken?
A: It's incomplete, not broken. Namespace authentication proves origin. That's useful. The problem is treating it as sufficient when it only covers half the threat surface. The registry needs runtime behavior verification as a complement, not a replacement, to identity verification.