The MCP Servers Nobody Audited

security ai consulting architecture mcp

A client connected 11 MCP servers to their development environment in three months. When I reviewed the OAuth scopes, two of them had write access to production infrastructure. Nobody had checked.

I was six weeks into a platform security review for a Series C healthcare SaaS company when their lead engineer casually mentioned they'd "wired up a bunch of MCP servers" to help the team move faster. He said it the way people talk about installing VS Code extensions — just a thing you do, not something you think hard about.

I asked for a list. He couldn't give me one. So I went looking.

Eleven servers, three months, zero reviews

The team had connected 11 MCP servers to their AI-assisted development setup between March and June. Some were official — the GitHub server, a Postgres query tool, their CI provider's server. Some were community-maintained, pulled from registries that had popped up faster than anyone could curate them. One was a homegrown wrapper around their internal admin API that a junior engineer built during a hackathon.

Every single one had been installed by the developer who wanted it, approved by nobody, and documented nowhere.

This isn't unusual. I've seen some version of this pattern at three different clients in the past four months. MCP adoption has exploded because it solves a real problem — giving AI tools structured access to the systems developers actually work with. But the permission model makes it dangerously easy to over-grant access and move on.

The OAuth scopes problem

Here's what tripped me up at this client. Two of the community MCP servers had been granted OAuth scopes that went far beyond what their stated purpose required. One was a "database schema explorer" that had been approved with full read-write access to their production PostgreSQL cluster. The other was a log search tool running with admin-level access to their cloud provider's API.

The schema explorer only needed read access to information_schema. Instead, it could DROP TABLE in production. Nobody had reviewed the scope request because the OAuth consent screen was a wall of text that the installing developer clicked through in four seconds.

When I asked the engineer who'd installed the schema explorer why it had write access, he looked genuinely surprised. "I thought it only read schemas. That's what the README said."

The README was correct about the tool's intent. The OAuth scope request was about its capability. Those are very different things.

Warning

An MCP server's documentation describes what it's designed to do. The OAuth scopes describe what it's allowed to do. The gap between those two is your attack surface.

The pattern I keep seeing

Across three engagements, the failure mode is remarkably consistent:

Phase 1: Someone installs an MCP server because it solves an immediate problem. A developer wants to query staging from their AI tool, or search logs without switching to a browser. Reasonable motivations.

Phase 2: The installation process asks for permissions. The developer grants them. There's no approval workflow, no scope review, no security team in the loop. The MCP server works, so it stays.

Phase 3: Other developers see it working and install more servers. Each one gets the same rubber-stamped approval. Within a few weeks, you have a dozen third-party services with direct access to internal systems, and nobody has a complete inventory.

It reminds me of the early days of browser extensions — except browser extensions couldn't usually reach your production database.

What the audit actually found

At the healthcare client, I cataloged all 11 servers and mapped their effective permissions against what they actually needed. The results:

  • 4 servers had appropriate, minimal scopes
  • 5 servers had broader access than necessary but were at least from trusted sources
  • 2 servers were community-maintained with scopes that constituted a real security risk

The hackathon admin API wrapper was its own category of problem. It bypassed their API gateway entirely, had no rate limiting, and used a single long-lived service account token that had been committed to a private repo. The token had admin privileges because "it was easier during the hackathon."

None of this was malicious. Every decision made sense in isolation, in the moment it was made. That's what makes this pattern so persistent.

The fix wasn't to ban MCP servers — they're genuinely useful, and telling developers they can't use productivity tools is a losing strategy. Instead, we put three things in place:

A server allowlist. Only pre-approved MCP servers can connect to internal systems. New ones go through a 30-minute security review that checks OAuth scopes against stated functionality.

Scope minimization as default. Every approved server gets the narrowest scopes that let it function. The schema explorer got read-only access to information_schema and pg_catalog. The log tool got scoped to search-only, no admin operations.

Quarterly access reviews. Same cadence as their existing IAM reviews. Someone looks at which MCP servers are installed, what they can access, and whether they're still being used. The two servers nobody had touched in six weeks got removed.

Total implementation time: about two days. The hard part wasn't the technical controls — it was convincing the team that MCP servers deserved the same scrutiny as any other third-party integration with production access.

The uncomfortable parallel

We went through this exact cycle with SaaS integrations ten years ago. Companies connected Zapier workflows and Slack apps and analytics tools to everything, granting broad OAuth permissions because the setup wizard made it easy and the immediate value was obvious. Then breaches started happening through those integrations, and suddenly everyone cared about third-party access reviews.

MCP is following the same trajectory, just faster. The difference is that MCP servers often get deeper access than a typical SaaS integration — they're designed to let AI tools do things, not just read data. A compromised or over-privileged MCP server isn't just a data leak vector. It's a tool that can take actions on your behalf.

I don't think the answer is to slow down adoption. But I do think every team running MCP servers in 2026 should be able to answer one question: what can each of these servers actually do, right now, with the permissions they have? If nobody on your team can answer that without checking, you're in the same spot my client was — trusting tools you haven't verified, connected to systems you can't afford to lose.