Should security teams approve MCP servers from public package sources without attestation?

What makes provenance mandatory for public MCP servers?

Public package sources are convenient, but they are also an untrusted supply path. An MCP server is not just a library, it is executable integration code that can sit between agents and internal systems, so approval has to treat provenance as part of the security boundary. Without attestation, you are trusting both the code and the path it took to reach you.

That is why the approval question changes once the server can reach internal systems. At that point, the team is no longer only evaluating functionality, it is evaluating whether the artifact can be tied to a known build, a known publisher, and a known change history. That is the minimum required to make downstream access decisions defensible.

When the server handles tokens, credentials, or tool calls, provenance also helps answer a practical question: did the package arrive with the behaviour you expect, or with hidden logic that only appears at runtime? Public package ecosystems have repeatedly shown that a trusted name or a popular install count is not enough to prove the artifact is safe to approve. LiteLLM PyPI package breach and postmark-mcp malicious MCP server 2025 both show how package distribution can be used to hide credential abuse inside legitimate-looking functionality.

What can an unverified MCP server actually change in your environment?

An MCP server can affect far more than the feature it advertises. It may proxy authentication, transform requests, call other services, or expose internal data through tools that look harmless during review. If the server is unverified, you are also accepting the possibility that it contains extra network destinations, data capture logic, or privilege escalation paths that were not part of the intended design.

This matters because MCP servers can become a control point for access delegation. If a server is meant to broker tool use, then hidden behaviour can turn it into a confused deputy, where the caller’s authority is reused in ways the security team never intended. The risk is not only compromise of the package itself, but misuse of the trust the organisation has already extended to it.

Attestation and signing give reviewers a way to distinguish between the version they examined and the version that actually runs. That is especially important for public sources, where package ownership, release processes, and maintainer behaviour can change without warning. Model Context Protocol: Authorization specification is useful here because it shows the direction of travel for mcp security, including explicit server-side authorization and token handling expectations.

How should security teams decide whether to approve one?

Approval should be based on whether the server can be traced, validated, and controlled before it gets any production reach. A public package that lacks attestation should be treated as an untrusted dependency, even if the code appears benign, because the absence of provenance evidence leaves too much uncertainty about build integrity and release authenticity.

The practical decision rule is simple: if the server will touch internal tools, internal data, or internal credentials, require a signed build or equivalent attestation, verify the publisher chain, and make change control part of the approval record. If that evidence does not exist, the right answer is to defer approval rather than to compensate with monitoring after deployment.

For broader supply-chain discipline, teams should align package approval with OpenSSF guidance and keep authorization details tied to the server’s intended role, not to the package name alone. If the server is part of an agentic workflow, the security bar should be higher, not lower, because tool access and delegated action magnify the impact of a compromised release. OWASP Agentic AI Top 10 is relevant when MCP is acting as the action layer for agents rather than as a passive integration library.

Risk and Threat Considerations

Public MCP servers create a supply-chain trust problem with direct security consequences. A malicious or compromised release can carry hidden tool logic, credential handling behaviour, or outbound connections that are invisible in a superficial review but fully active once the server is connected to internal systems.

Failure mechanism: Attackers or malicious maintainers can publish a server that looks legitimate, then use the installed code to intercept secrets, relay privileged requests, or pivot from an approved integration path into internal systems.

Impact: The organisation may end up approving a component that can exfiltrate tokens, misuse delegated authority, or create an access path that bypasses normal application and identity controls.

Practitioner Guidance

What to verify: Do not trust package metadata or popularity signals on their own. Verify that the artifact is tied to a reproducible build, a known publisher, and a reviewable change history before it is allowed anywhere near production data or credentials.

Decision rule: If the server can call internal systems or handle secrets, require attestation and signing as part of the approval gate. If you cannot establish where the code came from and what changed, treat the package as unapproved regardless of functional usefulness.

Practitioner takeaway: For MCP servers, provenance is not a procurement preference, it is an access-control prerequisite, because unverified integration code can become an authenticated path into your environment.

Related resources from NHI Mgmt Group

• What do security teams get wrong about MCP servers and package registries?
• How should security teams implement authorization for MCP servers in Python without exposing external credentials?
• How should security teams implement OAuth 2.1 for MCP servers without creating token sprawl?
• How should security teams authenticate programmatic access to MCP servers without relying on interactive browser logins?