Notifications
Clear all
Topic starter
22/06/2026 10:19 am
TL;DR: MCP servers expand the agent attack surface beyond prompt injection by introducing unauthenticated tool access, excessive permissions, persistent token exposure, and weak auditability, according to WorkOS. The core issue is that identity and authorisation assumptions built for browser-era access break when agents call tools directly at runtime.
NHIMG editorial — based on content published by WorkOS: The security risks specific to MCP servers, and how to address them
Questions worth separating out
Q: How should security teams govern MCP tool access in production environments?
A: Security teams should govern MCP tool access as delegated non-human identity, not as generic API traffic.
Q: Why do MCP servers increase the blast radius of AI systems?
A: MCP servers increase blast radius because they often give an agent access to multiple tools for the full session, not just the minimum needed for one action.
Q: What do teams get wrong about audit logging for AI tool use?
A: Teams often log the server error but not the identity event.
Practitioner guidance
- Make authentication mandatory at the MCP boundary Require OAuth 2.1 or equivalent identity enforcement before any tool is reachable, and reject unauthenticated requests at the server rather than relying on client behaviour.
- Scope every agent session to the smallest useful tool set Grant only the tools needed for the current task, and revoke that access automatically when the session ends.
- Stop handing long-lived tokens directly to agents Issue task-specific credentials with per-service revocation so one leaked context cannot be reused across Slack, GitHub, or data stores.
What's in the full article
WorkOS's full post covers the operational detail this analysis intentionally leaves at the control-design level:
- Step-by-step OAuth 2.1 handling for MCP servers, including unauthenticated request handling and token verification
- Concrete examples of structured tool-result sanitisation and approval gating for high-risk agent actions
- Session-scoped authorisation patterns for reducing blast radius across MCP tools and connected services
- Identity-layer audit log fields that make incident reconstruction and compliance reviews possible
👉 Read WorkOS's analysis of MCP server security risks and agent tool access →
MCP server security: are your controls keeping up?
Explore further
22/06/2026 11:10 am
MCP security exposes an identity control plane problem, not just an application hardening problem. The article is right to frame MCP as a distinct attack surface because tools are invoked by agents through a protocol boundary that sits between model output and production access. That means the security question is who or what is authorised to call a tool, not just whether the tool itself is vulnerable. Practitioners should treat MCP servers as non-human identity governors, not as ordinary APIs.
A few things that frame the scale:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, which leaves 48% with a blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent misuses MCP-connected tools?
A: Accountability should rest with the team that defined the agent session, granted the tool scope, and accepted the downstream access model. If a tool can alter data or reach external services, governance must assign a named owner for the agent identity, the session policy, and the audit trail.
👉 Read our full editorial: MCP server security risks are broader than prompt injection
