What Is an AI Control Plane? Why the Industry Still Hasn’t Agreed

A quick note before I start: this is not meant to be a definitive answer on what the AI control plane will become. The category is still very new, and a lot of what I have written here comes from speaking with customers, studying how different vendors are approaching the problem, and trying to make sense of where the market is heading. These are some of my current learnings, and I hope they are useful to anyone thinking about the same questions.

Spend enough time around enterprise AI right now and almost everything starts to sound like a control plane.

An AI gateway is described as a control plane. An agent governance platform is a control plane. A platform coordinating coding agents across the software development lifecycle is a control plane. Microsoft has a control plane for agents. Salesforce has an agent control plane. ServiceNow has an AI Control Tower. Other companies use the same language for observability, security, model governance, or the infrastructure developers use to move AI applications and agents into production.

The confusing part is that none of them are necessarily wrong.

A control plane is not defined by a particular feature such as identity, policy, routing or observability. It is defined by the system underneath it that is being controlled. In Kubernetes, for example, the control plane manages the overall state of a cluster while worker nodes execute application workloads. The control plane decides what should happen; execution takes place elsewhere. Kubernetes describes this architecture in terms of the components that manage the cluster and the nodes that run workloads.

AI is beginning to adopt the same architectural pattern, but the word "AI" covers such a wide range of systems that saying "AI control plane" tells you surprisingly little about what is actually being controlled.

At 8090, the underlying system is software development. Its Software Factory describes an AI-native software development control plane that coordinates people, context and coding agents from requirements through implementation. Portkey uses a more traditional infrastructure separation, with its AI Gateway operating in the data plane while a control plane manages configuration, routing information and analytics. TrueFoundry expands that infrastructure boundary across models, applications, agents, MCP and other production AI infrastructure. Fiddler approaches the problem through telemetry, evaluation, runtime enforcement and governance. Microsoft Agent 365 starts with an enterprise estate of agents and extends identity, security, administration and governance to them.

Speakeasy uses the same phrase for something broader again: a layer spanning employees, AI clients, coding agents, internal agents, identity, enterprise tools, policy and observability. Its definition explicitly includes products such as Claude, ChatGPT, Cursor and Copilot alongside internal and autonomous agents, and frames the control plane around connecting, distributing, securing and observing AI across the organization.

These products can all legitimately call themselves control planes because they are controlling different systems.

That leads to the question I think matters much more than the definition itself:

What exactly should the AI control plane control?

Should engineering have a control plane for the AI applications it builds? Should software teams have another for coding agents? Should IT and Security have one for ChatGPT, Claude, Cursor, Codex and the other AI products employees adopt directly? What happens to agents appearing inside SaaS applications? Should autonomous agents with their own identities live somewhere else again? And as employees increasingly become agent builders themselves, do those categories remain separate at all?

I do not think the market knows yet.

The AI control plane is not a finished category. We are watching its boundaries being drawn in real time.

What a control plane actually is

The useful thing about the term "control plane" is that it separates desired state and governance from execution.

In Kubernetes, the API server exposes the system's control surface, controllers continuously reconcile actual state against desired state, the scheduler makes placement decisions, and worker nodes execute workloads. The important concept is not any individual component. It is the separation between deciding how the system should operate and performing the underlying work.

The same principle can be applied to AI.

A control plane might know that a particular user is entitled to use a particular agent, that the agent can access certain tools, that a sensitive action requires approval, that one model cannot receive a certain class of data, and that every action should generate an audit record. The control plane does not necessarily need to host the model, execute the agent, run the business application or inspect every byte of traffic itself.

Those decisions can be enforced at several different places: an AI gateway, an MCP gateway, an API gateway, an endpoint or browser control, an agent runtime, a SaaS integration, an identity provider, or the underlying enterprise system being accessed.

This distinction matters because a control plane and a gateway are not the same thing.

A gateway is usually an enforcement point in the path of traffic. Portkey illustrates the distinction particularly clearly in its enterprise architecture. Its AI Gateway runs in the customer's data plane and processes AI requests, while the managed control plane maintains administrative and configuration state.

TrueFoundry uses the term more broadly, describing a governance layer spanning models, LLM interactions, agents, MCP and agent-to-agent communication, with gateways providing many of the runtime control points.

