MCP Security Best Practices for Production Deployments

A working OAuth handshake does not mean a secure MCP deployment. Here is what production teams still have to build themselves.

A developer connects a Model Context Protocol (MCP) client to a new remote server. The server opens with an OAuth flow, so the connection looks secure. The same server also controls the authorization endpoint returned to the client. In vulnerable versions of the widely used mcp-remote package, a malicious server could place operating-system commands inside that authorization endpoint. When the client processed the response, those commands could run on the developer's machine.

This was a documented attack, not a hypothetical one. It was published on July 9, 2025, as CVE-2025-6514 and affected mcp-remote versions 0.0.5 through 0.1.15. GitHub classified it as a critical command-injection vulnerability. Version 0.1.16 contained the fix. The case shows why a working MCP connection is not always secure. OAuth was present. The client and server completed the expected connection process. Untrusted server data still reached a sensitive execution path.

The wider ecosystem shows the same gap. A May 2026 measurement study of 7,973 live remote MCP servers found that 40.55% exposed tools without authentication. The researchers also tested 119 OAuth-enabled servers. Every tested server carried at least one authentication flaw, and 96.6% had a flaw tied to dynamic client registration. The study identified 325 flaws and produced nine CVE identifiers.

MCP is not insecure by design. The protocol does not create a full production security posture on its own. The official MCP authorization specification states that authorization is optional, and it focuses mainly on transport-level access for HTTP connections. Production teams still have to secure individual tool calls, credentials, arguments, target resources, server processes, and audit records.

A production MCP deployment should meet five requirements:

• Authenticate every remote connection.
• Authorize every sensitive tool invocation, with attention to arguments and target resources.
• Use short-lived, narrowly scoped credentials.
• Harden MCP server processes through isolation, input validation, and dependency integrity.
• Record every allow-or-deny decision.

The rest of this guide explains how to implement these controls and how to verify that they keep working after deployment.

Five control areas production teams must own. The MCP protocol covers transport access. Everything else requires deliberate implementation.

What MCP Covers and What Production Teams Must Secure

MCP standardizes how clients discover capabilities and invoke tools. Its current authorization profile covers HTTP transport access, token handling, server discovery, and OAuth integration. The specification also states that authorization is optional and that Standard Input/Output (STDIO) deployments should not use the HTTP authorization flow. Production teams therefore build their own controls around the protocol, and those controls extend past basic protocol compliance.

A 2026 NIST NCCoE concept paper, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," treats identification, authentication, authorization, delegation, logging, and dataflow tracking as separate control areas. That is the right production model, because no single protocol feature covers them all. The operator owns five domains: authentication, tool-level authorization, credential controls, server and input hardening, and audit logging.

Authentication: Proving Who Is Connecting

A remote MCP server should not trust a connection just because the client can reach its endpoint. For protected HTTP deployments, the current MCP authorization specification uses OAuth 2.1 as the baseline. It also requires protected resource discovery, token validation, and audience binding.

In practice, this takes more than an OAuth login screen. The client should use Proof Key for Code Exchange (PKCE) during the authorization flow. The server should be reachable only over HTTPS. The client must discover the correct authorization server from trusted metadata, and the MCP server must then confirm that the token was issued for that specific server.

Consider one example. An agent connects to one MCP server for source-code access and another for project management. Both servers use the same identity provider. A token issued for the project-management server may still carry a valid signature. The source-code server must reject it, because it was created for a different audience. This check limits the damage from a leaked token or a configuration mistake. RFC 8707 defines the resource parameter that tells the authorization server where the token will be used. The MCP profile requires clients to include this resource in authorization and token requests, and it requires MCP servers to reject tokens intended for another resource.

Several OAuth standards support this flow:

• RFC 9728 helps the client discover the authorization server linked to a protected MCP resource.
• RFC 8707 binds the token request to the intended MCP server.
• RFC 9207 helps the client verify the authorization server and prevent mix-up attacks.
• PKCE protects authorization codes from interception and reuse.
• RFC 7591 defines dynamic client registration.

