Before You Connect an MCP Server to Production

The decision: connect only after six gates pass

Approve a production MCP connection only when the team can name its owner, enumerate the exposed tools and data, bind credentials to the intended server, contain the process and network path, stop consequential actions, and reconstruct an incident. If any one of those controls is missing, keep the integration disconnected or in a read-only sandbox.

This is an AccessAllGPT decision framework, not a requirement of the protocol. MCP defines interoperable messages and capabilities. The production safety boundary is the configured system around it: client, server, authorization service, upstream APIs, model, user interface and runtime.

Evidence boundary: requirements are not the whole review

Verified protocol requirements provide a floor, not a production approval. The authorization specification says clients MUST implement RFC 8707 resource indicators, include the resource parameter in authorization and token requests, and identify the intended MCP server. It says servers MUST validate that the token was issued for them, while clients MUST NOT send tokens to an MCP server other than those issued by that server’s authorization server. The tools specification says servers MUST validate inputs, enforce access controls, rate-limit calls and sanitize outputs; clients MUST treat annotations as untrusted unless the server is trusted.

Other controls have different evidence status. The tools specification says a human SHOULD be able to deny calls and explicitly does not mandate one interface pattern. The six gates, fixed allowlist, approval payload, logging fields, staged rollout and stop conditions below are AccessAllGPT implementation guidance. They are recommendations derived from the documented attack paths and OAuth controls, not MCP conformance requirements or findings from testing a client or server.

Gate 1: draw the authority path

Document the human principal, MCP client, MCP server, authorization server and every downstream service. For each hop, record which identity is presented, which data crosses the boundary, where credentials are stored and whether the component can read, write, delete, publish, pay or change permissions.

Separate local and remote servers in the review. A local server is executable code running with access derived from the client process; a remote server introduces HTTP, authorization discovery and network trust. A familiar tool name does not make either path low risk.

Gate 2: expose less than the server offers

Freeze an allowlist of tool names and input constraints for the first deployment. The MCP tools specification permits the available set to vary with authorization and supports notifications when that set changes. Treat a newly visible or materially changed tool as a configuration change that requires review, not as context the model may accept silently.

Keep discovery and read operations separate from mutation. Tool descriptions and annotations are server-supplied metadata, not an authorization control. Enforce policy in the client and server even when the model selects the call.

Gate 3: bind tokens to one intended server

For HTTP transports, implement the authorization specification rather than forwarding a user or upstream API token. The current specification requires clients to send the OAuth resource parameter in authorization and token requests, and requires servers to validate that access tokens were issued for them as the intended audience.

Reject token passthrough. MCP security guidance identifies it as an anti-pattern, and the authorization specification says servers must not accept or transit tokens intended for other resources. Begin with narrow scopes, elevate only for the requested operation, and make revocation possible without disabling unrelated integrations.

Gate 4: put approval at the consequence boundary

The tools specification says a human should be able to deny tool invocations and recommends showing exposed tools, invocation indicators and confirmation prompts. For sensitive calls, show the destination, tool name, material inputs, affected records, requested scope and expected side effect before execution.

Do not use approval as the only defense. A prompt can be misunderstood, rushed or manipulated by untrusted content. Back it with server-side access control, input validation, rate limits, timeouts and policy that the model cannot modify. Allow low-risk reads to proceed only when data classification and tenant isolation support that choice.

Gate 5: contain local code and remote discovery

For a local server, show the complete startup command before installation, require explicit consent and run with minimal filesystem, network and environment access. Prefer a sandboxed process and grant individual directories or destinations only when the task requires them. Do not expose shell history, SSH material, cloud credentials or unrelated project files by default.

For a remote server, validate OAuth metadata and redirect destinations before fetching them. MCP security guidance describes server-side request forgery through attacker-controlled discovery URLs and recommends HTTPS in production, controls for private and reserved addresses, redirect validation and network policy or an egress proxy. Apply controls at request time as well as during initial validation.

Gate 6: make every call attributable and stoppable

Log the user or workload identity, client and server versions, granted scopes, discovered tool-set version, selected tool, validated inputs, approval decision, outcome and policy denial. Redact secrets and sensitive payloads according to the organization’s retention rules. Alert on new tools, repeated scope elevation, denied destinations, authorization failures and unusual call volume.

Test token expiry and revocation, server removal, credential rotation, a changed tool list, a denied high-impact call, timeout, malformed result and upstream outage. The rollback must work without cooperation from the model or the MCP server. A session identifier is not a substitute for authenticating each protected request.

Run a staged proof before production

Stage 0 reviews source, package provenance, architecture and requested authority. Stage 1 allows discovery with synthetic data. Stage 2 enables read-only access to a non-production tenant. Stage 3 permits a narrow production read path. A write tool should be a separate decision with its own approval, rollback and evidence window.

Predeclare tests and stop conditions. Record task completion, unauthorized attempts, approval quality, intervention, latency, errors and operator effort. Do not infer safety from a successful demonstration: this review produces a controlled deployment decision, not a benchmark score or proof that a server is free of vulnerabilities.

The go/no-go record

Record one of three outcomes: connect for the named read-only scope; run a time-bounded sandbox trial; or do not connect. A go decision must identify the accountable owner, allowed tools, denied operations, canonical server URI, token audience, scope ceiling, data boundary, runtime isolation, egress policy, approval gates, logging destination, kill switch and review date.

Choose “do not connect” when the server requires broad reusable credentials, cannot constrain or enumerate tools, forwards tokens, needs unrestricted host or network access, bypasses consequential approval, or cannot be disabled and audited independently. Convenience does not compensate for an unbounded authority path.

Disclosures

AccessAllGPT did not run or rank MCP clients or servers for this article. No vendor supplied data, paid for placement or received an endorsement. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenAI. Publication-wide relationships are listed on the disclosures page.