What to check before connecting an MCP server to production

Verification baseline: August 27, 2026

MCP stable specification reviewed: 2026-07-28

Connecting an MCP server to production is more than attaching another API to an LLM. Tools that read customer data, change files, send messages, modify permissions, or deploy systems make MCP an operational authorization path.

The question is therefore broader than whether MCP supports OAuth. Establish which user was authenticated and which server the token was issued for. Connect allowed tools and parameters, high-risk approvers, secret and tenant isolation, and revocation into one architecture.

MCP cannot be labeled inherently safe or dangerous. It standardizes communication and authorization flows between hosts, clients, and servers, but its specification acknowledges that protocol alone cannot enforce every security principle. Safety depends on host policies, server authorization, downstream credentials, and operating controls.

Changed assumptions in the latest MCP version

As of August 27, 2026, the latest stable revision is 2026-07-28. Its Modern Protocol is stateless, declaring version and capabilities per request. Mcp-Session-Id from earlier revisions is absent from current Streamable HTTP, and servers ignore that header if received.

This does not eliminate state-security concerns. Protocol sessions are gone, but cart and workflow handles, OAuth tokens, approval records, and downstream credentials remain. Official guidance requires that handle possession not count as authentication: bind handles server-side to verified users and expire them.

Distinguish OAuth versions too. MCP’s 2026-07-28 authorization document references OAuth 2.1 Draft-13, while the current IETF working draft is Draft-15. OAuth 2.1 is not yet a final RFC. Verify actual resource parameters, audience validation, PKCE, issuer validation, and HTTPS rather than relying on an OAuth 2.1 compatible label.^[6][7][8]

Do not collapse four identities into one

Production MCP involves at least four kinds of principal.

In the official architecture, a host manages multiple clients and controls connection permissions, security policies, and user consent. Each client has a one-to-one relationship with a server and maintains boundaries between servers. Protected MCP servers are OAuth resource servers; MCP clients are OAuth clients requesting on a user’s behalf.

Separate authentication from authorization.

Corporate-account login is an authentication result. Permission to read a tenant’s data or delete production records through a tool is a separate decision. Servers must not execute tools merely because login succeeded. Evaluate the verified principal, tenant, scope, tool, parameters, and target resource on every request.^[6][7]

MCP Production Trust Boundary Diagram

[Untrusted data: resources, prompts, tool results]

Untrusted data → LLM context → proposed action → policy + authorization + approval → actual tool execution only after passing

The LLM proposes actions in this structure; it does not grant permissions.

User or business principal

People, service accounts, and automation principals sign in and consent.

Identity Provider / Authorization Server

Authenticates users and issues tokens specifically for MCP Server A, with minimum scopes, short lifetimes, and step-up.

MCP Host / Client

Manages approved servers and per-user/role tool allowlists. Displays tools and parameters, approves high-risk actions, and separates credentials and context between servers.

Trust Boundary 1: Access token for MCP Server A

resource / audience = MCP Server A. The server validates issuer, audience, expiry, active state, and scope; binds principals and tenants server-side; authorizes tools and normalized parameters; and handles secret brokering, audit, and revocation.

Trust Boundary 2: Separate downstream credentials

Uses a separate downstream token or workload identity. Does not forward MCP client tokens.

Downstream API / Database / SaaS

Checks its own resource, scope, and tenant permissions and identifies the MCP server as a separate client.

Do not confuse token audience with scope

Scope describes what may be done. Audience or resource restricts where a token may be used.

A token with orders:write must not be accepted by every orders API and MCP server. It must be issued for a particular MCP server and valid only there.

MCP authorization requires clients to include a resource parameter in both authorization and token requests, identifying the target server’s canonical URI. Servers must validate that they are the intended audience and must neither accept nor forward tokens issued for other resources.

Operations should answer three questions.

Which resource does the authorization server use when issuing tokens?

How does the MCP server validate audience?

Is the same token reliably rejected by another MCP server or downstream API?

Verify the final question with negative tests, not documentation alone.

Token passthrough is not a proxy shortcut

Token passthrough occurs when an MCP server forwards its client’s access token unchanged to a downstream API. Current MCP authorization and security best practices explicitly prohibit it.

