MCP server vetting exposes the governance gap in AI access

At a glance

What this is: This article is a practical checklist for vetting third-party MCP servers, with the key finding that production risk comes from tool scope, credential handling, dependency drift, and ongoing governance rather than local setup.

Why it matters: It matters because IAM teams now have to govern machine access paths that behave like non-human identities, where tool permissions and secrets exposure can change faster than traditional review cycles.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's analysis of how to vet MCP servers for production trust

Context

MCP server vetting is an identity governance problem as much as a software selection problem. Once an AI client can call a server with real credentials, the server becomes part of the organisation's non-human identity estate, with access scope, secret handling, and upstream trust all needing review.

The practical failure mode is simple: teams often evaluate MCP servers as if they were static tools, then deploy them into production as if they were governed services. That gap matters for NHI, because permissions can be broader than the description suggests, dependencies can drift, and the tool surface can expand after initial approval.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP servers create new risks for NHI governance?

A: MCP turns AI-facing integrations into persistent, callable access paths, which means secrets, resources, and tools all become part of the non-human identity surface. If those interfaces are not bound to lifecycle controls, teams lose visibility into who or what is using enterprise capabilities and when.

Q: What breaks when an MCP server's tool descriptions do not match its actual actions?

A: The trust model breaks. AI systems use the declared tool surface to decide when to call a function, so a harmless description masking a destructive action creates hidden privilege. That mismatch also undermines review, because security teams may approve the stated purpose while the runtime capability is materially broader.

Q: How should teams govern MCP server installation in developer environments?

A: Treat MCP server installation as a controlled enrollment step, not a convenience action. If the installer can collect API keys, register tools, or establish persistent session authority, then approval, logging, and ownership need to happen at install time. The key control is deciding who can add trusted tools before they become part of daily developer workflow.

Technical breakdown

Why MCP tool scope becomes an access-control problem

MCP servers expose tools, resources, and prompts through a client-server model, which means the server is not just code but an access path. The operator has to understand not only what the server can read, but what it can write, delete, send, or trigger on behalf of the connected AI client. Tool descriptions matter because they are part of the decision surface the model uses, and misleading descriptions can hide high-risk actions behind innocuous labels. In practice, this is an entitlement problem: the capability set is the real control boundary, not the repository name or the install command.

Practical implication: classify every exposed tool as a governed entitlement and review the write paths separately from read-only access.

How credential handling turns MCP into a secrets risk

An MCP server that inherits tokens or API keys becomes part of the organisation's secrets handling chain. If it sends credentials to services outside the expected trust boundary, or asks for OAuth scopes broader than the stated use case, it creates a hidden credential relay. That is especially dangerous when configuration files, environment variables, and remote transport all sit in the same workflow. The technical issue is not just exposure, but unintended propagation: once the server can authenticate outward, it can also widen the blast radius of every connected AI client.

Practical implication: inspect where credentials enter, where they exit, and whether requested OAuth scopes match the minimum tool function.

Why version pinning and sandbox testing matter for MCP governance

MCP servers often pull dependencies dynamically, which means the runtime behaviour you approve today may not be the one that executes tomorrow. Pinning versions, checking lockfiles, and running the server in a sandbox with a test account are ways to make behaviour observable before production access is granted. This is also where logs and failure handling become security signals, because you can detect hidden calls, unexpected hostnames, and unused capabilities only when the server is isolated. In other words, production trust depends on whether the server remains bounded after the first run.

Practical implication: require pinned builds and isolated test execution before any MCP server receives team-wide access.

NHI Mgmt Group analysis

MCP server vetting is really NHI governance, not just software hygiene. A third-party MCP server carries credentials, tool permissions, and downstream API trust into production, so the identity problem starts the moment the server is allowed to act on behalf of an AI client. The organisation is governing a non-human identity with delegated authority, not merely approving code. The practical conclusion is that MCP servers need entitlement review, secret review, and lifecycle review together.

Tool descriptions are part of the security boundary, not documentation fluff. In an MCP environment, the AI relies on the declared tool surface to decide when to act, which means misleading docstrings or broad tool sets can hide privilege creep. This is a classic NHI pattern: the declared purpose of the connector and the actual capability of the connector can diverge. Practitioners should treat exposed tool definitions as policy-bearing metadata, because that is where abuse often becomes invisible.

