Notifications
Clear all
Topic starter
06/07/2026 9:36 am
TL;DR: MCP server deployments are expanding faster than traditional security practices can keep up, with researchers finding nearly 2,000 public servers and severe authentication and permission gaps, according to Descope and cited security researchers. The real issue is not just protocol hardening but whether identity teams can govern agent-facing access, consent, and scope before overscoped tools become production defaults.
NHIMG editorial — based on content published by Descope: MCP Server Security Best Practices to Prevent Risk
By the numbers:
- Knostic researchers scanned nearly 2,000 publicly accessible MCP servers and found that every single verified instance granted access to internal tool listings without any authentication.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: They should govern MCP servers as identity-sensitive access infrastructure, not as ordinary application endpoints.
Q: Why do MCP servers create new identity risks for enterprise IAM?
A: MCP servers sit between agents and real business systems, so they inherit authentication, consent, and privilege problems in a much tighter runtime loop.
Q: What breaks when MCP tools are overprivileged?
A: A single agent session can move from one low-risk action to multiple high-risk actions across different services without fresh review.
Practitioner guidance
- Separate authorization from MCP resource handling Keep token issuance, client registration, and policy enforcement in a dedicated authorization layer so the MCP server only validates access and serves tools.
- Bind tokens to the exact MCP server and tool set Use resource indicators and tool-specific scopes so a token issued for one server or task cannot be replayed against another server or broader workflow.
- Make consent task-scoped and time-bound Show users which tools, datasets, and actions an agent can access, then expire that permission when the task is complete rather than leaving it open-ended.
What's in the full article
Descope's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanations of OAuth 2.1, PKCE, and protected resource metadata for MCP deployments.
- Configuration guidance for client registration methods, including CIMD and dynamic registration.
- Example consent flows and scope-binding patterns for agent-led access across multiple tools.
- Deployment notes on how Descope's Agentic Identity Hub maps to MCP authentication and lifecycle management.
👉 Read Descope's MCP server security best practices for agent-led access →
MCP server security - are your identity controls keeping up?
Explore further
06/07/2026 9:50 am
MCP security is really a governance problem, not just a protocol problem. The article shows that the critical failure point is not whether MCP can be authenticated, but whether teams have identity controls ready before tool exposure becomes routine. The protocol is moving toward clearer security guidance, yet implementation still depends on mature IAM, consent, and access scope design. Practitioners should treat MCP as a production identity boundary, not an experimental integration layer.
A few things that frame the scale:
- 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, according to AI Agents: The New Attack Surface report.
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
A question worth separating out:
Q: Who is accountable when an MCP agent takes the wrong action?
A: Accountability rests with the organisation that defined the policy, the consent model, and the delegated scope, not with the protocol itself. If an agent acts outside the intended boundary, investigators need to trace which identity issued the token, which tools were exposed, and which control failed to limit the action. Governance evidence matters as much as technical logs.
👉 Read our full editorial: MCP server security best practices are becoming identity controls
