Should organisations treat MCP server collaboration as a Zero Trust problem?

Why This Matters for Security Teams

mcp server collaboration becomes a zero trust issue the moment tool access, secrets, or downstream actions are exchanged without explicit, runtime verification. Network segmentation alone does not protect against a server that can call other tools, inherit context, or expose credentials through configuration. Current guidance suggests treating each collaboration step as a separate trust decision, not as an extension of the original session.

This is especially important because MCP deployments often blur the boundary between model context and execution authority. The result is a hidden privilege path: one server can become a relay for secrets, automation, or data access that was never intended for that workflow. NHIMG research on the State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files, and only 18% implement any form of access scoping for tool permissions. That is not a network problem alone, it is an identity and authorization problem.

Zero Trust framing is also supported by NIST SP 800-207 Zero Trust Architecture, which emphasises continuous verification and explicit trust decisions. In practice, many security teams discover MCP overreach only after a tool chain has already exposed secrets or executed an unauthorised action, rather than through intentional design.

How It Works in Practice

The practical answer is to model MCP collaboration as a set of discrete trust exchanges. Each server, tool, and connector should have its own workload identity, policy scope, and audit trail. That means the question is not simply “is this server on the network,” but “what is this server allowed to request, on behalf of which context, for how long, and with which constraints?”

For agentic and MCP-style workflows, best practice is evolving toward identity-first controls: workload identity via SPIFFE or OIDC, short-lived credentials, and policy-as-code at request time. NHIMG’s Guide to SPIFFE and SPIRE is relevant here because workload identity gives a cryptographic basis for distinguishing one service from another, instead of relying on static IPs or coarse network zones. That is a better fit for MCP, where collaboration can be dynamic and the trust boundary may change from one tool call to the next.

• Assign each MCP server a unique workload identity, not a shared service account.
• Issue ephemeral credentials per task or session, then revoke them when the task ends.
• Enforce tool-level authorization with runtime policy evaluation, not broad allow lists.
• Log every cross-server request, including context, subject, action, and decision outcome.
• Block default trust between model context, secrets stores, and execution endpoints.

This maps closely to the OWASP Agentic AI Top 10 and the NHIMG OWASP Agentic Applications Top 10, because collaboration is only safe when every step is explicitly constrained. Where MCP servers are allowed to chain tools, the Zero Trust requirement becomes stronger, not weaker, because each hop creates another chance to disclose secrets or exceed scope. These controls tend to break down when server-to-server collaboration is implemented through shared credentials or long-lived tokens, because the trust decision is no longer tied to the actual request.

Common Variations and Edge Cases

Tighter Zero Trust controls often increase integration overhead, so organisations must balance strong isolation against developer friction and runtime latency. That tradeoff matters in MCP environments because some teams want rapid tool composition while security teams want narrow, observable trust boundaries. There is no universal standard for this yet, but current guidance suggests that collaboration between MCP servers should be treated differently from ordinary service-to-service traffic when secrets or execution authority are involved.

One edge case is internal-only collaboration. Teams sometimes assume that if every MCP server sits inside the same cluster, the risk is low. That assumption fails when one compromised server can harvest secrets from configuration, call privileged tools, or pivot into adjacent services. NHIMG’s Analysis of Claude Code Security is a useful reminder that autonomous workflows can create unexpected execution paths even when the original intent was narrowly scoped.

Another edge case is read-only access. Read-only is safer, but it is not automatically safe if the server can query sensitive context, infer secrets, or forward data to another tool. In those environments, Zero Trust should extend to data egress as well as action execution. The practical test is simple: if the collaboration step can influence authentication, authorization, or downstream execution without a fresh policy decision, the trust boundary is too loose.

Related resources from NHI Mgmt Group

• When should organisations treat on-prem access as a zero-trust problem?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• When should organisations prioritise Zero Standing Privilege for non-human identities?