TL;DR

Use Model Context Protocol as the governed interface through which agents discover and invoke enterprise capabilities, but do not treat MCP as the complete controller for an autonomous agent system.

The clean separation is:

The agent proposes. The controller authorizes. MCP carries the governed interaction. The runtime executes and verifies.

MCP standardizes client-server communication, capability negotiation, tools, resources, prompts, structured inputs, structured outputs, and related protocol behavior. Those capabilities make it an excellent enterprise tool plane. They do not make the model authoritative for identity, permissions, risk, workflow state, approvals, budgets, retries, termination, rollback, or production service objectives.

The recommended design is an Agent Control Plane with an MCP Tool Plane underneath it. The agent can recommend what should happen. Trusted services must decide whether it may happen, under whose authority, against which environment, within what limits, and with what evidence.

Introduction

MCP is quickly becoming one of the most important interoperability layers in enterprise AI. It gives AI applications a consistent way to discover tools, access resources, negotiate capabilities, send structured arguments, and receive structured results. That reduces the need to rebuild the same integration for every model, agent framework, and downstream platform.

That value is real, but it creates a predictable architectural mistake.

Teams see a protocol that can connect an agent to tools, add authorization, expose task behavior, and return structured results. They then assume the protocol should also become the workflow engine, policy authority, approval system, lifecycle manager, runtime scheduler, and production safety layer for the agent.

That is too much responsibility for one interface.

The Model Context Protocol architecture documentation is explicit that MCP focuses on the protocol for context exchange and does not dictate how AI applications use models or manage the context they receive. The specification also states that several security principles cannot be enforced by MCP at the protocol level and must be implemented by hosts and other surrounding components.

That gives us the right starting point for enterprise design:

MCP should be the governed control interface through which agents reach enterprise capabilities. It should not be the brain that makes every control decision.

This is Part 1 of the Enterprise Agent Control Plane Series. The series separates agent reasoning, policy authority, MCP connectivity, runtime execution, evidence, and agent-to-agent collaboration into distinct architectural concerns.

The Five-Part Enterprise Agent Control Plane Series

Part 1 establishes the mental model that the remaining articles will implement.

The Architectural Distinction That Matters

The most useful control statement is simple:

The agent proposes. The controller authorizes. MCP carries the governed interaction. The runtime executes and verifies.

Each sentence assigns a different type of responsibility.

The agent proposes because a model is well suited to interpreting goals, reasoning across incomplete information, selecting a possible action, creating a plan, and constructing candidate arguments.

The controller authorizes because identity, permissions, policy, risk, approvals, budget, workflow state, and termination must remain deterministic, inspectable, and enforceable even when the model is wrong or manipulated.

MCP carries the governed interaction because it gives the application a standardized protocol for discovering capabilities, describing schemas, invoking tools, accessing resources, and receiving results.

The runtime executes and verifies because side effects need isolation, timeout handling, idempotency, post-condition checks, evidence collection, and recovery behavior that do not depend on the model claiming success.

There is one terminology caveat worth making explicit. Calling MCP the transport layer is useful architectural shorthand, but MCP is more than a network transport. It defines protocol semantics above HTTP or standard input and output, including capabilities, tools, resources, prompts, tasks, and message behavior. In this series, MCP Tool Plane means the standardized capability-access plane. It does not mean MCP is only moving packets.

What MCP Actually Standardizes

MCP follows a client-server architecture. An MCP host creates and coordinates MCP clients, and each client maintains a connection to a corresponding MCP server. Servers expose capabilities such as tools, resources, and prompts. Clients and servers negotiate supported capabilities and exchange structured protocol messages.

That standardization is valuable because it creates a reusable boundary between AI applications and external systems.

Tool discovery and invocation

An MCP server can describe tools using names, descriptions, input schemas, optional output schemas, annotations, and execution-related metadata. The client can list those tools, present an approved subset to the model, invoke a selected tool, and validate structured results.

This is much stronger than embedding a collection of informal function descriptions into every agent prompt.

Resource access

MCP resources provide a standardized way to expose files, database schemas, application records, or other context-bearing information. Resources can be read, linked, embedded, and, where supported, subscribed to for updates.

Capability negotiation

