$HEADLESS SYSTEMS
$ cat /blog/agent-control-plane

You don't have users anymore. You have a fleet.

Petr Pátek··9 min·systems
You don't have users anymore. You have a fleet.

On June 9, 2026, KPMG put 276,000 people and their agents under a single governance plane. The firm is rolling out Microsoft 365 Copilot and Agent 365 across its entire global workforce, in 138 countries, to manage how AI agents get deployed, monitored, and retired. That is not a pilot. It is the first time a top-tier professional services firm has treated agents as a workforce that needs a management layer.

The headless thesis has been that machines are becoming the primary consumers of software. Here is the corollary nobody priced in: once an enterprise runs thousands of machine consumers, it has to govern them like a workforce, and a brand-new layer is forming to do it. Call it the agent control plane: a registry, an identity system, a gateway, and a policy engine that together decide which agents may touch which systems.

This piece takes a position: being callable is no longer enough. Humans got IAM, MDM, and SSO. Agents are now getting their equivalent, and if your product can only be reached through a dashboard a human logs into, it is invisible to the control plane and uncontrollable by it. Build for machines first now means build to be governed by a machine control plane, not just called by an agent.

What is an agent control plane?

An agent control plane is the management layer an enterprise uses to govern a fleet of AI agents. It combines five functions: a registry of which agents exist, an identity for each one, a gateway that mediates what they can reach, a policy engine that enforces the rules, and observability that records what they did. It is the admin console for machine consumers, the same way an MDM console is the admin console for company laptops.

A fleet needs one because agents break every assumption the old admin console made about users. Agents are ephemeral, spawned for a task and destroyed. They are fast, capable of more API calls in an hour than a person makes in a year. They are numerous, and they are delegated, acting on behalf of humans, organizations, or other agents. You cannot manage thousands of them by hand, and you cannot manage them at all if you cannot see them.

That visibility problem is why the registry is the anchor of the whole layer. Before an enterprise can apply policy to an agent, it has to know the agent exists. The control plane starts with an inventory and builds governance on top of it.

Three vendors, one architecture, one quarter

The strongest evidence that the control plane is real is that three independent vendors converged on the same shape inside a single quarter. None of them coordinated. They arrived at registry plus identity plus gateway plus policy because the problem forces that shape.

Microsoft shipped Agent 365 to general availability on May 1, 2026, and calls it, in plain words, the control plane for AI agents. Its Agent Registry uses Defender, Entra, and Intune together to surface unmanaged local agents an organization did not know were running, and it recognizes more than 20 kinds of local agent, including coding agents and MCP servers. Identity, policy, and data controls fire while an agent is being built, not after it misbehaves in production.

Google rebuilt Vertex AI into the Gemini Enterprise Agent Platform and wrapped it in the same governance stack. Agent Gateway acts as the centralized network control plane: it looks up metadata from an Agent Registry, enforces identity-based policy through an Identity-Aware Proxy, authenticates every agent with mTLS, and sanitizes interactions through Model Armor. Agent Identity gives every agent a trackable persona, and the platform integrates with Okta so access decisions defer to the existing identity provider.

GitHub got there first, shipping Enterprise AI Controls and an agent control plane to GA on February 26, 2026.

VendorRegistryIdentityGateway / policy
Microsoft Agent 36520+ agent types, incl. MCP serversEntraDefender + Intune policy
Google Gemini EnterpriseAgent RegistryAgent Identity + Okta, mTLSAgent Gateway, IAP, Model Armor
GitHubAgent control planeEnterprise identityEnterprise AI Controls

Bain’s read of Google Cloud Next 2026 named the pattern the “managed agent workforce”: registry, identity, gateway, observability, security, and cost control assembling into one operating layer. When three platforms independently build the same thing, it stops being a product and becomes infrastructure.

Shadow AI is the forcing function

The registry does not exist because someone wanted a nice inventory. It exists because enterprises discovered they were already running agents nobody sanctioned. The first job of every control plane on the market is discovery: finding the agents that are already talking to your systems.

The scale is why this became urgent. 80% of the Fortune 500 already run active AI agents, per Microsoft’s own February 2026 data, and most of those agents were adopted bottom-up by teams, not provisioned top-down by IT. That is shadow AI, and it is the exact pattern that shadow SaaS followed a decade ago, except agents can act, not just store data.

