MCP architecture is a client-server design in which an AI application (the host) runs one or more clients that each connect to an MCP server exposing tools, resources, and prompts — and every one of those connection points is a place security has to live. The Model Context Protocol standardizes how large language models reach external data and actions, which is powerful precisely because it hands a model the ability to call code and read data. This guide walks through how the architecture fits together, what the MCP server architecture looks like in practice, and where the trust boundaries that matter for security actually sit.
The three roles in MCP architecture
MCP defines a clean separation of roles. Getting these straight is the foundation for reasoning about risk:
- Host — the AI application the user interacts with (a desktop assistant, an IDE plugin, an agent runtime). The host embeds the model and orchestrates everything.
- Client — a connector inside the host that maintains a one-to-one session with a single server. A host with three servers runs three clients.
- Server — a separate process or service that exposes capabilities. This is the MCP server: it advertises what it can do and executes requests.
The model itself never talks to a server directly. It asks the host to invoke a capability, the host routes that through the relevant client, and the server does the work. That indirection is the seam where authorization and validation belong.
What an MCP server exposes
The MCP server architecture centers on three primitives, and each carries a different risk profile:
- Tools — functions the model can call to take action: query a database, send an email, open a pull request. Tools are the highest-risk primitive because they cause side effects in the world.
- Resources — data the server makes available for context: files, records, API responses. The risk here is exfiltration and, subtly, injection, because resource content flows into the model's context.
- Prompts — reusable prompt templates the server offers to the host. These shape model behavior and so are a place a malicious server can steer the model.
A tool is described to the model with a name, a description, and a JSON Schema for its inputs. That description is not neutral text — the model reads and acts on it, which is why tool descriptions are a genuine attack surface, not documentation.
Transports and where they run
MCP connections use one of two main transports. stdio runs the server as a local subprocess of the host, communicating over standard input and output — common for local tools like a filesystem or git server. Streamable HTTP (which superseded the earlier HTTP-plus-SSE approach) connects to a remote server over the network, used for hosted services and shared team infrastructure.
The transport determines the threat model. A stdio server runs with the privileges of the host process on the user's machine, so a malicious local server is essentially local code execution. A remote HTTP server crosses a network boundary and an ownership boundary — you are trusting whoever operates it — which is why remote MCP servers layer OAuth-based authorization on top of the protocol. Knowing which transport a given server uses tells you immediately what could go wrong.
The trust boundaries that matter
Once you see the pieces, the security-relevant boundaries fall out:
- Model-to-tool. The model decides which tool to call and with what arguments. If the model can be steered by injected content, it can be steered into calling a dangerous tool. This is where a confused-deputy problem lives.
- Server-to-host. Everything a server returns — tool results, resource contents, prompt templates — enters the model's context. A compromised or malicious server can plant instructions there.
- Host-to-user. The host decides what to surface for approval and what to auto-run. Silent auto-approval of high-impact tools removes the human from the loop entirely.
Good MCP architecture keeps a human confirmation step in front of consequential tool calls and treats every server response as untrusted input, not as trusted instruction.
The main security risks in MCP architecture
The recurring risks reported across MCP deployments cluster into a handful of categories:
- Prompt injection through tool descriptions and resources. Because the model reads tool descriptions and resource content, text placed there can carry instructions. A malicious server can describe a benign-sounding tool with a description that instructs the model to exfiltrate data when called. Content pulled from an external resource (a web page, an issue comment) can do the same. This is the AI-native version of injection, and it is the dominant MCP risk.
- Over-broad tool permissions. A server that exposes a
run_commandor unrestricted filesystem tool hands the model far more capability than any single task needs. Least privilege applies to tools exactly as it does to service accounts. - Credential and token handling. Servers often hold API keys or OAuth tokens to reach downstream systems. Where those live, how they are scoped, and whether the model can be tricked into using them for the wrong request all matter.
- Confused deputy and tool shadowing. With multiple servers connected, one server can define a tool whose name or description shadows another's, or induce calls to a more-privileged tool. The host's routing and naming discipline is the defense.
- Supply-chain risk in the server itself. An MCP server is software with its own dependencies. A vulnerable or malicious package inside the server undermines everything above it. This is where a software composition analysis tool applies to MCP servers the same way it applies to any other service.
Designing MCP architecture defensively
A few principles keep the design safe as it grows. Scope each server to the narrowest set of tools its job requires, and prefer read-only resources over action tools wherever a task allows. Keep human-in-the-loop confirmation on any tool with side effects, and make the approval prompt show the actual arguments, not just the tool name. Isolate servers from each other so a compromise of one does not grant access to another's credentials. Log every tool invocation with its arguments for audit, because after-the-fact investigation depends on it. And validate server identity and pin versions for remote servers, so you know the endpoint you authorized is the one you are still talking to. The Safeguard research team tracks how these patterns hold up as MCP tooling matures, because the protocol is young and the attack techniques are still being mapped.
FAQ
What is MCP architecture in simple terms?
It is a client-server design where an AI host runs clients that connect to MCP servers. Servers expose tools, resources, and prompts; the model requests capabilities through the host rather than calling servers directly.
What does an MCP server do?
An MCP server exposes capabilities to an AI model: tools that take actions, resources that provide data for context, and prompt templates. It runs as a separate process or service, over stdio locally or streamable HTTP remotely.
What is the biggest security risk in MCP architecture?
Prompt injection through tool descriptions and resource content. Because the model reads and acts on that text, a malicious or compromised server can embed instructions that steer the model into leaking data or misusing tools.
How do you secure remote MCP servers?
Use OAuth-based authorization, scope tokens tightly, pin and verify the server version and identity, keep human confirmation in front of consequential tools, and treat every server response as untrusted input rather than trusted instruction.