MCP security best practices start with a clear boundary: connecting a tool must not give an AI application more authority than its user or task requires. The Model Context Protocol provides an integration interface. Your application still needs to decide who may use each operation and which records they may access.
This guide covers a production review of remote and local MCP integrations. First, map the authority behind a tool. Then check authorization, untrusted content and failure behavior. A small project-document example shows how to turn those concerns into concrete acceptance checks.
Start MCP security best practices with a versioned inventory
Record the protocol version, SDK version, transport, server owner and exposed tools for each connection. Also identify the downstream systems it can reach. An integration that reads documentation has a different impact from one that changes customer records.
Version matters. The July 2026 MCP specification announcement describes a stateless core and the removal of protocol-level sessions. Earlier implementations can still have different lifecycle behavior. Therefore, review your deployed version rather than combining instructions from several releases.
Keep an owner and an update route alongside the inventory. If a tool description or dependency changes, the responsible person should know which workflows need another check.
Separate tool discovery from permission to act
A tool appearing in a catalog does not establish permission to run it. Check the authenticated caller, permitted operation and target resource on the server. Also apply the application’s task boundary before dispatching an action.
For example, a project-search tool should return only projects the caller may read. A separate project-update tool needs its own write check. Do not rely on the model to infer these boundaries from a description.
Prefer narrow operations with explicit inputs. A tool that updates one permitted field is easier to constrain than a general command runner. However, a narrow name is not enough: inspect what the implementation actually does.
Apply MCP security best practices to authorization
For remote HTTP authorization, use the requirements for your supported MCP version. The current authorization security specification requires servers to verify that access tokens were issued for them. It also requires PKCE support checks for clients using the authorization code flow.
Keep downstream credentials separate. Forwarding an incoming MCP access token unchanged to an upstream API breaks the intended audience boundary. Instead, use the appropriate authorization flow for that upstream service.
Then test the negative cases. An expired token, the wrong audience or insufficient permission should stop the operation before it reads or changes protected data. Also confirm that error responses do not disclose credentials.
Treat tool results as untrusted content
A tool result can contain customer text, repository comments or material from a website. That content can include instructions aimed at the model. Therefore, distinguish retrieved information from the user’s authorized task.
The OWASP prompt injection prevention guide describes indirect instructions in external content and recommends layered defenses. Input handling and model guidance help, but server-side access controls must still limit the actions a manipulated model can request.
For instance, a document asking the assistant to export every project should not expand a request to summarize one file. Test that the application keeps the original scope and that the server independently rejects unrelated access.
Constrain network access and local execution
Remote authorization can involve fetching metadata URLs. Validate destinations and redirects, and apply outbound network restrictions appropriate to your environment. Otherwise, discovery may become a route to internal services the caller should never reach.
Local servers need a different review. They run code with the permissions of their process. Pin trusted packages, limit filesystem and environment access, and isolate execution when practical. Also keep credentials out of model-visible responses and logs.
The official MCP security best practices documentation covers these network and local-server risks. It also explains why an application state handle must not become a substitute for authentication. Bind access to the verified caller on every request.
A worked example: one project document
Consider a hypothetical support assistant. A user asks it to summarize a document in Project A. The tool accepts a document identifier, checks the caller’s project access and returns the permitted text. Another customer’s Project B exists in the same service.
Begin with synthetic users and documents. Give one fixture access to Project A only. Then run the following checks against the actual tool path:
- A permitted Project A document returns its expected text.
- A Project B identifier returns no protected content.
- An instruction embedded in the document cannot authorize a write.
- A guessed workflow handle cannot retrieve another caller’s result.
- A revoked or expired credential fails without changing stored data.
Next, inspect what the assistant sends to other tools. Even a permitted document should not be copied into an unrelated external search query. As a result, the review covers both access to the source and the destination of the information.
Record the expected result and observed result for each case. A successful connection test proves connectivity; it does not establish these access boundaries.
Make failures observable and recoverable
Log the tool name, verified actor, target reference, outcome and a correlation identifier where appropriate. Avoid retaining full prompts or document bodies by default. Then define who can inspect the logs and how long to keep them.
Also plan for uncertain writes. If a timeout occurs after an update request, inspect the stored result before repeating it. Use idempotency controls where the downstream operation supports them. Finally, confirm that disconnecting an integration removes the access you intended to revoke.
Review MCP security best practices before rollout
Start with one useful workflow and test its denied actions as carefully as its successful ones. Keep the inventory current, review changes to tool capabilities and preserve a way to disable the specific integration if it misbehaves.
For development and integration work, explore Yasa’s implementation support. A diagram of the connected systems and one real task are useful starting points.
Define the boundary before connecting the tool
Planning an MCP integration? Tell Yasa which system it connects to, what it should do and whose data it may use. We can discuss a focused implementation and review plan.
