What is an AI control plane?

Every enterprise is rolling out AI faster than IT can keep up with. Claude, ChatGPT, Codex, Cursor, Copilot and many more: these aren’t experiments anymore, they’re how employees work. And most of the organizations deploying them have no idea which tools are in use, by whom, or with what data.

Organizations that go all-in on AI with no guardrails get burned — an agent runs a destructive query against production, an employee pipes customer data into a consumer chatbot, an internal MCP server appears overnight against the warehouse with credentials no one is tracking. Organizations that respond by banning AI outright get left behind by competitors who didn’t.

The AI control plane unlocks the goldilocks path: full adoption with the monitoring, identity, and guardrails to keep it from blowing up. It’s the governing layer between every AI agent in the company and every system they’re allowed to reach: the part that decides what’s connected, who’s authenticated, what’s inspected, and what’s measured. The name borrows from networking, where Kubernetes, service meshes, and Cloudflare already have control planes for the same reason: they name the part of the system that governs the rest of the system.

The insight driving the category is that enablement and governance are the same problem seen from two sides. Any architecture that treats them separately ends up failing at both.

What follows is drawn from thirty days of conversations with more than 50 technology executives actively navigating this rollout.

Every company is becoming AI-native

Every enterprise is under pressure to become AI-native. Boards have told CEOs to deliver. CEOs have pushed the mandate down to CTOs, CIOs, CISOs, and the newly appointed Chief AI Officers. Budgets have been unlocked. Announcements have been made.

The problem these executives are discovering is that “become AI-native” isn’t a simple checkbox exercise. Much like the move to the cloud, the move to AI-native entails a long list of platform components that need to be put in place. AI agents like Cursor, Claude Code, Copilot, and ChatGPT are merely the tip of the iceberg. After purchasing licenses, every company runs into a set of problems that need to be solved:

• There’s no central place to provision MCP, Skills, and other tools. Every team picks its own.

• There’s no consistent identity layer. People connect their personal accounts to enterprise data.

• There’s no visibility into what’s being used, by whom, with what data.

• There’s no way to enforce policy on tools IT can’t see.

• There’s no measurement of adoption, and therefore no way to report progress against the board mandate.

Companies that respond by locking everything down kill adoption. Companies that don’t lock anything down get incidents. Neither path is survivable for long.

This is the problem the AI control plane exists to solve.

Enablement and governance: two jobs in tension

The AI control plane has two jobs. The first is enablement: rolling out AI capabilities across the organization so every team can use them. The second is governance: making sure that rollout doesn’t cause a security incident, a data leak, a compliance violation, or a regulatory problem.

These two jobs are in tension. Enablement wants to remove friction. Add more tools, connect more data, give more people access. Governance wants to proceed cautiously. Inspect every interaction, scope every permission, audit every action.

Splitting enablement and governance across two teams always fails

The instinctive organizational response is to assign these jobs to different teams: IT or security owns governance, and a platform team or newly-appointed Chief AI Officer owns enablement.

This split has a consistent failure mode. The governance team, lacking visibility into what people actually need from AI, designs controls that block the most useful capabilities. The enablement team, under pressure to ship, routes around the controls or negotiates exceptions. The result is either a governance posture that exists on paper while employees use personal ChatGPT accounts for real work, or an adoption program that moves fast and creates incidents the security team discovers in postmortems.

A single layer resolves the conflict

The insight behind the control plane is that these are not two separate problems. They are the same problem seen from two sides. Enablement without governance produces incidents that eventually force a crackdown that kills adoption. Governance without enablement produces a posture that looks safe on paper while employees route around it with personal accounts and shadow tools.

A control plane resolves the tension by making governance a property of the enablement layer itself. You don’t choose between rolling AI out and keeping it safe. The thing that rolls it out is the thing that keeps it safe.

This is why the networking analogy is precise. Kubernetes does not have a separate team for “letting workloads run” and another for “making sure workloads run safely.” The control plane does both, by design.

The shape of an AI control plane

Before diving into the components, it’s valuable to look at the jobs to be done. We believe the control plane has four functions:

Connect. Bring every AI agent (Claude, ChatGPT, Cursor, Copilot, Codex, internal agents, product agents) and every system that matters (SaaS tools, internal APIs, databases, skills) onto a single plane. No custom integration work per tool. Per-team registries. SSO-integrated so identity flows through. So what: new AI capabilities reach the right teams in days instead of months, and IT stops chasing a moving target of ad-hoc integrations.

