Every MCP server you connect is a third party you have handed one of your agents a door to. Some you wrote. Many you did not. Anthropic already counts more than 10,000 public MCP servers, and the friction to wire one in is close to zero, which is exactly the problem. The tools that let a developer add a server in an afternoon also let them add a supply chain dependency that reaches production data, without a review, without an owner, and often without security knowing it happened.
If someone asked you to list every MCP server running against your systems right now, who owns each one, and what it can reach, could you? At most organizations the honest answer is no, and that gap is the vetting problem in one sentence. This article is a practical checklist for closing it, built for security and identity teams who own the risk. It builds on our pillar on MCP gateway authorization.
What is MCP server vetting?
MCP server vetting is the process of assessing an MCP server before and while it is connected, to understand what tools it exposes, what data and systems it can reach, how it authenticates and authorizes calls, and whether its access can be scoped, monitored, and revoked. It treats each MCP server as a third-party supply chain dependency with access to production, rather than a harmless plugin. The goal is not only to approve or reject a server, but to bound what any server can do regardless of how much you trust it.
That second half matters, because vetting alone is never enough. A server that is safe today can ship a new tool tomorrow, and a server you trust can still be pointed at data it should not reach. Vetting tells you what you are connecting. Enforcement is what keeps it bounded after you connect it.
Why third-party MCP servers are a supply chain problem
The documented incidents make the abstract risk concrete, and they cluster into a few shapes:
The first is that a server can attack you before you ever call a tool. Trail of Bits showed that a malicious server can hide instructions in its tool descriptions, which reach the model when it lists available tools, before any explicit invocation. Connecting the server is the exposure. That alone should end the idea that vetting is a one-time approval of a tool you plan to call.
The second is over-scoped credentials turning a small foothold into a large one. In the GitHub MCP case, a malicious issue in a public repository coerced an agent into leaking private repository data using the same token, jumping the trust boundary because one credential reached both. In the database MCP case, the agent operated with a service role that bypassed row-level security while reading attacker-controlled content. Same pattern, different system. Broad standing access plus untrusted input is the recipe.
The third is authentication without authorization, at scale. When an AI feature on a widely used platform exposed data across tenants, the credentials were valid. The server just did not check whether the authenticated user should see the specific resource. That is the most common authorization gap there is, wearing an MCP badge.
Underneath all of it sits a governance problem the identity community kept naming through 2026. You cannot govern what you cannot see, and shadow agents proliferate the moment developers start handing agents their own credentials. OWASP now publishes a dedicated Top 10 for agentic applications precisely because this surface is new and growing, and its excessive-agency item from the LLM Top 10 is the failure mode most of these incidents share. Meanwhile machine identities already outnumber human ones by more than 80 to 1, and most organizations report they lack identity security controls for AI. MCP servers are a fast-growing slice of that.
The MCP server checklist
Work an MCP server through these seven areas before you connect it, and keep the answers current after you do. The through-line is that the strongest controls do not depend on trusting the server, because the servers you least control are the ones most likely to hurt you.
| Area | Description |
|---|---|
| 1. Inventory and ownership | Can you produce a current list of every MCP server connected to your systems, with a named human owner for each. Is a server registered before it is allowed to make any call, so unregistered servers are blocked at the gateway rather than discovered later. Discovery is the prerequisite for everything else on this list. |
| 2. Identity and least privilege | Does the server, and each agent using it, have its own dedicated identity rather than a shared secret. Are its credentials scoped to the minimum it needs, short-lived rather than long-standing, and never a broad role that bypasses the data layer's own controls. The pattern to aim for, described well at Identiverse 2026, is persistent identity with ephemeral credentials. |
| 3. Tool surface | Do you know exactly which tools the server exposes, and have the tool descriptions been reviewed, given that descriptions themselves can carry injected instructions. Is each agent shown only the tools it needs, a scoped catalog rather than the full set. A tool an agent cannot see is a tool it cannot be talked into using. |
| 4. Authorization enforcement | Is there an authorization decision outside the server, checked before a tool runs, that considers the agent, the user it acts for, the tool, and the arguments. Does the system fail closed, denying when it cannot get an explicit allow. This is the item that holds even when the server is third-party and you cannot see its code. |
| 5. Data and downstream reach | What can the server actually reach once a call succeeds, and does that reach respect the underlying data controls rather than bypassing them. For retrieval and RAG paths, is access filtered by the user's real permissions, something we cover under access control for RAG. The chain does not end at the MCP server, so neither should your assessment of what it can touch. |
| 6. Evidence and audit | Can you produce a record of every action a given server or agent took, with the policy that allowed or denied each call. If a regulator or an incident review asks what a third-party server's agent did last Tuesday, the answer should be a query, not an investigation. This is what audit logs are for. |
| 7. Lifecycle and revocation | Can you narrow or cut a server's access without redeploying anything, and does its access expire or get reviewed rather than living forever. The right emergency control is graduated, a dimmer switch rather than a kill switch, so you can scope a server down the moment it worries you while legitimate work keeps running. |
If a server fails several of the first three areas, that is a reason to be cautious about connecting it. If it fails areas four through seven, that is usually a reason to fix your own enforcement, because those controls are yours to build regardless of whose server it is.
Not every server deserves the same scrutiny
Running the full checklist against every server equally is how vetting programs stall. The work does not scale, so it quietly stops happening, and you are back to no vetting at all. The way to keep it alive is to tier servers by how much you trust them and how much they can reach, and spend your attention where the risk actually is.
A server you wrote and run yourself, against non-sensitive data, is a low tier. You still inventory it and enforce authorization on it, but it does not need a deep third-party review. A third-party server from a known source, reaching moderately sensitive systems, is a middle tier that warrants a real look at its tool surface, its credential model, and its downstream reach before it goes live. A server from an unknown source, or any server that can touch regulated data, production writes, or customer records, is the top tier, and it gets the whole checklist plus the tightest scope you can give it and the closest monitoring you have.
Tiering changes the default. A high-tier server does not get connected until it has been through the full assessment, and it fails closed on anything not explicitly allowed. A low-tier server can move faster, because the blast radius if it misbehaves is small and bounded by the authorization you enforce anyway. What tiering must never do is let a server self-select its tier based on how much the team wants to use it. The tier is set by what the server can reach, not by how convenient it would be to skip the review. The data it touches decides the scrutiny it gets.
Vetting is continuous, not a gate
The instinct to treat vetting as a one-time approval is the thing to resist. A server's tool set can change after you approve it, a credential can drift broader than intended, and a server that was internal-only can quietly gain external reach.
The sensible posture, which mirrors the observe-then-enforce advice from EIC Berlin 2026, is to start any new server permissive but closely logged, watch what it actually does, and tighten its scope deliberately as the real pattern of use emerges. Re-vet whenever the tool surface changes. Treating non-human identity governance as an ongoing program rather than an intake form is the difference between a checklist that ages out in a month and one that keeps working.
How Cerbos fits
The reason so much of this checklist is achievable even for servers you did not write is that the strongest controls do not live inside the server. They live at the boundary. Cerbos is an external authorization layer, so the decision about whether a tool call runs is made by a policy decision point you own, not by the third-party server you are trying to assess.
That flips several checklist items from "hope the vendor did it right" to "we enforce it regardless." Least privilege, per-call authorization on the agent and the acting user, fail-closed denial, a complete decision log, and runtime scope changes without a redeploy are all things you control at the boundary, independent of the server's own hygiene. Policies are written as code, versioned and tested, and the same model governs every non-human identity in your estate, human-sponsored agents included. The practical patterns are in our MCP authorization guide.
The question every security leader is really being asked about agents is the one every audit and every incident review ends on. Show me the policy that was in effect at the time. If the answer for a third-party MCP server is a screenshot or a Slack thread, you have vetting without enforcement. If it is a decision log tied to a versioned policy, you have both, and you can connect servers with your eyes open rather than closed.
Try Cerbos to enforce authorization on third-party MCP servers you do not control, or book a call to review your agent supply chain with the team.
Go deeper:
- Zero Trust for AI: Securing MCP servers (eBook) for the full authorization pattern behind MCP
- The IAM security checklist for 2026 (Checklist) for the wider identity and access gaps to close
FAQ
Tagged in