Clients and servers declare supported protocol capabilities. This lets an application adapt to features that are present rather than assuming every server behaves identically.

Model-independent integrations

A well-designed MCP server is not tied to one model provider or one orchestration framework. The same capability can be reused by different hosts, agents, and applications, subject to their own authorization and policy decisions.

Structured contracts

Input and output schemas create a machine-readable contract between the AI application and the server. They improve validation, interoperability, testing, and error handling.

These are substantial capabilities. They make MCP an excellent foundation for the enterprise tool plane.

They still do not answer the central governance question:

Who is authoritative when the model asks to do something consequential?

The Agent Control Plane at a Glance

The architecture below separates reasoning, control, connectivity, execution, and system-of-record authority.

The most important detail is the return path from the agent to the controller. The model does not directly become authoritative because it selected a tool. It submits a proposal back to a trusted component that can compare the requested action with the original business request, the authenticated identity, the current environment, policy, approval state, budget, and workflow history.

Responsibilities by Layer

This separation creates defense in depth. The controller evaluates whether the request is allowed in the broader workflow. The MCP server evaluates whether the operation is valid within its domain. The enterprise system still enforces its own resource-level rules.

A standardized request should never become a bypass around the system that owns the data or action.

The Agent May Propose Context, but the Runtime Must Supply Authority

One of the most dangerous agent-tool designs places privileged context inside model-generated arguments.

A tool schema might allow fields such as:

• user ID
• tenant ID
• target environment
• authorization scope
• approved flag
• risk level
• policy version
• production override

The model can populate those fields, but it cannot prove them. Allowing the agent to send them as authoritative values is equivalent to letting a caller write its own access token claims.

The safer pattern separates proposal data from the trusted execution envelope.

The agent may propose

• service or resource identifier
• requested operation
• summary of intent
• implementation plan
• rollback plan
• candidate arguments
• supporting evidence references
• expected outcome

The trusted runtime must supply

• authenticated principal
• tenant or organization
• granted scopes
• target environment
• policy version
• risk classification
• approval evidence
• trace ID
• budget
• deadline
• idempotency key
• source application
• release and tool versions

The following YAML illustrates the boundary. It is not an MCP standard object. It is an application-level control contract that a trusted controller can assemble before invoking an MCP tool.

execution_request:
  proposal:
    operation: restart_service
    target:
      service_id: payments-api
    reason: "Health checks have failed for five minutes"
    implementation_plan:
      - capture_current_state
      - restart_one_instance
      - validate_health
    rollback_plan:
      - restore_previous_instance_set
    expected_outcome: "Service health returns to normal"

  authority:
    authenticated_principal: user-48291
    tenant: enterprise-a
    granted_scopes:
      - service.read
      - service.restart
    environment: production
    risk_tier: high
    policy_version: agent-runtime-policy-v12
    approval:
      required: true
      approval_id: apr-93721
      expires_at: "2026-07-21T22:30:00Z"
    trace_id: trc-57c2a
    budget:
      max_tool_calls: 3
      max_elapsed_seconds: 120
    idempotency_key: idem-8b7f2
    source_application: incident-response-agent

  enforcement:
    allow_only_declared_operation: true
    require_schema_validation: true
    require_precondition_check: true
    require_postcondition_check: true
    require_structured_evidence: true
    stop_on_policy_change: true

The agent should be able to influence the proposal section. It should not be able to create or change the authority section.

The controller should also avoid copying proposal fields into the authority envelope without independent validation. For example, the model may propose production, but the trusted workflow state must determine whether production is the approved target.

Successful execution means the controller can prove which authenticated principal initiated the work, which policy version authorized it, which approval covered the exact action, which tool version ran, which idempotency key protected the side effect, and which evidence demonstrated the outcome.

A common failure is allowing the same field to appear in both sections and then trusting whichever value is convenient. The contract should define one authoritative source for every security-sensitive attribute.

Where MCP Fits Extremely Well

MCP is a strong architectural choice when the problem is standardized access to capabilities.

Standardized tool discovery

Hosts can discover and list tools through a common protocol rather than maintaining one custom catalog format per agent framework.

Typed input and output schemas

Schemas help the client validate model-generated arguments and help servers return structured results that downstream components can test and interpret.

