Model Context Protocol (MCP)

How MCP works

MCP defines a client–server architecture with three distinct roles. Understanding them is the prerequisite for governing them.

Host, client, and server

The host is the application the user interacts with — a chat interface, an IDE assistant, or an autonomous agent runtime. The host instantiates one or more MCP clients, each maintaining a dedicated connection to a single MCP server. The server is a separate process (local or remote) that exposes capabilities to the model in a structured, discoverable form.

Servers advertise three primitives:

• Tools — functions the model can call to take action: query a database, send an email, create a ticket, run a shell command.
• Resources — data the model can read: files, records, API responses, documents.
• Prompts — reusable templates the server offers to the host.

When a model decides to use a capability, the client forwards a structured request to the server, the server executes it, and the result is returned into the model's context. The transport is typically JSON-RPC over stdio for local servers or HTTP for remote ones.

Why it matters

Before MCP, every connection between an AI application and an external system was a custom integration. MCP turns that N×M integration problem into an N+M one: any MCP-compatible host can talk to any MCP server. The result is a fast-growing ecosystem of servers — official, community, and vendor-built — that an agent can compose at runtime. That composability is precisely what makes MCP strategically important, and precisely what makes it a security concern.

MCP vs traditional API integration

MCP and a hand-built API integration can reach the same backend system, but they differ in how capability is exposed, discovered, and controlled.

The decisive shift is the caller. A traditional integration runs code a developer wrote and reviewed; an MCP tool call is chosen by a model at inference time, with arguments derived from context that may include untrusted input.

Security implications of MCP

MCP expands what an agent can do, and therefore expands what an attacker can do through the agent. The risks below are not theoretical edge cases — they follow directly from the protocol's design.

Over-permissioned servers and excessive agency

MCP servers are frequently configured with broad, long-lived credentials — a database connection with full read/write access, an API token scoped to an entire workspace. The model then has, in effect, all the authority the server holds. "Excessive agency" describes the gap between what an agent needs to do for a task and what it is technically able to do. A summarization agent that holds a delete-capable database tool can be induced to delete records, even if deletion was never part of its job.

Tool calls invisible to network and DLP controls

Local MCP servers communicate over stdio, and even remote ones carry free-form arguments rather than recognizable file transfers. A network DLP appliance sees an encrypted session or nothing at all; it does not see that a tool-call argument contains a customer list or a secret. The action an agent takes — and the data it passes — happens below the layer most enterprise monitoring inspects.

Indirect prompt injection via tool results

This is the risk most specific to MCP. When a server returns a resource — a web page, an email, a document, a record — that content enters the model's context and is treated as instruction-bearing text. An attacker who can plant text in a data source the agent will read (a calendar invite, a support ticket, a code comment) can inject instructions that the model then acts on, using its legitimate tools. The agent is not compromised in the traditional sense; it is faithfully following instructions that arrived through data.

Supply-chain risk of third-party servers

Installing an MCP server is installing code that runs with the agent's privileges and shapes the model's behavior. Risks include malicious or typosquatted servers, tool descriptions written to manipulate model behavior ("tool poisoning"), and silent redefinition of a tool after it has been approved ("rug pulls"). Because servers are easy to add and the ecosystem is young, provenance and integrity are often unverified.

Authentication and credential sprawl

Each server needs credentials to the system it fronts. Without centralized brokering, those secrets accumulate across host configurations, are frequently over-scoped, and rarely rotate. A single leaked server configuration can expose standing access to a production system.

Questions MCP governance should answer

• Which MCP servers are connected, and what do they expose? — Inventory of servers, tools, and the scopes they hold.
• What did this agent actually do? — A per-task record of every tool call, its arguments, and its result.
• Was this tool call within policy? — Least-privilege enforcement evaluated before execution, not after.
• Did a high-risk action get human sign-off? — Approval records with reviewer identity for destructive or sensitive operations.
• Did this action originate from injected content? — Traceability from a tool call back to the data that triggered it.