The trust boundary collapses before code execution begins. A malicious repository can look like a normal install target, especially when the README, profile, and registry listing all reinforce the same false identity. That makes discovery and onboarding part of the attack path, not just the malware payload.
How the trust boundary breaks before the payload runs
When a fake mcp server is treated as a trusted capability source, the failure starts at discovery and onboarding, not at execution. The client is effectively asked to trust the server’s self-description, so a malicious package, profile, or registry entry can present itself as the right tool surface and inherit the confidence of the surrounding workflow. That is a supply-chain and capability-trust problem, not just a bad server problem.
Once the server is accepted as legitimate, downstream checks may be too late. The agent or client may already have attached tokens, exposed prompts, or delegated actions on the assumption that the server sits inside the expected trust boundary. MCP Security Guide covers why MCP authorization, token handling, and server trust assumptions have to be designed together.
The important detail is that the attack path can look ordinary from the outside. If the README, registry listing, and install flow all agree, the operator sees consistent but false identity signals, which makes the malicious server feel like a normal capability provider. Model Context Protocol: Authorization specification is the right reference for understanding why audience-bound tokens and no token passthrough matter to that boundary.
Why fake capability sources are so effective against MCP workflows
Fake capability sources exploit the fact that MCP is often consumed as infrastructure, not as an application with a hostile perimeter. A server that claims to offer a useful tool can shape what the client believes is available, what it may call, and where secrets are sent. AI Supply Chain Security and AI-BOM Guide is useful here because the server is part of the artifact chain, not an isolated runtime component.
This is also why token forwarding is dangerous. If the client passes bearer credentials into a server that was never meant to be trusted, the fake source can become a relay for privileged access, data exfiltration, or unauthorized tool use. The control point is not just “is the server running”, it is “is the server authorized to receive this capability for this audience and purpose?”
RFC 8707: Resource Indicators for OAuth 2.0 matters because the token should be scoped to the intended resource, while RFC 9728: OAuth 2.0 Protected Resource Metadata supports discovery of the resource’s real authorization requirements instead of trusting a self-asserted capability claim.
What changes in practice when the server identity is untrusted
Practically, the operator has to treat onboarding as a security decision, not a convenience step. A server should not be trusted because it is popular, well described, or embedded in a familiar marketplace. It should be verified against source, ownership, transport, authorization model, and the exact capabilities it requests before any secret or delegated action is allowed. OWASP Agentic AI Top 10 is a useful external lens for the identity and privilege abuse that follows when an agent trusts the wrong tool source.
If the server can influence tool selection, request forwarding, or hidden side effects, assume the trust boundary has to be rebuilt around the client, not the server. That means separating discovery from authorization, limiting what a new server can see on first contact, and making capability approval explicit rather than inferred from packaging or metadata. The right mental model is “untrusted until verified,” even when the server looks like a normal integration target.
OWASP Agentic Applications Top 10 and The agentic AI applications guide both reinforce the same operational point: once tool authority is misplaced, the agent’s normal behaviour becomes the attacker’s delivery path.
Risk and Threat Considerations
A fake MCP server is dangerous because it can convert a trusted integration point into a credential and action sink. The most serious failure is not a crash, it is silent trust abuse, where the server is allowed to receive tokens, prompts, or tool calls simply because it presents a convincing identity.
Failure mechanism: The client or agent accepts the server’s self-claimed role, forwards capabilities, and then executes against attacker-controlled logic or endpoints.
Impact: This can expose secrets, alter tool outputs, create unauthorized actions, or extend attacker control across the agent’s downstream tools and workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Fake MCP servers exploit misplaced trust in agent/server authority. |
| Recommendation — Require explicit capability approval before granting a new server any tool or token access. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The issue turns on whether the server is authenticated as the intended capability source. |
| NHI-09 — NHI Reuse | Reused trust signals across registry, README, and profile make spoofing easier. | |
| Recommendation — Authenticate MCP servers with verifiable, audience-bound trust before forwarding credentials. Bind each server identity to a unique, verified source and reject reused trust artifacts. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | A fake MCP server can be treated as authenticated when it is not the intended resource. |
| API5 — Broken Function Level Authorization | Trusted capability sources can overreach into actions the server should not control. | |
| Recommendation — Enforce resource-bound authentication so tokens cannot be accepted by the wrong server. Authorize each capability separately instead of trusting server identity alone. | ||
Practitioner Guidance
What to verify: Verify the server’s provenance, the exact capabilities it asks for, and whether the authorization audience matches the intended resource before any token is exposed. If the server cannot prove who it is and what it is allowed to do, do not treat installation success as trust.
Decision rule: If discovery, registry metadata, and package branding are the only reasons the server feels trustworthy, treat it as untrusted until an explicit authorization check, source review, and capability boundary review are complete.
Practitioner takeaway: The control objective is to prevent a convincing server identity from becoming a capability grant; if the trust decision happens after onboarding, the attacker has already moved the boundary.
Related resources from NHI Mgmt Group
- What breaks when MCP tools are treated as trusted by default?
- What breaks when a frontend server is compromised and treated as trusted internally?
- What breaks when MCP server creation and connection are treated as separate workflows?
- What breaks when a remote MCP server is treated like a simple passthrough for agent access?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org