TL;DR: MCP security depends on platform-enforced isolation, per-request identity, curated server approval, structured logging, and tool-level least privilege, according to Stacklok’s how-to guide. The core problem is that MCP turns AI tool use into real execution paths, so default prototyping habits create standing access and audit gaps that traditional API security does not close.
At a glance
What this is: This is a how-to guide on securing enterprise MCP servers, with the central finding that production risk comes from treating agent tool access like a prototype rather than governed execution.
Why it matters: It matters to IAM and NHI practitioners because MCP shifts AI from passive inference to actionable access, so identity, authorization, logging, and blast-radius controls have to be enforced at runtime.
Context
Model Context Protocol is the layer that lets AI agents invoke tools, not just generate text. In enterprise use, that means an MCP server can become an execution gateway into databases, file systems, APIs, and workflows if access is not tightly governed.
The governance gap is that many teams still deploy MCP servers with prototype-era assumptions: shared credentials, weak isolation, and manual trust decisions. For NHI and agentic AI programmes, that creates a control problem that traditional API security alone does not solve because the issue is not only authentication, but authorisation, isolation, and auditability at the tool boundary.
The article’s main point is that MCP security is a platform responsibility as much as a protocol question. The operational question for practitioners is whether the MCP layer is treated as a governed identity boundary or as another unreviewed integration surface.
Key questions
Q: What breaks when MCP servers rely on a single shared credential?
A: A single shared credential breaks attribution, scope control, and revocation precision. If the server can be used by multiple people, you cannot easily tell which human authorised a specific action, and removing the credential can disrupt unrelated workflows. That makes the credential both operationally convenient and governance-heavy.
Q: Why do MCP servers need platform-level identity and authorisation controls?
A: MCP servers can trigger real tool actions, so the risk is not only authentication but what an authenticated caller can do next. Platform-level controls are needed because the specification leaves enforcement to the runtime. Without that layer, the server becomes an ungoverned execution boundary.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.
Q: What is the difference between API security and MCP security?
A: API security focuses on protecting known endpoints and request boundaries. MCP security must also govern the agent’s state, the context it carries, and the sequence of tool actions it can trigger. In practice, that means moving from endpoint-centric controls to workflow-centric access policy and continuous enforcement.
Technical breakdown
Why MCP security is not the same as API security
MCP changes the security model because the server sits between an AI agent and real enterprise systems. API security usually answers who authenticated, but MCP also has to govern what an authenticated caller may do, which tools it may invoke, and under what conditions those actions are allowed. That makes MCP a policy enforcement layer, not just a transport layer. Because the specification leaves enforcement to the platform, security quality depends on how the server runtime handles identity, isolation, and logging. In practice, the risk is not only data exposure but delegated execution.
Practical implication: Treat the MCP runtime as an authorization control point, not as a generic API endpoint.
How container isolation contains MCP server blast radius
An isolated container limits what a compromised MCP server can reach if the server image, dependency chain, or configuration is abused. The point is to prevent a single server from seeing the host filesystem, moving laterally across the network, or inheriting privileges it does not need. For MCP, this is especially important because servers may expose many tool paths through one process. If the runtime allows broad filesystem or network access by default, the compromise surface expands from one tool integration to the entire environment connected through that server.
Practical implication: Run each MCP server with minimal filesystem, network, and privilege scope so one compromise stays local.
Why per-request identity and curated approval matter for MCP servers
Shared credentials turn MCP usage into a traceability problem because every request appears to come from the same account, and any leak can be reused across users or agents. Per-request identity preserves accountability by binding each call to the specific user or agent that initiated it. A curated registry adds a second control by ensuring only approved servers can be deployed. Together, they reduce both insider ambiguity and supply chain exposure from unreviewed servers, signed artifacts, or copied configurations that bypass governance.
Practical implication: Require per-request identity and approved server registration before an MCP server can reach production tools.
Threat narrative
Attacker objective: The objective is to turn one trusted MCP integration into broad delegated access across tools and workflows with weak auditability.
- Entry occurs when an MCP server is deployed with shared credentials, weak isolation, or an unreviewed provenance chain that expands trust beyond the intended boundary.
- Credential access emerges when that server can be reached through a single account or reused token that does not preserve user- or agent-level accountability.
- Escalation follows when the compromised or over-privileged server can invoke multiple tools, trigger workflows, and act across systems that were never intended to share one trust domain.
- Impact is realised when the attacker or misconfigured agent uses the server to query data, write files, or execute actions across connected enterprise systems.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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 security is now an identity boundary problem, not just an API hardening problem. MCP turns an AI tool request into a real execution path, so the control question shifts from who connected to what that identity is allowed to do at tool level. That is a material change for IAM, PAM, and NHI governance because authorization must follow the action, not just the session. Practitioners should treat the MCP layer as governed delegated access.
Platform-enforced isolation is the control that decides whether one compromise becomes an enterprise event. When an MCP server can see the host filesystem, reach other services, or inherit broad network access, the blast radius grows beyond the server itself. This is why container boundaries and default-deny runtime constraints matter more than cosmetic security settings. The practitioner conclusion is simple: if isolation is optional, production risk is structural.
Per-request identity is the operational answer to shared-credential drift. Shared API keys and service accounts erase actor-level accountability, which means audit trails cannot distinguish user intent from reused access. That is especially dangerous in MCP because tool calls can be high-impact even when they look like ordinary requests. Enterprises need identity binding at the point of execution, not after the fact.
Curated server approval is the missing governance layer for MCP supply chain risk. Open server ecosystems make it easy to pull in unreviewed integrations that extend trust to code, provenance, and dependency paths that have never been assessed. The governance issue is not just malware, but unsanctioned capability expansion. Practitioners should assume the server catalog is part of the access control plane.
Zero-trust for MCP is really tool-level least privilege plus observability. Deny-by-default access, structured logging, and clear tool scoping create the minimum viable control stack for agentic execution. Without those controls, the organisation cannot answer who invoked which tool, what parameters were passed, or which action followed. The implication for identity programmes is that auditability and authorisation must be designed together.
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.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Identity binding has to move to the tool call. MCP deployments fail when access is defined once at login and then reused across many actions. The governance model needs per-request identity, because the security decision is no longer about connecting to a service but about authorising a specific action path in real time.
Runtime isolation is the practical control that separates experimentation from production. An MCP server that can reach the host, other services, or broad network paths turns one compromised integration into an environment-level problem. For practitioners, the issue is not whether isolation is nice to have, but whether the platform enforces a blast-radius boundary that survives misconfiguration.
Curated approval closes the trust gap that open server ecosystems create. The server catalog is part of the security perimeter, because unreviewed integrations can introduce both supply chain exposure and ungoverned capability expansion. That is why governed registries and provenance checks should be treated as access control, not as developer convenience.
For practitioners
- Enforce isolated runtime boundaries Run every MCP server in its own container with minimal filesystem, network, and privilege access so compromise stays contained to that server.
- Bind every call to a unique identity Replace shared keys and shared service accounts with per-request identity so each tool call is attributable to a specific user or agent.
- Approve servers before deployment Maintain a curated internal server registry and require provenance checks so only reviewed MCP servers can be made available to developers.
- Log tool use at execution time Send every request, tool call, parameters, and result into structured logs that flow to your SIEM and observability stack.
- Scope tool access by role and task Apply role-based access control at the tool level so read-only agents cannot write and code-review agents cannot reach unrelated data tools.
Key takeaways
- MCP servers create execution risk because they can call tools, write data, and trigger workflows, so identity and authorization must be governed at the action layer.
- The main control failure is not the protocol itself but the habit of running it with shared credentials, broad privileges, and weak isolation.
- Production MCP security depends on container boundaries, per-request identity, curated server approval, and structured logging that can support investigations.
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) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Shared credentials and weak request identity are central risks in MCP server deployments. |
| NHI-05 — Overprivileged NHI | MCP servers can reach many tools, so excessive privilege becomes immediate blast-radius risk. | |
| NHI-03 — Vulnerable Third-Party NHI | Approved server registries and provenance checks address unreviewed MCP server supply chain exposure. | |
| Recommendation — Bind each MCP tool call to a specific identity and eliminate shared credentials. Scope MCP server permissions to the minimum tool set required for each task. Review and approve MCP servers before deployment and require provenance attestation. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP gives agents delegated execution paths that can be abused through excessive or shared privilege. |
| Recommendation — Constrain agent delegation paths so tool use cannot exceed explicitly authorised privilege. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The article frames MCP as deny-by-default, permit-by-exception tool access. |
| Recommendation — Apply deny-by-default policy to MCP tool calls and verify every request at runtime. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Tool-level access control and per-request identity align directly with permission governance. |
| Recommendation — Apply entitlement governance to each MCP tool and remove access not needed for the task. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Per-request identity: An access model in which each tool call carries the initiating user’s identity and authorization context rather than a shared backend credential. For MCP, this is what preserves attribution and reduces the blast radius of server compromise.
- Curated Registry: A curated registry is a governed catalog of approved tools or services with verified configurations and ownership. In NHI and AI tooling programmes, it functions as the control point for sanctioned discovery, installation, and lifecycle management.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
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.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org