Skip to content

alt text

MCP Best Practices

Introduction

The Model Context Protocol (MCP) is a way for AI systems to interact with tools and services exposed by software applications. It was introduced in 2024 by Anthropic as a way for allowing the Claude LLMs to connect to third-party systems, including the user's own computer. It is described as being a "USB-C port" for AI applications, providing a standardized means of interaction 1.

Security

For the best security, it is good to run local MCP servers from within containerized applications. Remote MCP servers should be authenticated to via OAuth 2.1. All MCP servers should have been reviewed by the AI/ML developer team and approved for use. Some MCP servers will be available from pre-built agents deployed to Teams, Copilot 365, or Microsoft Foundry. In all cases, tool use should be treated with the care that it deserves, as it takes a simple, loosely defined request in natural language from a user and attempts to create a complex, structured API query.

Architecture Diagram

Below is an architecture diagram that shows the preferred style of connecting and running local, containerized MCP servers.

flowchart LR
    User[User]

    subgraph LocalEnv["Local Environment"]
        FileSystem[File System]
        LocalTools[Local Tools]
        subgraph MCPHost[MCP Host]
            MCPClient[MCP Client]
        end

        subgraph Docker["Docker Container"]
            MCPServer["3rd Party MCP Server"]
        end

        MCPClient --> FileSystem
        MCPServer --> LocalTools
    end

    User --> MCPClient
    MCPClient --> MCPServer
    GitHub["3rd Party GitHub Repo"]
    Remote["Remote APIs and Tools"]

    MCPServer --> Remote
    GitHub -.-> MCPServer

Risks

Most MCP-related risks boil down to:

  1. Lack of user consent/authorization
  2. Lack of integrity checks (tools, prompts, messages…)
  3. Lack of isolation (file system, network, other MCP servers…)

The OWASP MCP Security Cheat Sheet2 provides the following as potential pitfalls:

  • Tool Poisoning: Nefarious behavior hidden a tool's instructions that can corrupt LLM responses
  • Rug Pull Attacks: When a remote MCP server changes what a tool does after a user approves its usage
  • Tool Shadowing / Cross-Origin Escalation: When an MCP server attempts to override a tool defined by another MCP server
  • Confused Deputy Problem: The server calls a tool using higher-level permissions than a user actually possesses
  • Data Exfiltration via Legitimate Channels: Tool calls are used to smuggle out enterprise data
  • Excessive Permissions / Over-Scoped Tokens: A high-level permissioned tool is preferred over a lower-level permissioned tool (e.g. update vs. read)
  • Supply Chain Attacks: MCP servers are installed without a review process, which causes problems when they later become compromised
  • Message Tampering and Replay: Tool messages are modified or repeated intentionally to cause overload
  • Sandbox Escapes: MCP servers hosted locally are given excessive permissions, enabling them to modify the system in which they are hosted outside of their sandbox

MITRE has cataloged additional LLM-related risks in a matrix called ATLAS3, which can be used as a reference.

Mitigations

  1. Always read the MCP source code to start! Never run local MCP servers without first reading the code to learn what it does. You can use tools such as Snyk to scan the codebase first as well.
  2. Never connect to unvetted remote MCP servers. The AI/ML team maintains a list of approved MCP servers that have gone through a review process. If the server has not been reviewed, DO NOT connect to it. If you are not sure whether an MCP server is approved, reach out to a developer first.
  3. Always use OAuth access tokens instead of Personal Access Tokens (PATs) or API keys. PATs are insecure and do not have an automatic expiration date, which is dangerous in case they are ever leaked. MCP supports OAuth 2.1, passing along user credentials to enable stronger security through token-based authentication and role-based access control. This mostly impacts remote MCP servers as local MCP servers are more likely to rely on API keys stored within environment variables.
  4. Apply rule of least-permissions to accessible tools. Users should not be given to all tools offered by an MCP server unless absolutely necessary. All tools should be reviewed to avoid giving access to tools that perform dangerous tasks automatically (creates, updates, deletes).
  5. Containerize local servers before running them. In line with the principle of least-permissions, local MCP servers should not be given access to the full file system and network. Containerizing the server will keep tools accessible, but prevent permanent breaking changes to the local environment.
  6. Avoid connecting multiple MCP servers simultaneously. This creates confusion in agents that must choose between similarly-named tools, which could cause data leakage if data intended for one tool is sent to another. In addition, as the number of tools grows, the amount of problem context that can be held by the agent diminishes as it is instead taken up by tool descriptions.
  7. Monitor and log all tool calls. For local MCP servers, all calls to tools should be reviewed carefully to ensure dangerous actions aren't being undertaken by the agent. Avoid automatically approving all calls without first reviewing the tool inputs and reasons for invocation.

  1. https://modelcontextprotocol.io/docs ↩

  2. https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html#key-risks ↩

  3. https://atlas.mitre.org/matrices/ATLAS ↩