How to Secure an MCP Server in Production

A production MCP server should be treated as a privileged application boundary, not a prompt plugin. Secure it with normal application controls—OAuth, token audience validation, least privilege, input validation, SSRF protection, audit logs, and approval for consequential actions—plus agent-specific defenses for untrusted tool descriptions and outputs.

MCP standardizes how capabilities are exposed. It does not decide who should be allowed to use them.

Start with the threat model

Document four actors:

the human user;
the AI client or host application;
the MCP server;
the downstream system the server can access.

Then map which identity is used at every hop. A common failure is allowing the client’s infrastructure identity to become a universal substitute for the current user. The model may appear to act “for Alice” while the downstream API sees a broad service account.

Follow the current authorization boundary

The November 2025 MCP authorization specification uses OAuth-based discovery and protected-resource metadata for remote HTTP servers. Its most important security rule is straightforward: token passthrough is forbidden. An MCP server must not accept a token intended for another service and simply forward it downstream.

Token passthrough breaks audience validation and makes it difficult to know which service a credential was issued for. Instead:

validate issuer, audience, signature, expiry, and required scopes;
issue or obtain a credential intended for the MCP server;
use a separate, explicit downstream authorization flow where delegation is needed;
keep tokens out of model context, tool output, URLs, logs, and error messages.

Read the MCP authorization specification alongside the protocol’s security best practices.

Prevent confused-deputy authorization

A confused deputy occurs when an attacker causes an authorized server to misuse its access. In an MCP flow, this can happen through manipulated redirect parameters, forged consent context, or a request that makes the server call a protected downstream resource for the wrong user.

Controls include:

binding authorization requests to the initiating client and user session;
exact redirect-URI validation;
state and PKCE verification;
explicit consent for sensitive scopes;
audience-restricted access tokens;
rejecting credentials supplied inside tool arguments;
rechecking authorization at execution time, not only during tool discovery.

Treat every URL as an SSRF boundary

Some MCP servers fetch URLs, connect to remote endpoints, import schemas, or follow redirects. The official MCP security guidance calls out server-side request forgery because a tool can otherwise reach loopback services, cloud metadata endpoints, or private infrastructure.

For server-side fetches:

allow HTTPS only outside local development;
resolve and validate the destination before connection;
reject loopback, link-local, private, and metadata IP ranges unless explicitly required;
revalidate every redirect;
enforce response-size, content-type, and timeout limits;
avoid accepting arbitrary callback or webhook destinations.

Do not assume a URL is safe because the model generated it or a document contained it.

Design tools around least privilege

One broad execute_action tool is hard to authorize and evaluate. Prefer narrow tools with explicit schemas and separate read/write capabilities.

Better boundaries:

find_customer instead of unrestricted database queries;
draft_refund separate from approve_refund;
list_files separate from delete_file;
tenant and user identity supplied by trusted server context, not model arguments;
server-side validation of identifiers, amounts, allowed transitions, and ownership.

In EmbedChat AI, platform adapters and tenant context constrained which commerce tools and data could participate in a request. Exposing that layer through MCP would not remove those constraints; it would make their schemas reusable.

Tool descriptions are not a security policy

An MCP tool name and description guide model selection, but model compliance is not authorization. A malicious or compromised server can also publish deceptive descriptions, change a tool definition, or return content containing instructions for the model.

Protect the host application by:

trusting only approved servers and transports;
pinning or reviewing material capability changes;
displaying the real server and action before sensitive approval;
keeping system policy outside tool-return text;
treating results as untrusted data;
validating the final action against trusted application state.

OWASP’s Agentic Security Initiative now maintains MCP guidance and a 2026 Top 10 for agentic applications, reflecting how tool supply chains, identity, memory, and action control have become distinct security concerns. See the OWASP Agentic Security Initiative.

Control sessions and transport

Use TLS for remote traffic.
Bind session state to authenticated identity.
Generate unpredictable session identifiers.
Expire idle sessions and revoke them on logout or credential rotation.
Prevent cross-tenant session reuse.
Limit concurrent and long-running calls.
Support cancellation and bounded retries.
Do not expose a local server beyond the intended interface.

For local MCP servers, command execution and filesystem access deserve the same review as installing any privileged developer tool.

Require human approval where impact changes

Approval should describe the concrete action—not ask whether the user trusts “the AI.” Show the destination, record, fields, amount, recipients, and irreversible effect. Revalidate the data after approval so a model or tool cannot swap the target.

Read-only search may run automatically. Sending an email, publishing content, modifying production data, or spending money should use a different permission path.

Log the complete causal chain

Record:

authenticated user and client;
MCP server and capability version;
tool selected and validated arguments;
policy and approval decision;
downstream request identifier;
result status, latency, and sanitized error;
final agent outcome.

Do not store secrets or unrestricted private content merely because traces are useful. Use structured redaction and retention rules.

Production MCP checklist

[ ] Exact server ownership and trust policy
[ ] OAuth discovery and redirect validation
[ ] Token issuer, audience, expiry, and scope validation
[ ] No token passthrough
[ ] Separate downstream credentials and delegation
[ ] SSRF-safe URL fetching and redirect handling
[ ] Narrow read/write tools with strict schemas
[ ] Tenant/user identity from trusted context
[ ] Approval for consequential actions
[ ] Tool-output and prompt-injection defenses
[ ] Version/change review for capabilities
[ ] Rate, time, cost, and concurrency budgets
[ ] End-to-end audit traces with redaction
[ ] Revocation, cancellation, and incident response

MCP is production-ready only when the server is secure even if the model selects the wrong tool, the user submits hostile content, or a downstream service fails. Prompt instructions can improve behavior; they cannot carry the security boundary.