Passthrough ignores the original audience and makes actual call paths and client identities harder to distinguish downstream. Logs may appear to show another principal calling directly rather than the MCP server. Reusing one token across resources also expands compromise impact.

Separate the credentials into two independent paths.

MCP Client → MCP Server:

MCP-specific token; resource / audience = MCP Server

MCP Server → Downstream API:

Separately acquired downstream token; resource / audience = Downstream API

Even when users authorize third-party access, third-party credentials must not pass through the MCP client. Official elicitation specifications require direct user authorization of the MCP server, which stores and manages downstream tokens. The protocol core may be stateless, but external-integration credential stores still hold state.^[7][8]

Least privilege requires more than a scope

Creating read, write, and admin scopes does not complete least privilege. Production needs at least four gates.

Official guidance recommends progressive scopes: begin with limited rights and request the minimum additional scope when an action first needs it, rather than granting everything initially. Servers may return 403 with a precise scope challenge for insufficient scope.

Tool allowlists must vary by server and user

Do not automatically expose every tool from an MCP server to every user and agent.

Manage allowlists at least along these dimensions.

Approved MCP servers

Allowed tools by user, role, and tenant

Allowed tools by development, staging, and production environment

Action types, including reads, changes, deletion, and external transmission

Target resources and maximum work volume

Automatic execution or approval requirements

Tool names are not globally unique security identities. The specification limits name uniqueness to a server, while server names may also collide. Manage policy using trusted server identity plus tool ID, not merely delete_file or a display name.

JSON Schema validation and authorization are different operations

A tool’s inputSchema defines parameter structure and format. Passing it means the request has the correct shape, not that the caller may access the supplied values.

For example, even if these parameters satisfy the schema:

{ "tenant_id": "tenant-b", "record_id": "1234", "action": "delete" }

The server must reject a caller who does not belong to tenant-b.

Validate parameters in this order.

Validate format and required values

Normalize encoding, paths, and identifiers

Check allowed values and ranges

Check principal and tenant ownership of resources

Check business rules and current state

Assess bulk work, external transmission, and high-risk actions

Check approval conditions

Revalidate authorization immediately before execution

The tool specification also requires input validation, appropriate access controls, rate limits, and output sanitization. It recommends client confirmation for sensitive operations, input display before invocation, result validation before LLM context, and audit records.^[6][7]

Human approval does not replace authorization

A user pressing Confirm does not turn a prohibited operation into an authorized one.

Approval is an additional gate checking business impact and user intent after server-side authorization. Requests from unauthorized users must be rejected before an approval screen is shown.

Approval criteria by action risk

Bind high-risk approval records to these values.

MCP server

Tool

Normalized parameters

Tenant and environment

Expected impact

Approving user

Short expiry

Single execution or an explicit work scope

Do not reuse approval if the LLM changes parameters before another invocation.^[6]

Enforce a boundary between prompt injection and tool use

Prompt injection occurs when untrusted documents, emails, webpages, or tool results influence model decisions. Attackers can embed instructions to transmit content externally through another tool.

Separate the model’s proposal from the system’s authorization of the action.

Untrusted data

→ Model-proposed tool call

→ Tool allowlist → server-side authorization → parameter validation → human approval where needed → actual execution

Annotations cannot replace this boundary. Official MCP material explains that annotations do not provide prompt-injection resistance. An untrusted server can falsely declare readOnly, and annotations are not enforcement. Strong guarantees require host policy, server-side access control, network controls, and sandboxing. Model Context Protocol Blog

Block or require stronger approval for this combination.

Can read private data

Reads untrusted external content

Can transmit data to or modify external systems

Telling a model not to send sensitive content does not control this combination.

Secret boundaries must stay outside prompts

Do not put API keys, refresh tokens, database credentials, or signing keys in prompts, tool descriptions, or ordinary tool arguments.

Use these boundaries.

MCP clients hold only MCP-server-specific tokens

MCP servers retrieve downstream credentials from secret stores

Downstream credentials are bound to users, tenants, and integrations

Tools use credential references or server-side connections, not credentials themselves

