MCP Server Security: Hardening a Model Context Protocol Server You Operate
Running your own MCP server puts you in charge of who can reach its tools and what those tools can do. This guide covers server-side hardening: authenticating callers, authorizing each tool invocation, containing the confused-deputy risk, restricting tool egress, and deciding what belongs on the HTTP transport versus a locked-down local process. It closes with the enforcement layer that governs MCP traffic crossing the network.
When you operate a Model Context Protocol server, you own the surface that an LLM reaches through to call tools. That surface authenticates callers, exposes tool definitions, executes tool logic, and returns results into a model's context window. Each of those steps is a place an attacker aims for. This guide walks through hardening the server you run, from the caller boundary inward, and marks which controls live on the HTTP transport versus a local process.
The caller-facing controls extend the MCP server authentication and authorization patterns already on the blog.
Authenticate the caller and validate the token per request
An MCP server on the Streamable HTTP transport acts as an OAuth 2.1 resource server. It receives a bearer token, validates its signature and audience, and confirms the token was issued for this server rather than replayed from another. Validate on every request rather than caching a trust decision for the life of a connection, because a long-lived session that skips re-validation becomes a standing grant. Reject tokens with the wrong audience outright, since audience confusion is the entry point for several MCP attacks.
Authorize each tool call against role and arguments
Authentication tells the server who is calling. The server still has to decide whether this caller may run this tool with these arguments. Bind each tool to the roles allowed to invoke it, and evaluate argument constraints at call time. A database.query tool restricted to read-only roles should reject a caller whose role permits only ticket lookups, and a refund tool should cap the amount an argument can carry. Default to deny for any tool a role has not been explicitly granted.
Contain the confused-deputy risk
An MCP server that calls downstream APIs on a user's behalf can be turned into a confused deputy, where the server's own privileges are used to reach data the calling user should never see. The confused-deputy pattern shows up when the server holds broad service credentials and attaches them to requests without narrowing to the caller's authority. The fix is to carry the caller's identity through to the downstream authorization decision, so the server acts with the user's scope rather than its own. A server that swaps user identity for a powerful service account at the boundary erases the very context the downstream system needs.
Restrict what tools can reach
Treat each tool as a process with its own egress rules. A tool that summarizes tickets needs no outbound internet access, and a tool that reads a specific database needs a connection to that database and nothing else. Restricting tool egress limits what a compromised or manipulated tool can exfiltrate. This matters more with third-party tool code, where you did not write the logic and cannot assume it stays inside its stated purpose. The Anthropic MCP server security guidance walks through the vetting side of running tools you did not author.
Decide what belongs on HTTP versus a local process
The controls above assume network-facing traffic a policy layer can see. A server that runs locally over stdio, launched as a child process by the model host, communicates through pipes with no network hop. For those, security shifts to the operating system: run the process as a low-privilege user, restrict its filesystem to the paths it needs, and constrain outbound network so a malicious server cannot phone home. Anything that needs central authorization and audit belongs on the HTTP transport, where the traffic becomes inspectable and a gateway can enforce policy across every server at once.
DeepInspect
This is where DeepInspect fits for MCP servers on the HTTP transport. DeepInspect sits inline as a stateless proxy in front of your MCP endpoints and evaluates every tools/call against the caller's verified identity, the tool, the argument content, and organizational policy, then permits, redacts, or denies before execution. It carries caller identity into the decision so a server cannot act as a confused deputy under a broad service credential, and it commits a signed, per-decision audit record for every call.
For stdio and local servers, DeepInspect is clear that the control lives at the host, not the network, and it governs the HTTP-transport traffic where a proxy can actually enforce policy.
If you are exposing MCP tools to production agents, book an AI readiness assessment at deepinspect.ai.
Frequently asked questions
- What is the biggest MCP server security risk?
Over-broad authorization is the one that turns a small mistake into a large breach. A server that authenticates callers but then lets any authenticated caller invoke any tool, using the server's own powerful credentials downstream, is one crafted request away from exposing data across users. The confused-deputy version of this, where the server's privileges substitute for the caller's, is especially damaging because the authentication looks correct in the logs. Scoping tools per role and carrying caller identity through to downstream calls closes most of the exposure.
- How do I authenticate callers to an MCP server?
On the HTTP transport, run the server as an OAuth 2.1 resource server. Callers present a bearer token, and the server validates its signature, expiry, and audience on every request, confirming the token was minted for this server. Reject tokens whose audience points elsewhere, since audience confusion enables token replay across servers. Avoid static shared secrets that never rotate, because a leaked secret grants standing access with no per-request check. For local stdio servers there is no network caller to authenticate, so the trust boundary becomes the host and the OS user the process runs as.
- Does MCP server security differ for stdio versus HTTP transport?
Yes, and the difference decides which controls apply. HTTP-transport servers expose network traffic that a gateway can authenticate, authorize, and audit centrally, so the controls are token validation, per-call authorization, and decision logging. Stdio servers run as local child processes with no network hop, so the controls are operating-system isolation: least-privilege users, filesystem restrictions, and constrained egress. Putting a sensitive server on HTTP makes it governable by central policy; keeping it on stdio makes it a host-hardening responsibility.
- How does an MCP server become a confused deputy?
It happens when the server holds broad credentials to downstream systems and uses them on behalf of callers without narrowing to each caller's authority. A low-privileged user asks the server to fetch a record, the server queries the database with its own admin-level connection, and the record comes back even though the user had no right to it. The server's identity was confused for the caller's. Preventing it means propagating the caller's identity into the downstream authorization decision so the server acts with the user's scope, not its own.
- Can I centralize security across many MCP servers?
On the HTTP transport, yes. Placing an enforcement proxy in front of your MCP endpoints lets one policy set and one audit format cover every server, so a new server inherits authentication, per-call authorization, and logging without bespoke code. This is the practical reason to prefer HTTP for anything that needs governance: it turns a sprawl of individually configured servers into a single controlled surface. Local stdio servers stay outside that central layer and rely on host isolation instead.