MCP Needs a Control Plane: How Cosmic Governs Agent Access to Your Content

There is a debate running through the developer community right now about where the Model Context Protocol goes next. One camp wants an app store: a marketplace where you browse, install, and rate MCP servers like extensions. Another camp argues that discovery is the easy part, and that what MCP actually needs is a control plane: a governance layer that decides what each agent is allowed to read, write, and do once it connects.

The control plane argument is the correct one. An app store solves the question of how you find an MCP server. A control plane solves the question that actually matters in production: what happens after the agent is connected and starts making calls against your data.

This post breaks down what a control plane means in practice, why content infrastructure is where it matters most, and how Cosmic's MCP server treats your content as a governed resource from the first request.

Discovery is the easy part

Finding an MCP server is a solved problem. You read the docs, you grab a connection string, you add it to your client config. A marketplace makes that marginally faster, but it does not change the risk profile of connecting an autonomous agent to a system that holds your production content.

The moment an agent can call tools against your CMS, a different set of questions opens up:

• Which buckets, object types, and fields can this agent read?
• Can it write, or only read?
• Can it publish, or only create drafts?
• Is every action attributed and auditable?
• How is the connection authenticated, and how is that credential rotated or revoked?

None of those are discovery questions. They are governance questions, and they are exactly what a control plane is for.

What a control plane actually controls

A control plane sits between the agent and the resource. It enforces four things on every request:

1. Authentication. Who is this agent, and is its credential valid right now?
2. Authorization. What is this agent allowed to do, scoped to the narrowest set of resources and actions it needs?
3. Auditability. Every read and write is logged and attributed, so you can answer "which agent changed this, and when?"
4. Revocability. Access can be cut instantly, without redeploying anything, the moment a credential leaks or an agent misbehaves.

For a code-execution MCP server, the resource is a runtime. For a content MCP server, the resource is your published, customer-facing content. The blast radius of an over-permissioned content agent is your live site. That is why content infrastructure is the place where the control-plane model matters most.

How Cosmic treats content as a governed resource

Cosmic's MCP server was built around the control-plane model rather than bolted onto it. Here is how each layer maps to the protocol.

Scoped keys, not master access

Every Cosmic connection is authenticated with API keys that are scoped to a single bucket. You hand an agent a read key when it only needs to read, and a write key only when it genuinely needs to create or update content. The agent never holds account-level credentials, so a leaked key exposes one bucket, not your whole organization.

When an agent needs to write, you provision a separate client with a write key. The separation is explicit in code, which makes the permission boundary obvious in review.

Draft-by-default keeps a human in the loop

An agent creating content does not mean an agent publishing content. New objects can land as drafts, which means the agent does the work and a person makes the call on what goes live. That single default turns "an autonomous agent has write access to our site" into a reviewable, low-risk workflow.

Every action is attributed

Cosmic logs who created and modified each object, and that attribution carries through to analytics. With Cosmic Insights you can see content performance broken down by author type: human, agent, or automation. The control plane is not just about blocking bad actions, it is about being able to answer questions afterward. You always know which agent touched what.

Managed and hosted, so there is nothing to patch

Because Cosmic is a managed content API, there is no self-hosted MCP server to keep patched, no plugin supply chain to audit, and no runtime for you to harden. The control plane runs as part of the platform. With supply-chain attacks on self-hosted packages making headlines almost weekly, removing an entire class of infrastructure you have to secure yourself is a real reduction in surface area.

Where this fits with zero-touch OAuth

The MCP community recently shipped Enterprise-Managed Authorization, which makes zero-touch OAuth a stable part of the standard. That is the authentication leg of the control plane getting formalized at the protocol level. We wrote about what that means for content stacks in MCP Server Security: What Zero-Touch OAuth Means for Your Content Stack. The short version: the protocol is moving in exactly the direction the control-plane argument points, and content platforms that already scope and attribute access are positioned to take advantage of it.

If you are newer to MCP and want the fundamentals first, start with What Is an MCP Server? How It Works, and How to Build One, then see how a cloud-native server compares to a self-hosted one in Cosmic MCP Server vs Strapi MCP.

The takeaway

A marketplace would make MCP servers easier to find. A control plane makes them safe to run. For content infrastructure, where the resource on the other side of the connection is your live, customer-facing site, governance is the feature that matters: scoped keys, draft-by-default writes, full attribution, and instant revocation.

Cosmic's MCP server gives agents structured, governed access to your content with those controls built in. You decide what each agent can read, what it can write, and what it can publish, and you can see and undo everything it does.