Regulators and analysts are treating it as a governance emergency. Gartner projects that by 2030, more than 40% of enterprises will experience a security or compliance incident tied to unauthorized shadow AI. Microsoft is explicit that governance is now the gate for enterprise agents: you do not get to production without passing through the control plane. Discovery, then identity, then policy. That sequence is the whole game.

The control plane is an admission gate

Here is where this matters for anyone building software. The control plane is not just an internal ops tool. It is an admission gate, and your product is on one side of it or the other.

To be admitted to the fleet, a product has to be three things: registry-discoverable, so the control plane can inventory it; identity-bound, so each agent calling it carries a verifiable, scoped identity; and policy-scoped, so the gateway can allow or deny specific actions. A product that exposes that surface gets governed, and a governed product gets deployed. A product that only renders a login page cannot be inventoried, cannot be identity-bound, and cannot be policy-scoped. To the control plane, it does not exist.

This is the identity primitive made operational. As I argued in agent identity is the missing primitive, the agent economy is being built on shared API keys that cannot answer which agent did what. The control plane is the layer that consumes real agent identity and turns it into per-agent rate limits, per-agent policy, and per-agent forensics. It is also the concrete form of the governance layer I described in the agent protocol stack: the single plane that sits above MCP tool calls and A2A delegations and watches both.

Being callable is now table stakes. Being governable is the bar. That reframes machine consumability, the property The Headless Index was built to measure, from “can an agent operate this?” to “can an enterprise safely admit this to its fleet?”

What this means for how you build

The build implication is concrete and testable. Expose a registry entry so the control plane can discover you. Bind every call to a scoped agent identity so the gateway can attribute it. Publish policy hooks so an administrator can allow or deny specific actions. Emit an audit log keyed to agent ID and human sponsor so forensics works after the fact.

Do that, and any of the three control planes shipping today can admit your product to a governed fleet. Skip it, and you are asking a Fortune 500 security team to make an exception for software it cannot see, at exactly the moment governance became the gate. The human dashboard, if you keep one, becomes the thin adapter on top of a governable API surface. The surface is the product.

This is the same move headless has always pointed at, seen from the operations side. The API was the product for the developer. Now the governable API surface is the product for the enterprise.

Observability is the part everyone underbuilds

Admission is the easy half. Watching what happens after admission is the half that decides whether governance is real or theater. An agent that passes the gate then makes tool calls through MCP and delegates tasks through A2A, and a control plane that cannot see across both is governing with one eye closed.

This is why every serious control plane bundles observability with the registry, not as an add-on. Google’s platform routes agent traffic through a gateway precisely so it can record it; Microsoft wires Defender into Agent 365 so agent activity lands in the same place as the rest of the security graph. The point is a single audit trail keyed to agent identity, not two disconnected logs you stitch together after an incident.

Without that, per-agent controls collapse. You cannot rate-limit an agent you cannot distinguish, revoke one agent without revoking the shared credential behind it, or tell an auditor which of forty agents took a regulated action. Observability is what turns a registry from an inventory into a control system. A product that emits clean, attributable, per-action logs makes that observability possible. A product that only logs “someone hit the API” makes it impossible, and impossible-to-observe is the same as impossible-to-govern.

The admin console changed shape

Humans got IAM to say who they are, SSO to log in once, and MDM to manage the devices they carry. Agents are getting the exact same stack, compressed into one quarter and one layer: a registry to know they exist, an identity to say who they act for, a gateway to mediate what they reach, and policy to decide what they may do. KPMG putting 276,000 people and their agents under Agent 365 is what the transition looks like at scale.

If the headless thesis is right that machines are the primary consumers, then the admin console for those consumers is the piece of infrastructure that matters next, and it is being built right now by the largest platform vendors on the planet. The question for anyone shipping software is no longer whether an agent can call your API. It is whether an enterprise can govern your software as one more managed member of its fleet. Products that answer yes get deployed. Products that answer with a login page get left outside the gate.

Build to be governed, not just called. For more on how machines are becoming the primary consumers of software, subscribe to the newsletter or see how we score vendors on machine consumability in The Headless Index.