MCP security

Model Context Protocol (MCP) security protects the connections, credentials, capabilities, and data involved in an MCP deployment. It includes the host and server, the protocol messages between them, and the backend actions those messages can cause.

The MCP authorization specification defines an authorization framework for HTTP-based deployments. The OWASP MCP Security Cheat Sheet describes additional deployment risks. Following the protocol is one part of the review. The host, server, and backend also need their own security checks.

Explore Dome: Tool Gateway · Docs: Security tutorial.

Follow the credential across each hop

Suppose an employee uses an assistant connected to an MCP document server. The assistant presents an access token to that server. The server then uses a separate backend credential to retrieve a document.

The receiving service must validate the token intended for it. A token issued for another service should not be accepted as proof of access to this one. Nor should the server simply forward an incoming token to a backend without checking how that backend expects to be accessed.

If the document server uses a broadly privileged service credential to retrieve a file the employee cannot access, it can become a confused deputy: the caller is using the server's greater privileges. Check where the employee's document permissions are enforced.

Use authentication and authorization for token vocabulary and delegated authorization for actions performed on a user's behalf. Keep the connection map focused on where each credential is accepted.

Explore Dome: Access · Docs: Govern per end user.

Remote services and local processes need different checks

For a remote server, examine endpoint identity, transport protection, authorization configuration, and any URLs used for discovery or outbound requests. An attacker who controls a discovery URL may cause the application to send a request to an unintended destination before any tool is called.

A local server runs code on the host machine. Check where the package came from and which files, environment variables, and network destinations it can access. A local transport does not automatically isolate the process from the user's files or secrets.

For both forms, review the tool definitions and track changes. A description can influence model behavior before the tool executes. Tool poisoning explains how a tool definition can redirect the model.

Record the reviewed version or configuration. Approval of a server name without a specific deployment leaves the team unsure what was actually examined.

Explore Dome: Tool Gateway · Docs: Tools gateway.

Test tool calls, not just the list of available tools

A practical review should include three distinct tests with synthetic records:

1. A valid caller performs an allowed operation.
2. The caller directly invokes a tool outside its permitted scope.
3. The caller requests an otherwise permitted operation on a document or record it is not allowed to access.

A tool outside the caller's permitted scope should be refused even when invoked by name. An allowed document tool should still check access to the particular file requested.

Dome's Tool Gateway documentation distinguishes discovery from invocation and describes configured authorization, credential injection, guards, and audit on that path. Backend ownership and state checks remain relevant when those facts are known only to the backend.

Save the refusal response and check backend records to confirm the forbidden operation did not run.

Explore Dome: Tool Gateway · Docs: Tools gateway.