MCP needs an enterprise control plane

Published:
• 15 min read
MCP needs an enterprise control plane

MCP is useful.

It is also not the strategy.

That distinction matters, because a lot of companies are about to make the same mistake with AI agents that they already made with APIs, microservices, RPA, event streaming, and low-code platforms.

They will see a protocol, mistake it for an operating model, and then wonder why every team has a different agent stack, a different auth pattern, a different audit trail, a different way of calling tools, and a different answer to the question: “Who was allowed to do what, on behalf of whom, and why?”

Model Context Protocol is a good way to expose tools and context to agents.

But in an enterprise, the winning move is not “build some MCP servers.”

The winning move is to build the control plane around them.

That means an Agent Gateway, an LLM Gateway, a governed MCP platform, and a security model that treats agent actions as real production actions, not clever autocomplete.

The real product is not the chatbot

The tempting story is simple:

A technician asks an AI assistant what is wrong with a customer service. The assistant checks network health, modem status, orders, incidents, and inventory. It explains the likely fault and proposes the next action.

That is a good demo.

But the demo is not the architecture.

The real product is the platform underneath the assistant:

If those questions are not answered centrally, the company does not get an AI platform.

It gets shadow integration with a friendlier UI.

Three layers, three jobs

The cleanest pattern is to separate three concerns that often get mashed together.

1. LLM Gateway

The LLM Gateway owns model access.

It should decide which model can be used for which class of data, use case, cost profile, latency target, and regulatory boundary.

It should handle:

The LLM Gateway should not know the deep business meaning of “diagnose this customer line” or “create this incident.”

Its job is to make model usage governable.

2. Agent Gateway

The Agent Gateway owns orchestration.

It receives the user request, resolves identity and context, chooses the right agent flow, controls tool access, enforces approvals, and records the decision trail.

It should handle:

This is where the company decides whether an AI interaction is read-only, advisory, operational, or allowed to trigger a write action.

That distinction is not cosmetic. It is the difference between an assistant that can explain a fault and an assistant that can create an incident in production systems.

3. MCP servers

MCP servers expose domain tools.

They should not be random wrappers around internal APIs. They should be product-grade domain interfaces owned by the teams that understand the systems behind them.

Good MCP servers expose capabilities like:

Bad MCP servers expose a pile of raw backend operations and hope the agent figures it out.

That is not intelligence.

That is outsourcing architecture to a language model.

MCP should be domain-owned, not platform-owned

The central AI platform team should not own every MCP server.

That would create a bottleneck, and worse, it would separate tool ownership from domain knowledge.

The better model is federated ownership with central standards.

The platform team owns:

Domain teams own:

That is the same lesson enterprise architecture keeps relearning: centralize the platform, federate the products.

Security starts with identity, not prompts

The wrong way to secure agents is to start with prompt rules.

Prompt rules matter, but they are not the security foundation.

The foundation is identity, authorization, policy, and audit.

For enterprise MCP, the baseline should look like this:

MCP’s own authorization direction treats protected MCP servers as OAuth resource servers that validate access tokens intended for them. That is the right mental model for enterprises: MCP servers should not become little identity providers scattered across the company.

They should enforce tokens, scopes, and policy.

They should not invent security.

The agent must never be “the user”

This is a subtle but important point.

The agent should act on behalf of a user, but it should not become a vague super-user.

Every tool call needs a clear answer to four questions:

That is how you avoid the worst version of enterprise AI: a helpful assistant with broad backend access and a fuzzy audit trail.

For low-risk read operations, the gateway can authorize directly from the user’s role and tool scope.

For high-risk operations, the gateway should require policy checks:

Agents should not get broad trust because they are useful.

They should get narrow authority because the platform can prove the action is allowed.

Prompt injection is a tool-safety problem

Prompt injection is usually described like a model problem.

In enterprise systems, it is more useful to treat it as a tool-safety problem.

The model will read messy input: customer notes, emails, order comments, incident descriptions, scraped diagnostics, vendor data, and maybe malicious text embedded somewhere inside that context.

Some of that input may try to instruct the model to ignore policy, reveal data, or call a tool it should not call.

You cannot solve that by adding one heroic system prompt.

You solve it by designing the runtime so a confused model cannot cause too much damage.

That means:

The LLM can recommend.

The gateway decides.

The tool enforces.

That separation is the architecture.

Build MCPs like APIs, not scripts

The best way to build MCP servers is boring in the right way.

Treat them like APIs with stronger product semantics.

Each MCP server should have:

The mistake is to expose backend APIs directly and call that an MCP layer.

