There's a lot written about MCP security. Almost all of it's written for the person implementing the server, and it's good: threat models, OAuth flows, sandbox escapes, CVE write-ups. None of it's written for the person who has to sit in a room and say yes or ship it in the next release.
That person is usually a PM, and the honest state of the world is that no neutral, published checklist exists for them. I went looking. What comes back is vendor content marketing with a lead-capture form attached, or engineering documentation that assumes you can read a sequence diagram. NIST has control overlays for AI systems in development, and they aren't finished. OWASP published a Top 10 for Agentic Applications in December 2025 that's genuinely useful and is still organised around what an attacker does, when what you need is a list of what you have to decide.
So here's my attempt. Twelve questions, each one attached to something that actually happened to somebody with a name and a date. I've skin in this: I'm the PM for an MCP-based product at APIMatic, and I've had to answer most of these about my own thing.
The thing to understand before the list
If you read the security research you come away thinking the danger is exotic. Hidden instructions in tool descriptions. One malicious server rewriting how your agent uses a different, trusted server. Confused-deputy attacks against OAuth proxies. All of that's real, all of it has been demonstrated, and almost none of it has been used against anybody.
Here's what has. Through mid-2026, four MCP incidents are confirmed exploited in the wild rather than demonstrated in a lab. Three of the four are the same attack, and it's the least clever one available: the package changed after you trusted it.
In September 2025 an npm package called postmark-mcp shipped fifteen perfectly clean releases. It was a straight clone of the real Postmark library and it worked. Version 1.0.16 added one line, which BCC'd every email the server sent to an address at a domain the attacker controlled. 1,643 downloads. Koi Security put the blast radius at roughly 300 organisations. In February 2026 a group forked the real Oura Ring MCP repository under five fabricated GitHub profiles and got the lookalike into MCP registries, carrying a credential stealer. By July 2026 the same crew were running 7,600 malicious GitHub repositories, of which more than 800 pose as AI skills or MCP servers.
The fourth isn't an attack at all. In June 2025 Asana found that a tenant-isolation check in their own MCP server was wrong, and customers had been able to see other organisations' projects, tasks, comments and files. Around a thousand customers. They took MCP offline from 5 to 17 June. That's a multi-tenancy bug, the kind that has existed since SaaS existed, and it produced the only confirmed exposure of real customer data on this entire list.
Which tells you where to point your attention. The research matters and you should ask about it. But the questions that would have caught three of these four are boring supply-chain hygiene, and the one that would have caught Asana is a question you already know how to ask.
The two failures that will surprise you
Two of the research findings are worth understanding properly, because they break the mental model most people arrive with.
The tools can all be trustworthy and the system can still leak. In May 2025 Invariant Labs demonstrated this against the official GitHub MCP server, which has around fourteen thousand stars and no vulnerability in it. Somebody files a public issue on your repository. The issue body contains instructions. An agent with access to both that public repo and your private ones reads the issue, follows the instructions, and writes private repository contents into a public pull request. Every tool did what it says on the tin. The data that leaked came out through the front door.
Cato Networks did the same thing to Atlassian's MCP in June 2025 by filing a support ticket. The attacker was external, never authenticated, and never touched the MCP server. An internal engineer's AI action executed their payload with internal privileges.
Approval isn't durable. CVE-2025-54136 against Cursor, disclosed August 2025 at CVSS 8.8: once a user approves an MCP configuration, an attacker with write access to the repository can silently swap it for a malicious command, and the tool doesn't warn or re-prompt. You approved something once. What runs is whatever is there now.
The questions
Take these into the review. I've grouped them by what they're actually deciding, because half of them are product calls that get treated as implementation details.
| Question | Why, and who it happened to | Your answer |
|---|---|---|
| 1 Which tools are we exposing, and can I say the whole list out loud in one breath? | GitHub MCP, May 2025. The exploit needed one tool that reads private repos and one that writes publicly, in the same session. Surface area is a scoping decision. | list them, don't count them |
| 2 Does this server write anything, or only read? | Anthropic's directory requires every submitted tool to declare readOnlyHint or destructiveHint. If nobody can produce that split, the decision hasn't been made. | read / write / destructive, per tool |
| 3 If one tool is fully compromised, what is the worst single action it can take? | Supabase and Cursor, July 2025. The agent ran with service_role, which bypasses row-level security, so "read a support ticket" became "read the tokens table". | name the action, not the likelihood |
| 4 Does the server act as the user, or as one shared service account? | The precondition for the confused-deputy class. The spec is blunt: servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server". | |
| 5 Can untrusted text reach this agent? Tickets, issues, inbound email, form fields. | Atlassian, June 2025. If the answer is yes, every downstream tool has to be treated as attacker-influenced, and no amount of auth hardening changes that. | list every inbound path |
| 6 Remote or local? If local, what exact command line runs on the user's machine? | CVE-2025-6514 in mcp-remote, CVSS 9.6, 437,000 downloads. The spec requires clients to show the exact command "without truncation" for a reason. | |
| 7 Do we accept third-party MCP servers inside our product, and who owns that list? | postmark-mcp and the Oura clone. Both came from registries. The official registry says it "relies on the broader ecosystem for security scanning of actual server code". | a named person, not a team |
| 8 What happens when a server changes its tools after a user approved them? | CVE-2025-54136. Ask two things: do we re-prompt on change, and would we even notice? Tool-definition pinning exists and isn't on by default anywhere. | |
| 9 What exactly does the user see before a write happens, and can they refuse? | Human in the loop is SHOULD in the spec, never MUST. It's a design deliverable with an owner and a mock, or it doesn't exist. | point at the screen |
| 10 Is every tool call logged with who, what, when and which arguments, and can support retrieve it mid-incident? | Asana needed twelve days. The spec lists audit logging only as a client SHOULD, so on your server it's your requirement or nobody's. | |
| 11 Can this server ever see more than one tenant's data? | Asana, June 2025, ~1,000 customers. Not exotic and not AI-specific. It's the one that actually exposed real customer data. | |
| 12 What's the kill switch, and who can pull it without a deploy? | Asana disabled the feature for twelve days. If turning it off requires an engineering release, your incident response is one release cycle long. | a flag, and who holds it |
What the July 2026 spec release fixed, and what it didn't
The specification that landed on 28 July 2026 is a serious piece of security work and it's worth knowing what it covers, because it will come up as a reason not to worry.
It hardens authorization substantially. Six separate proposals went in: clients now have to validate the issuer parameter, which closes OAuth mix-up attacks; credentials are bound to their issuing authorization server; there's proper handling of scope accumulation during step-up auth. MCP servers are now formally OAuth 2.1 resource servers and must publish protected-resource metadata so a client can discover the right authorization server and stop guessing. The session handshake is gone, which retires protocol-level session hijacking as a category. Sampling is deprecated with a twelve-month removal window.
Here's the part to hold on to. None of that touches prompt injection, tool poisoning, or rug pulls. The spec doesn't claim it does. On tool descriptions its position is a warning rather than a control: clients "MUST consider tool annotations to be untrusted unless they come from trusted servers", which is advice about who you trust. It isn't a mechanism that helps you decide. Nothing pins a tool definition or forces re-consent when one changes. And human in the loop is still a SHOULD.
So a team can be fully compliant with the July 2026 specification and still ship every failure in the table above. That isn't a criticism of the spec. Authorization is the part a protocol can fix, and it fixed it. The rest is your product.
What the ecosystem will and won't do for you
Two things are commonly mistaken for a safety net.
The official MCP Registry, still in preview, does namespace authentication and metadata hosting. It verifies that whoever published under a reverse-DNS name controls that domain or GitHub org. It doesn't read the code, the tool descriptions, the permissions, or the runtime behaviour, and it says so plainly.
Anthropic's Connectors Directory goes further and is explicit about its own limit: verified connectors "have been tested by Anthropic for quality and compatibility, though verification is not a security audit." Community connectors are screened but not reviewed in depth, and once connected they have identical capabilities to verified ones. The submission bar is real, though, and worth reading even if you never submit: every tool needs a readOnlyHint or destructiveHint, OAuth 2.0 is required, and a missing privacy policy is an immediate rejection. That's a free, opinionated list of what a large vendor thinks the minimum is.
What does help concretely: mcp-scan, from Invariant Labs and now inside Snyk, passively scans a server for injection patterns in descriptions and has a tool-pinning mode that hashes tool definitions and flags a silent change. That's the postmark case, caught. It's open source and it takes an afternoon.
And run MCP Inspector against the server before you ship, yourself, with a person from your team who has never seen it. Enumerate the real tool list and call each one. Question 1 in that table is answerable in twenty minutes if somebody actually does this, and the number of teams shipping a server whose full tool list nobody has read is higher than you would like. In July 2025 Knostic scanned the internet and found 1,862 exposed MCP servers, of which none required authentication. Every one of those had a PM.
Three habits that survive contact with a real review
Write the questions down before the demo. Once you've seen the thing work, you'll ask about what it does rather than about what happens when it goes wrong. The table above exists so that the list isn't generated in the room.
Ask "what is the worst single action" and refuse the probability answer. Engineers will tell you how unlikely it is, and they will usually be right, and it isn't the question. Blast radius is a scoping decision and it belongs to you.
Treat every version bump of a third-party server as a new decision. Postmark was clean fifteen times and hostile the sixteenth. Whatever process you've for approving a server has to run again when the server changes, or it's a process for approving a snapshot of something that moves.
None of this requires you to read the authorization spec. It requires you to hold the position that a tool your product exposes is a product surface, with a blast radius and an owner, exactly like any other. That part was always yours.