Reusable integrations across agents

One approved server can support several agents and hosts without rebuilding the downstream integration for each model.

Read and write separation

Servers can expose separate capabilities for retrieval, simulation, proposal, and execution. This is better than one overpowered tool with mode flags that are easy to misuse.

Controlled access to enterprise APIs

An MCP server can become a domain-specific façade over a complex enterprise API. It can narrow operations, normalize errors, validate business rules, and return evidence in a form that an agent runtime understands.

Consistent observability and trace correlation

A gateway or host can propagate trace context across model decisions, controller checks, MCP calls, server actions, and downstream APIs.

Model and framework portability

The enterprise can change models or orchestration frameworks without rebuilding every downstream connector. Portability is not automatic, but the protocol reduces integration coupling.

Centralized server admission and lifecycle control

An approved registry can track server ownership, package source, version, supported tools, security review, environments, and retirement status.

These benefits are exactly why MCP should sit underneath the control plane rather than be avoided.

What MCP Does Not Replace

MCP should not be expected to become every component in the agent platform.

This is not a weakness in MCP. It is a scope boundary.

Protocols become more useful when they are not forced to absorb the complete operating model of every system that uses them.

Experimental MCP Tasks Do Not Eliminate the Need for a Controller

The November 25, 2025 MCP specification introduced Tasks as an experimental capability. Tasks are durable state machines that can wrap supported requests, expose execution status, support polling, return deferred results, and, where negotiated, support listing or cancellation.

That is useful for long-running tool operations.

An MCP server that starts a large data export, security scan, infrastructure job, or batch process needs a better model than holding one synchronous connection open. A task ID, status lifecycle, result retrieval, cancellation, expiration, and authorization-context binding are practical protocol features.

However, an MCP Task is not the same thing as an enterprise workflow engine.

A task can represent the durable execution state of a request. It does not automatically define:

• the complete business workflow graph
• cross-tool ordering and dependency management
• policy evaluation across workflow stages
• risk-based approval routing
• organization-wide concurrency rules
• compensation across several systems
• budget allocation across nested activities
• release compatibility for paused workflows
• cross-agent arbitration
• production incident ownership

The distinction is similar to the difference between a job API and a business process engine. The job API may report submitted, working, completed, failed, or canceled. The workflow engine decides why the job exists, whether it may start, what must happen before and after it, and what the organization should do when it fails.

Use MCP Tasks where they improve protocol-level handling of deferred work. Keep authoritative workflow state in a controller or state machine designed for the complete business process.

Tool Annotations Are Not Security Controls

MCP tools can include annotations that describe behavior. Those hints may indicate that a tool is read-only, destructive, idempotent, or otherwise constrained.

The specification requires clients to treat tool annotations as untrusted unless they come from a trusted server.

That matters because a malicious, compromised, or simply incorrect server can mislabel a dangerous operation. Even a trusted server can contain an implementation defect that makes an allegedly read-only operation produce side effects.

The controller and server should therefore validate behavior using stronger evidence:

• server admission and ownership
• signed or verified package provenance where available
• code and configuration review
• environment-specific allowlists
• narrow downstream credentials
• schema and business-rule validation
• runtime network restrictions
• dry-run or simulation support
• post-condition verification
• audit evidence
• regression and abuse-case testing

A hint can improve user experience and tool selection. It should not be the only control protecting production.

Exposing an Agent Controller Through MCP Can Be Valid

There are cases where an enterprise wants agents or applications to manipulate agent tasks through MCP. A controller service can expose bounded tools such as:

• agent.task.start
• agent.task.status
• agent.task.cancel
• agent.task.pause
• agent.approval.submit
• agent.artifact.read

That can be a clean interface, provided the MCP server is a façade over a real controller.

The controller still needs to own durable task state, authorization, policy, approval logic, resource limits, cancellation semantics, evidence, and termination. The MCP call should create or manipulate a bounded task under a defined contract.

It should not forward unrestricted natural-language instructions to another autonomous agent with broad credentials and call that governance.

A safer agent.task.start request contains a narrow task type, approved target class, constrained input schema, execution deadline, budget, and policy context supplied by trusted infrastructure. The receiving controller resolves the task type to a versioned workflow and approved capability set.

