How to Secure an MCP Server: A Practical Hardening Guide and Checklist

Secure an MCP server with defense in depth: authenticate and authorize every request, enforce least privilege, use TLS and private or isolated networking, validate inputs, protect tokens and sessions, monitor activity, require approval for dangerous actions, and patch regularly.

Securing the Model Context Protocol (MCP) in production or an internet-connected deployment requires layered controls. Exact capabilities vary by SDK, framework, transport, identity provider, and runtime. Do not assume that every MCP implementation offers the same authentication or session controls, or that an MCP server is secure by default.

What it means to secure an MCP server

MCP standardizes communication between AI clients or agents and external tools, data sources, and services. An MCP server may read files, query APIs, modify records, execute operations, or return data to an agent.

The main trust boundaries are:

• Clients and users: applications, agents, services, or people requesting access.
• Tools and resources: functions, files, databases, APIs, and other exposed capabilities.
• Untrusted content: prompts, tool descriptions, protocol messages, files, retrieved data, and tool results.
• Execution environments: the process, container, host, network, and downstream services available to the server.
• Secrets and sessions: access tokens, API keys, session state, signing keys, and credentials used on behalf of clients.

A secure design separates identity verification, authorization, transport protection, input validation, execution isolation, secret management, and monitoring. HTTPS alone is not sufficient: encrypted traffic does not prevent an overprivileged client, malicious input, unsafe commands, stolen tokens, or a compromised dependency.

The five essential control areas

1. Authenticate and authorize every request: use the framework’s supported OAuth/OIDC, signed-token, or API-gateway flow, and reject missing or unauthorized credentials.
2. Apply least privilege: use fine-grained scopes or RBAC, separate service identities, deny-by-default rules, and read-only permissions wherever possible.
3. Protect transport and execution: use TLS for remote traffic, private or segmented networking where appropriate, and containers or sandboxing to avoid unrestricted host access.
4. Validate untrusted input: check tool arguments, prompts, files, protocol messages, and returned data to reduce prompt injection, command injection, and unsafe operations.
5. Operate and verify the service: protect tokens and sessions, log and monitor activity, require approval for high-impact actions, control abuse, and keep dependencies patched.

Understand the main MCP security risks

Identify what an attacker, compromised client, or manipulated agent could influence. Common MCP security risks include:. After identifying the risks, readers can compare MCP security scanners for assessing MCP servers and agents.

• Prompt and context injection: untrusted instructions in prompts, retrieved content, files, or tool results can influence an agent’s decisions.
• Tool poisoning: a tool description, metadata field, or dynamically discovered component can contain misleading or malicious instructions.
• Command injection and unsafe execution: poorly constrained arguments can cause unintended commands or operations.
• Excessive permissions: broad access to tools, files, APIs, or chained capabilities increases the impact of token theft or server compromise.
• Token and session attacks: exposed credentials can enable impersonation, replay, or session hijacking.
• Data leakage: a tool or agent may return sensitive data to an unauthorized user, downstream service, response, or log.
• Supply-chain compromise: unapproved tools, changed metadata, vulnerable libraries, or tampered dependencies can alter server behavior.
• Denial of service: expensive tools, excessive requests, large inputs, or unbounded concurrency can exhaust resources or downstream quotas.

Treat every request as potentially unsafe until its identity, authorization, input, target, and impact have been checked.

Choose controls for the deployment model

Local stdio deployments

A local stdio MCP server typically communicates through the client process instead of accepting network connections. That can reduce network exposure, but it does not remove the need for security. The server may still access files, environment variables, local credentials, shell commands, and other processes. For deployment-specific guidance, see the checklist for local MCP server security.

Confirm which operating-system identity starts the process, which directories and commands it can access, whether it runs as a non-root user, and whether tools are isolated. Restrict file paths, environment variables, child processes, and outbound connections to what the workflow requires.

Remote HTTP-based deployments

A remote HTTP-based MCP server has a broader trust boundary. Define the client and user identity model, protect network transport, authorize requests, secure sessions, control proxy or gateway exposure, and prevent unwanted public access. For a deployment-specific hardening checklist, see remote MCP server security.

