Agent control plane

What is an agent control plane?

An agent control plane is the one place where your organisation can see every AI agent it runs and change what those agents are allowed to do. It answers six questions about every agent from one screen or one process: does it exist and who owns it, what identity does it sign in with, which tools, data and budget may it use, what has it been doing, where is it in its life (requested, approved, live, retired), and can we stop it right now.

The name comes from networking. In a network or a Kubernetes cluster, the data plane does the work (moving packets, running containers) and the control plane decides what the data plane may do and keeps watch over it. Applied to agents: the agents mailing your customers and posting to your ERP are the data plane. The control plane is the layer above them, and you operate it, not the agents.

Most of the parts already have their own entry in this dictionary. The agent registry is the inventory. The agent identity is the login and the permissions. The LLM gateway meters the model calls. The agent kill switch is the stop. This entry is about what ties them together, and about why that only becomes necessary at a certain size.

The six controls a control plane bundles

Inventory and ownership. Every agent, including the ones a supplier runs and the ones a colleague built in an afternoon, with a named owner. This is the agent registry, and everything below reads from it.

Identity and permissions. Each agent signs in as itself, so a log line says which agent did what, and a leaver's account can be closed without silently killing three agents. This is the agent identity.

Policy. Which tools an agent may call, which data it may read, whether it may send mail or write to the ledger, and how much it may spend per day. Set once per class of agent, instead of configured by hand inside each one.

Observability. Logs and traces of what each agent did, which tools it called, how many tokens it used and what that cost. The LLM gateway supplies the model-call part; the platform the agent runs on supplies the rest.

Lifecycle. A request-and-approve step before an agent goes live, a way to roll out a new version, and a way to retire an agent so its identity, permissions and triggers go with it. Without that last step, retired agents keep running.

Emergency stop. Halting one agent, or all of them, on a human decision, and knowing that the loop, the queue, the triggers and the credentials have actually stopped.

Putting these in one layer is not about tidiness. Each control depends on the ones before it. You cannot cap the spend of an agent you do not know exists, and you cannot revoke the identity of an agent that signs in as a person.

Why it appears once you pass a handful of agents

With three agents, one person's head is the control plane. They know what each one does, where it runs and how to switch it off. That stops working around the tenth agent, for three specific reasons.

Sprawl. Building an agent no longer takes a project. Copilot Studio, Agent Builder, SharePoint and a dozen SaaS tools each let a non-developer make one. Gartner's April 2026 press release on agent sprawl expects an average Fortune 500 company to have over 150,000 agents in use by 2028, up from fewer than 15 in 2025. Your numbers are smaller; the shape of the curve is the same.

Leavers. An agent built under a personal account stops working, or keeps running under a dead account, the day that person leaves. The Microsoft 365 admin centre now has a dedicated card for agents without owners and updates the count the moment a user is deleted. That feature exists because the problem is common.

Other people's agents. Your CRM, your helpdesk tool and your accounting package each ship agents that reach into your data. They are on no list you made, because you did not build them. Microsoft's registry has a separate category for partner-built agents and can pull agents in from Amazon Bedrock, Salesforce Agentforce and other platforms, for the same reason.

Once those three are in play, the questions arrive faster than one person can answer them. Which agent sent that mail. Which one spent 400 euros in tokens last night. Whether the agent finance built in March still needs write access to the supplier table.

Where a control plane lives today

Microsoft Agent 365 is Microsoft's version, generally available since 1 May 2026 and licensed per user. It lives in the Microsoft 365 admin centre under Agents, which Microsoft's own documentation calls the grounding control plane for all agents managed at your organisation. The registry lists Microsoft-built, partner-built and in-house agents, flags agents without owners and agents at risk, and lets an administrator approve, block, delete or reassign them. Identities come from Microsoft Entra Agent ID, data rules from Purview, threat detection from Defender. It is included in Microsoft 365 E7 and sold as an add-on to E5 and Business Premium, so an SME on Business Premium can get it.