Tokens and secrets are excluded from logs, errors, URLs, and tool results

Credential-access rights and tool-execution rights are managed separately

For third-party authorization, the MCP server stores and manages tokens without passing them to the client. Elicitation URLs must not contain credentials or personal information, and pre-authenticated URLs must not be passed.^[6]

Local stdio servers have a separate risk model

HTTP authorization is optional in the MCP specification, while stdio obtains credentials from its environment rather than following the same OAuth flow. This does not imply that local servers are trusted.

A local MCP server may run with the same user permissions as its client. Show the actual execution command before installation, restrict filesystem and network access, and use sandboxing and least privilege. Official guidance likewise requires exact commands, explicit approval, and file and network restrictions for one-click setup.^[7][8]

Do not derive tenants from model-supplied values

Trusting tenant_id directly from tool parameters is particularly dangerous in multitenant systems.

Derive the tenant from verified server-side evidence such as the following.

Authenticated user and tenant membership

Authorization grant

Server-side policy mapping

Connected downstream account

Workload identity and deployment environment

Tenant or project IDs in arguments only select targets. Servers must still verify caller access to those targets.

Apply the same rule to caches, state handles, downstream tokens, and approval records. Avoid global keys without user and tenant binding.

Bad state key:

workflow:1234

Recommended structure: tenant-a:user-42:workflow:1234

Modern MCP has no protocol session, but cross-request workflow handles can travel as ordinary arguments. Official guidance requires server-side binding to verified users and expiration, rather than treating handle possession as authentication.^[8]

Design credential lifetime and revocation together

Short token lifetimes reduce exposure but do not replace revocation. Conversely, a revocation endpoint cannot ensure immediate blocking if resource servers cache old authorization decisions too long.

MCP security considerations require short access tokens and refresh-token rotation for public clients. RFC 7009 defines a standard endpoint for revoking access and refresh tokens; RFC 7662 defines introspection of active, expired, or revoked state and authorization metadata.

When users leave, change tenants, disconnect integrations, or face security incidents, the following should be handled together.

Revoke the user-to-MCP grant

Invalidate MCP refresh and access tokens

Revoke downstream grants held by the MCP server

Remove tool and tenant policies

Invalidate state handles and unused approvals

Disable server connections or client registrations

Cancel ongoing high-risk work

Do not omit revocation paths because a token will expire soon.^[8]

Audit does not mean storing every prompt

Security audit has a different purpose from agent observability. Model latency, retrieval time, token use, and retry analysis belong to Topic 020. MCP security audit reconstructs authorization decisions and actual side effects.

Record at least these events and attributes.

Verified user or service principal

Tenant and environment

MCP server identity and authorization-server issuer

Protocol version

Tool ID and version

Redacted summaries or hashes of normalized parameters

Requested and actually granted scopes

Audience and token-validation results

Applied policy version

Allow, deny, or step-up decisions

Human approver, time, and scope

Downstream resource and action

Execution result and error

Credential, grant, and server revocation events

Changes to tool lists and permission settings

Exclude these values from ordinary audit logs or keep them in separately protected storage.

Raw access and refresh tokens

API keys and secrets

Complete prompts and completions

Complete sensitive tool results

Raw parameters containing personal information

Authenticated URLs or credential references

The tool specification recommends logging usage for audit, but a separate data-minimization policy must decide what is recorded.^[6]

Server trust is not determined by names or descriptions

MCP clientInfo is self-reported protocol data and must not drive security decisions. Annotations are untrusted unless supplied by trusted servers, and server names may collide globally.

A server trust record should include at least these items.

Operating and deployment owner

Exact remote endpoint or local package identity

Package version, digest, and signature

Authorization-server issuer

Allowed redirect URIs and client-registration method

Exposed tools, resources, and prompts

Filesystem, network, and downstream-access scope

Data storage, retention, and deletion policies

Update channel and automatic-update status

Security contacts and incident paths

Connection-disable and removal procedures

A changed tool list requires review of new tools and changes to existing permissions and risks, not merely a UI refresh.^[6]

Treat third-party MCP as a separate trust domain

Before connecting external servers, examine these questions rather than popularity.