SSE and Streamable HTTP have transport-specific behavior. Confirm their authentication and session handling in the selected implementation instead of assuming that one model applies universally.

Document:

• Which clients and users may connect.
• Where TLS terminates and which component validates identity.
• Whether a reverse proxy, API gateway, firewall, private network, or optional mTLS boundary is used.
• How sessions, tokens, timeouts, and replay-sensitive flows are handled.
• Which tools and downstream destinations each identity may use.
• How the server is isolated from the host and unrelated workloads.

Cloud deployments

A cloud server is not secure merely because it runs on a managed platform. Apply the same controls at the network, identity, workload, and application layers: limit public exposure, use the platform’s identity and secret-management boundaries, isolate the workload, restrict egress, enable logging, and verify the permissions of any managed services the server can access.

Authenticate and authorize every request

Implement the MCP server’s supported authorization flow and reject unauthenticated or unauthorized requests. Depending on the framework and deployment, this may use OAuth 2.0 or 2.1, OIDC, validated signed tokens, or an API gateway that performs identity verification.

Authentication establishes who is making a request. Authorization determines what that identity may do. A valid identity must not automatically receive access to every tool, resource, or operation.

At minimum:

• Validate the token signature, issuer, audience, expiry, and other required claims.
• Reject missing, malformed, expired, or incorrectly scoped credentials.
• Use separate service identities for different clients, agents, jobs, environments, and tenant contexts.
• Secure OAuth consent flows with exact redirect-URI matching and safe state handling where supported.
• Use the authenticated identity for every subsequent authorization decision.
• Check authorization for every inbound request and every sensitive tool operation.

Do not assume that all MCP implementations have native authentication. Capabilities depend on the selected SDK, framework, transport, and identity provider. Use the strongest supported identity flow rather than relying on a broad static credential.

Apply least privilege to tools and data

Use deny-by-default policies with fine-grained scopes, role-based access control (RBAC), attribute-based rules, and per-tool permissions where supported. Expose only the minimum capabilities required for each client, user, or workflow.

Restrict:

• Tools: publish only the functions a client actually needs.
• Operations: separate read, create, update, delete, administrative, and execution actions.
• Filesystem paths: allow specific directories or files instead of unrestricted host access.
• Resources and data: limit records, fields, repositories, and environments by identity and context.
• API scopes: grant only the downstream permissions necessary for the task.
• Outbound targets: restrict network destinations and prevent arbitrary egress where appropriate.
• Chained capabilities: review whether one tool can invoke another or combine permissions unexpectedly.

Use separate service identities for production and development, read-only and write-capable workflows, and unrelated clients. Prefer read-only access by default. Enforce authorization in the server or its trusted policy layer, not solely in the model or client.

For multi-tenant systems, bind tenant identity to authorization decisions, resource filters, tool permissions, session state, and downstream credentials. Test that one tenant cannot use another tenant’s tools, data, tokens, or sessions, and log denied cross-tenant attempts.

Avoid passing a client’s access token directly to downstream APIs when the implementation supports server-controlled credentials. The server should authorize the downstream action independently where possible.

Protect transport, sessions, and execution

Use TLS and reduce network exposure

Protect remote MCP traffic with TLS and verify that clear-text access is unavailable through an alternate endpoint.

Additional controls may include:

• A reverse proxy or API gateway for controlled exposure, request filtering, and centralized policy enforcement.
• Private or limited network exposure instead of an openly reachable endpoint.
• Network segmentation and firewall rules restricting clients, management paths, and downstream destinations.
• Optional mutual TLS when certificate-based client authentication is appropriate.
• Separate network paths for management traffic and tool execution where the deployment requires it.

Protect sessions and credentials

Use secure session storage, expiration, and replay or hijacking protections according to the transport and framework. Protect session handles and state on the server, bind them to the authenticated context where supported, and keep credentials out of URLs, logs, prompts, and tool arguments.

