MCP Server Security Guide: Build, Deploy, and Verify Controls

An MCP server is exposed wherever a client can discover a tool, invoke it with arguments, and reach a downstream system. This guide focuses on the controls that keep the server from turning client or metadata trust into an unauthorized effect.

For an MCP server, the evidence should bind one client identity and one declared tool to the downstream call it is allowed to make. A successful request to the wrong tenant is a failure even when token validation succeeded.

Use MCP protocol architecture to separate what the client discovers from what the server authorizes at execution time.

Classify the server and its trust boundary

Decide whether the server is local stdio or remote, then map the client, server identity, transport, tools, and downstream services. For a remote deployment, record the token issuer, intended resource, accepted audience, transport termination point, and identity handed to the downstream API. Test the same tool through every enabled transport; a secure HTTP path does not compensate for a stale or unauthenticated alternate endpoint.

The design names where authentication, authorization, and network policy are enforced. Stop when a remote endpoint relies on a local-process trust assumption or the downstream identity is unknown.

Design tools as narrow capabilities

Use explicit schemas, short descriptions, least-privilege arguments, and separate read from write operations. Reject free-form destinations for consequential actions.

Invalid fields, cross-tenant identifiers, and unexpected effects are rejected before the downstream call. Disable a tool whose schema cannot express the policy boundary it needs.

Do not hide the server's downstream credential in a tool description or prompt template. agent credential leak controls matter when OAuth tokens, API keys, or service-account material cross the client-server boundary.

Authenticate and authorize the actual caller

For remote servers, validate credentials at the resource server and bind scopes to individual tool actions. Do not let a shared backend identity erase the caller context.

A token for one resource or scope cannot discover or run another tool. Fail closed when token validation, identity propagation, or policy lookup fails.

Treat tool metadata and responses as untrusted

Review descriptions, resource templates, prompts, and server output for instruction injection. Preserve a distinction between content and authority.

A malicious tool response cannot change the client policy or introduce a hidden write action. Remove the server from the approved catalog if a metadata review or integrity check fails.

Test bypasses and preserve evidence

Run tests for malformed arguments, missing scope, poisoned metadata, alternate transport, stale discovery, and direct backend access.

Every denied test has an audit record and no downstream state change. Roll back to the last approved server version and repeat the high-impact cases before re-enabling it.

Keep the server-owned denial and backend outcome as the primary proof. On a supported integration, a selected Runtime Guard decision may join the trace only after server-side identity and argument checks. Confirm that checkpoint in AgentGuard documentation.

That observation does not authenticate the client, issue scopes, propagate identity, or authorize the downstream API. A missing observation is not evidence that the alternate transport or direct-backend bypass was denied.

Retain the denied call and backend outcome

Retain the malformed call, missing-scope case, poisoned tool metadata case, and final backend audit entry. Together they demonstrate that the server blocks both bad credentials and bad instructions.

Use MCP authorization specification and OWASP MCP Top 10 to refine server and identity requirements, then prove them with a client request that reaches the intended downstream authorization boundary.