Harden an MCP server for enterprise: SSO, audit, gateway

Hardening an MCP server for enterprise means moving it from a demo that trusts anyone with the URL to a service that verifies a real identity on every call, records what each agent did, and enforces least privilege at a gateway. By the end of this guide you will have an MCP server that validates an OAuth 2.1 access token on every request, routes login through your company identity provider, writes an audit line per tool invocation, and sits behind a gateway that scopes each agent to the tools it needs. That is the gap between a proof of concept and something a security team will sign off on.

The gap is not academic. A 2026 review of 1,000 public MCP servers found critical vulnerabilities in 33% of them. Endor Labs analyzed 2,614 MCP implementations and found 82% expose file operations prone to path traversal, 67% call APIs related to code injection, and 34% touch APIs susceptible to command injection. The first publicly documented malicious server, postmark-mcp, reached roughly 300 organizations before disclosure. And CVE-2025-6514, an OS command injection in the widely used mcp-remote client, scored 9.6 and affected a package with 437,000+ downloads. An MCP server is a remote execution surface pointed at your internal tools. Treat it like one.

What you need before starting

• A remote MCP server over HTTP (stdio-only local servers have a different threat model and are out of scope here).
• An enterprise identity provider that speaks OAuth 2.1 / OIDC: Okta, Microsoft Entra ID, Auth0, or Keycloak all work.
• A place to send logs: a SIEM or log sink such as Microsoft Sentinel, Splunk, or an S3 bucket with retention.
• The ability to put a reverse proxy or gateway in front of the server. This can be an existing API gateway or a purpose-built MCP gateway.

Step 1: Make the server an OAuth 2.1 resource server

The current MCP authorization spec (revision 2026-07-28) is built on OAuth 2.1. The MCP server acts as an OAuth resource server: it does not run login itself, it validates access tokens minted by a separate authorization server. Concretely, the server must reject any request without a valid bearer token, validate that token per OAuth 2.1 Section 5.2, and publish Protected Resource Metadata so clients can discover which authorization server to use. All authorization endpoints run over HTTPS, and clients must use PKCE with SHA-256. Anonymous access is the single most common failure we see in the wild, so start here.

Step 2: Route login through your identity provider (SSO)

Do not build your own login. Point the authorization server metadata at your enterprise IdP so that authenticating to the MCP server means authenticating to Okta, Entra, or Auth0, with the same MFA, conditional access, and offboarding your org already runs. This is what SSO buys you: when an employee leaves and IT disables their account, their agent's access to the MCP server dies with it. Avoid static API keys in production. They are hard to rotate, hard to attribute to a person, and they turn every log line into an anonymous one. Short-lived tokens with rotation are the enterprise default, and they pair with the TTL pattern we use for the server URLs themselves.

Step 3: Bind every token to your server, and never pass tokens through

This is the step most tutorials skip, and it is the one that stops the worst attacks. An AI agent in a single session may touch many resource servers, which makes the OAuth confused deputy problem acute: a token meant for one server gets replayed against another. The spec closes this two ways. First, clients MUST use Resource Indicators (RFC 8707): the client names your server in the token request, and the authorization server mints a token whose audience is your server and nothing else. Your server then rejects any token not minted for it. Second, the spec says the MCP server MUST NOT pass the caller's token through to a downstream API. Token passthrough is the confused-deputy anti-pattern by name. When your server needs to call something downstream on the user's behalf, use Token Exchange (RFC 8693): swap the inbound token for a fresh, audience-bound one that preserves the user's identity in an actor claim. Same user, correct audience, no replay.

Step 4: Put a gateway in front and scope tools by least privilege

Once you have more than one MCP server, or more than a handful of tools, centralize the controls. An MCP gateway sits between agents and servers and enforces authentication, per-tool permissions, and logging in one place, converting ungoverned tool sprawl into managed infrastructure. The gateway is where you apply least privilege: a support agent gets the read-only lookup tools, a billing agent gets the refund tool, and no agent gets every tool because it happened to authenticate. The gateway is also the right place to do the Token Exchange from Step 3, and to validate tool input schemas before a call reaches the server, which blunts the injection classes the Endor Labs data flagged.

Step 5: Turn on structured audit logging into your SIEM

Enterprise sign-off requires answering who accessed what, when, and why. Emit a structured log line for every tool call: the authenticated subject, the tool name, the arguments (redacted where sensitive), the resource touched, and the result. Feed those lines into your existing SIEM rather than a local file, so they inherit retention, alerting, and search. Microsoft Sentinel export, Splunk forwarding, and S3 archival are the common paths, and they are what a SOC 2 or ISO 27001 audit will ask for. Logs also give you anomaly detection: a spike in a single agent's tool calls, or a tool being invoked at 3am from a new location, is a signal you can only see if you recorded it.

Step 6: Pin and scan your tool definitions

Tool poisoning and rug pulls exploit the fact that agents trust tool descriptions. A server can ship a benign description, get approved, then silently redefine the tool to exfiltrate data. Defend against this by pinning tool definitions to a version, treating a description change as a change that needs review, and scanning third-party MCP servers before you connect an agent to them. Curate an internal registry of approved servers rather than letting any agent connect to any URL. This is governance, not code, but it is the control that would have stopped the WhatsApp MCP integration that poisoned tool descriptions to extract message histories in late 2025.

Verifying it works

Run these checks before you call the server hardened:

1. A request with no token returns 401, and the response advertises the authorization server via Protected Resource Metadata.
2. A token minted for a different resource is rejected (test your RFC 8707 audience check).
3. Disabling a user in your IdP kills their agent's access within the token lifetime.
4. Every tool call produces exactly one audit line in your SIEM, with the authenticated subject present.
5. An agent authorized for tool A cannot invoke tool B through the gateway.

Common failures and fixes

• Server accepts any token that validates. Validation is not enough. Check the audience. A token minted for another service that shares your IdP will validate but is not for you.
• Tokens passed straight to downstream APIs. This is the confused-deputy anti-pattern the spec forbids. Insert Token Exchange at the gateway.
• Audit logs on local disk. They disappear with the container and no one alerts on them. Ship to the SIEM.
• One broad scope for all tools. If authenticating grants every tool, you have authentication without authorization. Split scopes per tool or tool group.
• Trusting third-party servers by URL. A CVSS 9.6 RCE shipped in a package with 437,000 downloads. Vet before you connect.

Going further

If you have not built the server yet, start with our guide on building an MCP server for an existing Next.js SaaS, then apply this hardening pass on top. For the surrounding request-layer security patterns that these steps assume, see Next.js server actions security. The through-line is the same one that governs the rest of your stack: authenticate every caller, scope every permission, log every action, and trust no input by default.

Sources

• Authorization Security Considerations, Model Context Protocol (2026-07-28)
• Authorization, Model Context Protocol specification
• Resource Indicators in OAuth 2.0: A guide to RFC 8707, WorkOS
• MCP Security Statistics 2026, Practical DevSecOps
• MCP Security: Risks, Real Incidents and Controls, Checkmarx
• MCP Security Best Practices for Enterprise Teams in 2026, Stacklok