How to Secure an MCP Server: Auth, Sandboxing, and Tool Allowlisting

The Model Context Protocol makes it easy to expose tools to an agent and easy to forget that every one of those tools is now reachable by anything that can reach the server. Authorization in the MCP spec is explicitly optional, which means a server can be fully spec-compliant while accepting any connection with no authentication at all. Tool execution by default runs wherever the server process runs, so a tool that shells out to run a command or fetch a URL is one bug or one poisoned tool description away from doing that on behalf of an attacker rather than the intended agent. And most MCP clients grant an agent access to every tool a connected server advertises, with no separate step asking whether this particular session actually needs all of them. None of that is a flaw in the protocol. It is what you get from a protocol that deliberately leaves authorization, sandboxing, and access policy to the implementer rather than baking in one opinionated answer. The three sections below are that implementer's job.

Before touching configuration, get clear answers to a few questions. Getting these wrong is the most common reason teams end up bolting on the wrong control for their actual deployment.

The current MCP specification defines authorization for HTTP-based transports as a specific, narrower profile of OAuth 2.1, not a free-form "add whatever OAuth flow you like" instruction. In this model, the MCP server acts as an OAuth 2.1 resource server, the MCP client acts as an OAuth 2.1 client, and a separate authorization server (which may or may not be the same system as the MCP server) issues the actual access tokens. The flow is built on four underlying specifications: OAuth 2.1 itself, RFC 8414 for authorization server metadata discovery, RFC 7591 for dynamic client registration, and RFC 9728 for protected resource metadata. Getting these four pieces wired together correctly is most of the work.

Authentication controls who can talk to your MCP server. It does nothing about what happens once a tool call actually executes. A tool that runs a shell command, fetches a URL, or executes model-generated code needs its own execution boundary, because a single vulnerable or maliciously modified tool running in the same process as your server's request handling can compromise everything else that process can reach.

OAuth handles who is connecting, and a valid, correctly scoped token proves the connection is legitimate at a coarse level. It does not tell you which of the specific tools your server exposes that session should actually be able to call, because the MCP spec does not standardize per-tool scope conventions. That gap has to be closed with your own policy layer, and it needs to be enforced twice, not once.

Configuration that looks correct in code is not the same as configuration that behaves correctly under an actual request. Run each of these checks before calling the deployment done, and re-run them whenever the token validation, sandbox, or allowlist logic changes.

These are the specific ways this implementation goes wrong in practice, not hypothetical edge cases.

None of these three controls is free, and pretending otherwise leads to configurations that get quietly rolled back the first time they cause friction. Stronger sandboxing (gVisor, microVMs) adds real per-call latency and infrastructure cost compared to a bare container or in-process execution, which is why the trust-level classification in the prerequisites matters: paying that cost for every internal, low-risk tool call is often not worth it, while skipping it for a third-party server executing model-generated code is a real gap. Fine-grained, parameter-level tool allowlisting is an ongoing maintenance burden, not a one-time setup task. Every new tool needs an explicit grant decision, and every change to an existing tool's schema needs a re-review, and teams that let that process lapse drift back toward broad, undocumented trust without necessarily noticing it happened. The MCP spec's own authorization flow is also narrower than it might look: it standardizes authentication and coarse resource-level access well, but it deliberately leaves per-tool scope granularity to the implementer, which means two MCP servers can both be fully spec-compliant on authentication while having completely different actual tool-level access control. Compliance with the OAuth flow described here is a necessary control, not evidence on its own that a deployment is secure. Automated scanners, covered in our comparison of Cisco, Invariant, and Akto's MCP scanners, catch some known patterns like poisoned tool descriptions and can flag some rug pull activity, but that tooling category is young, without a long independent track record, and complements the manual work in this guide rather than replacing it. Finally, none of this exists in isolation: the identity and access decisions made for a single MCP server should fit into a broader program for how your organization manages AI agent and non-human identities generally, which our agentic AI identity maturity model walks through at the organizational level rather than the single-server level covered here.