Remote servers

Are the endpoint and operator identified?

Does the authorization-server issuer match expectations?

Are client credentials separate from other authorization servers?

Can metadata-discovery URLs be prevented from pointing at internal IPs, cloud metadata, or localhost?

Are tools and scopes limited to the actual purpose?

In which regions and systems is data stored?

Can changes to tools, permissions, and terms be detected?

Is there an immediate kill switch?

Clients must separate registration state, credentials, and tokens by authorization server. Malicious metadata discovery can create SSRF toward internal or cloud-metadata endpoints. Enforce HTTPS, block private and reserved IPs, revalidate redirects, and control egress.

Local servers

Have package sources and publishers been verified?

Have actual commands and arguments been reviewed?

Can automatic updates change what executes?

Is access to home directories, SSH keys, browser profiles, or environment variables required?

Is external network egress required?

Can execution use a sandbox or separate OS user?

Are credentials and state removed on uninstall?

A local server is code executing with user permissions, not merely an installation file. Discovery and convenient installation are not trust approval.^[8]

MCP Production Security Checklist

If any item cannot be answered clearly, first validate in a read-only sandbox or limited tenant rather than connecting all permissions at once.

Version and transport 1

The MCP revisions supported by production clients and servers are recorded.

Version and transport 2

The 2026-07-28 Modern Protocol is distinguished from legacy session-based revisions.

Version and transport 3

HTTP requests are checked for protocol version and mismatches are rejected.

Version and transport 4

Streamable HTTP servers validate Origin.

Version and transport 5

Local HTTP servers bind to localhost or restricted IPC by default.

Version and transport 6

The environment variables and OS permissions inherited by stdio servers have been checked.

Server trust 1

Allowed MCP endpoints or packages are managed through an allowlist.

Server trust 2

Display names and self-reported serverInfo are not used as security identities.

Server trust 3

Remote operators, domains, TLS, and authorization-server issuers have been verified.

Server trust 4

Exact local commands, package versions, and digests have been reviewed.

Server trust 5

Server or tool-list changes trigger reapproval or risk review.

Server trust 6

A kill switch can immediately block connections.

Authentication and authorization 1

An authentication boundary verifies users or service principals.

Authentication and authorization 2

MCP servers validate tokens on every request.

Authentication and authorization 3

User authentication and tool-execution authorization are separate.

Authentication and authorization 4

Principal, role, and tenant mappings are managed server-side.

Authentication and authorization 5

Insufficient authorization is rejected with distinct 401 and 403 handling.

Authentication and authorization 6

Connections start with limited rights and step up only for actions that require it.

Token audience and passthrough 1

Authorization and token requests include the MCP server’s resource.

Token audience and passthrough 2

Servers accept only tokens with themselves as intended audience.

Token audience and passthrough 3

Negative requests using tokens for other APIs or MCP servers fail.

Token audience and passthrough 4

Tokens are not passed in query strings or tool parameters.

Token audience and passthrough 5

MCP client tokens are not forwarded downstream.

Token audience and passthrough 6

Downstream APIs use separate tokens or workload identities.

Token audience and passthrough 7

Client credentials and token stores are separated by authorization server.

Tool and parameter policy 1

Tool allowlists exist per user, role, tenant, and environment.

Tool and parameter policy 2

Tools do not execute merely because the model selected them.

Tool and parameter policy 3

All tool inputs are checked against schemas and business rules.

Tool and parameter policy 4

Identifiers, paths, URLs, quantities, and dates are normalized before authorization.

Tool and parameter policy 5

Tenant and project IDs in arguments are not trusted directly.

Tool and parameter policy 6

Target resources are checked for membership in the caller’s tenant.

Tool and parameter policy 7

Separate limits cover bulk work, external transmission, and repeated calls.

Tool and parameter policy 8

Tool outputs are sanitized and validated before entering LLM context.

Tool and parameter policy 9

Annotations are used only as hints from trusted servers.

Human approval and high-impact actions 1

High-risk actions and their owners are defined.

Human approval and high-impact actions 2

Approval displays show tools, targets, parameters, and expected impact.

Human approval and high-impact actions 3

