MCP server auth patterns for secure edge deployments

At a glance

What this is: This is a WorkOS article about securing MCP servers on Vercel Edge with an authHandler pattern, and its key point is that authentication can be applied declaratively while individual tools still decide whether access is required.

Why it matters: It matters because IAM teams now have to govern MCP servers as NHI-facing access surfaces, where authorization, scope, and user context must be consistent across public and private tools.

👉 Read WorkOS's article on secure MCP server deployment with AuthKit

Context

MCP server security is now an identity problem as much as a developer-experience problem. When an MCP server exposes both public and private tools, the security boundary is no longer the deployment wrapper alone. The primary issue is whether authentication and authorisation are enforced at the point of tool execution, especially when AI agents and users may traverse the same server.

For IAM and NHI programmes, this changes the control conversation from server access to tool-level access scoping. If authentication is optional by design, then policy must distinguish between harmless utility functions and tools that can touch user data, privileged workflows, or downstream systems. That is where the access model either holds or quietly drifts.

Key questions

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. Public utility tools can remain open, but any tool that touches data, workflows, or downstream systems should require explicit policy checks and audit logging. The goal is to prevent silent scope creep inside a shared MCP surface.

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. Once an MCP server can invoke tools, read user context, or reach external systems, it needs the same scoping, ownership, and audit discipline used for other non-human identities. The control gap is usually entitlement drift, not authentication alone.

Q: What do teams get wrong about authenticating MCP tools?

A: They often assume a valid token means the tool is safe to use. In reality, token validation only proves identity, while the tool still has to decide whether that identity is allowed to perform the action. If those checks are merged, privileged functions can inherit trust they never earned.

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.

Technical breakdown

Auth wrapper patterns for MCP servers

The authHandler pattern wraps an MCP server so authentication logic sits outside business logic. In practice, that means requests are validated once, user context is extracted from a token, and the resulting authInfo travels into tool handlers. This is cleaner than scattering checks across every route, but it also creates a single trust choke point: if the wrapper is misconfigured, tools may receive incomplete or unauthenticated context. The architecture works best when authentication and authorisation are deliberately separated, with the wrapper handling identity proof and each tool enforcing its own access decision.

Practical implication: review the wrapper as a control boundary and verify that every tool gets the correct authInfo state.

Public and private tools in one MCP server

The article’s mixed-auth model allows a single MCP server to host both unauthenticated tools, such as ping or status, and authenticated tools, such as user-data creation. That is useful for operational simplicity, but it also creates a governance challenge: the server is not the control plane, the tool is. If the permissions model is too coarse, public tools can become reconnaissance surfaces and private tools can inherit weaker access logic than intended. In NHI terms, this is a scope-management problem, not just a login problem.

Practical implication: classify every MCP tool by sensitivity and require explicit access rules for anything beyond read-only utility.

JWT verification and user context propagation

JWT verification validates the token, while userManagement lookup supplies a richer identity object for downstream authorisation. That separation matters because many systems stop at token validity and assume authentication equals entitlement. It does not. A valid JWT can still represent a user whose access should be constrained by role, tenant, or tool-specific policy. For MCP environments, the key technical issue is whether the claims in authInfo are sufficient to make a tool decision, or whether the tool needs an additional policy check before execution.

Practical implication: treat token validation as the start of the decision chain, not the end of it.

Threat narrative

Attacker objective: The objective is to reach sensitive tool actions through an MCP server that does not enforce consistent tool-level authorisation.

1. Entry occurs when a request reaches an MCP server that exposes both public and private tools under a shared auth wrapper.
2. Credential access or abuse occurs if a valid JWT or missing auth state is accepted without a tool-specific decision, allowing broader interaction than intended.
3. Impact follows when private tools inherit weak access logic and can be used to read or create user data from the same server surface.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Mixed public and private tools create a scope-governance problem, not a routing problem. When a single server serves both anonymous health checks and sensitive data operations, the risk is entitlement drift across tool boundaries. That is where NHI governance and application security meet: the same server can be operationally simple and still be badly scoped. Teams should review whether any public tool can become a discovery path into privileged functionality.

Authorization-by-wrapper only works when identity claims are sufficient for the downstream decision. JWT validation proves the token, not the business right to use the tool. If the tool depends on tenant, role, or task context, that context must be preserved and checked at execution time. The practitioner conclusion is straightforward: token acceptance and tool entitlement are different controls, and conflating them creates silent overreach.

MCP servers are becoming NHI control points, not just developer endpoints. The moment an MCP server mediates access to user context, data creation, or external systems, it inherits workload-identity governance requirements. That means access scoping, sensitive-tool classification, and auditability should sit in the same control model as other non-human identities. Practitioners should stop treating MCP as a narrow integration pattern and start treating it as an identity surface.

From our research:

• 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.
• For a wider view of the control model, see OWASP Agentic Applications Top 10 for the agent and tool-risk patterns that make MCP governance harder.

What this signals

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the operational message is clear: these systems are being deployed faster than access governance is being built. The immediate programme risk is not only secret leakage, but inconsistent authorisation across public and private tools. Teams should treat MCP servers as part of their non-human identity inventory, with the same review discipline applied to other workload-facing access surfaces.

MCP tool scoping debt: when access rules are attached to the server wrapper instead of the tool, sensitive functions inherit the wrong trust model. That pattern will keep surfacing as AI agent adoption spreads, because orchestration simplicity tends to outrun identity governance unless the control model is explicit from day one.

For practitioners

• Classify every MCP tool by access sensitivity Separate read-only utility tools from tools that can touch user records, workflows, or downstream systems. Apply explicit authorisation requirements to the sensitive set and document the decision as part of the service’s identity model.
• 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. A valid wrapper is not enough if a tool can still execute on inherited trust.
• 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.
• Separate token validation from entitlement checks Use JWT verification to establish identity, then apply role, tenant, or task policy before execution. Do not let identity proof and business authorisation collapse into the same control step.
• Instrument sensitive tool usage with audit-ready logs Log the authenticated subject, tool name, and decision outcome for every privileged call so security and compliance teams can reconstruct who used which MCP capability and why.

Key takeaways

• MCP servers are now identity surfaces, not just developer plumbing, because tool-level access determines who can do what.
• The evidence points to a basic control gap: many MCP deployments still expose credentials or fail to scope tool permissions tightly enough.
• Practitioners should inventory tools, separate authentication from entitlement, and bring MCP servers into NHI governance reviews.

Key terms

• MCP server: An MCP server is a service that exposes tools and data to AI clients through the Model Context Protocol. In governance terms, it becomes a new access surface that can carry user context, secrets, and privileged actions, so it must be inventoried and controlled like other non-human identity endpoints.
• Auth handler pattern: An auth handler pattern places identity verification and session context handling in a wrapper around application logic. This keeps security code out of business functions, but it only works if the wrapper is enforced consistently and each downstream tool still makes its own access decision.
• Tool-level authorisation: Tool-level authorisation means each individual function or capability decides whether a caller may use it, rather than trusting the server as a whole. It is the practical control that prevents a mixed-purpose MCP server from letting low-risk access leak into high-risk operations.
• AuthInfo: AuthInfo is the identity context passed into a tool after authentication succeeds. It typically carries claims, user details, or other metadata that downstream code can use for authorisation, but it should never be treated as proof that the caller is entitled to every tool on the server.

Deepen your knowledge

MCP server auth patterns and tool-level access scoping are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for workload-facing APIs or AI tool servers, it is worth exploring.

This post draws on content published by WorkOS: The Vercel MCP + WorkOS AuthKit template for secure MCP server deployment. Read the original.