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

At a glance

What this is: This is a blog post on MCP server vetting, arguing that unreviewed servers have become a high-privilege entry point into AI-enabled development environments.

Why it matters: It matters because IAM, AppSec, and platform teams now have to govern not just agents and tools, but the trust boundary around the MCP servers that extend agent privileges into enterprise systems.

Context

MCP server security is really a trust-boundary problem. MCP servers can expose files, commands, APIs, and workflows to AI coding agents, which means approval decisions affect both software supply chain hygiene and identity governance.

The governance gap is that many teams treat these servers like ordinary extensions or examples rather than privilege-bearing components. Once deployed, they can expand access inside the development environment long before anyone validates provenance, permissions, or runtime behaviour.

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 unvetted MCP servers create more risk than normal integrations?

A: Unvetted MCP servers can inherit broad tool reach while hiding what data they read, what they transmit, and what decisions they influence. Unlike a conventional integration with clear boundaries, they sit inside an agent workflow that can browse, write, and act in sequence. That makes the risk cumulative, because one connection can expand the agent’s authority across multiple systems.

Q: How do teams know an approved MCP server is drifting out of scope?

A: Teams know an approved MCP server is drifting out of scope when runtime behaviour changes, new permissions appear, or the server begins touching files, commands, or APIs that were not part of the original review. Behavioural baselines and audit logs are the key signals, because configuration alone can miss the change.

Q: Should organisations treat MCP servers like ordinary plugins or like privileged identities?

A: Organisations should treat MCP servers like privileged identities, because they are not passive extensions. They execute inside trusted workflows, make file and API access possible for agents, and can widen the blast radius of a compromise if their permissions are not tightly scoped and continuously revalidated.

Technical breakdown

Why MCP servers become high-privilege access brokers

MCP servers sit between an AI agent and the systems it is allowed to touch, so they inherit the agent's ability to read files, run commands, and call internal APIs. That makes them closer to an access broker than a simple plugin. If the server is unvetted, its declared purpose can hide a much broader effective scope than the team intended. In practice, the security issue is not just code quality. It is the combination of elevated runtime authority, loose permission boundaries, and trust granted before legitimacy is confirmed.

Practical implication: Treat every approved MCP server as a privilege-bearing component and review the access it can actually exercise, not only the function it claims to provide.

How supply-chain risk enters through public repos and dependencies

The article describes a pattern where developers pull MCP servers from GitHub repos, example configs, and package dependencies without formal review. That creates a software supply chain path where a malicious or tampered component can enter through a trusted workflow. Dependency abuse matters because a server can look legitimate at first glance while still pulling in unsafe packages, typosquats, or hidden execution paths. The attack surface therefore starts before runtime, at selection and installation time, and expands again when updates or new dependencies arrive.

Practical implication: Use source integrity review and dependency scanning together, because repository trust alone does not establish behavioural trust.

Why continuous monitoring matters after approval

Vetting is only the first control. MCP servers can drift after deployment through configuration changes, new permissions, dependency updates, or silent behavioural changes that alter what they can do. The article's monitoring pattern combines runtime scoring, behavioural baselines, and end-to-end audit logs to detect when a server begins touching unexpected files, issuing unrequested commands, or widening its network reach. That matters because the original approval decision can become obsolete as soon as the server changes.

Practical implication: Put MCP servers under continuous behavioural monitoring so permission expansion and configuration drift are caught after release, not discovered during incident response.

Threat narrative

Attacker objective: The objective is to gain trusted runtime access inside the development environment and use that access to reach files, commands, APIs, and downstream workflows.

1. Entry occurs when a developer installs an MCP server from a public repository or shared configuration without formal vetting.
2. Credential or access abuse follows because the server operates with elevated environment privileges and can read files, run commands, or call internal APIs through trusted automation channels.
3. Impact comes when a malicious or misconfigured server expands its scope, triggers unsafe actions, or enables lateral movement across development workflows and connected systems.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud 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 vetting is now a supply-chain control, not a developer preference: The article shows that the approval moment is the governance moment, because an MCP server can inherit privileged runtime access before anyone validates legitimacy or scope. That shifts the control problem from post-deployment detection to pre-deployment trust qualification. Practitioners should treat MCP server approval as a security decision with identity impact, not a convenience choice.

Hidden privilege expansion is the core governance failure: MCP servers collapse the gap between tool integration and access delegation, which means a seemingly small extension can become a high-trust execution path. That is why source integrity, permission review, and dependency analysis all matter together rather than as isolated checks. The practical conclusion is that privilege must be evaluated at the server boundary, not only at the agent boundary.

Runtime monitoring turns static approval into enforceable control: The article correctly points to behavioural baselines, inventory tracking, and end-to-end audit logs because post-approval behaviour is where silent drift appears. In identity terms, the issue is not just who requested access, but what the server can still do after its initial review window closes. Teams should assume MCP server behaviour changes and govern accordingly.

Trusted automation creates an identity boundary that traditional software review misses: The security problem is not merely malicious code, but a component that can execute inside trusted development workflows with authority that looks legitimate to downstream systems. That makes the relevant named concept runtime trust debt: access granted on install that remains insufficiently revalidated during use. Practitioners should rework approval processes around this debt, because the enterprise is trusting action before trust has been proven.

AI coding environments now depend on non-human identity governance by another name: MCP servers extend the agent's reach into systems, so they must be governed like other privileged non-human identities even when the packaging looks like ordinary software. That means inventory, least privilege, and ongoing attestation all matter, but they must be applied to a component that can change behaviour dynamically. The field should stop treating MCP as a niche integration pattern and start treating it as an identity-governed control plane for agent access.

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: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime trust debt: approval at install time is not enough for MCP servers that can keep changing behaviour after deployment. Security teams need controls that re-test trust during execution, because the meaningful risk appears when a server's live permissions no longer match the original review.

MCP server governance now sits at the intersection of supply-chain security and identity control. That makes inventory, behavioural logging, and permission review mandatory inputs for any programme that lets agents reach into enterprise tools and data.

For practitioners

• Vet MCP server provenance before installation Confirm repository ownership, contributor history, and release integrity before any server is admitted into developer workflows or internal catalogs.
• Audit server permissions against declared purpose Map each requested file, shell, network, and API capability to a documented use case, and reject any scope that is broader than the task requires.
• Scan dependencies for tampering and typosquats Review transitive packages from registries and flag suspicious naming, hidden scripts, or unexpected network behaviour before approval.
• Monitor approved servers for configuration drift Track runtime behaviour, permission changes, and new access paths so silent privilege expansion is detected after deployment.
• Maintain a governed MCP inventory Keep a live register of every approved server, its owner, its scope, and its review status so shadow deployments are visible quickly.

Key takeaways

• MCP servers create a governance problem because they can inherit privileged access into agent workflows before their legitimacy is confirmed.
• The article says 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly the control surface can become dangerous.
• The practical response is to combine provenance review, scoped permissions, dependency scanning, and continuous runtime monitoring.

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.
• Runtime trust debt: Runtime trust debt is the accumulation of unresolved trust assumptions that systems continue to rely on while they are running. It appears when identities, permissions, attestations, certificates, or policy checks are not continuously revalidated, creating hidden exposure in live operations. Over time, this debt increases the chance of unauthorized access, drift, and brittle incident response.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.