Server-side authorization completes before approval.

Human approval and high-impact actions 4

Approval is bound to exact tools, parameters, tenants, and environments.

Human approval and high-impact actions 5

Changed parameters require renewed approval.

Human approval and high-impact actions 6

Deletion, permission changes, production operations, payments, and bulk export require request-level approval.

Human approval and high-impact actions 7

Reauthentication, scope step-up, or dual approval applies where needed.

Human approval and high-impact actions 8

Automatically executable actions and human-approved actions are documented.

Prompt-injection boundary 1

Resources, prompts, and tool results are untrusted input by default.

Prompt-injection boundary 2

LLM tool calls are proposals, not execution commands.

Prompt-injection boundary 3

Instructions inside prompts cannot change tool allowlists or authorization policy.

Prompt-injection boundary 4

External transmission after reading private data requires stronger approval.

Prompt-injection boundary 5

Host, server, and network policies control exfiltration, rather than model instructions.

Prompt-injection boundary 6

Audit can identify execution paths that included untrusted content.

Secret and tenant isolation 1

Secrets are excluded from prompts, descriptions, URLs, and ordinary arguments.

Secret and tenant isolation 2

Downstream tokens are stored in protected MCP-server secret stores.

Secret and tenant isolation 3

Tokens are separated by user, tenant, and integration.

Secret and tenant isolation 4

One tenant cannot read another tenant’s cache, state, or credentials.

Secret and tenant isolation 5

State handles are not authentication mechanisms.

Secret and tenant isolation 6

Handles are bound to users and tenants and expire.

Secret and tenant isolation 7

Errors and audit logs contain no tokens or secrets.

Lifetime and revocation 1

Access tokens do not remain valid unnecessarily long.

Lifetime and revocation 2

Refresh tokens are stored confidentially and rotated where required.

Lifetime and revocation 3

User grants and downstream grants each have revocation paths.

Lifetime and revocation 4

Servers, tools, and client registrations can be disabled immediately.

Lifetime and revocation 5

Offboarding, tenant changes, and disconnection have automatic revocation procedures.

Lifetime and revocation 6

Authorization-cache duration does not exceed the revocation target.

Lifetime and revocation 7

State handles and unused approvals are invalidated together.

Lifetime and revocation 8

Ongoing high-risk work can be canceled or blocked.

Audit and incident response 1

Allow, deny, step-up, approval, and revocation decisions are recorded.

Audit and incident response 2

Records connect users, tenants, servers, tools, policy versions, and results.

Audit and incident response 3

Parameters are recorded with redaction or hashing.

Audit and incident response 4

Ordinary logs exclude raw tokens, secrets, and complete sensitive prompts.

Audit and incident response 5

Tool and scope change history is retained.

Audit and incident response 6

Abnormal volumes, repeated failures, and cross-tenant attempts are detected.

Audit and incident response 7

Runbooks identify grants and downstream connections to revoke after credential exposure.

Audit and incident response 8

Records support reconstruction of actual side effects after an incident.

Conditions for holding production connections

Hold production connectivity if any of these conditions exists.

The server does not validate token audience.

Client tokens are passed unchanged to downstream APIs.

All tools are exposed to every user.

Tenants are determined only from prompts or arguments.

High-risk actions execute automatically based solely on model decisions.

Secrets appear in prompts, arguments, or logs.

Third-party operators and execution permissions cannot be established.

No path exists to revoke credentials and connections.

Execution results cannot be linked to users, tenants, and approvals.

Test successful rejection, not only successful connection

Checking that a server connects and tools run does not complete even half of security verification.

Before production, verify that these requests reliably fail.

Tokens for another audience

Expired or revoked tokens

Tokens with insufficient scope

Disallowed tools

Another tenant’s resource IDs

Parameters changed after approval

Another user’s state handles

Disallowed downstream destinations

Disabled server and client credentials

The production criterion is not whether an agent can perform work.

Can the system prevent work using incorrect users, tokens, tools, parameters, tenants, and approvals, quickly revoke existing rights, and reconstruct the process through audit records?

With an answer to that question, MCP becomes a controllable operational authorization path as well as a connection mechanism.