MCP security broke in 60 days - what survived

The headline number sounds like a disaster: more than 30 MCP-related CVEs in a single 60-day stretch, according to a widely-shared security review, including a remote code execution bug rated 9.6 out of 10 in a package downloaded close to half a million times. It reads like a protocol that fell apart. It isn’t. The most clear-eyed comment on the thread named the real story: the root causes, “absent authentication, blind trust, no access control,” are “all things the protocol leaves up to each implementer to solve independently.” The Model Context Protocol didn’t break. It did exactly what it said it would, which was to hand security to whoever built the server, and a lot of them dropped it.

That changes the question for anyone evaluating these tools. If you run an operation and your team is starting to connect AI assistants to real systems, you are not auditing a protocol. You are auditing each server, one at a time, against a short list. We covered the other side of this table already, the liability you take on when you expose your own tools to agents. This piece is the buyer’s side: what to ask before you let an outside MCP server touch your data, and it belongs to the harder questions that come with handing AI real work.

Why the CVE wave was predictable

Spin up thousands of servers in a year, tell each builder that authentication is their problem, and a steady drip of vulnerabilities isn’t a shock.

It’s arithmetic.

The pattern researchers kept finding was depressingly plain. Red Hat’s writeup on the state of MCP security noted servers “bound to 0.0.0.0, meaning they were accessible to any device on the same local network without authentication,” many of them exposing “tools capable of executing operating-system commands without proper input validation or privilege restriction.” Read that twice. Some of these servers shipped with command execution wide open and no front door at all.

None of that is a flaw in the protocol text. It’s the absence of a safeguard the protocol never required, and that was a deliberate design choice rather than an oversight. The people who wrote MCP kept the core spec small on purpose, because a lean standard is easy to adopt and a heavy one dies in committee. Reasonable call. The cost of that call is that every security control you would expect, identity, scoping, logging, rate limits, becomes a thing each builder bolts on or forgets. Most of the early ones forgot, because they were racing to prove the tool worked, not to prove it was safe.

The spec is catching up, to be fair. Newer versions of the authorization guidance are tighter, the official registry is starting to vet what it lists, and the better client tools now nudge builders toward real auth. Good. But none of that changes the buyer’s position, because a maturing standard still can’t force any individual server to be safe, and you are connecting to a specific server, not to the standard. Waiting for the protocol to make this problem disappear is the same wishful thinking that automating a sloppy process will tidy it up. The structure has to come from you.

So the contrarian read is the calm one. A CVE a week wasn’t a sign the idea was rotten. It was the visible cost of a young ecosystem shipping fast and treating security as a later problem, the same way the early web shipped before HTTPS was the default and paid for it for a decade. The servers that came through the 60 days clean were not luckier. They were the ones that never trusted the spec to do their security for them, and you can spot those servers by asking five questions.

Five questions to ask before you connect a server

Here is the list. Run it on any MCP server before it gets near your data, whether a vendor built it or someone on your team cobbled it together over a weekend. Treat it the way a procurement team already treats a SOC 2 report or a vendor security questionnaire, because that is exactly what it is: a connected MCP server is a new piece of software with a key to your systems, and it earns the same scrutiny as any other.

Who authenticates? The right answer is a real identity layer, not a static key pasted into a config file. The mature pattern, per Red Hat’s guidance on getting MCP authentication right, is for the server to “delegate to an external OAuth/OIDC provider” and act as “an OAuth relying party, verifying tokens and enforcing scope and role checks on incoming requests.” Plain version: the server reuses the identity system you already trust instead of inventing its own. A good answer names a provider you recognize. The red flag is a server that hands out a long-lived token and calls it a day, or worse, one that accepts whatever token shows up. Stack Overflow’s deep dive on authorization in MCP is blunt that servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server.” A server that takes a token minted for something else has no real front door.

Who authorizes each tool? Authentication proves who is calling. Authorization decides what they get to do, and the two are not the same question. A server should scope access by impact, because, as that same Stack Overflow piece puts it, “reading data is generally less destructive than writing it, which is less destructive than deleting it.” The good answer sounds like tiered permissions: this client can read records, that one can also create them, almost nobody can delete. The red flag is one fat scope that grants everything, the “admin” pattern the article warns against directly. If connecting the server means handing it the keys to every function at once, the authorization layer is decorative.

Where does the audit trail live? Every tool call should land in a log that records who triggered it, when, and what it touched. Ask to see a sample. A server that can’t tell you what it did last Tuesday has already failed the review, because the entire promise of letting an agent act on your behalf rests on being able to reconstruct what it actually did. This is the question vendors most often fumble, and the fumble is telling.