For simple delegation, another agent can sometimes be represented as an MCP tool. For long-running collaboration between independently operated agents, the Agent2Agent Protocol is more naturally aligned. A2A version 1.0 defines agent discovery, collaborative tasks, task state, messages, artifacts, streaming, and asynchronous notification patterns. Part 5 of this series will show how A2A can form the agent-to-agent plane while MCP remains the agent-to-tool plane.

The Main Failure Modes to Design Against

The control-plane boundary becomes easier to defend when the team names the likely failure modes before implementation.

MCP server sprawl

Without admission control, MCP can recreate the enterprise integration problem at a different layer. Every team publishes a server, tool names overlap, versions drift, ownership becomes unclear, and old servers remain reachable after their purpose has disappeared.

Control: Maintain an approved registry with publisher identity, owner, source, version, environments, tool inventory, security review, data classification, lifecycle status, and retirement date.

Excessive tool exposure

Showing every enterprise capability to every agent increases prompt size, selection ambiguity, attack surface, and blast radius.

Control: Build the visible tool catalog dynamically from the authenticated requester, agent identity, task type, target environment, data classification, risk tier, and workflow stage.

Prompt injection through tool results

Retrieved content and tool output can contain instructions that attempt to override policy, request additional tools, reveal secrets, or redirect the workflow.

Control: Treat external content as untrusted data. The controller must not allow tool output to change system policy, identity, approval state, tool visibility, or execution budget.

Overpowered tools

Tools such as run_arbitrary_sql, execute_shell, call_any_api, or write_file_anywhere collapse too much authority into one interface.

Control: Separate read, simulate, propose, and execute operations. Create domain-specific tools with narrow schemas, resource allowlists, bounded side effects, and explicit evidence contracts.

Credential confusion

An MCP server that accepts a client token and forwards it unchanged to a downstream API can violate token audience boundaries, bypass controls, and create a confused-deputy problem.

Control: Validate that the inbound token was issued for the MCP server. Use a separate downstream token issued for the downstream resource. Never let the model choose or supply credentials.

False confidence from standardization

A standard protocol can make an unsafe integration look mature. The request has a schema, the tool has a name, the server returned structured JSON, and the trace shows success. None of that proves the action was authorized, appropriate, idempotent, or correct.

Control: Treat protocol conformance and operational safety as separate acceptance gates.

A Governed Request Flow

The following flow shows where each decision should occur. Notice that authorization happens before tool exposure and again before execution. Verification happens after the downstream system responds.

The design intentionally repeats certain checks. That is not waste. It reflects different scopes of authority.

The controller knows the workflow, user, policy, budget, approval, and cross-system context. The MCP server knows the domain operation, downstream resource, business rules, and execution contract. The enterprise system knows the authoritative current state and native permissions.

Implementation Principles for the Control Boundary

A reference architecture is only useful when it changes implementation decisions.

Keep authority out of prompts

Do not rely on system instructions such as “never use production without approval.” Enforce the rule in code by withholding production tools, credentials, and routes until the policy and approval checks pass.

Build the tool catalog per request

The catalog exposed to the model should be the minimum set needed for the current workflow stage. A read-only investigation should not expose remediation tools simply because the agent might need them later.

Revalidate after pauses

An approval may arrive minutes or hours after the proposal. Before execution, revalidate identity, scopes, policy version, target state, tool version, approval scope, expiration, and budget.

Require idempotency for retryable side effects

The controller should create the idempotency key. The server should enforce it. The model should not be responsible for deciding whether a retry is safe.

Verify outcomes independently

Do not accept “success” because the model interpreted a positive tool response. Query the authoritative system, compare the observed state with the expected post-condition, and store the evidence.

Make denial a normal result

The controller needs structured outcomes for denied, approval-required, budget-exceeded, conflict, stale-state, unsupported, and unsafe requests. A denial is not necessarily an exception. It is often the correct policy result.

Preserve one trace across every layer

The business request, model proposal, policy decision, approval, MCP call, downstream action, verification, and final outcome should share a trace or run identifier.

Test the control plane without trusting the model