These controls solve different problems. Resource metadata tells the client where to authenticate. Issuer validation confirms which authorization server answered. Audience validation confirms where the token may be used. PKCE protects the authorization code before it becomes a token.

Client registration also needs careful handling. The current MCP draft prefers Client ID Metadata Documents or pre-registration. Dynamic client registration remains available for compatibility, but the profile now marks it as deprecated. There is a practical reason for this change. A 2026 study of remote MCP authentication tested 119 OAuth-enabled servers. The researchers found dynamic-client-registration flaws in 96.6% of the tested group. This figure should not be treated as the failure rate for every MCP server. However, it shows why open and automatic client registration needs stronger controls.

STDIO deployments need a different approach. The MCP OAuth flow is designed for HTTP transport and should not be applied to local STDIO connections. A local MCP server should instead run as a restricted workload. Give each STDIO server its own process identity. Limit its filesystem and network access. Provide only the environment variables it needs. Store its secrets separately from the user's desktop session.

Common authentication failures include:

• Assuming that a reachable server is an authenticated server.
• Checking a token's signature but not its audience.
• Reusing one OAuth client identity across unrelated agents.
• Accepting authorization responses from an unverified issuer.
• Saving refresh tokens in logs or configuration files.
• Giving a local STDIO server the full desktop-user environment.

Authentication answers one question: who is connecting? It leaves the harder question open. Should this identity be allowed to run this tool, with these arguments, against this resource? That decision belongs to the authorization layer.

Four OAuth controls work together in a production MCP authentication flow. Each one closes a different gap. None of them, alone, is sufficient.

Authorization: Governing What Each Tool Call Can Do

Authentication proves who connected. Authorization decides what that identity may do next.

Start with default deny. At tools/list, show each agent only the tools relevant to its task. Then evaluate every tool invocation again before execution. Discovery filtering reduces exposure, but it cannot replace an execution-time decision.

The policy should inspect the agent and initiating user, the tool and requested action, the actual arguments, the target repository, table, tenant, or endpoint, the task and environment, and whether the action is read, write, or destructive.

Allowing update_issue, for example, is too broad. A better rule may let one support agent update labels in a test repository while blocking changes to issue content in production repositories. Read-only tools also need controls. A read call can expose source code, customer records, system logs, or secrets.

Multi-agent workflows take extra care. When one agent delegates to another, the second agent should not inherit the first agent's full permission set. Each hop should narrow the scope to what the delegated action requires.

Role-Based Access Control (RBAC) can handle stable roles. Attribute-Based Access Control (ABAC) adds attributes such as resource, environment, and ownership. Policy-Based Access Control (PBAC) can include task purpose or agent function. Teams may implement these rules through OPA, Cedar, or an existing policy service. What matters is that the policy runs for every invocation.

RFC 9396 provides a standard structure for richer authorization details, including actions and resource locations. MCP does not automatically turn those details into tool-level policy.

OWASP identifies scope creep and insufficient authorization as major MCP security risks. For the distinction between server access and tool access, see AgntID's guide to MCP's missing authorization layer.

Tool-call authorization requires evaluating six dimensions. Checking only the agent identity and tool name is not enough.

Credentials: Short-Lived, Vault-Injected, Never Hardcoded

An MCP server should not carry one permanent credential for every agent and action.

Keep secrets out of source code, container images, manifests, prompts, and tool descriptions. Store them in a managed vault, such as HashiCorp Vault or a cloud secret manager. The runtime should retrieve the credential only after the tool call is approved.

The credential should also match the action. An agent reading one repository should not receive a token that can modify every repository in the organization. A task that lasts five minutes should not depend on a token that stays active for months.

Rotate credentials regularly and revoke them when an agent, server, owner, or policy changes. Test the revocation process before an incident, not during one.

MCP servers must also avoid token passthrough. A client token meant for the MCP server should not be forwarded unchanged to a downstream service. The server should use a separate credential with the minimum required scope. The MCP specification requires servers to accept tokens issued for their own resource and to not transit unrelated tokens.