Control. Enforce who can use what, under what conditions. Scoped access by team or role. Credential management that doesn’t rely on employees pasting API keys into config files. OAuth 2.1 where the protocols support it. Full audit trail. The shift that matters here is that policies become executable rules rather than documents in a wiki: versioned, testable, and applied automatically at the point of use rather than relied on to be remembered. That’s the difference between a policy written into a Confluence page and a policy the control plane enforces on every request. So what: the policy on paper is the policy at runtime. Audits stop surfacing questions the CISO can’t answer.

Secure. Apply AI guardrails to every prompt, response, and tool call in real time. Active blocking of PII and data exfiltration. Passive detection of prompt injection and shadow MCPs. Alert the incident response team when something warrants it. Integrate with existing SIEM and security tooling rather than replacing it. So what: incidents are detectable in real time instead of discovered in postmortems, and the response team works from the tooling they already know.

Observe. Measure what’s actually happening. Visibility of token use by team, client, tool, and user. Track adoption against organizational targets. Produce the data that proves, or disproves, that the AI investment is working. So what: the board mandate has metrics behind it instead of anecdotes, and leadership can tell real adoption from theater.

The components of the AI control plane

Several categories of technology have emerged over the last eighteen months, each addressing a slice of the problem. Understanding what each does, and what it doesn’t do, is the fastest way to see why the control plane framing is necessary.

LLM gateways. An LLM gateway sits between applications and the language models they call. It handles routing across providers (OpenAI, Anthropic, Google, open-source), manages API keys, enforces rate limits, and often provides caching and cost tracking. Portkey and LiteLLM are examples. LLM gateways solve a real problem (managing model access at scale), but they sit at the model layer. They see prompts and completions. They don’t see which employee asked the question, which tool the AI called, which data was returned, or whether any of it should have been allowed.

MCP gateways and MCP security tools. The Model Context Protocol has become the emerging standard for how AI agents connect to tools and data. MCP gateways sit in front of MCP servers and handle authentication, authorization, and inspection of tool calls. Products like Speakeasy, Runlayer, and MintMCP have a focus here. These tools solve the discovery, security and observability slice of the problem, specifically protecting the tool-calling path, but they don’t handle model routing, organization-wide adoption, or the broader enablement story.

Identity and access controls. Enterprises already have identity providers (Okta, Azure AD, Google Workspace) and SSO infrastructure. Extending these systems to AI tools is non-trivial. Most AI agents were built for individual users, not enterprise identity, and scoping permissions to teams, roles, or individual tools requires a layer the identity provider itself doesn’t provide.

Observability. Observability in the AI context means visibility into what employees and agents are actually doing with AI: which tools are being used, by which teams, with what frequency, producing what outcomes. This is the layer executives most often realize is missing first, because it’s the one they need to report against the board mandate. Traditional APM and logging tools don’t cover this; they weren’t designed to capture the semantics of AI interactions.

Policy and threat detection. Real-time inspection of prompts, responses, and tool calls, looking for PII leakage, prompt injection, data exfiltration, and policy violations. The primitive that makes this possible at the AI agent itself is the agent hook, a lifecycle handler that fires on every prompt and tool call. Some of this overlaps with MCP security. Some of it is new territory because the threats are new.

Each of these categories is real and each solves a real problem. The reason none of them is sufficient on its own is structural: they see different parts of the same interaction.

The AI control plane is what you get when you put these pieces on a single architectural foundation so they see each other. The value is not in any individual component. It’s in the integration.

AI guardrails and AI risk management in the control plane

The AI control plane is how enterprises operationalize two terms that show up across vendor pitches and analyst reports: AI guardrails and AI risk management.

AI guardrails are the runtime controls that inspect and constrain what AI agents are allowed to say and do — blocking PII leakage, prompt injection, unsafe tool calls, and data exfiltration. In the control plane, that work is done by the Secure function: real-time inspection of every prompt, response, and tool call, integrated into existing SIEM tooling rather than replacing it.

AI risk management is the broader program of identifying, measuring, and mitigating the risks AI introduces to the business: regulatory, security, operational, and reputational. The control plane is the execution layer for that program. Connect gives risk teams a real-time inventory of every AI agent and tool in use. Control turns policy on paper into rules enforced at runtime. Secure detects active threats. Observe produces the audit trail and metrics risk and compliance teams need to evidence the program.