Use deterministic tests to prove that unauthorized environments, expired approvals, invalid scopes, duplicate idempotency keys, budget exhaustion, stale workflow versions, and prohibited tools are blocked even when the model requests them correctly.

Give every layer a kill switch

Operators should be able to disable an agent, workflow type, MCP server, individual tool, target environment, credential, or downstream route without redeploying the entire platform.

Decision Checklist

Before treating MCP as part of a production agent architecture, confirm the following:

• The authenticated requester is bound to every run.
• The agent workload identity is separate from the requester identity.
• The model cannot create or alter authorization context.
• The controller owns the authoritative workflow state.
• Tool visibility is filtered by identity, task, environment, and risk.
• The controller validates every proposed action before MCP invocation.
• The MCP server performs domain-level authorization and business validation.
• Inbound MCP tokens are audience-bound and are not passed through to downstream APIs.
• Retryable side effects require controller-generated idempotency keys.
• Post-conditions are checked against an authoritative system.
• Approval records are scoped, versioned, and revalidated before execution.
• Budgets cover the complete run, not only the model call.
• Loops, duplicate calls, and no-state-change behavior have stopping rules.
• Every high-impact action produces structured evidence.
• Operators can pause, cancel, disable, and investigate the workflow.

A system that cannot satisfy these controls may still use MCP successfully for low-risk retrieval or developer productivity. It should not be granted broad production authority simply because the integration works.

Operational Implications

The recommended architecture creates separate modules, but it should not create separate accountability.

One service owner must remain accountable for the end-to-end agent outcome. Supporting ownership can be distributed across the AI platform team, identity team, security team, tool owners, application owners, data owners, SRE, and business service owners.

The operating model should define:

• who approves new MCP servers
• who owns each tool contract
• who assigns agent identities and scopes
• who writes and reviews runtime policy
• who owns the workflow state service
• who monitors task failures and budget anomalies
• who investigates incorrect or duplicated actions
• who can disable an agent or tool during an incident
• who reviews exceptions and residual risk
• who decides when an agent earns more authority

This separation also improves change management. A model update, tool schema change, policy change, server upgrade, or downstream API change should not silently alter the effective authority of the system. Each component needs versioning, compatibility checks, regression tests, rollout controls, and rollback criteria.

The control plane should be observable as a service in its own right. Measure policy denials, approval wait time, wrong-tool proposals, schema failures, duplicate suppression, task cancellations, verification failures, compensation attempts, budget stops, and manual escalations. Those signals reveal whether the architecture is controlling risk or merely recording activity.

Conclusion

MCP is one of the strongest building blocks available for enterprise agent interoperability. It standardizes how AI applications discover capabilities, exchange structured context, invoke tools, receive results, and, in supported scenarios, track deferred work.

The mistake is not using MCP. The mistake is confusing interoperability with authority.

A production agent needs a trusted controller that owns identity, workflow state, policy, risk, approvals, budgets, retries, stopping, and lifecycle decisions. It needs a governed MCP tool plane that exposes only approved capabilities. It needs MCP servers that enforce domain rules and return structured evidence. It needs an execution runtime that contains side effects and verifies outcomes. It needs enterprise systems to remain authoritative.

The practical architecture is:

The agent proposes. The controller authorizes. MCP carries the governed interaction. The runtime executes and verifies.

Part 2 of this series will move inside the trusted controller and define the services, state model, policy decisions, approval checkpoints, budgets, retry rules, and termination controls required to operate an enterprise agent safely.

External References

• Model Context Protocol: Architecture overview
  Canonical URL: https://modelcontextprotocol.io/docs/learn/architecture
• Model Context Protocol: Specification
  Canonical URL: https://modelcontextprotocol.io/specification/2025-11-25
• Model Context Protocol: Tools
  Canonical URL: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
• Model Context Protocol: Tasks
  Canonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks
• Model Context Protocol: Authorization
  Canonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
• Model Context Protocol: Security Best Practices
  Canonical URL: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• A2A Protocol: Agent2Agent (A2A) Protocol Specification
  Canonical URL: https://a2a-protocol.org/latest/specification/

The post MCP Is the Tool Plane, Not the Agent Controller: Enterprise Agent Control Plane Series, Part 1 appeared first on Digital Thought Disruption.