The important principle is simpler than either implementation:

The control plane determines how the system should behave. The enforcement points make those decisions real.

Once you look at the market through that lens, the apparently contradictory definitions start making much more sense.

There are already several different AI control planes

The first major definition is what I would call the AI infrastructure control plane.

This category grew from the infrastructure developers needed to operate generative AI applications in production. Once companies started building applications on OpenAI, Anthropic, Gemini and open-source models, engineering teams needed routing, provider credentials, retries, rate limits, observability, cost controls, guardrails and model governance.

Portkey is a good example. Its natural control surface is AI traffic moving through infrastructure the engineering team controls. TrueFoundry grew from a similar production-infrastructure problem but now spans models, AI applications, agents, MCP, deployment, routing and governance.

There is a second definition around the agent lifecycle.

Guild describes its control plane around building, deploying, governing and sharing agents. Its governance capabilities include credentials, runtime controls, policies, approvals and auditability, but its natural starting point is an engineering team deliberately building and operating a fleet of agents.

Fiddler comes from a different heritage but increasingly reaches the same object from the trust side. Its control plane focuses on understanding what agents are doing, evaluating their behaviour, monitoring them continuously, enforcing policy and maintaining an audit trail.

Then there is the software development control plane.

8090's Software Factory is not primarily trying to govern AI usage across the enterprise. It is reorganizing the software development lifecycle around humans and coding agents working inside one coordinated system. Requirements, context, architecture, implementation and oversight all belong inside the object being controlled. The system is software production itself.

More recently, another category has emerged around the enterprise agent estate.

Microsoft Agent 365 describes itself as the control plane for agents. It extends familiar enterprise concepts such as identity, registry, lifecycle management, least privilege, Defender security, Purview governance and administrative controls to an increasingly heterogeneous agent estate.

Salesforce MuleSoft Agent Fabric comes at the problem through integration. It focuses on discovering, registering, governing and orchestrating agents across different platforms, with governance around MCP, APIs and agent-to-agent interactions.

ServiceNow AI Control Tower takes an even more management-oriented view, positioning itself as a central place for enterprises to discover, govern, observe and measure AI assets across connected systems.

Finally, another definition is forming around AI being adopted directly across the workforce.

Speakeasy's reference architecture includes people, ChatGPT, Claude, coding agents, internal agents and autonomous workers as callers that need governed access to enterprise systems. Its control plane combines identity, access, policy, security and observability across those interactions. Speakeasy explicitly argues that an enterprise control plane needs both enablement and governance rather than treating them as separate problems.

Runlayer also sits close to this workforce problem, combining discovery of employee AI usage with catalogs, MCP access, identity-aware policy, runtime security and auditability.

Same phrase. Different system boundaries.

The market makes more sense when you ask what is being controlled

Rather than treating every company using the words "AI control plane" as part of one homogeneous category, I find it more useful to group them by where they start.

Developer and AI infrastructure control planes

These products generally begin with AI that a company intentionally builds or deploys. Their strongest control points naturally exist inside infrastructure the company already owns or can instrument.

Software development control planes

8090 is an important outlier because its control plane is not primarily governing AI infrastructure. It is governing how software itself gets produced in a world where coding agents perform an increasing amount of the work.

Enterprise agent control planes

These products start higher in the stack. Their goal is increasingly to give enterprises an inventory and governance layer across agents or AI assets rather than only governing the technical infrastructure used to build them.

Workforce AI control planes

This is the area we are currently most interested in at Kelasa. The starting problem is not only how to govern an agent engineering deliberately deployed. It is how companies understand and manage AI being adopted across the workforce through ChatGPT, Claude, Cursor, Codex, MCP-connected tools and increasingly agentic SaaS products.

The important caveat is that none of these categories is fixed.

Airia already reaches beyond traditional agent infrastructure into AI discovery across the enterprise. Microsoft is extending Agent 365 beyond agents created inside Microsoft's own ecosystem. Salesforce is discovering and governing agents across multiple platforms. ServiceNow is moving deeper into cross-enterprise AI discovery and control. Runlayer and Speakeasy are moving further into runtime policy and identity.

The market is not settling into permanent camps. It is converging from several directions.

