MCP server security now depends on pre-install audit

At a glance

What this is: This guide frames MCP server security as a pre-install and runtime governance problem, with third-party servers treated as untrusted code that can inherit agent permissions, scopes, and reach.

Why it matters: It matters because IAM and security teams now have to govern tool-connected non-human access as an active trust boundary, not a static software install decision.

By the numbers:

• 41% of popular OpenClaw skills carry security vulnerabilities, according to ClawSecure research.

Context

MCP server security is fundamentally a trust-boundary problem. The protocol lets AI agents call tools and data sources, but that convenience also means a third-party server can inherit the agent's permissions if it is installed without scrutiny.

The governance gap is the assumption that a popular or widely used server is safe by default. In practice, the server's tool definitions, scopes, and runtime behaviour matter more than its reputation, which is why pre-install review is the first control that fails when teams skip MCP security guide.

Runtime monitoring matters because a clean scan at install time does not prove that the server will stay clean after updates, configuration drift, or a poisoned tool response.

Key questions

Q: What breaks when a third-party MCP server is installed without pre-install review?

A: The trust model breaks first. An installed MCP server can inherit agent permissions, read files, call tools and act on behalf of the user, so skipping pre-install review turns a bounded integration into an unreviewed extension of privilege. The practical failure is not only compromise, but also the inability to prove what the server was allowed to do before it was trusted.

Q: Why do third-party MCP servers create more risk than internal-only connectors?

A: Third-party MCP servers extend trust beyond the organisation's direct control, so they can expand the blast radius of prompts, context, and responses. The risk is not only data exposure but also governance drift, because the external endpoint may see more than the team originally intended.

Q: What are the signs that an MCP deployment is becoming too permissive?

A: Common warning signs include AI applications reaching systems they do not need, broad tool exposure without business justification, and no clear separation between read and action permissions. Another red flag is when teams cannot explain which server can access which source. If the integration map is unclear, the control model is probably too loose.

Q: How should security teams handle identity in MCP servers that call backend tools on behalf of users?

A: They should preserve user context end to end by using short-lived tokens, token exchange, or federation instead of shared service credentials. That lets the backend see a scoped identity tied to the originating user, which improves attribution, reduces blast radius, and makes access reviews meaningful.

Technical breakdown

Why MCP server trust is an identity problem

An MCP server is not just a plugin. It is an execution path that can act with the same authority as the agent it serves, which makes its trust model an identity problem as much as a software problem. If a server can read files, call tools, or reach external systems on the agent’s behalf, then its privileges must be treated like any other delegated non-human identity. The security failure is not only malicious code, but also over-broad delegation that was never meant to exist in the first place. See the NHI Authentication Guide.

Practical implication: Model each server as a delegated NHI and approve only the authority it truly needs.

How tool poisoning and prompt injection enter through server output

Tool poisoning happens when a server hides malicious instructions in tool names, descriptions, or returned content. Indirect prompt injection is more subtle: the server returns data that the agent treats as instruction-bearing context, then the agent follows it because the boundary between data and command is too weak. This is why prompt injection in MCP is not a simple content-filtering problem. The dangerous path is the agent-and-tool communication layer, where outputs from one server can shape the next tool call, and where trust is often inherited instead of validated. See the Prompt Injection Guide.

Practical implication: Treat every tool response as untrusted input and isolate instruction handling from returned data.

Why runtime drift defeats one-time review

A one-time review only assesses the version you saw. MCP server risk changes when dependencies update, scopes expand, or maintainers ship a new release that behaves differently from the audited code. That is supply-chain drift, and it matters because the server can remain trusted in policy while becoming untrusted in practice. The security model therefore needs continuous observation of behaviour, permissions, and egress, not just a pre-connect approval stamp.

Practical implication: Pair pre-install approval with continuous runtime monitoring for scope and behaviour changes.

Threat narrative