Confirm the selected SDK’s behavior for session expiration, invalidation, refresh, and concurrent use. There is no single session model for every MCP implementation.

Isolate tool execution

Assume that a tool may be misused or compromised. Run the server and its tools with the least operating-system privilege required, preferably as a non-root service. Use containers or other sandboxing mechanisms where appropriate.

• Restrict commands and approved executable paths.
• Use read-only mounts for tools that do not need to write.
• Limit filesystem, process, network, and device access.
• Set CPU, memory, disk, file-descriptor, and execution-time limits.
• Use timeouts and cancellation for slow or stuck operations.
• Restrict outbound network access to approved destinations.
• Separate workloads or identities for tools with different risk levels.

Validate inputs and control outputs

Treat prompts, tool descriptions, protocol messages, files, retrieved content, tool arguments, and returned data as untrusted. Validate inputs before a tool executes and constrain outputs before returning them or passing them to another component.

Use controls such as:

• Strict schemas for every tool argument.
• Explicit type, length, size, encoding, and range limits.
• Allowlists for commands, paths, methods, resource identifiers, and destinations.
• Sanitization and dangerous-pattern checks appropriate to the operation.
• Business-rule validation, such as permitted status changes or transaction limits.
• Output filtering and provenance handling for sensitive or untrusted results.
• Re-validation after transformations, tool chaining, or data retrieval.

Do not rely on a tool description to make an operation safe. A description can be manipulated, and a model can misunderstand it. Keep dangerous operations narrowly defined, reject unexpected arguments, and separate data from executable instructions wherever possible.

Require approval for high-impact actions

Require explicit human confirmation immediately before destructive, irreversible, financial, administrative, or otherwise high-impact actions. Show the user what will happen rather than merely asking them to approve a tool name.

Protect secrets, tokens, and downstream credentials

Store API keys, signing keys, refresh tokens, and other secrets outside source code. Keep them out of prompts, tool results, process output, diagnostic errors, and logs. Use controlled environment or vault-based approaches supported by the deployment.

For tokens and sessions:

• Use secure storage and restrict which process or identity can read each secret.
• Set expiration and refresh behavior appropriate to the risk and implementation.
• Rotate credentials and signing material where supported.
• Revoke or invalidate compromised credentials and sessions when the framework provides that capability.
• Protect against replay and hijacking through transport security, validation, expiration, and server-side session controls.
• Never include full credentials in audit records or diagnostic errors.

Maintain a recovery procedure for exposed credentials: contain the affected endpoint or tool, revoke and rotate credentials, assess downstream access, preserve relevant logs, restore trusted components, and verify that the replacement credentials work only within their intended scope.

Add rate, resource, and abuse controls

Limit abuse and resource exhaustion with controls appropriate to each tool and deployment:

• Per-client and per-user request limits.
• Input and output size limits.
• Concurrency limits and bounded queues.
• Tool-specific timeouts and cancellation.
• CPU, memory, storage, token, and downstream API budgets.
• Back-pressure and failure handling for dependent services.

Apply limits at more than one boundary when necessary: the edge proxy, MCP server, tool runner, and downstream service may each need different controls. Log rejected or throttled requests so repeated abuse can be investigated.

Secure tools and dependencies

Review every tool and component connected to the server. Use approved or signed components where available, pin dependency versions, scan dependencies, and validate tool metadata before deployment.

• Review new tools, descriptions, permissions, and downstream destinations.
• Check dependencies for known vulnerabilities before release.
• Pin and review protocol libraries, runtime images, and other important components.
• Detect unexpected metadata or behavior changes in dynamically discovered tools.
• Patch MCP libraries, dependencies, images, and operating-system components regularly.
• Test permission changes and tool updates before promoting them to production.

A trusted connection does not make an untrusted or tampered tool safe. Tool integrity belongs in the same review process as application code and infrastructure changes.

Log and monitor MCP activity

Enable audit logging and monitoring for security decisions and operational behavior. Record enough context to investigate an event without storing secrets or unnecessary sensitive data. For broader guidance on monitoring agent actions and security telemetry, see AI security monitoring.