The most important boundary may be who controls the runtime

"Developer AI" and "employee AI" are useful labels today, but I suspect the more durable technical distinction is who controls the runtime and how the AI enters the organization.

When a company builds an AI application itself, engineering controls most of the execution path. The organization chooses the model, writes the application, controls deployment and can insert gateways, SDKs, tracing, credentials and policy directly into the architecture.

That is why so much of the first generation of AI infrastructure formed around developer-built AI. It is the easiest place to create a reliable chokepoint.

An employee using ChatGPT is different. The company may administer the enterprise account, but it does not own ChatGPT's runtime. The same applies when an engineer opens Cursor or Claude Code, or when a business user turns on an AI feature inside a SaaS application.

The enforcement architecture therefore changes.

You might discover usage through endpoint, network or identity signals. You might apply some controls in the browser. You might give an AI client governed access to enterprise tools through MCP. You might rely on provider APIs for administration and audit data. You might apply authorization again when the AI reaches Salesforce, GitHub, a database or another underlying system.

No single chokepoint necessarily sees everything.

SaaS-embedded AI creates another variation. The enterprise may control its Salesforce or ServiceNow tenant but not the AI runtime itself. The SaaS provider controls execution while the enterprise controls tenant configuration, identity and whatever governance surface the vendor exposes.

Autonomous agents introduce yet another problem. They may have their own identities, credentials, scopes, schedules and lifecycle rather than simply inheriting all of the permissions of the employee who initiated a task.

These are not edge cases. They are increasingly different forms of the same enterprise AI environment.

And the standards underneath them are still being assembled.

NIST launched an AI Agent Standards Initiative in February 2026 focused on interoperable and secure agents, including identity, authorization and protocol interoperability. MCP itself is evolving quickly as the ecosystem attempts to standardize how agents reach external tools and data.

We are trying to define the AI control plane while some of the most important primitives underneath it are still changing.

Employee AI deserves more attention

There is another reason I think the control-plane conversation has historically been too focused on AI systems deliberately built by developers: that is not the only place enterprise AI adoption is happening.

Menlo Ventures estimates that the application layer represented approximately $19 billion of enterprise generative AI spending in 2025. Horizontal AI represented $8.4 billion, with general-purpose copilots such as ChatGPT Enterprise, Claude for Work and Microsoft Copilot accounting for an estimated $7.2 billion. Horizontal agent platforms represented approximately $750 million. Coding represented another estimated $4 billion category.

These are Menlo's market estimates rather than audited industry revenue figures, so I would not treat the exact numbers as settled market facts. The relative scale is still instructive.

Enterprise AI is not arriving through one AI platform team.

It is arriving through general-purpose AI clients. It is arriving through coding agents. It is arriving through SaaS applications employees already use. It is arriving through MCP connections an engineer can configure in minutes. It is arriving through agents engineering deliberately builds and through agents vendors bundle into software the company already owns.

These trends are happening simultaneously.

That changes the governance problem.

If your control plane assumes AI means an API call from an application your developers built, it can provide excellent governance over that traffic while still seeing very little of an employee using a third-party AI client.

If it assumes AI means an agent registered in an agent platform, it can provide excellent lifecycle governance over that agent while potentially missing AI that entered the company another way.

If its main control point is the browser, it may have excellent visibility into employee interactions but less visibility into an autonomous backend agent running continuously with its own credentials.

If it starts with the coding environment, it can solve a critical engineering problem without necessarily solving the AI being adopted by finance, legal, marketing or sales.

The control point determines the visibility.

This is why I do not think the future of AI governance can be understood only through the infrastructure developers are deploying today.

The boundary between employee AI and agents is already starting to blur

There is another reason I am hesitant to treat these categories as permanent.

What we call an AI "client" today is increasingly becoming an agent platform.

ChatGPT can call tools and perform longer-running tasks. Claude can use skills and tools. Coding agents can operate across repositories, terminals, browsers and external systems. SaaS products are embedding agents directly inside normal application workflows. Employees can increasingly create automations and agents without writing traditional software.

The person using an AI client today may be supervising several agents tomorrow.

Likewise, "coding agent" may eventually become a historical label rather than a clean product category. Software development happened to be one of the first places where long-running agentic work became economically valuable and technically practical. The same interaction pattern can spread into research, finance, sales, legal, operations and many other forms of knowledge work.

