Introduction

Model Context Protocol, or MCP, defines a structured way for an AI application to connect to external capabilities and data. The central pieces are the host application, an MCP client, and one or more MCP servers. The host is the product the user interacts with, such as an IDE or an assistant application. It normally creates a separate client connection for each server so that protocol state, capabilities, and failures remain associated with the correct server.

An MCP server exposes capabilities through protocol operations. Tools are executable operations that may query a service, modify a record, send a message, or perform another side effect. Resources represent data that a client can retrieve, while prompts provide reusable prompt templates or interaction patterns. These categories are useful architecturally, but none of them should be treated as trusted merely because it came through MCP. Production security depends on who owns each component, what data crosses each connection, and what authority an operation can exercise.

Request Flow and Component Roles

A typical interaction begins when the host establishes a session with an MCP server through a supported transport. The client and server initialize their protocol session and communicate supported capabilities. The host can then discover available tools, resources, or prompts and decide how those capabilities should appear in the user experience or model context. The exact transport may differ between local and remote deployments, but the trust questions remain the same.

When a model proposes a tool call, the host or client is responsible for applying the product's interaction and authorization policy before forwarding the request. The server validates the request again and performs the operation using its own credentials and runtime permissions. The result travels back through the server and client to the host, where it may be shown to the user or added to model context. This repeated validation is intentional: a client-side policy reduces unsafe requests, while server-side validation protects the server when another client or a malformed message reaches it.

A resource read follows a related path but has a different risk profile. The server resolves the requested resource and returns content or metadata. Read-only does not mean harmless: a resource may contain confidential information, malicious instructions, personal data, or content that is stale. The host must preserve provenance and apply access controls before presenting or using the content.

Trust Boundaries in Development

The first boundary is between the user and the host application. The host receives natural-language requests, tool results, resource content, and possibly instructions from external systems. A production host should not assume that every instruction inside retrieved content represents the user's intent. It needs clear rules for confirmation, especially when an action changes data, contacts a third party, spends money, or exposes secrets.

The second boundary is between the host's MCP client and the server. A server may be a local process installed from a package, a separately managed internal service, or a remote service operated by another team. These deployment choices change the authentication, isolation, and update model. A local process can still read files, inherit environment variables, access network destinations, or execute vulnerable dependencies. A remote server can still receive sensitive arguments and return content that influences the model.

The third boundary is between the MCP server and its downstream systems. The server may call a database, cloud API, filesystem, ticketing system, or shell command. MCP authentication does not automatically authorize those downstream actions. The server should use narrowly scoped service identities, explicit destination controls, timeouts, rate limits, and operation-specific authorization. A server that can issue unrestricted administrative requests is a high-impact component even if its MCP interface exposes only a few tools.

Production Identity and Authorization

Authentication answers who is connecting; authorization answers what that identity may do. In a production deployment, identify the host or user context and the MCP server separately where possible. Avoid one shared credential for every client and server. Separate identities improve revocation, incident investigation, rate limiting, and least-privilege enforcement. Remote deployments also need secure transport and a defined method for handling credentials; credentials should not be placed in tool arguments or returned in tool results.

Capability negotiation is useful for compatibility, but it is not an authorization decision. A server announcing that it supports tools does not mean a particular user may invoke every tool. Authorization should be evaluated for the requested operation, target, tenant, and data classification. For example, a user may be allowed to read a project resource but not delete the project, even when both capabilities are exposed by the same server.

Tool schemas help constrain inputs, but a schema is not a complete security policy. The server should validate types, ranges, lengths, identifiers, and relationships between fields. It should reject unexpected destinations, unsafe file paths, invalid tenant references, and requests that exceed the caller's scope. For high-impact actions, the host may require explicit user approval and display the target, intended effect, and important parameters before execution. Approval should be bound to the specific action rather than treated as permanent permission.

Operational Controls and Failure Handling

Production operation requires visibility across the full request path. Record which identity initiated a request, which server handled it, which tool or resource was selected, the authorization result, and the downstream outcome. Redact secrets and unnecessary personal data. Correlate client, server, and downstream logs with a request identifier, while recognizing that logs themselves become sensitive assets requiring access control and retention rules.

Design for partial failure. A server can be unavailable, a downstream API can time out, a response can exceed size limits, or a tool can return an error after creating a side effect. The host should communicate uncertainty clearly and should not automatically retry non-idempotent operations without a defined policy. Servers should use bounded timeouts, controlled concurrency, response-size limits, and predictable error handling. Circuit breakers or rate limits may be appropriate for expensive or fragile dependencies.

Treat updates and configuration as part of the trust model. Pin or review server versions, verify the source and integrity of deployment artifacts, manage secrets outside source code, and limit the environment inherited by local processes. Test tool behavior with malformed input, unauthorized targets, oversized results, prompt injection in resources, and downstream failures. Security review should examine the effective permissions of the runtime, not only the names and descriptions exposed by the MCP server.

Common Mistakes and Practical Review

A frequent mistake is trusting tool descriptions as if they were a security contract. Descriptions are useful for discovery, but a compromised or poorly maintained server can describe a dangerous operation in harmless language. Review the implementation, identity permissions, network destinations, data flows, and approval behavior. The same caution applies to prompt templates and resource metadata: they can shape model behavior but do not establish authority.

Another mistake is treating a local development setup as a production trust model. Developers often run a server with broad filesystem access, personal credentials, unrestricted outbound network access, and verbose logs. Production should replace those defaults with a dedicated runtime identity, a restricted working directory, minimized environment variables, explicit egress rules, and controlled data handling. Test the deployment using the permissions that production will actually grant.

During a review, trace one representative read operation and one representative write operation from user request to downstream effect. For each step, identify the identity, input validation, data classification, approval requirement, timeout, audit event, and failure behavior. If any step cannot be explained precisely, the boundary is not yet operationally defined. This method produces concrete remediation work instead of relying on a general statement that the MCP server is trusted.

Summary

MCP separates the host experience from server-provided capabilities, but it does not erase the security boundaries between them. The host manages user interaction and client sessions; the server validates requests and implements tools, resources, and prompts; downstream systems remain separate authorities with their own permissions and failure modes.

For production, focus on explicit identity, least privilege, server-side validation, user approval for consequential actions, careful treatment of retrieved content, bounded execution, and useful audit trails. Capability negotiation supports interoperability, while authorization decides what may actually happen. The practical goal is not to trust or distrust MCP as a single unit, but to document every boundary and apply controls appropriate to the data and authority crossing it.