Notifications
Clear all
Topic starter
06/07/2026 9:47 am
TL;DR: MCP deployments face tool poisoning, cross-server shadowing, spoofing, token theft, and silent schema changes, with thousands of internet-exposed servers and zero authentication already observed by researchers, according to Descope. The core issue is that agent connectivity outpaced identity controls, so approval, scope, and token handling now define the real blast radius.
NHIMG editorial — based on content published by Descope: Top 6 MCP vulnerabilities and how to fix them
Questions worth separating out
Q: How should security teams harden MCP servers in production?
A: Security teams should harden MCP by combining identity controls with network isolation.
Q: Why do MCP environments create a larger identity risk than ordinary API integrations?
A: MCP environments create larger identity risk because the model consumes tool descriptions as context and may act on them immediately.
Q: What breaks when MCP tool definitions change without re-approval?
A: What breaks is the assumption that a previously trusted tool still behaves the same way.
Practitioner guidance
- Enforce server-specific trust boundaries Namespace every tool by source server and block cross-server references that let one server influence another.
- Require OAuth 2.1 with constrained tokens Use short-lived, sender-constrained credentials and validate every request against the original client and server identity.
- Re-approve tool changes before execution Pin tool schemas in production, detect changes between sessions, and force explicit re-approval when definitions drift.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how each MCP vulnerability manifests in production server setups
- Specific mitigation patterns for OAuth 2.1, scope design, and token handling in remote MCP deployments
- Detailed guidance on server whitelisting, tool filtering, and schema-change detection
- Practical implementation examples for developers building secure MCP servers and clients
👉 Read Descope's analysis of the top MCP vulnerabilities and how to mitigate them →
MCP vulnerabilities: what IAM teams need to tighten now?
Explore further
06/07/2026 10:04 am
Tool trust is becoming an identity control, not a developer convenience. MCP collapses the distance between model context and action, which means tool descriptions now influence authorisation outcomes. That shifts the governance burden from simple application security to identity and access design across servers, tokens, and agent permissions. Practitioners should treat tool trust as a first-class identity decision.
A few things that frame the scale:
- From our research: 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Our research also shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when a compromised MCP server causes unauthorized actions?
A: Accountability sits with the organisation that allowed the trust chain to exist without enough controls. That includes ownership of server identity, token lifecycle, approval boundaries, and logging. If the environment cannot show who approved which tool and when, accountability is already weak.
👉 Read our full editorial: MCP vulnerabilities show why AI agent identity needs tighter controls