This means the distinction between an employee using AI and an organization deploying an agent becomes harder to maintain.

An employee might instantiate an agent from a prompt, give it access to company tools and delegate a multi-step task without ever thinking of themselves as somebody who "deployed an agent."

At that point, which control plane owns it?

The workforce control plane because an employee created it? The agent control plane because it is now autonomous? The SaaS platform because that is where it runs? The integration control plane because it accesses enterprise systems through APIs? The identity system because the most important question is whose authority it operates under?

These questions sound theoretical until products make them ordinary.

I think that happens faster than most enterprise architecture does.

A control plane cannot rely on one universal chokepoint

There is an architectural consequence to all of this.

Traditional infrastructure often has relatively clean boundaries. A Kubernetes cluster has a defined control surface. A cloud provider controls the infrastructure it exposes. A network has routers through which traffic flows.

Enterprise AI is messier because the enterprise does not own every execution environment.

ChatGPT may be operated by OpenAI. Claude by Anthropic. Cursor has its own runtime. Salesforce controls its SaaS agents. Developers may run an internal agent in AWS. An MCP server may execute inside the company's VPC. A local coding agent may operate on an employee's laptop. Another autonomous agent may run continuously as a non-human identity against enterprise APIs.

Trying to force all of that through one universal proxy may end up defining the governance problem according to what the proxy can see rather than what the company actually needs to manage.

A more realistic architecture may involve a control layer coordinating several enforcement points.

Some model policies may be enforced at an AI gateway. Tool access might be enforced at an MCP or API gateway. A provider integration might manage access inside a SaaS AI product. Endpoint or browser software might help govern employee interactions. The destination application can still enforce its own authorization model. An agent runtime might enforce sandboxing or human approval.

The important point is not that this is definitely how the market will settle.

It is that the control plane does not necessarily need to become the entire data plane.

Speakeasy takes a more centralized view of the problem, arguing that AI governance needs correlation across user identity, model calls, tool calls, policy and audit rather than leaving these traces across disconnected systems. I agree with the underlying problem. Where I think the category is still open is exactly how much of that enforcement ultimately needs to run through one technical path versus how much can be coordinated across distributed enforcement surfaces.

That distinction will matter enormously as the category matures.

The market has not decided how many control planes an enterprise needs

Forrester's emerging framework is useful here. It separates the agent ecosystem into functional planes for building, orchestrating and controlling agents and argues for governance that can extend across heterogeneous agent environments rather than living only inside the platforms that create them.

But that still leaves a larger question unanswered:

Does every kind of enterprise AI ultimately belong under the same control plane?

One possible outcome is specialization. Engineering maintains a control plane for internally developed AI applications. Software teams use another system for coding agents. IT governs workforce AI separately. Major SaaS platforms govern their own agents. These systems exchange identity, inventory and policy signals but remain distinct because the technical enforcement mechanisms are genuinely different.

There is a reasonable argument for this architecture. Governing an LLM request in a gateway is not the same technical problem as controlling what an employee shares through a browser, which is different again from managing a persistent autonomous agent operating with its own identity.

A second possibility is federation. Specialist systems remain at their natural enforcement points while a higher-level enterprise layer becomes the source of truth for some combination of inventory, ownership, policy, identity, lifecycle and audit.

A third possibility is that one of the major enterprise platforms expands far enough to become the de facto control plane. Microsoft has Entra, endpoints, Microsoft 365, Defender, Purview, Copilot and Agent 365. ServiceNow has CMDB, workflows, GRC, IT operations and AI Control Tower. Salesforce has business applications, MuleSoft, APIs and Agent Fabric.

Their ability to connect AI governance to the systems they already control gives each of them a natural advantage.

But there is also an inherent tension in a provider-owned control plane. Enterprises rarely use a single cloud, a single model provider, a single SaaS ecosystem, or a single agent framework.

A fourth possibility is therefore that a genuinely independent category emerges whose role is to coordinate AI governance across providers without becoming every underlying runtime or security product itself.

It is too early to know which outcome wins.