OWASP lists hardcoded secrets and long-lived tokens under token mismanagement. For more on this risk, see AgntID's guide to AI-agent credential anti-patterns.

Tool and MCP Server Security: Hardening the Execution Path

Secure credentials cannot protect a server that executes unsafe input. Production teams should harden four areas.

Server-side schema and semantic validation

Apply strict JSON Schema validation on the server. Reject unknown properties, invalid types, oversized values, and malformed input.

Schema checks are only the first layer. Validate meaning as well. A file path may match the schema and still escape the approved directory. An API request may be valid JSON and still reference an unauthorized target endpoint.

For example, a repository tool should confirm that the named repository belongs to the approved organization. It should not trust a syntactically valid repository name on its own.

Runtime and process isolation

Run each MCP server in a container or sandbox. Use a non-root identity. Restrict filesystem access, network egress, environment variables, and system calls.

A local STDIO server should not automatically inherit the desktop user's SSH keys, browser data, cloud credentials, and entire home directory. Give it access only to the files and services its tools require.

Tool description and dependency integrity

Record a hash of each approved tool name, description, and input schema. Check it again after reconnection or catalog refresh. Unexpected changes may indicate tool poisoning or a rug-pull update.

Pin package versions and container digests. Verify checksums or signatures. Scan dependencies before deployment. The OWASP MCP Security Cheat Sheet recommends integrity checks, dependency scanning, isolation, and monitoring for changes to tool descriptions.

One real example is CVE-2025-6514. A flaw in mcp-remote let crafted authorization-endpoint data from an untrusted MCP server reach an operating-system command path. The advisory rated it critical at 9.6 and named version 0.1.16 as the patched release.

Approval or step-up controls for destructive actions

Destructive tools should not run like ordinary read calls. Require human approval or step-up authorization for production deployments, record deletion, permission changes, financial actions, and large exports.

The approval screen should show the exact tool, arguments, resource, and expected effect. Approval should apply to that action only, and should not create a permanent elevated session.

Audit Logging: Immutable, Identity-Bound, SIEM-Ready

A log that says delete_file: 200 OK is not enough.

Each tool-call record should include the initiating user or workload, agent and task identity, MCP server and tool name, arguments or a redacted digest, target resource, policy version and decision, credential reference, timestamp and execution result, and trace ID.

Keep a record of both permitted and rejected calls. Do not store raw passwords, access tokens, or sensitive personal data.

OWASP recommends logging MCP tool calls with parameters, user context, and timestamps. It also recommends sending those logs to a Security Information and Event Management (SIEM) platform and alerting on new tools, unusual call volume, and admin actions.

For higher-assurance environments, add hash-based tamper evidence and use immutable or Write Once Read Many (WORM) storage. Retention should reflect legal duties, contracts, data classification, and incident-response needs.

Server logs stay useful, but they often show only what executed. They may not show why the action was permitted or which policy applied. That execution-time distinction is covered in AgntID's article on security observability inside the enforcement layer.

A complete audit record requires ten fields. A log that captures only the tool name and result cannot support incident investigation or compliance review.

How AgntID Addresses the Execution-Time Gap

OAuth can establish a valid connection. Identity and Access Management (IAM) can establish identity and broad entitlement. A vault can protect secrets. A SIEM can collect events. None of those systems decides whether one specific tool call should run with its current arguments.

AgntID operates at that point. Its customer-hosted runtime intercepts MCP tool calls, evaluates policy, resolves a scoped credential, and allows or denies the action before execution. It then records the decision and execution context. For example, an authenticated deployment agent may be allowed to read production status but blocked from starting a deployment during a change freeze. The identity stays valid. The specific action does not.

AgntID does not replace OAuth, IAM, secret managers, SIEM platforms, MCP servers, or dependency scanners. It connects those controls to the moment when an agent turns intent into an external action.

Request access at agntid.ai

FAQ