SECURITY March 15, 2026 · 8 min read · Pavel We scanned 900 MCP configs on GitHub. 75% had security problems. We scanned 900+ MCP configurations on GitHub. 75% failed basic security checks. I expected to find maybe a dozen hardcoded API keys and a handful of overly permissive configurations scattered across the results. The usual negligence you stumble on when you go digging through public repositories looking for things people probably shouldn't have committed. What I didn't expect was that three out of four configuration files would fail basic security checks, and that the single most popular "MCP package" in the entire dataset wouldn't actually be a package at all. This is the full account of how I got to those numbers, what the raw data revealed along the way, and where I think the whole MCP configuration ecosystem is quietly heading. AI creates faster than it can be verified. MCP servers multiply this problem: every tool your agent calls is a new unverified input. The runtime layer, the proxy between your agent and the API, is where verification actually happens, because it's the only place that sees everything. Why I started poking around in the first place I've been building AI agent security tooling for the past few months, mostly focused on runtime enforcement, which is basically making sure autonomous agents don't do things they shouldn't be doing when they're making calls to LLM APIs behind your back. MCP kept surfacing in that work. For anyone who hasn't encountered it yet: MCP is the protocol that Claude Desktop, Cursor, and a growing number of similar tools rely on to connect AI agents to external servers. You define which servers the agent talks to in a JSON config, and then it just... has those capabilities. Reading files, querying databases, calling APIs, running shell commands, whatever those servers decide to expose. That configuration file is basically the permission boundary for everything the agent can do. Get it wrong and every misconfiguration flows directly into the agent's behavior, which gets uncomfortable when you consider that agents process untrusted input from users, tool outputs, and scraped web content. I kept running across theoretical discussions of MCP vulnerabilities. Prompt injection through tool results, malicious MCP servers, data exfiltration via crafted tool calls. Plenty of hypothetical attack scenarios had been written up, but I couldn't find anyone who had actually gone and looked at what real developers are configuring in practice. Are most setups reasonably locked down? Is version pinning widespread? Do people genuinely put their API keys directly into these JSON files? I figured the fastest way to answer those questions was to just go look. How the scanner was built (and what broke along the way) The core approach was deliberately unsophisticated. GitHub has a search API for code that I used to look for specific filenames and content patterns across public repos. The scanner grabs claude_desktop_config.json , .cursor/mcp.json , and anything with mcpServers in it, pulls down the raw file, tries to make sense of the JSON, and if it parses okay, runs its 52 checks against it. The checks cover whether there are leaked credentials, what kind of permissions each server gets, whether anyone bothers pinning package versions, and a few other things I kept adding as patterns emerged during early test runs. The implementation hit several annoying problems that are probably worth mentioning because they ended up shaping the final dataset. GitHub's Code Search caps results at roughly 1000 per query pattern, which I partially worked around by splitting queries using date ranges and file size qualifiers, though there's still an inherent ceiling on coverage. More frustratingly, some file paths on GitHub contain spaces, parentheses, and unicode characters (one particularly memorable path included Portuguese text about "creating your second brain with AI" and I still don't know if it was an actual project or a joke), and the scanner kept crashing on URL encoding issues. It took three separate rounds of fixes before the thing could crawl reliably without dying on edge cases. After approximately 40 minutes of crawling, waiting on rate limits, and retrying failed downloads, the scanner had collected 900 configuration files from 839 unique repositories. Every repository identifier was SHA256 hashed before being stored. No owner names, no repository URLs, and no actual credential values exist anywhere in the dataset. The initial results were surprisingly bad 75% of the collected configuration files contained at least one security finding. I had gone into this expecting something around 30%, maybe 40% if I was being particularly pessimistic about developer habits. Not three quarters. Technically 74.8% but at that point who's counting. The number seemed high enough that I spent a while double-checking the analysis pipeline to make sure I wasn't overcounting or flagging things incorrec...