An MCP tool should be closer to a business capability than a database operation.

For example, a technician should not need an agent that separately calls inventory, VLAN, IP address, technology, order, modem, and incident APIs, then guesses the service health story from raw fragments.

The agent should call a domain tool such as get_customer_health, and that tool should return a structured, explainable view:

{
  "customerId": "redacted",
  "serviceId": "redacted",
  "status": "degraded",
  "confidence": "high",
  "signals": [
    {
      "source": "access_network",
      "status": "warning",
      "summary": "Optical signal is outside normal operating range"
    },
    {
      "source": "order",
      "status": "ok",
      "summary": "No active migration or open fulfillment order"
    }
  ],
  "recommendedNextAction": "run_line_diagnostics"
}

That is a better interface for agents because it encodes domain meaning.

It is also a better interface for humans.

Start with a thin slice

The platform should not begin with a giant enterprise rollout.

It should begin with one narrow, valuable, production-shaped slice.

A good first slice is technician support:

  1. technician asks a question about a customer service
  2. Agent Gateway authenticates the technician and resolves context
  3. the agent calls read-only diagnostic MCP tools
  4. the LLM summarizes the result in technician language
  5. the agent proposes a next action
  6. creating an incident requires confirmation and write scope
  7. the full run is logged end-to-end

That slice is small enough to ship.

It is also rich enough to prove the platform:

If the slice cannot prove those things, the platform is not ready for broader adoption.

The reference architecture

The shape I would aim for looks like this:

flowchart LR
  User[Employee or technician] --> AG[Agent Gateway]
  AG --> Policy[Policy and approval engine]
  AG --> LG[LLM Gateway]
  AG --> Registry[MCP registry]

  LG --> Models[Approved model providers]

  AG --> Assurance[Assurance MCP]
  AG --> Order[Order MCP]
  AG --> Incident[Incident MCP]

  Assurance --> Network[Network and inventory APIs]
  Order --> Fulfillment[Order and product APIs]
  Incident --> ITSM[Incident platform]

  AG --> Audit[Audit and trace store]
  Assurance --> Audit
  Order --> Audit
  Incident --> Audit

C4-style network view

The same architecture needs a network view, because a real technician request does not magically start inside the AI platform.

It starts at the edge, crosses identity and access controls, enters the internal agent platform, calls internal domain systems through governed APIs, and may use an approved model provider through controlled egress.

flowchart TB
  subgraph Internet["Public internet"]
    Technician["Technician browser or mobile"]
  end

  subgraph Edge["Company edge and access zone"]
    WAF["DNS, WAF and ingress controls"]
    IdP["Enterprise identity provider"]
    UI["Technician AI UI"]
  end

  subgraph AIPlatform["Internal AI platform zone"]
    AG["Agent Gateway"]
    Policy["Policy and approval engine"]
    Registry["MCP registry"]
    LLM["LLM Gateway"]
    Audit["Audit and trace store"]
  end

  subgraph MCPZone["Internal MCP domain zone"]
    Assurance["Assurance MCP"]
    Order["Order MCP"]
    Incident["Incident MCP"]
  end

  subgraph EnterpriseSystems["Enterprise API and system zone"]
    APIM["API management and service mesh"]
    Network["Network and inventory APIs"]
    Fulfillment["Order and product APIs"]
    ITSM["Incident platform"]
  end

  subgraph ControlledEgress["Controlled model egress"]
    ModelProvider["Approved model providers"]
  end

  Technician --> WAF
  WAF --> IdP
  IdP --> UI
  UI --> AG

  AG --> Policy
  AG --> Registry
  AG --> Audit
  AG --> LLM
  LLM --> ModelProvider

  AG --> Assurance
  AG --> Order
  AG --> Incident

  Assurance --> APIM
  Order --> APIM
  Incident --> APIM
  APIM --> Network
  APIM --> Fulfillment
  APIM --> ITSM

  Assurance --> Audit
  Order --> Audit
  Incident --> Audit
  Policy --> Audit
  LLM --> Audit

This is the view that usually decides whether the architecture is enterprise-grade or just another internal demo.

The edge should authenticate access. The Agent Gateway should control runtime authority. MCPs should stay inside the domain boundary. API management should protect downstream systems. The LLM Gateway should be the only sanctioned path to model providers.

The important part is not the boxes.

The important part is where the decisions live.

Model routing lives in the LLM Gateway.

Tool authorization lives in the Agent Gateway and policy engine.

Domain logic lives in MCP servers.

System-specific complexity stays behind the domain boundary.

Audit crosses everything.

Request flow

The flow is easier to understand as a sequence than as a static architecture diagram.

