TL;DR: MCP server security now depends on registry, runtime and audit controls because compromised or misbehaving Model Context Protocol servers can exfiltrate data, execute code or manipulate agent decisions across thousands of users, according to Jozu. Traditional app, network and gateway controls do not see enough of the MCP execution path to govern these risks.
At a glance
What this is: This is a practical guide to MCP server security, arguing that organisations need supply chain checks, runtime policy and tamper-evident audit to govern a fast-growing AI attack surface.
Why it matters: It matters because MCP servers sit between AI agents and privileged tools or data, so a single compromised server can expand blast radius across many users and workflows.
Context
MCP server security fills a governance gap that sits between application security and network security. An MCP server can expose privileged tools and data to an AI agent, so the control question is not just whether the code runs, but whether it can be trusted before load and constrained at every invocation.
The article treats MCP as a supply chain and runtime problem at the same time. That matters because the same server may be delivered through public registries, run on developer laptops or clusters, and act on behalf of agents across high-risk workflows.
Key questions
Q: What breaks when MCP servers are trusted without registry and admission controls?
A: A trusted MCP server can become a hidden execution path for data theft, unsafe actions or code execution. The failure is not just an inventory gap. It is a broken trust boundary where an agent can load and use a server that has not been checked for provenance, signature integrity or malicious tool behaviour.
Q: Why do MCP servers create a bigger secrets risk than ordinary package installs?
A: Because the threat is not only code on disk, but code that executes inside a real user context and can read live credentials immediately. A malicious MCP server can preserve expected functionality while harvesting SSH keys, cloud tokens, and configuration files in the background.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.
Q: Who should own MCP server risk in an IAM programme?
A: Ownership should sit across IAM, platform security, and the team operating the server, with clear accountability for credential scope, access review, and revocation. If the server can touch production tools, it should be governed like privileged machine identity infrastructure rather than a developer convenience layer.
Technical breakdown
Why MCP servers need admission control before they load
MCP servers are not ordinary packages because they arrive as trusted capability bundles for agents. Admission control checks signatures, scan results and provenance before the server is allowed to load, which closes the gap created when an attacker tampers with an artifact upstream. In practice, this is where registry policy matters most: the organisation decides whether the artifact is allowed to enter the trust boundary at all, rather than discovering risk after the server has already influenced an agent session. See the MCP Security Guide.
Practical implication: block unverified MCP artifacts at load time and make provenance part of the admission decision.
Why runtime policy has to inspect each tool invocation
MCP security fails if controls stop at session start. ToolPolicy evaluates each tool call with the agent, the tool, the arguments and the action conditions in view, which is necessary because the risk changes from one invocation to the next. That is especially important for destructive or money-moving actions, where the control objective is not just authentication but scoped authorisation tied to the exact request. This is also where high-risk actions can be separated from routine reads, so the policy engine can require confirmation only when the blast radius justifies it. See the AI Agent Authorisation Guide.
Practical implication: enforce per-tool and per-argument policy at runtime instead of relying on one-time approval.
Why tamper-evident audit must cover both registry and runtime
A useful audit trail for MCP is not a log of events alone. It must chain artifact loads, policy decisions, denials, approvals and content events so the organisation can prove what was loaded, what was allowed and who approved a high-risk action. That is critical because MCP activity often happens outside the visibility of traditional DLP or gateway tooling, especially when communication uses stdio or local execution paths. Without a cryptographically chained record, incident review becomes guesswork instead of evidence-based reconstruction. See the AI Agent Observability, Audit and Incident Response Guide.
Practical implication: log registry admissions and runtime decisions in a chained audit record that compliance can export.
Threat narrative
Attacker objective: The attacker aims to turn a trusted MCP integration into a control point for data theft, code execution or unsafe business actions.
- Entry occurs when a user or agent loads a compromised or malicious MCP server from a registry or repository into a trusted workflow.
- Credential access follows when the server captures or forwards tokens, API keys or other secrets passed through agent interactions.
- Escalation occurs when the server manipulates agent decisions, issues unsafe tool calls or executes code in a context that the organisation assumed was trusted.
- Impact is the theft of data, execution of remote code or approval of harmful actions at scale across many users and workflows.
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.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
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
Registry trust must be separated from build trust: The central governance mistake in MCP security is assuming that a signed artifact is automatically a safe artifact. The article's Mini Shai-Hulud example shows why that premise fails when an attacker owns the build pipeline or the release workflow. The implication is that admission logic has to sit outside the pipeline's trust boundary, because provenance inside the pipeline is not the same thing as trust in the environment that consumes it.
Tool-level authorisation is the new control plane: MCP changes the shape of least privilege because the server is not just a package, it is a delegated interface to tools and data. That means privilege has to be evaluated per tool call, per agent and per argument, not just per session or per installed server. The practical conclusion is that identity governance for MCP is closer to execution control than to software inventory.
Shadow MCP is a governance failure, not an inventory issue: When teams do not know which MCP servers are in use, they cannot enforce policy, inspect risk or produce evidence. That gap becomes operationally dangerous because the article shows public registries, developer desktops and production agents all pulling from the same ecosystem. Practitioners should treat uncontrolled MCP adoption as a formal governance defect, not just an asset-management miss.
Tamper-evident evidence is part of the control, not the report: The article correctly treats audit as a runtime requirement rather than a retrospective spreadsheet exercise. If the log cannot prove artifact load, policy evaluation and human approval, then compliance evidence is weak and incident reconstruction is speculative. For practitioners, the point is to design audit as a first-class security mechanism, not a downstream reporting task.
MCP server security is really identity-bound delegation security: The named concept here is the identity blast radius created when an MCP server can act through multiple agents, tools and workflows at once. That makes blast radius the right unit of governance, because compromise of one server can cross many user sessions and many business processes. Security teams should judge MCP controls by how far delegated authority can travel when a server is misbehaving.
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.
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
- Read next: MCP Security Guide
What this signals
Identity blast radius: MCP governance is moving from package hygiene to delegated execution control. Once a server can shape tools, arguments and downstream decisions, the relevant question is how far its authority can spread before the organisation notices. That is why admission, runtime policy and audit have to be designed as one chain rather than separate tools.
The next maturity step is to govern MCP servers as runtime participants rather than static software assets. Organisations that still treat them as ordinary packages will miss the local execution paths, the stdio traffic and the policy failures that determine whether an agent is safely constrained or silently manipulated.
For practitioners
- Inventory all MCP servers in use Sweep developer laptops, IDEs, agent runtimes, CI/CD systems and production clusters to identify unmanaged servers and unknown dependencies. See the Agentic AI Identity Guide.
- Centralise approved servers in an internal registry Mirror approved MCP servers into a private registry and make it the only source agents and IDEs can pull from.
- Require signed admission policy for every artifact Block any MCP server that lacks verified signature, provenance and scan results before it can load.
- Enforce per-tool runtime policy Apply policy at each invocation for high-risk tools such as payments, emails, database writes and code commits.
- Chain audit evidence across registry and runtime Record loads, denials, approvals and content events in a tamper-evident log that compliance can export without manual reconstruction.
Key takeaways
- MCP server security is a control problem as much as a software problem, because these servers sit inside privileged agent workflows.
- The article shows that signatures, scanning and registry policy must be paired with runtime enforcement and tamper-evident audit.
- Teams that cannot inventory MCP servers or trace their decisions do not yet have governance over the attack surface.
Related NHI Mgmt Group resources: MCP Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Smithery.ai MCP hosting breach 2025
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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Public and mirrored MCP servers can arrive with latent compromise or unsafe behaviour. |
| NHI-05 — Overprivileged NHI | MCP servers frequently have broad tool access that can exceed the task they support. | |
| NHI-07 — Long-Lived Secrets | MCP servers often pass or store tokens, keys and credentials that become durable attack paths. | |
| Recommendation — Treat third-party MCP servers as untrusted until signatures, scans and provenance are verified. Scope each MCP server to the minimum tools and arguments needed for its delegated job. Reduce durable credential exposure by limiting secret passthrough and logging of sensitive values. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The incidents and controls revolve around credential theft and movement through trusted agent paths. |
| Recommendation — Map MCP threats to credential access and lateral movement to prioritise detection and containment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime tool policies and scoped agent access align directly to entitlement control. |
| PR.DS-10 — Data in Transit is Protected | MCP traffic often carries sensitive arguments and responses that need protection and inspection. | |
| Recommendation — Apply PR.AA-05 to enforce per-tool and per-agent authorisation for MCP actions. Protect MCP data flows and inspect content in transit where the protocol carries sensitive context. | ||
Key terms
- MCP — Model Context Protocol: An open protocol enabling AI agents to connect to external tools, data sources, and services. MCP introduces new NHI considerations as agents must authenticate with credentials, ideally ephemeral, scoped tokens rather than persistent API keys.
- Artifact Admission Control: Artifact admission control is the decision gate that checks whether a package or server may load into a trusted environment. For MCP, it combines signature checks, provenance validation and scan results so untrusted or modified artifacts are blocked before they can influence agent behaviour.
- Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
- Tamper-Evident Audit Log: A tamper-evident audit log is a record chain designed so that later changes can be detected. In MCP security it captures artifact loads, approvals, denials and tool actions, giving compliance and incident teams a defensible history of what happened and when.
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 October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org