Attacker objective: The attacker wants to convert trusted agent connectivity into secret theft, data exposure, or unauthorized actions that look legitimate in logs.

1. Entry occurs when a third-party MCP server is installed and granted the agent's permissions without independent review.
2. Escalation follows when excessive scopes, tool poisoning, or indirect prompt injection let the server steer privileged tool calls.
3. Impact occurs when the server uses legitimate access to harvest secrets or exfiltrate data through approved channels.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

Audit-before-install is the missing control boundary: MCP guidance often assumes the review happens after trust has already been granted. That is too late for third-party servers that inherit agent permissions on connection. The governance failure is not just weak review, but review occurring after the trust decision has been made. Practitioners should treat install-time approval as the primary control point, not a hygiene step.

Prompt injection in MCP is an identity abuse problem, not only a content problem: When a server can shape tool output, it can also shape agent behaviour through inherited authority. That means the control failure is in delegation, scope, and execution context, not merely in unsafe text. The implication is that agent permissions and server output handling must be governed as one chain, because agentic AI security and tool trust collapse together when data becomes instruction.

Ephemeral trust debt: A server that looks clean at install can accumulate risk through updates, dependency drift, and changed tool behaviour. The trust debt exists because the approval model is static while the execution environment is dynamic. That is why runtime monitoring is not a secondary control but the only way to know whether the original approval still matches reality. For practitioners, the lesson is that one-time trust decisions do not age well in MCP estates.

MCP server security belongs in the broader non-human identity programme: The article makes the case that servers should be governed like delegated machine identities because they act with persistent, inherited authority. That puts them squarely inside lifecycle, scope, and offboarding discipline rather than ad hoc developer tooling. Teams that separate AI tooling from identity governance will miss the control plane where the risk actually sits.

OWASP ASI coverage is necessary but not sufficient: The source correctly maps MCP risk into agentic threat categories, but practitioners still have to translate those categories into delegated access controls. A risk label does not enforce scope, sandboxing, or runtime validation by itself. The operational takeaway is to align agentic risk taxonomies with access governance, then enforce that alignment before any server is connected.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

MCP server governance is converging with non-human identity governance because the practical question is no longer whether a server can run, but whether its authority can be bounded, observed, and revoked like any other delegated machine identity.

Ephemeral trust debt: The real operational risk is that approval models are static while tool behaviour is dynamic, so teams need controls that survive updates, dependency drift, and new tool output patterns.

The security programme impact is clear: pre-install review, sandboxing, and runtime monitoring need to be handled as one lifecycle, not three separate projects.

For practitioners

• Audit servers before installation Review source code, tool definitions, dependency provenance, and requested scopes before any MCP server connects to an agent.
• Enforce least-privilege scopes Deny filesystem, shell, and unrestricted network access by default, then add back only the permissions required for the server’s actual job.
• Isolate server runtime Run approved servers in a sandbox or container with restricted egress so a compromised component cannot reach the wider environment.
• Separate data from instructions Treat every returned document, row, or page as untrusted content and prevent tool output from silently steering the agent’s next action.
• Monitor for post-install drift Track behaviour, scope changes, and dependency updates after approval so a trusted server does not become an unreviewed one.

Key takeaways

• MCP server security fails when teams assume popularity, install-time review, or a clean scan is enough to make third-party servers trustworthy.
• The article’s evidence points to a broad ecosystem problem, not an isolated bug, with vulnerable skills and exposed secrets showing how tool-connected identities expand attack surface.
• Practitioners need to govern MCP servers as delegated non-human identities, with pre-install review, scope restriction, sandboxing, and continuous runtime monitoring.

Related NHI Mgmt Group resources: MCP Security Guide · Agentic AI Security Guide · Prompt Injection Guide · Miasma and Hades Supply Chain Worms

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Delegated non-human identity: A machine or agent identity that acts on behalf of a user or system and inherits access to connected tools. The control problem is not only authentication, but the scope, duration, and downstream reach of that delegation once the session is established.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.