The LLM Gateway is not a side box. It sits in the runtime loop whenever the agent needs model reasoning, model selection, redaction, cost control, retention policy, or response evaluation.

The Agent Gateway remains the control point for identity, tool authorization, approvals, and audit. The MCP servers remain the domain boundary for business-safe tools.

sequenceDiagram
  autonumber
  actor Technician
  participant UI as TDC AI / Technician UI
  participant AG as Agent Gateway
  participant Policy as Policy + Approval Engine
  participant LLM as LLM Gateway
  participant Model as Approved LLM Provider
  participant Registry as MCP Registry
  participant Assurance as Assurance MCP
  participant Order as Order MCP
  participant Incident as Incident MCP
  participant APIs as Domain APIs
  participant Audit as Audit + Trace Store

  Technician->>UI: Ask about a customer service
  UI->>AG: Send prompt, user token, customer context
  AG->>Policy: Validate identity, role, session, customer relationship
  Policy-->>AG: Read-only diagnostic tools allowed
  AG->>Audit: Start correlated agent run

  AG->>LLM: Classify intent and plan with redacted context
  LLM->>Model: Route to approved model with policy controls
  Model-->>LLM: Proposed plan and required tools
  LLM-->>AG: Plan: check assurance, order status, incident history

  AG->>Registry: Resolve approved MCP tools and versions
  Registry-->>AG: Tool contracts, scopes, endpoints

  AG->>Policy: Authorize read tool calls
  Policy-->>AG: Approved
  AG->>Assurance: get_customer_health(customerId)
  Assurance->>APIs: Query network, inventory, modem state
  APIs-->>Assurance: Diagnostic signals
  Assurance-->>AG: Structured health result

  AG->>Order: get_order_status(customerId)
  Order->>APIs: Query fulfillment and product state
  APIs-->>Order: Order signals
  Order-->>AG: Structured order result

  AG->>LLM: Summarize tool results for technician
  LLM->>Model: Generate explanation from structured results
  Model-->>LLM: Draft answer and next action
  LLM-->>AG: Explanation plus proposed next step

  alt Incident creation is needed
    AG->>Policy: Check write scope and approval requirement
    Policy-->>AG: Step-up confirmation required
    AG-->>UI: Ask technician to confirm incident creation
    Technician->>UI: Confirm
    UI->>AG: Confirmation
    AG->>Incident: create_incident(summary, evidence)
    Incident->>APIs: Create ticket in incident platform
    APIs-->>Incident: Incident ID
    Incident-->>AG: Incident created
  else Advisory only
    AG-->>UI: Return explanation and recommended next action
  end

  AG->>Audit: Record prompts, model route, tool calls, policy decisions, outputs
  AG-->>UI: Final answer with trace ID
  UI-->>Technician: Show explanation, evidence, next action

This is the part many architecture sketches hide.

The request is not “user talks to model, model calls tools.”

The real flow is: user enters through the Agent Gateway, the Agent Gateway asks the LLM Gateway for governed reasoning, the Agent Gateway authorizes and executes tool calls through MCP servers, the MCP servers talk to domain APIs, and the Agent Gateway returns an audited answer.

That is the control plane.

What the platform team should deliver

If a team wants to win the mandate for MCP, Agent Gateway, and LLM Gateway across a large company, it should not pitch a loose collection of agents.

It should pitch a platform capability.

The first deliverables should be:

The story should be simple:

We will let domain teams build AI tools quickly, but inside one governed runtime where identity, security, policy, audit, and model usage are handled once.

That is a much stronger bid than “we can build a chatbot.”

What to measure

The platform should be measured like an enterprise integration product, not like a demo.

Useful measures include:

The company should also measure developer experience.

If domain teams cannot build and certify MCP servers without begging the central team for every change, adoption will fail.

Governance that kills speed is just another bottleneck.

The goal is governed speed.

The real argument

MCP is exciting because it gives agents a common way to use tools.

But the enterprise value is not the protocol by itself.

The enterprise value is the control plane around the protocol:

That is the architecture worth building.

Not an AI assistant sitting on top of fragile integrations.

An enterprise agent platform where MCP servers become governed domain products, the Agent Gateway becomes the runtime control point, and the LLM Gateway makes model usage manageable instead of accidental.

That is how MCP becomes more than a clever connector pattern.

That is how it becomes enterprise infrastructure.

References

Share this post on:
Share this post on X Share this post on LinkedIn Share this post via WhatsApp Share this post on Facebook Share this post via Telegram Share this post on Pinterest Share this post via email

Related reading

More pieces in the same part of the map.