Notifications
Clear all
Topic starter
08/06/2026 4:47 pm
TL;DR: Secure MCP server templates on Vercel Edge reduce the friction of adding authentication to AI tool servers, but they also expose a sharper governance issue: public and private tools can coexist unless authorization is enforced at the tool level, according to WorkOS. The real control question is whether identity checks are attached to execution paths, not just to the server wrapper.
NHIMG editorial — based on content published by WorkOS: The Vercel MCP + WorkOS AuthKit template for secure MCP server deployment
Questions worth separating out
Q: How should security teams govern MCP servers that mix public and private tools?
A: They should classify each tool by sensitivity and enforce authorisation at the tool level, not just at the server wrapper.
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: What do teams get wrong about authenticating MCP tools?
A: They often assume a valid token means the tool is safe to use.
Practitioner guidance
- Classify every MCP tool by access sensitivity Separate read-only utility tools from tools that can touch user records, workflows, or downstream systems.
- Verify tool-specific enforcement, not just server-level authentication Test that private tools reject calls when authInfo is missing, malformed, or insufficient for the requested action.
- Map MCP servers into NHI governance reviews Include MCP servers in service-account and workload identity inventories so access scoping, audit trails, and entitlement ownership are reviewed alongside other non-human identities.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- The exact Next.js and Vercel Edge pattern used to wrap an MCP server with a single authentication handler.
- The sample code paths for public tools and authenticated tools, including how authInfo is passed into handlers.
- The JWT verification and WorkOS user lookup flow used to populate user context.
- The built-in test interface for validating authenticated and unauthenticated tool behaviour before deployment.
👉 Read WorkOS's article on secure MCP server deployment with AuthKit →
MCP server auth on Vercel Edge: what changes for IAM teams?
Explore further
08/06/2026 6:37 pm
Tool-level authorisation is the real MCP control boundary. A wrapped server can authenticate a request and still leave individual tools too broadly exposed. The article shows that the governance decision is not whether the server is protected, but whether each tool can independently reject unauthorised use. Practitioners should treat MCP tool inventory as an access-control map, not a developer convenience layer.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows the problem is not just secret exposure but control design.
A question worth separating out:
Q: How do security teams reduce risk before deploying MCP servers at scale?
A: They should start with tool inventory, access classification, and logging. Before rollout, define which tools are public, which require authentication, and which need stronger policy checks or tenant constraints. That creates a defensible boundary for review and avoids discovering sensitive access paths after deployment.
👉 Read our full editorial: MCP server auth patterns for secure edge deployments