These aren’t competing categories. They’re different layers of the same architecture, and the control plane is what lets one organization run both.

AI control plane vs AI governance framework

Most AI governance frameworks — NIST AI RMF, ISO/IEC 42001, and the internal policy decks and responsible AI commitments that follow them — describe what an organization should do: identify AI use cases, classify risk, document controls, monitor outcomes, review periodically. The framework is the program.

An AI control plane is the runtime that executes the program. The framework says “log every interaction with sensitive data”; the control plane is the thing that actually intercepts the interaction and writes the log. The framework says “scope access by role”; the control plane is the thing that evaluates the role on every request and decides what passes.

The two are complementary. An AI governance framework without a control plane is a document. A control plane without a framework is infrastructure with nothing telling it what to enforce. AI governance tools and AI governance platforms that ship policy templates without runtime enforcement leave the gap between policy and behavior unclosed. The control plane closes it.

Why the AI control plane is emerging now

Three forces are converging to make this a visible category rather than an academic concept.

The mandate is real and top-down. Boards have told CEOs to deliver AI transformation. CEOs have tasked their C-suite with executing. The executives who now own this (CTOs, CIOs, CISOs, Chief AI Officers) need to produce something concrete. They are actively looking for a category to buy from.

Sprawl is visible. Most enterprises, when they run an audit, discover they have dozens of AI tools in use across the organization, most of which were never approved and none of which are centrally managed. The gap between official AI policy and actual AI usage has become wide enough that leadership can see it.

Risk is priced in. Data leaks through consumer AI tools, prompt injection attacks on agent systems, regulatory pressure from the EU AI Act, and the general anxiety around data handling have made the cost of doing nothing concrete. AI risk management has moved from a board-deck slide to an operational program, and the conversation has shifted from “what if something happens” to “what are we doing about the things that are already happening.”

The category is being named now because the conditions that make it necessary have all arrived inside the same eighteen-month window.

Why existing AI governance tools don’t absorb the category

Three types of incumbent vendor could plausibly claim to own this space. Each has a structural reason they will struggle to.

None of this means incumbents are irrelevant. It means the window for category definition is open, and the organizations that establish the architecture and the vocabulary now will set the terms of how buyers evaluate everything that follows.

What a mature AI control plane enables

When the pieces are in place, the operational shape of the organization changes in a handful of specific ways.

AI reaches every team in days, not months

AI is available to every employee on day one, not after a months-long provisioning process. New tools get added to the central registry once and are available to the teams entitled to use them. Teams don’t stand up their own integrations in parallel.

Consistent permissions across every agent and tool

Identity, permissions, and policy are enforced consistently across every AI agent and every tool. An engineer using Cursor, a salesperson using ChatGPT Enterprise, and an analyst using an internal agent are all subject to the same permission model, because the permissions live in the control plane rather than in each agent.

Security visibility into the AI layer

Security has visibility into the AI layer in the same way it has visibility into the network, the endpoints, and the cloud. Incidents are detectable in real time. Audits have data to draw from. The CISO is not operating blind.

Adoption metrics for leadership

Leadership has numbers. Adoption by team. Which tools are producing outcomes and which are shelfware. Where AI is moving the business and where it isn’t. The board mandate has metrics behind it instead of anecdotes.

Reusable infrastructure for new AI projects

New AI initiatives (a new agent, a new internal tool, a new workflow) ship on shared infrastructure instead of reinventing the connection, identity, and governance layers every time. The second, third, and tenth AI project cost a fraction of the first.

None of this is speculative. The components to do each of these things exist today. What’s been missing is the framing that puts them together under a single architecture and a single name.

A note on Speakeasy

Speakeasy is building the AI control plane. We started with the connection and identity layer, because that’s where the pain is most acute for companies trying to move beyond bottom-up AI adoption, and we’ve been extending across the four functions since. We are not the only company working on this, and we won’t be. But we believe the category is real, we believe the window for defining it is open, and we believe the organizations that take the architecture seriously now will be meaningfully better positioned than the ones that wait for the market to tell them what to buy.

If you’re one of the executives tasked with turning an AI mandate into an operating reality, the most useful thing you can do this quarter is draw the architecture of how AI should flow through your organization, figure out which pieces you already have and which you don’t, and decide whether you want to assemble it yourself or build on a foundation designed for it. Either way, the term to have in your head while you do that work is AI control plane. It names the thing you’re actually building.