MCP auth: The difference between a bridge and a backdoor
Read how the agent connector boom turned into the internet’s newest security liability and how to fix it before the next CVE.
For the last few months, Model Context Protocol (MCP) has been having a real moment, and honestly, it deserves it.
And we did.
We connected agents to file systems, CI/CD, cloud consoles, email, CRMs, internal dashboards, and databases. Everywhere context lived, we built a bridge.
There was only one problem: Like Jurassic Park, we were so preoccupied with whether we could connect agents to everything, we didn’t stop to ask if we should.
There was only one problem: we got so absorbed in the thrill of building bridges everywhere that we didn’t stop to ask whether we were putting guardrails on them (or even checking who could stroll across).
That’s what this piece is about: the security hangover after MCP’s gold rush (unauthenticated servers in the wild, supply-chain scares, drive-by localhost attacks) and the simple steps we need to take to keep using MCP everywhere without turning it into an open door.
The Gold Rush phase (aka the part where everyone forgets security)
MCP spread because it solved real pain. It’s the “universal USB-C for LLMs” idea: one standard to talk to many tools, across many models. That interoperability erased months of bespoke integration work, and adoption spiked.
But every gold rush has the same shadow. When something makes progress feel frictionless, we start treating the safety checks as optional chores, something we’ll do “after it works”.
Two truths explain almost everything happening right now:
- Auth in MCP is optional.
- A lot of people are skipping it.
Security researchers scanning the public internet have found roughly 1,862–2,000 internet-reachable MCP servers exposed with no authentication. They’re not just visible; many will happily list tools or execute calls for anyone who asks.
Let’s translate that out of protocol-speak:
A system designed to let AI run tools on your behalf is, in thousands of cases, letting anyone run tools on your behalf.
That’s not “risky in theory.” That’s “risky by default”.
Famous last words: “It’s fine, it’s just dev tooling”
Most of these servers didn’t get exposed because people are reckless. They got exposed because people are busy, optimistic, and shipping.
A lot of setups start innocently:
- “I just want Cursor/Claude to query my staging DB”
- “Quick bridge to Jira and Slack for the agent”
- “Let’s wire it to the local filesystem for tests”
- “We’ll add auth later; it’s internal”
But MCP servers almost never stay “just dev tooling.”
Because agents naturally expand:
- Today it’s read-only.
- Tomorrow it’s “create a ticket”.
- Next week it’s “ship the hotfix”.
- Then it’s “run whatever scripts I run”.
Security write-ups have been repeating the point: MCP servers inherit the blast radius of the tools they wrap. If one wraps cloud credentials, a filesystem, email, or deployment rights, an attacker doesn’t need to break your org; they just need your MCP server.
It’s not that MCP is inherently dangerous. It’s that MCP is leverage. And unsecured leverage is irresistible.
Supply chain reality check: CVE-2025-6514
The ecosystem’s wake-up call came the old-fashioned way: the supply chain.
In July 2025, security researchers discovered CVE-2025-6514 in mcp-remote, a widely used MCP OAuth proxy distributed via npm. The vulnerability enabled command execution and credential compromise. With over 437,000 downloads, the blast radius was substantial.
This matters because agent tooling supply chains have a special kind of potency:
- If a normal library is compromised, your app might be owned.
- If an MCP component is compromised, your app and your agent’s toolbelt might be owned.
And the hits kept coming. Two months later, the September 2025 npm phishing campaign compromised 18 popular packages, including chalk and debug, which are pulled billions of times per week. The attack showed how quickly malicious updates cascade through transitive dependencies. Exactly the kind of dependency graph MCP servers love.
The lesson isn’t “don’t install MCP packages.”
It’s “treat MCP packages like they’re sitting on your production control plane”. Because, functionally, they are.
The first malicious MCP server in the wild
Then came the thing everyone knew would happen eventually, but nobody wanted to see this soon.
In September 2025, Koi Security reported what appears to be the first confirmed malicious MCP server “in the wild”. It impersonated a legitimate Postmark MCP integration and silently BCC’d users’ emails out to an attacker-controlled endpoint.
This is the moment the ecosystem crosses a threshold: Once attackers can publish convincing MCP servers, the security model shifts from “protect your endpoints” to “assume extensions are hostile until proven otherwise.”
Favorite horror story: drive-by localhost attacks
And now for the plot twist that feels like a Black Mirror cold open.
Security teams have been documenting drive-by localhost MCP attacks: you visit a website, and the site quietly hits an MCP server listening on your machine (localhost). If that local server is permissive, the attacker can trigger tool calls that do real damage. File exfiltration, command execution, credential harvesting, the works.
No download.
No “are you sure?” prompt.
No drama.
Just a tab in your browser, and suddenly your laptop is a crime scene.
Local MCP is supposed to be a convenience. In some setups, it’s become ambient authority, and the web will happily abuse ambient authority.
The problem is not MCP. It’s the gap between power and discipline
None of this is a reason to slow down MCP adoption. If anything, it’s a sign of success: attackers go where the leverage is, and MCP has leverage now.
But leverage demands discipline.
Right now, MCP is moving from “cool integration trick” to “critical infrastructure” faster than our security instincts are catching up. Optional auth and friendly defaults were fine when MCP lived in small, trusted circles. They’re not fine when MCP is internet-reachable, wrapping real systems, and installed via supply chains that attackers already probe daily.
This is the familiar human pattern: When tech makes something possible, we treat it as inevitable. When it becomes inevitable, we assume it’s safe. And then reality reminds us that safety is a thing weIf you build with AI agents, you already know why. MCP turns the chaotic jungle of integrations into something sane. One clean standard to plug models into tools, data, services, local apps. The kind of thing that makes the “agentic future” look less like a keynote slide and more like your Tuesday. MCP’s promise is straightforward and intoxicating: connect agents to everything., not a thing we assume.
What secure MCP actually looks like
The main fix for secure MCP servers is putting real authentication in front of them. Not because auth is trendy, but because MCP servers are becoming real infrastructure, and infrastructure without identity is just a disaster waiting to happen.
Most of the damage we’re seeing right now comes from MCP servers with no locks at all. Adding auth won’t erase every risk (supply-chain traps and malicious servers still exist), but it closes the easiest path to disaster and shrinks the blast radius when the ecosystem gets weird.
You don’t need a 40-page spec reading session to do the basics right. The official guidance and every major write-up converge on the same fundamentals.
- Put authentication in front of every MCP server that touches real systems: If it can touch real data or run real actions, it needs real auth.
- Use scoped, delegated tokens: Treat agent access like user access: least privilege, time-bound, revocable. MCP supports OAuth for exactly this reason—use it.
- Never expose MCP to the public internet by accident: Bind to localhost if it must be local. Gate it if it must be networked. A surprising number of “internet MCP” incidents are just accidental exposure plus no auth.
- Assume tool descriptions and context are untrusted: Prompt-injection isn’t theoretical here; it’s a documented class of attack on agent toolchains.
- Audit what agents do: Treat tool calls like production operations. You want to be able to answer: what was called, by whom, on which server, and when? Because when something goes wrong, that trail is the difference between a mild headache and a week-long incident.
If you do those five things, you eliminate the vast majority of today’s real-world MCP horror stories, without giving up any of the momentum that made MCP worth adopting in the first place.
We’re past "early adopter". We’re in "clean up aisle five".
The scan results. The npm CVE. The first malicious server. The localhost drive-bys.
This isn’t a future threat model. It’s the current ecosystem.
MCP is becoming plumbing. And when plumbing is insecure, the whole house floods.
So here’s the simple call: If you run MCP servers, secure them now.
Not when you “harden later.” Not when it “graduates from dev.”Now.
Because we want MCP everywhere.
And the only way MCP scales safely is if secure MCP becomes the default, not the exception.
How WorkOS fits in
The good news: this isn’t an unsolved research problem.
It’s an identity and access problem we already know how to handle if we take it seriously.
That’s where WorkOS comes in.
Instead of reinventing auth for every MCP server:
- If you are already running user auth, use WorkOS Connect as an OAuth bridge: MCP clients authenticate through WorkOS, users sign in to your app, and WorkOS issues tokens that the MCP client can use with your MCP server. This is how Mux launched its MCP server quickly without rebuilding auth. For more details, see our docs.
- If you don’t want to run user auth (as you should), use AuthKit for all your logins: users, AI agents, MCP clients, and servers. WorkOS AuthKit handles all the complexity of the OAuth Authorization Server. You just build the MCP tools and resource endpoints. For more details, see our docs.
- Map OAuth scopes to internal roles and permissions using WorkOS RBAC. Each access token your MCP server receives will include the granted permissions so you can enforce least-privilege access.
- Use WorkOS Audit Logs to see what your users, agents, and MCP clients did, when, and on whose behalf. Get enterprise-grade compliance and stream logs to your customer’s existing SIEM provider effortlessly.
MCP gives agents reach.
WorkOS helps you decide who gets that reach, to what, and under what rules.