My suspicion is that the answer will involve some combination of specialization and federation. That is an opinion, not a settled architectural fact. The control points across identity, endpoints, SaaS, gateways, agent runtimes and enterprise applications are too useful to disappear, while the fragmentation across those systems creates an obvious need for greater coordination.

The interesting question is which layer eventually earns the right to be called the AI control plane.

Our view at Kelasa

At Kelasa, we are not trying to answer that entire market question today.

We do not think we need to claim that every AI application, developer-built agent, coding agent and SaaS agent will eventually be governed through one technical control plane. The category is too young, the underlying primitives are still evolving, and the boundaries between these forms of AI are becoming less clear every month.

What we are much more confident about is where there is an immediate problem.

Much of the first generation of AI infrastructure begins with a company deliberately building an AI application or agent. The organization knows it exists, engineering controls its runtime, and governance can be inserted somewhere into the development or production path.

But that is not how a large part of AI is entering companies today.

Employees adopt ChatGPT and Claude. Engineers use Cursor, Claude Code and Codex. Teams connect tools through MCP. AI capabilities appear inside SaaS applications that were purchased long before anyone thought of them as agent platforms. Increasingly, employees can create their own automations and agents without waiting for a central engineering team.

For IT and Security, the first problem is often not:

How do I govern the agent my AI engineering team built?

It is:

What AI is already being used across the company, how do I give employees a governed way to use more of it, and how do I maintain control as those systems become connected to company tools and data?

That is where Kelasa is starting.

We describe the job as Discover, Enable, and Govern AI across the organization.

Discovery matters because companies cannot govern only the AI they already know about. As adoption becomes distributed, understanding which AI products, agents, tools, and connections actually exist becomes the starting point.

Enablement matters because governance cannot mean discovering AI and reflexively blocking it. Employees are adopting these products because they are useful. If the approved path requires weeks of approvals while the unapproved path requires a browser tab and a credit card, companies should not be surprised when shadow AI grows.

The governed path should be easier than the ungoverned one.

Governance matters because AI is moving from generating answers to taking actions. Identity, permissions, access, approvals, auditability and revocation become much more important when AI can reach Salesforce, GitHub, a database, a financial system or another enterprise application.

That is deliberately a thesis about the problem Kelasa is solving today, not a claim that Kelasa must eventually own every form of AI governance inside the enterprise.

Employee AI may remain its own category. Coding agents may require a separate control plane. Developer-built agents may continue to be governed primarily through AI infrastructure platforms. SaaS platforms may develop their own governance boundaries. These systems may eventually federate. Or the distinction between them may gradually disappear as AI clients become agents and employees become agent builders.

We do not think the industry knows yet.

What seems much clearer is that AI adoption is becoming heterogeneous, and enterprises increasingly need ways to manage it across more than one provider, one runtime and one interface.

That is the problem Kelasa is focused on today.

A useful test for every AI control plane

Until the category becomes clearer, there is one question I think enterprises should ask every vendor using the words "AI control plane":

What do you control, and what can you not see?

If the control plane depends on an LLM gateway, what happens when AI does not use that gateway?

If it governs registered agents, what happens to an agent nobody registered?

If its enforcement lives inside a browser, what happens to an autonomous backend agent?

If it controls the software development lifecycle, what happens to AI used by finance or legal?

If it manages one SaaS ecosystem, what happens outside that ecosystem?

If it can discover AI but cannot help provision or govern access to it, what happens after discovery?

If the product controls MCP traffic, what happens when an application calls the underlying API directly?

If policy is defined centrally, where is it actually enforced?

If an employee asks an AI system to perform an action, whose identity reaches the underlying system?

If the control plane goes unavailable, does AI stop working, fail open, fail closed, or continue under cached policy?

How portable are the policies, identities and audit records if the enterprise changes model provider, gateway or agent framework?

None of these limitations automatically makes a product bad.

They tell you where its architectural boundary sits.

And that is the point.

The mistake is not having a boundary. Every control plane needs one.

The mistake is confusing the boundary of a product with the boundary of enterprise AI.

Where does the AI control plane end?

The AI control plane category is being created at the same time as the systems it is supposed to govern.

Agents have only recently become capable enough to operate for meaningful periods, use tools and interact with business systems. MCP is still evolving. Agent identity is still being standardized. Coding agents are becoming more autonomous. AI clients are gaining agentic capabilities. SaaS applications are embedding their own agents. Employees who previously consumed software can increasingly create automation themselves.

