Notifications
Clear all
Topic starter
15/08/2026 6:06 pm
TL;DR: Tool poisoning, typosquatting, rug pulls, command injection, and sandbox escapes can exploit MCP server security by abusing the protocol’s trust model before a model ever reaches external systems, according to SlashID. The core issue is that MCP identities are often approved by name and description, while runtime behaviour, scope, and server provenance remain insufficiently governed.
NHIMG editorial — based on content published by SlashID: Part 1 of a two-part series on MCP security
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when MCP servers run with shared local trust?
A: Shared local trust breaks isolation because any process on the machine may be able to call the server, and the server may inherit privileges that were never intended for broad reuse.
Q: Why do MCP servers create new identity governance issues for NHI programmes?
A: Because they act as access surfaces for software identities, not just as application endpoints.
Q: How do security teams reduce the risk of poisoned MCP metadata?
A: They should assume tool descriptions, prompt text, and registry metadata are untrusted input.
Practitioner guidance
- Build a complete MCP server inventory Record every server, registry source, tool scope, and business owner before allowing hosts to connect.
- Bind approval to signed server definitions Require hashes, versioning, and signed definitions for each tool and resource list, then re-verify them on every connection.
- Separate metadata from authorization Do not let tool descriptions, prompt templates, or registry text influence access decisions.
What's in the full article
SlashID's full analysis covers the operational detail this post intentionally leaves for the source:
- Controlled reproductions of the pre-patch MCP server flaws and how each exploit chain works in practice.
- The specific trust-dialog, path-check, and registry weaknesses that enabled the attacks against affected versions.
- The article's own reconstruction of tool poisoning, typosquatting, and rug-pull behaviour across MCP server types.
- Implementation context for the reproduced CVEs and the affected pre-patch server versions.
👉 Read SlashID’s analysis of MCP server security failures and attack paths →
MCP server security: are your AI tools over-trusted already?
Explore further
15/08/2026 6:15 pm
MCP server security is NHI governance, not just application security. Once an MCP server can enumerate tools and execute against external systems, it behaves like a privileged non-human identity with standing access. That means the relevant controls are inventory, scoping, verification, and offboarding, not just code review. Practitioners should treat every server as an identity subject to lifecycle governance.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files. That is a governance failure, not just a configuration weakness, because the secret and the server identity often fail together.
A question worth separating out:
Q: Who is accountable when a hostile MCP server steals developer secrets?
A: Accountability usually sits with the organisation that allowed the tool to run without sufficient provenance, isolation, and egress controls. In regulated environments, teams should also map the incident to secrets management, privileged access, and software supply chain control obligations.
👉 Read our full editorial: MCP server security exposes trust gaps in AI tool access
