MCP Architecture Diagram for Enterprise Deployments
Separating the data plane from control plane reveals where most MCP pilots fail to reach production.
MCP is now the de facto standard for connecting AI agents to enterprise tools, but adoption and the maturity of governance around it are not moving at the same speed. OpenAI, Google DeepMind, Microsoft Copilot Studio, and AWS all added MCP support within a short window of each other, and enterprise use now spans CRM, marketing automation, and developer tooling. SDK downloads reached roughly 97 million a month, and most technical leaders say they have production use, but only a small fraction of pilots reach governed production. The rest stall on identity, audit, and access-control gaps, and that stall traces back to a structural problem: most organizations still lack a mature AI-agent governance model even as deployment scales around them. A deployment that is easy to stand up but hard to govern functions as a pilot that hasn't been shut down yet, and the architecture diagram is where that distinction either gets built in from the start or gets ignored until it's expensive to fix.
What an enterprise MCP architecture diagram must show
If an enterprise MCP diagram shows only agent-to-tool connections, it captures the data plane, but it leaves the control plane invisible. That missing control plane is what causes pilots to stall. The canonical enterprise architecture spans two planes: a control plane made up of the registry, policy engine, credentials, and audit trail, and a data plane that carries every live MCP request. Core components span these planes: auth handler, identity resolver, policy engine, discovery filter, session router, backend router, credential broker, and audit emitter. Most diagrams drawn during pilots show only the data plane: agent, host, MCP server, tool, with the control plane omitted entirely. That omission is why those pilots can't be promoted to production. A diagram missing the registry, the policy engine, the credential broker, and the audit emitter is a different, incomplete architecture that happens to work in a demo. The rest of this piece builds out both planes in the order a production deployment actually needs them: data plane first, because it has to exist before anything else does, then control plane, because it's what turns a working connection into a governable one.
The data plane: how client, host, and MCP server components connect
Without a gateway, the data plane creates an N×M connectivity problem: each of N agents needs a direct connection to each of M tool servers, and that multiplies into credential sprawl, no central point of policy enforcement, and audit logs scattered across every pairing. An MCP gateway collapses that mesh into a single authenticated endpoint, and every tool call gets routed, monitored, and enforced through that one point. A production gateway handles OAuth 2.1 token issuance and validation, routes tool calls to the right backend MCP server, enforces per-team and per-role access policies, logs every tool invocation with user identity and a timestamp, and applies data-loss-prevention rules to what goes in and out of each tool call.
A recent revision to the MCP core made the protocol stateless, which removes session affinity as a scaling constraint. The production pattern that follows from that is a header-routing gateway sitting in front of a stateless, round-robin pool of tool servers, with long-running work pulled out into the separate Tasks extension. MCP server endpoints have no business being reachable from the public internet. They belong on an internal network, a VPC or private subnet, reachable only from the gateway, with the gateway handling all external authentication and forwarding identity headers down to the server. That arrangement buys real defense in depth: even a misconfigured server sitting behind the gateway still can't be reached by anything that hasn't already passed gateway authentication.
MCP's authentication model applies established OAuth and OIDC principles to agentic workflows, and applying those principles correctly means distinguishing three actor types that most pilots lump together as one, since three distinct authorization paths must be architected separately. Authorization is optional in the spec, but when you implement it, the specification recommends OAuth 2.1 with PKCE for any MCP server exposed over HTTP, and this replaces static API keys as the default mechanism.
The first actor type is the employee, and they access MCP servers through an approved client. Enterprise-Managed Authorization, or EMA, addresses this case by replacing per-server consent prompts with a zero-touch flow: a user signs in once and gets access to every approved server without repeating setup for each one, and Anthropic, Microsoft, and Okta have all adopted it. EMA solves the human-in-the-loop case well, but it doesn't establish workload identity for an agent acting on its own.
The second actor type is the unattended agent, one acting without a user present. That gap is addressed by the MCP OAuth Client Credentials extension, because EMA alone has no mechanism for establishing identity for an autonomous agent.
The third actor type is agent-to-agent delegation, where one agent invokes another on behalf of a user or process. Standardized identity and delegation for this case are still active areas of development within the MCP specification itself, so if you build for it today, you build ahead of a finished standard.
The gap between what the spec allows and what gets deployed in practice is stark. A scan of the public internet in July 2025 found 1,862 MCP server instances that responded to unauthenticated requests: technically compliant with a specification that makes authentication optional, but practically insecure by any operational standard. Fewer than a quarter of organizations route the authorization for their MCP infrastructure through their existing IAM or identity provider. Once agents start acting as first-class actors inside enterprise systems, they need the same treatment given to any other identity: authentication, authorization, least privilege, auditability, lifecycle management, and revocation.
The control plane: policy enforcement, discovery filtering, and the registry
If a policy engine has no registry, it enforces rules against an inventory it can't see. A registry without a policy engine is documentation with no teeth. Both have to appear in the diagram as connected components, with governance distributed across them rather than collapsed into a single labeled box."
The control plane holds four components, and they only work as a set: the registry, the policy engine, the credential broker, and the discovery filter. The registry maps every MCP server and every tool to an owner, a version, a data classification, a permission set, an approval rule, and a kill switch. Without it, security teams have no way to know which servers are trusted, what permissions they carry, or whether a tool's definition has quietly changed since it was approved.
The policy engine evaluates whether a given action is allowed for the actor requesting it, once that actor's identity has been resolved. Production gateways build this on Cedar or on Open Policy Agent. Cedar fits MCP more cleanly, because its model maps directly onto the concepts MCP architecture already needs: users, agents, sessions, tools, environments, credential modes, and delegation context.
The discovery filter controls which servers and tools an agent can even see in the first place. A tool that an agent can't discover can't be poisoned and can't be abused, which makes discovery filtering a prevention mechanism and not just an access convenience.
The credential broker issues short-lived, scoped credentials just in time for each tool call. Agent credentials should live on the timescale of minutes, not months, which is a sharp departure from how API keys and service-account secrets have traditionally been managed in most enterprises.
None of this makes the registry a replacement for the rest of IAM. An MCP registry provides inventory, approval workflows, and version history, but it doesn't substitute for identity and access management, network controls, or runtime enforcement. It has to connect into the broader control plane to mean anything. That connection matters because MCP servers can update their own tool definitions without notifying the client, and most clients don't detect or flag that kind of change. So the registry answers that blind spot with version-pinning and change-detection functions.
NIST's concept paper on agent identity organizes the same ground around four requirements: identification, authorization, access delegation, and auditing with non-repudiation, treating authentication as part of identification and delegation as a sub-area of authorization. That is where those requirements stop being policy intent on a slide and turn into enforced architecture running in production.
Where MCP-specific threats enter the architecture
Tool poisoning is a control-plane failure. An agent reads a tool's description with the same trust it extends to its own system prompt, and if a malicious server hides commands inside that description, the model follows them: reading files, leaking secrets, and still returning an answer that looks completely normal. Microsoft's Defender research team disclosed a case of exactly this in late June 2026, where a finance team's agent was connected to a third-party invoice enrichment tool that had been approved but never security-reviewed. The attacker updated the tool's hidden description to exfiltrate unpaid invoices, and because MCP picks up description changes on the fly with no re-approval trigger built in, the poisoned version went live undetected. So the architectural fix is a version-pinned registry with change detection and a mandatory re-approval workflow whenever a tool definition changes.
Rug pull attacks exploit the same gap from a different angle: registry and discovery filter failure. A tool behaves exactly as expected at install time and earns the permissions you grant it, but it can later change its own behavior silently, because MCP servers can update tool definitions without ever notifying the client. The fix again runs through the registry: signed tool definitions, version pinning, and alerts the moment a definition drifts from what was approved.
Unauthenticated and rogue servers fail identity and the control plane at the same time. Research scanning public MCP servers found more than a third had no authentication at all. A developer can stand up an MCP server against a production database in an afternoon, and the moment an agent discovers it, its tools become part of that agent's action surface whether or not anyone signed off on it. Wiz Research disclosed two flaws in the Amazon Q VS Code extension in June 2026, and together they let a malicious repository run arbitrary code and steal cloud credentials, all through a crafted workspace MCP configuration file. Because the spawned MCP server processes inherited the full developer environment, a successful exploit handed the attacker immediate access to cloud infrastructure. The architectural fix: a discovery filter that limits agents to registry-approved servers, network isolation that keeps servers off any publicly reachable address, and OAuth 2.1 enforced at the gateway rather than left optional at the server.
The newest attack surface comes from the protocol itself. MCP 2026-07-28 introduces new HTTP headers, Mcp-Method and Mcp-Name among them, and those headers open the door to protocol confusion, or Desync, attacks. If developers accidentally map API keys, tokens, or personal data into those headers, those secrets become visible to every load balancer, proxy, and logging system the request passes through on its way to the server. That risk sits squarely in the data plane and in implementation discipline, not in any control-plane policy. Gateway configuration review has to extend down to header-level handling and not stop at the level of routing and authentication.
