MCP server vetting is now a core AI supply-chain control

At a glance

What this is: This is a security analysis of MCP server vetting, showing that unreviewed servers become high-privilege AI supply-chain components with hidden access to tools, files, APIs, and system commands.

Why it matters: It matters because IAM, PAM, AppSec, and platform teams need to govern MCP servers as identities with scoped authority, not as harmless integrations that sit outside normal approval and monitoring.

By the numbers:

• 94% of IT professionals use AI tools, yet only 39% of organizations build robust internal frameworks to support their AI adoption.
• 35% of breaches involved data from unmanaged sources.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Knostic's MCP server security vetting guidance

Context

MCP server security vetting is about deciding whether a tool connector deserves privileged access in the first place. In practice, these servers sit inside the AI supply chain and can reach files, commands, APIs, and workflows that ordinary software approval processes never inspect closely enough.

The security gap is not theoretical. Developers often trust public repos, example configs, and shared snippets, while the server itself can extend an agent’s reach far beyond the interface. That makes MCP governance a control-plane problem for NHI, agentic AI, and developer workflow security at the same time.

Key questions

Q: What breaks when MCP servers are not vetted before use?

A: When MCP servers are not vetted, the enterprise loses control over privileged tool access inside AI workflows. A server can read files, call APIs, run commands, or mutate workflows before anyone confirms it is legitimate or minimally scoped. That creates a supply-chain path to secret exposure, workflow manipulation, and lateral movement through trusted automation.

Q: Why do MCP servers increase identity and access risk in AI environments?

A: MCP servers increase risk because they act like high-privilege non-human identities inside the development stack. They often receive broad permissions to support agent functionality, yet those permissions are rarely reviewed with the same discipline used for humans or service accounts. The result is more standing access, less visibility, and a larger blast radius.

Q: How do security teams know if an MCP server is behaving outside its approved scope?

A: They should compare observed file access, shell execution, and outbound calls against the server’s declared capability map. Unexpected directories, new APIs, or unapproved network destinations are strong drift signals. If the runtime behaviour is broader than the approved purpose, the server should be reclassified as unsafe until reviewed.

Q: Who should own approval for MCP servers in an enterprise?

A: MCP server approval should sit with a shared control group that includes AppSec, IAM, and platform ownership, not with developers alone. The reason is simple: these servers combine software provenance, privilege scope, and runtime behavior. A single team rarely sees all three risk dimensions well enough to govern them safely.

Technical breakdown

Why MCP servers behave like privileged NHI components

MCP servers are not just plugins. They are runtime connectors that can inherit broad access to local files, shell execution, network egress, and internal tools, which means their practical authority is closer to a non-human identity than to ordinary application code. Once approved, they can act inside the development environment with permissions that are often broader than the developer would receive manually. That is why vetting must examine source integrity, permission scope, dependency trust, and governance history together. A server that can read, write, and call out without narrow boundaries becomes a standing privilege problem, not a convenience feature.

Practical implication: treat each MCP server as a privileged identity with explicit scope, review, and revocation conditions.

How hidden attack channels emerge through tool and file access

The technical risk comes from how MCP servers interact with the agent and the IDE. They can inspect environment variables, scrape configuration files, mutate API calls, and trigger commands that look legitimate to the agent layer. That creates an internal attack channel where malicious behaviour hides behind normal development activity. If the server is tampered with, or simply over-permissioned, the agent can be induced to expose secrets, alter workflows, or route data to external endpoints without obvious user intent. This is why capability maps matter: the server’s declared purpose must match its real access pattern.

Practical implication: baseline every allowed capability and alert on requests that expand beyond the approved tool and file scope.

Why continuous monitoring is part of the approval decision

One-time approval is not enough because MCP server behavior changes after deployment. Configuration drift, dependency updates, and new permission requests can silently expand the server’s effective authority. Runtime scoring, audit logs, and behavioral baselines convert vetting into an ongoing control, making it possible to detect when a server begins touching new files, issuing unexpected shell commands, or making unapproved outbound calls. This is the same governance pattern used for other high-risk NHIs: what matters is not only whether the identity was trusted at onboarding, but whether its active behavior remains within the certified boundary.

Practical implication: pair pre-approval checks with runtime detection for drift, anomaly, and unexpected permission expansion.

Threat narrative

Attacker objective: The attacker aims to gain trusted runtime execution inside the AI development workflow and use that position to steal secrets, manipulate tool actions, or pivot deeper into the enterprise.

1. Entry occurs when a developer pulls an MCP server from a public repository, example config, or shared snippet without formal vetting.
2. Escalation follows when the server receives broad file, shell, or API access and can inspect secrets, alter workflows, or redirect agent actions.
3. Impact occurs when the compromised or over-scoped server exposes credentials, modifies outputs, or enables lateral movement inside the development environment.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP vetting is now an AI supply-chain control, not a developer preference. Once an MCP server can read files, execute commands, and call external tools, it sits inside the trust boundary for AI operations. That means approval decisions must join AppSec, IAM, and platform governance instead of living only in a developer workflow. The practical conclusion is that MCP servers need the same scrutiny applied to other privileged non-human identities.

