Model Context Protocol (MCP) for the Enterprise: Architecture and Controls

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools, data and workflows. Anthropic introduced it in November 2024, and it has since been adopted across many AI clients, developer tools and platforms. For enterprises, MCP is useful because it replaces a tangle of custom integrations with one interface, and risky for the same reason: every MCP server you connect widens what a model can read and change.

What MCP is, and what it is not

Before MCP, every AI application that needed to reach a system (a ticketing tool, a database, a file store) needed its own integration. With several AI applications and dozens of systems, the number of integrations multiplied, and each was built and secured differently.

MCP standardizes that connection. A system is wrapped once as an MCP server, and any MCP-compatible application can use it. The protocol uses JSON-RPC 2.0 messages and defines how the two sides discover each other’s capabilities, call tools and exchange data.

MCP is not a model, an agent framework, or an authorization system for your enterprise data. It does not decide what a user should be allowed to do. It carries requests to systems that must still enforce their own rules.

The architecture: hosts, clients and servers

The Model Context Protocol defines three roles.

• Host. The AI application the user interacts with, such as a desktop assistant, an IDE, or your own agent service. The host manages the model and decides which servers to connect.
• Client. A connector inside the host that maintains a connection to one server. A host with five servers has five clients.
• Server. A program that exposes capabilities from some system. Servers can run locally on the user’s machine or remotely as a network service.

Two transports are defined in the specification: standard input and output (stdio) for servers running as local processes, and an HTTP-based transport for remote servers. The specification is versioned by date and has been revised several times since launch, so check which revision your clients and servers implement.

What servers expose

Servers offer three main kinds of capability:

Primitive	What it is	Who controls use	Enterprise example
Tools	Functions the model can call, with a name, description and input schema	The model, subject to host approval	Create a ticket, query open orders
Resources	Data the host can read into context, identified by URI	The application or user	A policy document, a table schema
Prompts	Reusable prompt templates offered by the server	The user	“Summarize this account” workflow

Clients can also offer capabilities back to servers. These include sampling (a server asks the host’s model to generate text), roots (the host tells the server which locations it may work in), and in newer revisions, elicitation (a server asks the user for more information through the host). Each of these is a path by which a server can influence the host, which matters for security review.

Why enterprises are adopting MCP

The benefits are practical:

• One integration per system. Wrap the CRM once and every approved AI client can use it.
• Runtime discovery. Agents can see which tools are available without code changes in every application.
• Vendor neutrality. Because MCP is an open protocol supported across many clients, it reduces coupling between your tool integrations and any single model provider or agent framework.
• Separation of concerns. The team that owns a system can own its MCP server, including what it exposes and how.

That last point is the most important for architecture. MCP lets system owners publish capabilities the way they publish APIs, with the same ownership and review.

Enterprise concerns

The protocol gives you a standard way to connect. It leaves most of the security decisions to you. These are the ones we work through with every enterprise adopting MCP.

Authentication and authorization

For remote servers over HTTP, the MCP specification defines an authorization approach based on OAuth 2.1, so clients can obtain tokens from an authorization server your identity provider controls. Local stdio servers typically receive credentials from their environment, which puts secrets on the user’s machine and needs its own controls.

The deeper question is whose authority a tool call carries. Three patterns are common:

1. User delegation. The server acts with the user’s own permissions, using a token issued for that user. This is usually the right default because the system of record enforces the same rules it already applies.
2. Scoped service identity. The server uses its own credential with narrowly defined permissions. Appropriate for shared, low-risk capabilities.
3. Broad service account. One powerful credential serves every user. Avoid this. It turns every user, and every successful prompt injection, into an administrator.

The specification’s security guidance warns against token passthrough, where a server forwards a token it received from the client straight to a downstream API without validating that the token was issued for it. Build servers that validate tokens intended for them and obtain their own downstream credentials.

Server vetting and supply chain

Public MCP servers are easy to install and vary widely in quality. A malicious or careless server can do anything its credentials allow, and it can also attack the model directly: tool names and descriptions are text the model reads, so a hostile description can carry prompt injection. A server can also change its tool definitions after you approve it.