Depending on privacy and retention requirements, record:

• Authenticated user, client, agent, service, and tenant identity where applicable.
• Authentication failures and authorization denials.
• Tool calls, requested resources, operation type, and filtered arguments.
• Policy decisions, approval results, outcomes, errors, and execution duration.
• Data provenance and downstream destinations where relevant.
• Administrative changes to tools, permissions, credentials, configuration, and dependencies.
• Rate-limit events, isolation failures, suspicious input, and other security events.

Monitor for repeated authentication failures, unusual tool sequences, access outside normal scope, unexpected outbound destinations, abnormal resource use, and sudden changes in tool metadata or permissions. Protect logs from unauthorized modification and confirm retention and access rules for the environment.

Verify the implementation before production

Test the controls against the actual MCP SDK, framework, transport, identity provider, and deployment model. A control described in documentation may not be enabled in the selected runtime.

Authentication and authorization tests

• Send requests with missing, malformed, expired, wrongly signed, and incorrectly scoped credentials.
• Confirm every protected request and tool operation is checked.
• Attempt cross-client, cross-role, cross-tenant, and cross-resource access.
• Test read-only identities against write, delete, administrative, and execution operations.
• Verify approval gates cannot be bypassed through alternate tool paths or chained calls.

Input, execution, and abuse tests

• Test prompt, context, tool-description, argument, file, and returned-data injection scenarios.
• Try unexpected types, oversized values, invalid paths, unauthorized commands, and unapproved destinations.
• Confirm tools run with the intended user, filesystem, network, and process restrictions.
• Test timeouts, concurrency limits, rate limits, resource budgets, and cancellation.
• Check that secrets do not appear in responses, prompts, errors, process output, or logs.

Transport, session, and supply-chain tests

• Verify remote traffic uses TLS and that unintended clear-text exposure is unavailable.
• Test session expiration, invalidation, replay protections, and behavior after credential changes.
• Review proxy, firewall, private-network, mTLS, and egress rules where used.
• Change a tool or dependency in a test environment and confirm integrity checks, review gates, and alerts work.
• Confirm logs contain the required identity, policy, operation, outcome, provenance, and security-event information without secrets.

MCP server hardening checklist

1. Map trust boundaries: list clients, users, tenants, tools, data, downstream APIs, secrets, sessions, and execution environments.
2. Confirm the deployment model: document whether the server uses local stdio, remote HTTP, SSE, Streamable HTTP, or another supported transport.
3. Enable authentication: configure the supported OAuth/OIDC, signed-token, or gateway flow and reject invalid identities.
4. Enforce authorization: apply deny-by-default scopes, RBAC or attribute-based rules, tenant boundaries, and per-tool checks for every operation.
5. Reduce permissions: remove unnecessary tools, files, resources, API scopes, commands, and outbound targets; prefer read-only access.
6. Protect transport and sessions: use TLS for remote traffic, limit network exposure, protect session state, and verify replay defenses.
7. Validate untrusted input: apply schemas, allowlists, type and size limits, sanitization, business rules, and dangerous-pattern checks.
8. Isolate execution: use non-root execution, restricted commands, read-only mounts, timeouts, resource limits, and sandboxing where appropriate.
9. Protect credentials: secure tokens, sessions, signing keys, API keys, and downstream credentials; rotate or revoke them where supported.
10. Add operational controls: configure rate limits, concurrency limits, resource budgets, monitoring, approval gates, alerting, and recovery procedures.
11. Secure the supply chain: approve components, pin versions, scan dependencies, validate metadata, and patch regularly.
12. Test before launch: verify authentication failures, authorization bypasses, injection defenses, isolation, egress, replay protections, logging, and credential recovery.

Finally, confirm every planned control against the selected MCP SDK, framework, transport, identity provider, and environment. Security capabilities and configuration details vary, so production readiness depends on verifying the implementation—not assuming that MCP or HTTPS provides security by default.

Watch this in video

Foundations of Secure MCP: Architecture and Threat Model

Securing the MCP Server: What You Need to Know