They complicate governance because they often authenticate with personal credentials while behaving like standalone services. That creates a gap between who appears to be acting and what is actually executing. Zero Trust also weakens when hidden services initiate outbound connections without clear provenance, ownership, or data-boundary enforcement.
Why This Matters for Security Teams
MCP servers blur a boundary that zero trust depends on: a service can look like a normal application while actually acting with the reach of a privileged integration layer. When that layer inherits personal credentials, token scope becomes harder to explain, review, and revoke. nhi governance also weakens because the real identity is often the server, the developer, and the user all at once, which complicates ownership and auditability.
This is not just a model-context issue. It is an operational identity problem that shows up in secrets sprawl, overbroad tool permissions, and unclear trust zones. The risk profile is consistent with what NHIMG research has documented across non-human identities, where weak lifecycle controls and exposed secrets repeatedly become the failure point. See the broader NHI lifecycle concerns in the Ultimate Guide to NHIs and the Zero Trust baseline in NIST Cybersecurity Framework 2.0.
In practice, many security teams encounter MCP exposure only after a tool starts reaching systems it was never explicitly meant to touch.
How It Works in Practice
MCP servers complicate governance because they often sit between the user, the model, and downstream tools while inheriting trust from all three. That makes traditional IAM reviews misleading. A permission review may show the developer’s account or a shared service token, but the runtime behavior is driven by an autonomous workflow that can chain tools, request new data, or pivot into adjacent services. For that reason, current guidance suggests treating MCP servers as distinct non-human workloads with their own identity, policy, and revocation lifecycle.
The practical control pattern is to separate identity from human ownership and bind authorization to runtime context. That usually means workload identity for the server, short-lived credentials for each task, and policy evaluation at request time rather than static role assignment. For implementation detail, the Guide to SPIFFE and SPIRE is useful because it frames cryptographic workload identity as the control point, not shared secrets. On the policy side, the NIST SP 800-207 Zero Trust Architecture remains the clearest statement that trust must be continuously evaluated, not presumed from network location.
- Use separate identities for the MCP server, the operator, and the end user.
- Issue ephemeral secrets or tokens per task, then revoke them on completion.
- Scope tool permissions to specific actions, datasets, and destinations.
- Log tool invocation context, including requester, purpose, and downstream call chain.
- Block outbound access by default unless the request matches an approved policy.
NHIMG’s reporting on MCP security shows how often this breaks in the field, including 24,008 unique secrets exposed in configuration files in 2025 alone, which is a strong indicator that static credential handling remains common. These controls tend to break down when the MCP server is deployed as a convenience layer inside a shared developer environment because ownership, secrets, and outbound trust boundaries all collapse at once.
Common Variations and Edge Cases
Tighter control of MCP servers often increases deployment and operations overhead, so organisations have to balance developer velocity against containment and auditability. That tradeoff is especially sharp when MCP is used for internal productivity tools, where teams may argue that the server is “just an integration layer” and does not deserve workload-grade controls. Best practice is evolving, but current guidance is clear that convenience does not remove the need for identity separation.
One edge case is delegated access: an MCP server may need to act on behalf of a user, but that does not justify long-lived access tokens or blanket permissions. Another is multi-tenant hosting, where several teams share the same server process. In that model, static RBAC becomes brittle because the server’s actual behavior depends on runtime prompts, data sources, and tool selection. The OWASP Agentic Applications Top 10 is relevant here because it highlights how tool use, prompt injection, and uncontrolled autonomy can turn a seemingly narrow integration into a broad execution path. The OWASP Top 10 for Agentic Applications 2026 reinforces the same point from a standards perspective.
The practical takeaway is that MCP governance should be designed for runtime uncertainty, not just deployment-time approval. Where servers can initiate outbound connections without explicit provenance or data-boundary enforcement, Zero Trust assumptions become fragile very quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP servers often rely on poorly rotated secrets and tokens. |
| OWASP Agentic AI Top 10 | MCP servers enable tool use and autonomous actions that expand attack paths. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires continuous, context-based authorization for outbound tool calls. |
Inventory MCP credentials, replace static secrets with short-lived tokens, and rotate anything with unclear ownership.