A vetting process should cover:

• Source and maintainer, code review for internally hosted servers, and license
• The exact tools, resources and prompts exposed, and their descriptions
• Credentials required and the permissions they carry
• Network destinations the server contacts
• Version pinning, with re-review when tool definitions change

Maintain an approved server registry. Clients in managed environments should connect only to servers on it.

Least privilege

Apply least privilege at three levels:

• Server scope. A server for “read open support tickets” is safer than a server for “full ticketing system access.”
• Tool exposure. Expose only the tools a given agent or user group needs, not everything a server offers.
• Credential scope. Each credential grants the minimum rights the exposed tools require.

The specification includes tool annotations such as hints that a tool is read-only or destructive. Treat these as useful metadata for approval prompts, but not as enforcement. The specification itself says clients should not rely on annotations from untrusted servers.

Human approval

Hosts should require explicit user confirmation for consequential tool calls: sending external messages, changing records, moving money, granting access. The confirmation should show the actual parameters, not a paraphrase from the model. This is the single most effective control against indirect prompt injection through tool use. Our LLM security threat model explains why.

Audit

For every tool call you need to know who asked, which client and model made the call, which server and tool ran, with what arguments, what came back, and whether a human approved it. Without that trail, you cannot investigate an incident or satisfy an auditor. MCP does not provide this by itself; your gateway or servers must record it.

The gateway pattern

Most enterprises converge on a gateway between AI clients and MCP servers. It is the same idea as an LLM gateway applied to tools instead of models.

A typical MCP gateway:

1. Authenticates every client and user against the corporate identity provider.
2. Publishes a curated catalog of approved servers and tools, filtered by user role.
3. Brokers credentials, exchanging the user’s identity for scoped downstream tokens so secrets never live on laptops.
4. Applies policy per tool: allow, deny, require approval, or restrict parameters.
5. Inspects content, redacting sensitive data in responses and flagging suspicious tool descriptions or results.
6. Enforces limits on call rates, payload sizes and cost.
7. Logs everything to your security monitoring and audit stores.

The trade-offs are real. A gateway adds latency, becomes critical infrastructure, and needs an owner. Some client features, especially those that let servers call back into the host, may need specific handling. For most enterprises those costs are worth paying, because the alternative is governing every client and server configuration by hand.

A reference deployment

A practical enterprise MCP deployment looks like this:

• Internal MCP servers owned by the teams that own each system, built from a template that includes authentication, logging and schema validation.
• A small number of vetted third-party servers, internally hosted where possible and pinned to reviewed versions.
• An MCP gateway in front of all remote servers, integrated with identity, secrets and security monitoring.
• Managed client configuration so that approved desktop and IDE clients connect only through the gateway.
• Agent services built on your chosen framework that consume the same gateway catalog as human-facing clients. See our agentic AI architecture patterns for how tools fit into agent design.
• A review process for new servers and tool changes, run by platform engineering with security.

Failure modes to design against

• Shadow servers. Developers install public servers on their own machines with personal tokens, outside any review. Managed client configuration and a clear approved catalog reduce the incentive.
• Tool overload. An agent connected to dozens of servers sees hundreds of tools, chooses badly, and spends tokens reading descriptions it never uses. Curate tool sets per agent and per role.
• Descriptions nobody reads. Tool descriptions are prompts. Review them with the same care as system prompts, because the model follows them.
• Silent changes. A server update adds a write tool or changes a description, and nobody notices. Pin versions and alert on catalog changes.

Where to start

Start your Model Context Protocol rollout with read-only servers for a few high-value systems, delegated user authorization, the gateway, and full logging. Add write tools one at a time, each with approval requirements and a named owner. Resist the pull to connect every available public server because it is easy. Ease of connection is the feature, and it is also the risk.

How we help

We design enterprise MCP architectures, including the gateway, identity and credential brokering, server standards and the review process, and help your teams build the first production servers. See our agentic AI architecture service, or contact us to discuss your MCP rollout.