AI Security · Learn

What is the Model Context Protocol (MCP)?

The Model Context Protocol is how AI agents reach the outside world: one standard way to discover tools, read data and take actions. That makes it the most important trust boundary in an agentic system, and the first place an attacker looks.

AI Security · LearnAI Agent Security Testing Download PDF
TL;DR

The Model Context Protocol (MCP) is an open standard that connects AI applications to external tools and data. An MCP host (the AI app) runs clients that connect to MCP servers over stdio for local servers or HTTP for remote ones, using JSON-RPC 2.0. Servers expose tools the model can call, resources it can read and prompt templates. Remote servers are protected with OAuth 2.1. Because tool descriptions and outputs flow straight into the model's context, every MCP server is a trust decision: attacks include tool poisoning, tool shadowing, token passthrough and confused deputy flaws.

By Rohit Hatagale, AI Security Lead, SecureLayer7Updated

What MCP is

Before MCP, every AI application wired up every integration by hand: one connector for the ticketing system, another for the code host, another for the wiki. MCP replaces that with a single protocol. An integration is written once as an MCP server, and any MCP-capable AI application can discover and use it.

The specification borrows its shape from the Language Server Protocol, which did the same for code editors. Three roles matter:

  • Host: the AI application the user works in, such as a chat app, an IDE or an agent runtime.
  • Client: a connector inside the host, one per server connection.
  • Server: a service that exposes capabilities, such as a code host, a database, a file system or a SaaS API.

Messages are JSON-RPC 2.0. Local servers usually run as a child process and talk over stdio; remote servers are reached over HTTP.

Tools, resources and prompts

A server offers up to three kinds of capability, each with a name, a description and a typed schema the client discovers when it connects:

  • Tools are functions the model can call: create an issue, run a query, send a message. The specification is explicit that tools represent arbitrary code execution and must be treated with caution.
  • Resources are data the model or user can read, such as files, records or documents.
  • Prompts are reusable message templates the user can invoke.

Clients can also offer features back to servers, such as elicitation, where a server asks the user for more information mid-task. The key security fact is simple: tool names, descriptions and outputs all become text in the model's context, and the model cannot reliably tell instruction from data.

Where MCP's trust boundaries sit

MCP deliberately leaves enforcement to implementations. The specification sets principles (user consent before data access, explicit approval before any tool runs, tool descriptions treated as untrusted unless the server is trusted) and states that the protocol itself cannot enforce them. That puts three boundaries in your hands:

  • Which servers the host connects to. Installing an MCP server is closer to installing software than to adding a bookmark. A local server runs with the user's privileges.
  • What the server is allowed to do downstream. For remote servers, the specification uses OAuth 2.1: the MCP server is an OAuth resource server, clients must request tokens bound to that specific server with RFC 8707 resource indicators, and servers must reject tokens issued for anyone else.
  • What the model is allowed to do with the tools. Least privilege, scoped tools and human approval for high-impact actions are host-side decisions. See excessive agency for what happens when that boundary is too wide.

Common attacks on MCP

  • [MCP tool poisoning](/learn/ai-security/mcp-tool-poisoning): a server hides instructions in a tool description, and the model obeys them.
  • [MCP tool shadowing](/learn/ai-security/mcp-tool-shadowing): one server's tool description changes how the agent uses a different, trusted server's tools.
  • Token passthrough: a server accepts tokens that were not issued for it and forwards them downstream. The specification forbids it because it breaks audit trails and lets a stolen token ride through the server.
  • Confused deputy: an MCP proxy using one static OAuth client ID can be tricked into handing an attacker an authorization code without fresh user consent.
  • SSRF during OAuth discovery: a malicious server points the client's metadata fetches at internal addresses or cloud metadata endpoints.
  • Local server compromise: a malicious install command or package runs with the user's full privileges.
  • [indirect prompt injection](/learn/ai-security/indirect-prompt-injection): data a tool returns (a web page, an email, a ticket) carries instructions the model follows.

How to use MCP safely

  • Allowlist servers. Keep a reviewed catalog of approved servers and versions; block ad hoc installs in production. Route remote servers through an an MCP gateway so authentication, policy and audit live in one place.
  • Pin and diff tool definitions. Re-approve when a server's tool descriptions change.
  • Scope everything. Request the smallest OAuth scopes, give each agent its own AI agent identity, and require approval for writes and destructive actions.
  • Isolate execution. Run local servers and code-executing tools in a sandbox. See AI agent sandboxing.
  • Log every tool call with its arguments and result, tied to the user and agent that made it.
  • Test it adversarially. MCP integrations need the same pentest as any API, plus prompt-level attacks against the agent that uses them.

References

  1. [1]Model Context Protocol specification(Model Context Protocol)
  2. [2]MCP specification: Authorization(Model Context Protocol)
  3. [3]MCP Security Best Practices(Model Context Protocol)
  4. [4]OWASP Top 10 for Agentic Applications (2026)(OWASP)
  5. [5]RFC 8707: Resource Indicators for OAuth 2.0(IETF)
Related terms

Agents and MCP integrations need testing like any API, plus attacks on the model that drives them. Talk to a security expert about testing yours.

Related service
AI Penetration Testing
Adversarial testing of your LLM and AI features, prompt injection, data exfiltration, and agent abuse, with reproducible findings.
AI penetration testing

FAQ

Model Context Protocol (MCP), asked often

Scope an engagement

Test your AI application before an attacker does.

Our AI red team probes your LLM and agent features the way an attacker would, prompt injection, tool abuse, and data exfiltration, and ships findings with reproducible attacks and fixes your team can implement.