MCP Architecture Diagram for Enterprise Deployments
Enterprises must architect MCP deployments around auth and identity, not just boxes and connections.
The number that should stop you: MCP server downloads went from roughly 100,000 in November 2024 to over 8 million by April 2025. I stared at that jump for a while before it clicked — adoption outpaced the basic architectural thinking that usually happens before something scales, well beyond just outpacing security review. An enterprise MCP architecture diagram has to show more than boxes labeled "host," "client," and "server." What matters is how auth, identity, and policy enforcement wire those boxes together into something a security team can actually govern, day to day, tool call by tool call. Miss that part and you've built a pile of integrations that happen to share a protocol, nothing more.
MCP is an open standard, released by Anthropic in November 2024, that connects AI models to outside data and tools through a defined client-server setup. The Linux Foundation governs it now, with support built into ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor, and VS Code. Three primitives run the show: tools (functions the model can call, like a database query or a file write), resources (data the model can read, static or live), and prompts (templates that shape how tools and resources get used). Underneath sit three more layers: transport, protocol (JSON-RPC 2.0 messaging for handshakes and capability checks), and data, which describes what's on offer.
Host, client, and server get flattened into one blob in most diagrams, and that costs real information. The host is the app the model lives in: an IDE, a chat window, some internal tool your company built last quarter. The client is the MCP instance running inside that host, managing exactly one connection to exactly one server. The server hands tools, resources, and prompts back to the client, and it runs either locally over STDIO or remotely over HTTP/SSE. Local servers share a process with the host, so there's no network boundary to defend. Remote servers cross a boundary, and that drags in auth requirements, multi-tenant handling, and a pile of concerns a demo running on someone's laptop never has to touch.
What a minimal MCP deployment looks like and where enterprises diverge from it
The minimal case is close to trivial: one host, one client, one local server, one tool. Fine for a meetup demo. Tells you almost nothing about what a real deployment looks like.
Enterprises run multiple hosts across different teams, dozens of MCP clients active at once, and anywhere from a few dozen to a few hundred servers touching internal systems and third-party tools. That's the starting point, not some edge case you plan for later.
Here's the part most teams miss, and it took me a second read of the spec to actually register: MCP servers don't just answer requests, they can query and take action on their own for connected clients, which flips the usual request/response model on its head. A defense-sector advisory flagged this as a real attack path, since action paths can start on the server side instead of the client side, and a compromised server's blast radius reaches every client wired to it. Perimeter controls built for a world where clients always initiate requests just don't map onto a world where servers sometimes do.
Layer fragmentation makes things worse. Teams pick up servers on their own, no central registry, no shared auth model, and credentials and OAuth tokens pile up across dozens of independent integrations while nobody holds the full picture. Somewhere between 47% and 53% of organizations have already had an AI agent exceed its permissions or trigger a related incident. That's most companies, not some outlier scenario. What you end up with is a stack of one-off connections held together by whoever set them up first, with no one actually running the whole show.
Fragmentation, more than any missing box on a diagram, is the real problem here.
Why auth is the load-bearing element of any enterprise MCP diagram
The November 2025 version of the MCP spec (2025-11-25) finally locked in OAuth 2.1 as the standard for remote server authentication. Real progress, for a protocol that early on left auth mostly undefined and up to whoever built the server that week.
The spec got there in stages. March 2025: OAuth 2.1 named as the standard for API authentication. June 2025: MCP servers redefined as OAuth resource servers, so token issuance moved out to external identity providers instead of living on the server itself. November 2025: PKCE became mandatory for every client-side app, and CIMD got added so individual client instances could be uniquely identified.
There's still a hole, though. Authorization is explicitly optional in the spec, so a server can be fully spec-compliant and still hand every tool to any valid token floating around the environment. The June 2025 change split the MCP server, which checks tokens, from the authorization server, which issues them, so a server never has to be its own gatekeeper. But most major identity providers haven't caught up: Dynamic Client Registration, Protected Resource Metadata (RFC 9728), Resource Indicators (RFC 8707), and CIMD require additional integration work across most major identity providers. Design around that limit. Nobody's going to flip a setting and fix it for you.
Resource Indicators bind a token to the server it was issued for, so it can't get lifted and replayed against a different one. Direct defense against credential aggregation, and the latest spec pushes in that direction. Yet only about 8.5% of MCP servers currently run OAuth 2.1, even though it's mandatory for anything remote. That gap between what the spec requires and what's actually deployed is worth sitting with for a second. In the diagram, the authorization server and the identity provider carry the real weight. They're the connective tissue holding everything else together.
How identity, SSO, and SCIM connect to every layer of the architecture
OAuth handles the machine-to-machine handshake, but that's half the job at best. Enterprise governance needs a human identity attached to every action an agent takes, from the first tool call to the last.
SSO does that work: it ties every agent action back to a specific employee, rather than a generic service account or some anonymous OAuth client sitting unnamed in a log somewhere.
SCIM handles the part that changes over time. When someone leaves the company or switches roles, their agent's permissions need to update right along with everything else HR touches. Without SCIM, revocation becomes a manual step someone has to remember, and manual steps lag. Across dozens of MCP servers, manual permission cleanup just doesn't scale. It falls behind quietly, month after month, until nobody even notices the gap anymore.
Then there's just-in-time credential provisioning. Instead of a long-lived key sitting on a server, credentials get issued the moment a tool is called, scoped to that one call, and expired right after. That kills the hard-coded credential problem showing up across a significant share of current deployments.
What the diagram needs at this layer is simple to say and, oddly, easy to skip: the identity provider drawn as a real component instead of a footnote, a clear path from SSO assertion to OAuth token to tool-call authorization with every hop actually governed, and SCIM keeping the whole identity picture current without a human in the loop.
Skip this layer and you get the confused-deputy problem. If a downstream service just receives the token the MCP client handed it, that service can't tell the agent apart from the human behind it. That's a structural flaw baked into the design, the kind nobody patches on a Friday afternoon by tweaking a setting.
The threat landscape that makes policy enforcement a required architectural component
Tool poisoning is the attack that should worry architects most, because it's patient. A server offers harmless tools at first, earns approval, then quietly changes the tool definitions in a later session. The agent keeps calling the modified tool with no way to notice anything changed.
MCPoison, tracked as CVE-2025-54136, is this exact attack pattern in disclosed form. An attacker commits a clean MCP config to a shared repo, waits for approval, then swaps in a malicious payload in a later commit. Every session after that runs the attacker's commands, with no re-approval prompt anywhere to catch it.
What's strange, and worth sitting with, is which models fall for it. Testing under the MCPTox benchmark found a 72.8% attack success rate against tool poisoning for o1-mini. The more capable model was more susceptible, which doesn't track with how we usually think about model capability, honestly.
Prompt injection works on a similar principle but a different vector. An attacker plants instructions inside a document, a webpage, or a tool's output, and the agent reads it, follows the buried instruction, reaches for credentials it has access to, and sends them out the door. The OWASP Top 10 for Agentic Applications, 2026 edition, classifies this as ASI01, agent goal hijack, and ranks it among the top risks in the whole category.
Cross-server tool shadowing is the trust-boundary version of the same idea. Invariant Labs showed how one malicious server can weaponize other, trusted servers sitting next to it in the same environment. The protocol doesn't enforce a boundary between servers, so trust doesn't stay contained the way you'd want it to.
Supply chain risk isn't theoretical anymore either. The postmark-mcp backdoor, disclosed in September 2025, was the first confirmed malicious MCP server found in the wild. A server showing up on a marketplace tells you nothing about whether anyone actually checked it.
Scale makes all of this worse. A July 2025 internet scan found at least 1,862 publicly reachable MCP servers responding to requests with no authentication at all. Cisco's 2026 State of AI Security report put the number of organizations that feel ready to secure agentic AI deployments at just 29%.
Three things belong in the diagram because of all this: detection that checks tool definitions when they're registered and watches for changes between sessions, policy enforcement operating at the level of individual tool calls rather than just the front door, and audit logs that capture what a tool's definition actually was at the moment it got invoked, not just the fact that it got called.
How policy enforcement, audit, and observability fit into the architecture diagram
Perimeter enforcement alone doesn't cut it. Tool poisoning, prompt injection, an agent's intent slowly drifting off task: these all happen inside the session, after the front door already let something through. So enforcement has to happen at the tool call itself, not before it.
A policy engine sits in the path, checking each tool call against the identity behind it, the role attached to that identity, and the task that was actually authorized, before the call goes through. Scope has to lock to who started the action and what they were cleared to do. Default posture should deny anything not explicitly allowed for that identity and role, rather than allow by default and hope nothing slips through.
Audit logs carry their own requirements, and none of them are optional for anything that needs to pass a compliance review. They need to be tamper-proof, so neither the agent nor the server it called can quietly edit the record after the fact. They need to carry the actual human identity behind the action, not a service account, and they need to record the tool's definition as it existed at the moment of the call. That's the only way to catch a rug-pull later on.
Distributed tracing ties this back to the rest of the enterprise stack: a full trace from host to client to server and back, feeding into the same monitoring tools security and ops teams already run for everything else. Behavioral monitoring is a separate category, watching whether an agent's sequence of tool calls is drifting away from what it was actually asked to do, catching behavior that no single rule would flag on its own.
In the diagram, the policy engine sits between client and server, intercepting every call before it executes. The audit log gets its writes from the policy engine, not the server, so the record reflects what was actually permitted rather than just what was attempted. OTEL spans wrap the entire call chain, so every agent action produces one path a human can trace end to end.
This layer, when built well, bundles detection for MCP-specific threats — tool poisoning, prompt injection, behavioral drift, exfiltration — with tamper-proof logs and full call-chain tracing, rather than a pile of separate tools stapled onto whatever's already running.
Reading the full enterprise MCP architecture diagram as a connected system
A real enterprise MCP diagram has four layers, and each one has to stand on its own while staying wired clearly to the others.
The agent and host layer is where everything starts: the model itself, the host application, the MCP client instances managing each connection. Below that sits the identity and auth layer, holding the identity provider, SSO, SCIM, and the OAuth authorization server; it's the source of every permission decision made anywhere in the system. The control and policy layer is where enforcement actually lives: the policy engine, the MCP gateway or control plane, the registry of approved tools. The server and tool layer sits at the far end, made up of local and remote MCP servers and whatever downstream systems they're wired into.
The arrows matter as much as the boxes, maybe more. Every tool call needs to route through the policy layer before it reaches a server, never around it. Every SSO identity assertion needs to flow into the OAuth token that reaches the server, so there's no path in for an anonymous connection or a bare service account nobody's watching. Every invocation needs to write to the audit log through the policy engine, not through some side channel off the server, and OTEL spans need to cover the whole path without gaps.
One more piece belongs in the picture, and it often gets left out: a registry. An internal catalog of approved servers and tool definitions, with provenance, version history, and approval status tracked for each one, standing apart from a marketplace where anyone can list anything. That's what turns a diagram from a nice picture into something a security team can actually govern against, day to day, tool call by tool call.
Auth, identity, and policy are what make this an architecture at all. Take them out, and what's left is just a bunch of servers that happen to speak the same protocol.