What can a poisoned tool description reach? An agent reads tool descriptions as trusted instructions, so a malicious description can quietly steer it toward calls it should never make. You can’t fully prevent that at the description layer. What you can check is whether a steered call hits a hard boundary, a permission the server enforces no matter what the prompt asked, or a soft one that trusts the agent to behave. Picture it concretely: a client connected with read-only scope simply has no delete tool in its menu, so no amount of clever wording in a description can talk it into deleting anything, because the capability was never on the table. That is a hard boundary. The soft version exposes every tool to everyone and counts on the agent reading the descriptions correctly, which is the bet that lost 30 times in 60 days. The boundary is the thing that matters, not the agent’s good intentions.

Do the defaults fail closed or open? A new tool should be denied until someone grants it, never available until someone remembers to lock it down. This one question predicts the other four, because a team that defaults to closed has thought about all of this, and a team that defaults to open is hoping you will do the thinking for them.

Fail-closed or fail-open

Of the five, the defaults question is the one I would not compromise on, because it decides what happens in every situation you didn’t anticipate. A fail-open server treats access as the starting state and asks you to lock things down afterward. A fail-closed server starts with nothing permitted and makes you grant each capability on purpose. The first feels faster on day one and turns into the source of every incident on day ninety, which makes fail-open a tough sell the moment anyone runs a real audit.

We didn’t get this right on the first pass either. Running a production MCP server, the auth and scoping layer took far more iterations than the tools themselves, because the tools are the fun part and the boundaries are the part nobody enjoys until the day they save you. The lesson stuck: the surface area of a tool is trivial to build, and the surface area of its permissions is where the actual engineering lives.

Ask a vendor whether their defaults fail closed and listen to how fast the answer comes. A clear, immediate “closed, here’s how we scope it” is a good sign. A pause, or a pitch about flexibility, tells you the lockdown is your homework, and you will be doing it under pressure after something goes wrong rather than calmly before you connect. Which would you rather discover in a security review, that a server denies by default, or that it trusted everyone and waited for you to notice?

Run MCP where identity already lives

Here is the move that actually resolves this, and it isn’t waiting for a better spec. Stop treating the MCP server as a standalone thing you have to secure from scratch, and run it inside a platform that already solved identity, role-based access, and audit for human users years ago. Those controls don’t care whether the caller is a person or an agent. A request is a request, and it either passes the same checks or it doesn’t.

Think about what your organization already has. Your core systems already know who your people are, what role each one holds, and which records they can touch, and they already write an audit log a compliance officer can read. None of that had to be invented for AI. The mistake is standing up a fresh MCP server beside all of it with its own half-built notion of permissions, when the sane move is to make the agent enter through the same door everyone else uses.

The practical payoff shows up the first time something goes sideways. When an agent does something you didn’t expect, the question is always the same: who was it acting as, what was it allowed to do, and where is the record? A bolt-on server answers those three with a shrug. A server riding on an existing identity and permission layer answers them the way the rest of your stack already does, which means the incident is a five-minute log review instead of a forensic project. You also stop maintaining two separate ideas of “who can do what,” one for people and a flimsier one for agents, which is how the gaps that become CVEs creep in.

That’s the shape Tallyfy uses. The server at mcp.tallyfy.com runs in production with OAuth 2.1 and dynamic client registration, and it is listed on the official MCP registry, but the registration details are not the interesting part. What matters is that every tool call is a step inside a workflow that already knows who is allowed to do what and writes down what happened. An agent connecting through it doesn’t get a master key to every function. It gets the steps it is cleared for, with a human sign-off on anything consequential and a live record of who did what.

That is the same reasoning behind why it’s safer to bind an agent to a defined workflow than to hand it free run of your systems. The protocol stays minimal. The platform carries the weight it was never going to carry on its own.

This is where process beats plumbing. A model given a raw tool and no boundary will do whatever its instructions say, fast. The same model, reaching that tool through a workflow that gates the risky steps and logs the rest, is both useful and safe, because the structure does the part the protocol left blank. An agent supplies the judgment on one step; the process supplies the rules.

What actually survived

Run the title question backward. What came through the 60 days intact? What surprised us, watching the servers that held up, is how boring their security looked. Turns out the survivors didn’t outsource their security to a standard that was never offering any. They were the ones where identity was real, authorization was scoped by impact, the audit trail existed, and the defaults said no until told otherwise.

You don’t have to read 30 CVE writeups to apply that.

You have to run five questions on the next MCP server someone on your team wants to connect, and treat any one you can’t get a straight answer to as the answer. Who authenticates, who authorizes each tool, where the log lives, what a bad tool description can reach, and whether the defaults fail closed. A vendor who can answer all five quickly built their server for the world we are actually in. One who stumbles built it for a world where nobody was paying attention, and that world ended somewhere around the thirtieth CVE.