The Model Context Protocol (MCP) is quickly becoming the standard for connecting AI models to tools and data sources. But as MCP servers move from prototypes to production, a critical question emerges: how do you secure them?

Most MCP server implementations today have no built-in authentication. Anyone who knows the endpoint can call it. This works fine during development but is a non-starter for production deployments where multiple applications and agents need controlled, auditable access. For a broader view of what production MCP governance entails, see Registering and Governing MCP Servers.

The authentication gap

When you deploy an MCP server, you need to answer several questions:

  • Who is allowed to call this server?
  • What tools and resources can each caller access?
  • Are there rate limits or usage caps?
  • What happens when a request violates your content policies?

Traditional API gateways can handle some of these concerns, but they were designed for REST/HTTP traffic patterns. MCP has its own protocol semantics, tool invocation patterns, and streaming responses. Bolting on a generic gateway introduces friction and misses important context.

The authentication question also connects to how callers identify themselves. Whether you use OAuth 2.1 tokens, API keys, or mutual TLS depends on the deployment context — for a detailed comparison of those options, see MCP Server Authentication: OAuth 2.1 vs API Keys.

How to secure MCP servers

Securing an MCP server follows a short, deliberate sequence.

1. Register your MCP server

Add your MCP server to a governance platform. It receives credentials that identify it, enabling the platform to authenticate callers against a known registry rather than relying on network-level controls alone.

2. Define connections

Specify which applications and agents are allowed to connect to your MCP server. Each connection is explicit — there is no implicit trust. A caller that is not in the connection list is denied before any tool call is evaluated.

3. Configure guardrails

Set content-level controls on what can be requested and what can be returned. For example, you might allow a tool to be called but restrict what data it can return based on the caller's trust level. This is the layer that enforces policies like least-privilege tool scoping at the server boundary.

4. Set policies

Apply operational controls like rate limits per caller, geographic restrictions, and time-based access windows. A development application might get higher call limits during business hours, while a production agent is rate-limited to prevent runaway loops.

Content-aware security

What makes this approach different from a standard API gateway is the content awareness. The platform does not just check credentials and pass requests through — it inspects the semantic content of interactions.

This matters because MCP servers expose tools that can perform arbitrary actions. A tool that reads from a database is very different from one that writes to it, even though both go through the same MCP endpoint. Content-aware guardrails let you make fine-grained decisions about what each caller can do, based on the specific tool being invoked and the arguments being passed.

Bidirectional controls

MCP server responses can contain sensitive data. A complete security model applies controls in both directions:

  • Inbound: What requests are allowed? Which tools can be invoked? What parameters are permitted?
  • Outbound: What data can be returned? Are there content filters on responses? Should certain fields be redacted?

This bidirectional approach ensures that even if a tool produces unexpected output, the response is filtered before reaching the caller. It is the server-side complement to the PII detection and redaction you apply on the agent side.

Getting started

If you are running MCP servers in production — or planning to — adding authentication and explicit connection management should be among your first steps. Register your MCP server, define who can connect, set your guardrails, and you have a production-ready security posture rather than an open endpoint. For a step-by-step walkthrough of the registration process, see registering and governing MCP servers.

Common questions

Why can't I just put my MCP server behind a VPN or firewall? Network-level controls limit who can reach the endpoint, but they do not distinguish between callers, enforce per-tool permissions, or inspect call content. Any caller inside the perimeter has the same access. As MCP servers become shared infrastructure accessed by multiple agents and applications, you need identity-based controls that travel with each caller, not just network topology.

What is the difference between authenticating the MCP server and authenticating the caller? These are distinct concerns. Server authentication means the caller can verify they are talking to a legitimate, registered server and not an impersonator. Caller authentication means the server (and any governance layer in front of it) can verify who is making each request. Both are necessary: server authentication prevents tool call hijacking; caller authentication enables per-caller policy enforcement and audit attribution.

How do rate limits on MCP servers interact with agent-level rate limits? They are complementary. Agent-level rate limits cap how many tool calls a specific agent can make in a window. Server-level rate limits cap how many calls the server accepts in total across all callers. Running both ensures that a single agent cannot monopolize a shared server, and that the server is protected even if an agent's own limits are misconfigured.

Does this approach cover the full MCP security checklist? Authentication and connection management cover the access control layer. A complete MCP security posture also includes supply-chain verification of the server itself, output redaction, and incident response planning. For the full list, see the MCP Server Security Checklist.