It would be strange if the industry's architecture had already settled.

So I think the biggest unanswered question in the AI control plane market is not which company has the best gateway, the most complete agent registry, the strongest policy engine or the most comprehensive observability dashboard.

It is much more fundamental:

Where does the control plane end?

Does an enterprise need one control plane for developer-built AI and another for the workforce? Does identity become the common layer? Does a federated control plane coordinate policy across gateways, endpoints and SaaS platforms? Do the existing enterprise platforms absorb the category? Or does AI become sufficiently pervasive that a new independent management layer emerges above them?

We will find out.

At Kelasa, we are starting with the part of that problem that enterprises are being forced to confront: AI spreading directly across the workforce through AI clients, coding agents, tools, MCP connections and increasingly agentic SaaS.

We do not need to know the final boundary of the AI control plane to know that this part needs a better one.

Frequently asked questions

What is an AI control plane?

An AI control plane is a management and governance layer that determines how an underlying AI system should operate. The exact definition depends on what is being controlled. Some control planes govern model traffic, others govern developer-built agents, coding agents, enterprise agent estates, employee AI or the software development lifecycle.

Why are there different definitions of AI control plane?

Because "AI" is not one system. A model gateway, agent platform, coding environment and employee AI ecosystem all have different execution environments and control points. Vendors using the term AI control plane are often controlling different underlying systems.

What is the difference between an AI gateway and an AI control plane?

An AI gateway typically sits in the execution path and processes AI traffic. A control plane generally maintains configuration, policy, identity, governance or desired state for an underlying system. A gateway can be one enforcement point controlled by a broader control plane.

What is an agent control plane?

An agent control plane governs AI agents across some portion of their lifecycle or runtime. Depending on the product, this may include identity, registration, permissions, deployment, policy, security, observability, approvals and lifecycle management.

Is an MCP gateway an AI control plane?

An MCP gateway can operate as a control point for MCP traffic by managing authentication, authorization, tool access, policy and auditability. It does not automatically govern AI interactions that do not pass through MCP.

What is an enterprise AI control plane?

There is not yet one accepted industry definition. Broadly, an enterprise AI control plane aims to give an organization centralized visibility or governance across some portion of its AI estate. The market is still deciding whether this ultimately becomes one broad enterprise layer or several specialized control planes.

What is the difference between an AI control plane and AI governance?

AI governance describes the policies, principles, responsibilities and processes an organization uses to manage AI. A control plane is infrastructure that can help turn those decisions into operational controls. Governance can exist without a control plane, and a control plane still needs governance policies to determine what it should enforce.

Do companies need an AI control plane?

That depends on the complexity of the company's AI environment. As AI spreads across multiple models, agents, employee applications, SaaS platforms and enterprise systems, centralized inventory, identity, policy and auditability become increasingly valuable. The architecture used to provide that control is still evolving.

Will enterprises need multiple AI control planes?

Possibly. Developer AI, coding agents, employee AI, SaaS agents and autonomous agents have different control points. These may remain separate, federate beneath a higher-level layer, or eventually converge as the underlying categories blur.

What should companies ask when evaluating an AI control plane?

Start with the system boundary. Ask what the platform can discover, which AI applications and agents it can govern, where policy is enforced, how identity works, what happens outside its gateways or integrations, whether governance extends across providers, and what the product cannot see.

Sources and further reading

• Forrester: Announcing Our Evaluation of the Agent Control Plane Market
• Forrester: Agent Control Planes Still Need a Robust Standards Stack
• NIST: AI Agent Standards Initiative
• Kubernetes: Cluster Architecture
• Model Context Protocol
• Menlo Ventures: 2025 State of Generative AI in the Enterprise
• Portkey: Enterprise Architecture
• TrueFoundry: What Is an AI Control Plane?
• Fiddler: AI Control Plane
• Guild: Control Plane
• 8090: Software Factory
• Microsoft Agent 365
• Salesforce MuleSoft Agent Fabric
• ServiceNow AI Control Tower
• Airia: What Is an AI Control Plane?
• Speakeasy: AI Control Plane
• Runlayer