MCP server vetting exposes the governance gap in AI access

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Obot's blog post: Third-party MCP servers become a governance problem once they move from local testing into shared production use.

Why it matters: IAM and security teams need to govern tool scope, credentials, and ongoing access for MCP servers the same way they manage any other non-human identity with production reach.

Context

MCP server vetting is fundamentally about deciding whether a non-human integration should be trusted to act with your credentials in production. The article argues that what looks safe in a local editor session can become a governance issue once the same server is shared across a team or connected to live data.

The core problem is not installation. It is whether the server’s tool scope, credential handling, dependency state, and runtime visibility remain controlled after the first connection, especially when the server is community-built or no longer actively maintained.

That makes MCP a governance issue for non-human identity programmes, not just a developer convenience. The same pattern appears whenever an AI-connected tool can execute actions, access external systems, or outlive the assumptions made at onboarding.

Key questions

Q: What breaks when MCP servers are approved once but allowed to change later?

A: The original approval no longer describes the current access surface. If tools, backends, or ownership change after onboarding, the enterprise is operating on stale risk information. That creates blind spots in authorization, logging, and recertification, because the governing record reflects a past state rather than the server’s present capabilities.

Q: Why do MCP servers increase risk when tool permissions are too broad?

A: MCP servers can expand risk because they sit between an AI client and sensitive backends, often with enough reach to query data, trigger workflows, or modify records. If permissions are broad, a compromised or misbehaving agent can move from one tool to another with little friction. Least privilege and scoped discovery reduce that blast radius.

Q: What are the warning signs that an MCP server is too trusted?

A: The main signs are broad tool descriptions, remote servers that can change behaviour after approval, risky local STDIO wrappers, and outputs that can shape later agent decisions. If the server can reach production systems or return instruction-like text, it should be treated as a delegated access path, not a harmless connector.

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.

Technical breakdown

Why MCP server scope matters once it reaches production

MCP is a client-server protocol for connecting AI clients to external tools and data sources, but the operational risk comes from what the server is allowed to do with the caller’s credentials. A tool that only reads data has a very different trust profile from one that can delete records, send messages, or run shell commands. The article’s point is that tool definitions, docstrings, and exposed actions are part of the security boundary because the AI decides when to call them. If the server’s declared purpose and actual permissions diverge, governance starts with review and not with installation.

Practical implication: Treat exposed MCP tools as production entitlements and review them before any shared rollout.

Why credentials and OAuth scopes define the real access boundary

The article treats environment variables, API keys, and OAuth flows as the practical control surface for MCP risk. If a server forwards credentials to unintended services, requests broader scopes than its stated purpose, or redirects OAuth in unexpected ways, it has exceeded the intended trust model. This is classic NHI behaviour: a software identity acting under delegated authority, with the ability to move beyond the original use case if scope is too broad. In production, that means the access boundary is not the editor plugin itself but the combination of token handling, scope design, and downstream destinations.

Practical implication: Validate OAuth scopes and credential paths before production use, then revoke any server that can reach beyond its declared endpoints.

Why dependency pinning and sandbox testing are governance controls

MCP servers often depend on external packages, remote installs, and upstream repositories that can change without warning. If you run a server directly from the internet at startup, you lose version certainty and inherit supply chain drift as an access risk. The article also points to sandbox testing with no volumes mounted and limited network access as a way to observe behaviour before production. That is not just a dev hygiene step. It is a control to see how the server behaves under constrained conditions, whether it makes unexpected calls, and whether the implementation is still alive and maintained.

Practical implication: Pin versions, test in isolation, and block any MCP server whose runtime behaviour changes under real credentials.

Threat narrative

Attacker objective: The objective is to turn a trusted MCP integration into a path for credential reuse, unintended tool execution, or supply chain abuse.

1. Entry occurs when a team copies a third-party MCP server configuration from GitHub into an editor and gives it production credentials.
2. Credential abuse follows if the server exposes broader tool permissions or forwards tokens to services beyond its stated purpose.
3. Impact comes when the AI client repeatedly calls those tools in production, expanding access to data, calendars, files, or external systems the team did not intend to expose.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP server governance is now an identity problem, not just an integration problem: a third-party server that runs with delegated credentials behaves like a non-human identity with production reach. The trust decision is not whether the server installs cleanly, but whether its tool scope, token handling, and lifecycle can be governed after first use. That makes MCP subject to the same access discipline as any other production NHI, with explicit ownership and revocation paths.

Tool scope drift is the core risk in production MCP use: a server that looks harmless in testing can expose write, delete, or external-call capabilities once it is connected to live systems. The article’s vetting checklist is really a boundary-control test, because the AI client will call whatever the server advertises. Practitioners should read that as a warning that declared intent and executable privilege often diverge.

Runtime visibility becomes the decisive control once MCP servers leave the sandbox: onboarding checks can tell you whether a server is worth trusting today, but they cannot prove it will stay within bounds tomorrow. Updates, new dependencies, new users, and new AI clients all change the access picture. The implication is that MCP governance must move from point-in-time approval to continuous monitoring of tool calls and credential use.

Third-party MCP connectors create an upstream dependency on someone else’s maintenance discipline: abandoned repositories, stale commits, and shifting upstream APIs create a hidden availability and security risk that looks like a simple integration choice. The article is right to treat repository health as a security signal, because a dead project can become an unrevocable access path. Practitioners should treat maintenance state as part of entitlement review, not as an optional developer preference.

Ephemeral trust is the named concept this category now needs: the assumption that a server trusted in a local editor remains trustworthy in production is no longer valid once credentials, network access, and team-wide reuse enter the picture. Trust has to be re-evaluated at runtime, not just at install time. That shifts governance from approval of code to control of ongoing behaviour.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Ephemeral trust: MCP governance fails when a server trusted during local testing is assumed to remain safe after it moves into shared production use. Tool scope, credential paths, and maintenance state all change over time, so entitlement review has to become continuous instead of one-time.

A production MCP server should be managed as an externally sourced non-human identity with runtime monitoring and explicit offboarding paths. The relevant question is not whether the integration worked in a sandbox, but whether the server’s actual calls still match the access it was granted after rollout.

For practitioners

• Vet MCP tool permissions before rollout Review each exposed tool for read, write, delete, and shell capabilities, then compare those permissions with the server’s stated purpose before allowing shared use.
• Pin dependencies and source versions Freeze the package version, inspect lock files, and avoid direct internet installs at startup so the server you tested is the server you actually run.
• Sandbox every third-party server first Run the server in an isolated container with no mounted volumes and limited network access, then inspect logs for unexpected tool calls or hidden outbound requests.
• Validate credential paths and OAuth scopes Check where tokens come from, where they are forwarded, and whether requested OAuth scopes exceed the minimum needed for the declared tools.
• Continuously monitor runtime behaviour Move beyond one-time approval and review which tools are actually called over time so changes in access, maintenance, or dependency state do not go unnoticed.

Key takeaways

• MCP server vetting is really a test of whether delegated tool access can be governed after first use, not just whether the code installs cleanly.
• The highest-risk failure mode is scope drift, where a server that looked safe in testing can still write, delete, or forward credentials in production.
• Continuous monitoring, version pinning, and sandbox validation are the controls that keep third-party MCP integrations inside their intended boundary.

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.
• Delegated Credential: A token, key, or other secret that allows one system to act on behalf of another identity. For agentic environments, delegated credentials matter because they extend trust into runtime, where the agent can use them to reach tools, data, or services without a fresh human approval.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.

Deepen your knowledge

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