Google bundles the same controls in its Gemini Enterprise Agent Platform: an Agent Registry for agents, tools and MCP servers, an Agent Identity per agent, and an Agent Gateway that routes tool traffic and applies policy to it. ServiceNow AI Control Tower starts from the inventory: AI systems, models, prompts, datasets and MCP servers, from ServiceNow and from other clouds, with a lifecycle phase and a risk class for each. Gartner calls the category AI agent management platforms and published a market overview of it in July 2026, which is useful to know when a vendor borrows the term.

For most SMEs the honest answer is that the control plane is a mix: the Microsoft 365 and Power Platform admin centres for whatever runs there, spending limits at the model provider, and a spreadsheet for the agents that live somewhere else. That is fine as long as somebody owns the spreadsheet.

A minimum control plane for an SME

Take a company of forty people with six agents: two Copilot Studio agents built by sales and finance, a support agent from the helpdesk vendor, an n8n workflow with a model step that classifies incoming mail, and two nobody is quite sure about. The minimum for that company is five things.

1. One list, complete before it is pretty. Every agent, with an owner, a purpose, the systems it can reach and a risk level. Export the Microsoft registry to Excel as the starting point and add the rest by hand. The two nobody is sure about go on first.

2. Its own identity for each agent. Copilot Studio agents already get an Entra agent identity with the creator as sponsor. For the n8n workflow and the vendor agent, a dedicated account or API key per agent, never a shared one, and a note of where it lives.

3. A spend cap per agent, set where the bill is. A budget alert and a hard limit at the model provider, per key, so a loop shows up as a blocked call rather than as an invoice.

4. One place the logs land. Built in for the agents behind the Microsoft admin centre. For the rest, route model calls through an LLM gateway, or at least keep the provider's usage export somewhere a person looks monthly.

5. A tested stop. One written line per agent: to stop this, do this. Try it once on the least dangerous one.

Then a calendar entry every quarter where the owner of the list goes through the high-risk rows and asks whether each agent still needs to exist and whether its access has grown. That review is the control plane's real job; the tooling only makes it faster.

Agent control plane versus LLM gateway

Both are described as the central place where AI is governed, so they get confused. The difference is what they govern.

An LLM gateway governs model calls. It sees a prompt go to a model and a completion come back, and on that basis it meters tokens, caps spend per application, picks which model to route to, caches repeated prompts and logs the traffic. It does not know whether the caller is an agent, what that agent will do with the answer, or who owns it. To the gateway, an agent about to mail 3,000 customers looks like any other consumer of tokens.

An agent control plane governs agents and their actions. It knows the agent as an entity with an owner and an identity, decides which tools and data it may touch, approves or retires it, and can stop it. Token spend is one of the things it watches, and it usually reads that number from the gateway.

So the gateway is one instrument on the control plane's dashboard rather than a rival to it. The edges are blurring: Azure API Management now fronts MCP servers and agent APIs as well as models, and Google calls its policy point for agent tool calls a gateway. The test stays the same. If a control only ever sees model calls, it is a gateway. If it knows the agent by name and can switch it off, it is part of the control plane.

What to ask a platform vendor

Every vendor with an admin console now calls it a control plane. Four questions separate the ones that are.

Does it see agents you did not build on this platform? A control plane that only lists its own vendor's agents is a product catalogue. Ask how agents from other platforms and from your other suppliers get into the list, and whether that is automatic or a manual upload.

What does block actually stop? In the Microsoft admin centre, blocking a Copilot Studio agent removes it from every channel, while blocking a SharePoint or Foundry agent only removes it from Copilot Chat. Ask, per agent type, whether block stops the loop, the triggers and the credentials, or only hides the agent from users. And ask who can disable the identity, because an agent holding a valid token keeps working on what it already has.

Where do the logs go, and who can read them? A central log of every prompt and every action is what you want and a data protection question at the same time. Ask what is kept and for how long.

Can you get the list out? If the registry cannot be exported, the control plane belongs to the vendor, not to you.

One thing to keep in mind while asking. Gartner warned in May 2026 that treating agent governance as binary, either locked down or fully trusted, is the root cause of agent failures. The control plane should make a note-summarising agent cheap to approve and an invoice-approving agent hard to approve. If the tool treats both the same, people will go around it, and the agents that went around it are exactly the ones you needed to see.