Runtime privilege is the real risk surface, not repository popularity. Public repos, demo configs, and familiar-maintainer patterns can create a false sense of legitimacy. The control problem is that an approved server can still request excessive access, so the organisation must judge capability scope rather than community visibility alone. Practitioners should treat broad shell, file, and network permissions as a privilege escalation candidate until proven otherwise.

High-privilege AI connectors create identity blast radius across the development stack. When a server can mutate API calls, inspect environment variables, and trigger workflows, one weak connector can affect many downstream systems. That is a governance problem of concentration, not just misconfiguration. Teams should map where a single MCP server can amplify agent action across repositories, build pipelines, and internal tooling.

Configuration drift makes MCP governance a continuous assurance problem. The security assumption that a server is safe once approved fails as soon as dependencies update or permissions expand mid-life. This is not a patch cycle issue, it is a control-boundary issue, because the server’s effective authority can change without a new approval event. Practitioners need to design for change, not snapshot reviews.

Vetting quality should be measured by what the server can do, not what it claims to be. Source integrity, dependency hygiene, and governance checks matter only if they are tied to enforceable capability boundaries. The field is moving toward runtime inspection because static approval cannot keep pace with fast-moving AI development patterns. Security teams should therefore make dynamic enforcement the default for any MCP server with meaningful reach.

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.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• For a broader governance lens on AI-agent exposure, see AI Agents: The New Attack Surface report, which tracks how quickly agent access outpaces oversight.

What this signals

MCP server governance is converging with NHI management. As AI development stacks absorb more tool connectors, the boundary between software supply chain review and identity governance keeps shrinking. Organisations that already manage service accounts, secrets, and workload permissions should extend the same control logic to MCP servers before those connectors become untracked privilege endpoints.

Identity blast radius will become a practical planning metric. Once a connector can read files, invoke tools, and alter workflows, the key question is no longer whether it is convenient, but how far one compromise can travel. Security teams should prepare for approval processes that evaluate reach, not just trust, and align that with OWASP Agentic AI Top 10.

With 80% of organisations reporting that their AI agents have already performed actions beyond intended scope, the governance gap around connectors, permissions, and runtime checks is already visible. The next control failure is likely to be silent privilege expansion, not a classic malware event, which makes continuous inspection and auditability the decisive programme requirements.

For practitioners

• Classify MCP servers as privileged identities Assign ownership, approval authority, and revocation criteria for each server before it reaches an agent or IDE. Map the server to a named business purpose and deny any capability that is not required for that purpose.
• Vet source integrity and dependency chains Check repository ownership, commit history, maintainer patterns, package provenance, and any hidden execution paths in transitive dependencies. Reject servers that rely on opaque modules, unexpected network requests, or untrusted registries.
• Enforce least-privilege capability maps Document the exact files, commands, APIs, and network paths each server may touch, then compare observed behavior against that map. Treat shell execution and broad filesystem reach as escalation risks unless explicitly justified.
• Add runtime drift and anomaly monitoring Use behavioral baselines, audit logs, and real-time scoring to detect new permissions, unusual file access, and unexpected outbound calls. Escalate any capability expansion as a governance event, not just a technical alert.
• Maintain a centralized MCP inventory Track every approved server, its owner, its permissions, and its update history in one control point. Remove orphaned servers quickly and require re-review when maintainers, dependencies, or declared capabilities change.

Key takeaways

• Unvetted MCP servers are privileged AI supply-chain components, not low-risk add-ons.
• The evidence points to broad exposure, with hard-coded credentials and unmanaged secrets appearing in MCP environments at scale.
• Security teams need approval, inventory, and runtime monitoring for MCP servers before agent adoption expands further.

Key terms

• MCP Server: An MCP server is a connector that gives an AI agent structured access to tools, files, data, or system functions. In security terms, it is a non-human control point that can expand runtime authority, so its permissions and behavior need identity-style governance.
• Capability Map: A capability map is the explicit list of actions, resources, and network paths a server is allowed to use. It matters because MCP risk is defined by what the server can reach at runtime, not by its stated purpose or source repository alone.
• Configuration Drift: Configuration drift is the gap between an approved security state and the server’s current runtime state after updates or manual changes. For MCP servers, drift can silently widen access, introduce new behaviors, or invalidate the original vetting decision.
• Identity Blast Radius: Identity blast radius is the amount of downstream damage a single identity or connector can cause if it is misused or compromised. For MCP servers, it reflects how far one privileged tool path can spread across files, APIs, workflows, and adjacent systems.

What's in the full article

Knostic's full blog covers the operational detail this post intentionally leaves for the source:

• Repository vetting steps for MCP servers, including source integrity checks and maintainer verification
• Permission and capability review guidance for file, shell, and API access in development environments
• Runtime monitoring examples for configuration drift, behavioral anomalies, and privilege expansion
• Inventory and guardrail patterns for keeping approved MCP servers from spreading unchecked

👉 The full Knostic post covers source checks, permission audits, dependency analysis, and runtime monitoring details.

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.