Ephemeral testing does not solve persistent production trust. A server can look acceptable in a sandbox and still become risky once multiple AI clients, changing dependencies, and broader permissions enter the picture. That is why production governance must outlast first approval and monitor continued behaviour over time. The central lesson is that trust in MCP servers decays unless access boundaries, dependency state, and usage logs stay under continuous control.

Runtime access to tools creates an identity blast radius that traditional app onboarding never had to model. When a server can read calendars, modify records, or call external services, its effective privilege is the sum of every tool and every credential path it can reach. That means the governance question is not simply whether the server is legitimate, but how far its authority can spread once connected. IAM teams should treat this as a blast-radius containment problem for NHI estates.

Central control planes are becoming the governance layer for AI-connected NHI estates. The article points to a broader shift from vetting individual servers to supervising the access relationships between servers, skills, and agents. That is the right direction for organisations with growing AI estates, because isolated review cannot keep pace with runtime change. The practitioner implication is to move from one-time approval to continuous policy enforcement across the full connector graph.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which is why exposed connectors often behave like overbroad identities rather than governed services.
• That same research shows 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, reinforcing why runtime governance has to extend beyond initial vetting.

What this signals

Secret exposure and tool sprawl make MCP governance a lifecycle problem, not a one-time review. Once 53% of servers can leak credentials through configuration, the operational task shifts to continuous inventory, scope validation, and dependency control rather than initial trust decisions. The right internal model is the OWASP Non-Human Identity Top 10, because MCP servers sit squarely inside NHI governance.

Identity blast radius is the concept teams need to manage as AI connectors multiply. When a server can act through multiple tools and downstream services, the practical question becomes how far its authority can spread before detection or revocation catches up. The same pattern appears in our Reviewdog GitHub Action supply chain attack analysis, where trusted automation became an access multiplier rather than a bounded helper.

MCP governance will increasingly converge with broader AI control-plane policy, especially as organisations connect more agents, skills, and servers to the same approval and logging layer. Teams that already centralise identity policy should extend that discipline to connector sprawl, because ad hoc vetting does not survive production growth.

For practitioners

• Inventory every MCP server as a governed identity Record each server's owner, purpose, exposed tools, credential source, and upstream dependencies before it is allowed into any production workflow.
• Separate read-only tools from write-capable tools Review delete, send, update, and shell-execution capabilities as distinct entitlements, then restrict them from broader team access unless there is a documented business need.
• Inspect OAuth scopes and secret paths Compare the server's stated function with the scopes it requests, and verify that tokens, API keys, and environment variables never cross into unintended destinations.
• Pin versions and test in isolation first Run each new server in a sandboxed container with no mounted volumes, confirm dependency lockfiles are stable, and watch logs for hidden calls or unexpected hostnames.
• Move approved servers into continuous policy control Use a central control plane to enforce tool-use rules, monitor ongoing access, and review logs whenever new AI clients or users connect to the same server.

Key takeaways

• MCP servers are non-human identities in practice, so their tools, secrets, and dependencies need identity governance rather than ad hoc approval.
• The biggest production risk is not local testing, but unchecked scope creep, credential exposure, and hidden runtime behaviour after deployment.
• Teams that centralise policy, pin versions, and log tool calls will have a far better chance of containing the blast radius as AI connectors multiply.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool Scope: The specific set of actions or resources a tool-enabled identity is allowed to use. For MCP, scope is the practical boundary that keeps a model-connected server from turning into broad system access. Weak scope design creates unnecessary blast radius and complicates later revocation.
• Credential Relay: Credential relay is the immediate forwarding of captured authentication material from a phishing environment to the legitimate service. It is dangerous because it converts a one-time code or token into an active access path before the victim can react or the session can expire.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Obot's full article covers the operational detail this post intentionally leaves for the source:

• Repository-level vetting checks for maintainer activity, commit history, and issue patterns before approval.
• Code-reading techniques for finding tool definitions, docstrings, and credential-handling paths in Python and TypeScript.
• Sandbox run guidance for evaluating server behaviour, logs, and hidden tool calls before production rollout.
• Central gateway and control-plane features for governing approved MCP servers, agents, and skills at scale.

👉 Obot's full article covers the technical vetting steps, sandbox checks, and control-plane governance detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.