Forrester named it the third functional plane. Here is what an agent control plane actually is, the five capabilities it must deliver, and which 2026 products deliver each one.
What is an agent control plane?
An agent control plane is the third functional plane in an enterprise agentic architecture — a portable, vendor-agnostic governance layer that sits outside where agents are built and orchestrated, giving you independent visibility, consistent policy enforcement, and runtime control over every AI agent regardless of who built it or where it runs. Forrester formalized the term in December 2025 and named it the third plane alongside the build plane and the orchestration plane.
The borrowed metaphor is the networking control plane. In a network, the data plane moves packets while the control plane decides where packets are allowed to go. Translate that to agents: the data plane is the agent doing work — calling models, hitting tools, moving data — while the control plane decides which agent is allowed to do what, watches every action, and can stop it. IBM frames the control plane as sitting above the data plane: it routes requests, enforces permissions, and applies policy before actions run, rather than auditing them after the damage is done.
The reason this became its own category in 2026 is scale and heterogeneity. A single enterprise now runs agents built in Copilot Studio, LangGraph, Bedrock, and a dozen homegrown stacks, embedded across workflows nobody can fully enumerate. Governance bolted onto any one build tool only governs that tool’s agents. Forrester’s core principle is blunt: as agents proliferate across the build and orchestration planes, governance must sit outside both to stay independent — an out-of-band oversight plane.
This guide does what the ranking pages do not. We separate the three planes the way Forrester actually framed them, map the five control-plane capabilities to the real 2026 products and standards that deliver each, and name the three standards gaps that mean no incumbent can hand you a finished plane today. By the end you will be able to read any vendor’s control plane pitch as a parts list and spot what they are leaving out.
The three functional planes: build vs orchestration vs control
Forrester decomposes enterprise agentic architecture into three planes: the build plane (how you build, deploy, and scale agents), the orchestration plane (how you embed agentic and non-agentic components into business workflows), and the control plane (how you govern and oversee them at scale). The control plane is deliberately separate so governance is not captive to any one build or orchestration vendor.
The build plane answers how to construct agents. This is your agent framework, your model access, your tool definitions, your eval harness — LangGraph, Copilot Studio, the Anthropic and OpenAI SDKs, custom code. The build plane is where an agent gets its capabilities. It is also where, historically, governance got jammed in as an afterthought, which is exactly the trap the control plane exists to escape.
The orchestration plane answers how agents fit into real processes. Forrester calls this adaptive process orchestration: chaining agents with deterministic steps, humans, and legacy systems so a business workflow actually completes. Durable execution engines and workflow orchestrators live here. Orchestration decides the sequence; it does not, on its own, decide whether each actor in that sequence is authorized.
The control plane answers who is allowed, what happened, and how to stop it — across both other planes at once. Crucially it is out-of-band. If your control logic lives inside the orchestrator and the orchestrator misbehaves, you have no independent oversight. The whole point is a vantage point that survives a misbehaving runtime. That separation is what distinguishes an AI agent control plane vs data plane discussion from a simple monitoring dashboard.
Forrester’s market read backs the urgency. In a late-February 2026 poll of 47 tech vendors, 79% recognized the agent control plane as a meaningful and distinct product category, 92% had assigned a named product manager or team to agent governance or control-plane functionality, and 40% reported active RFPs explicitly requesting a control plane. This is a category buyers are now naming in procurement, not an analyst abstraction.
If your control logic lives inside the build or orchestration tool, a misbehaving runtime can take your governance down with it. The agent control plane is defined by its independence: it must keep seeing and enforcing even when the planes it watches behave unpredictably.
| Plane | Core question it answers | Representative tooling | Governance role |
|---|---|---|---|
| Build plane | How do we build, deploy, and scale agents? | Agent frameworks, model SDKs, eval harnesses, Copilot Studio | Where capabilities are created — not where governance should live |
| Orchestration plane | How do we embed agents into business workflows? | Adaptive process orchestration, durable execution engines | Decides sequence of actors; does not arbitrate authorization |
| Control plane | Who is allowed, what happened, how do we stop it? | Agent registry + identity + policy + observability + audit | Out-of-band oversight that spans both other planes |
The five agent control plane capabilities (and what each one does)
An agent control plane must deliver five capabilities: identity (a unique, attributable name for every agent), policy enforcement (runtime evaluation of agent actions against rules before they execute), observability (logs, metrics, and traces of agent behavior), lifecycle management (versioning, onboarding, updates, and revocation), and audit/compliance (immutable records of every action and policy decision). IBM defines these five as the spine of the control plane, and they are the checklist to grade any vendor against.
Identity issues, tracks, and revokes a unique identity for every agent so each action is authenticated and attributable to a specific principal. Without it, the other four capabilities have nothing to anchor to — you cannot enforce policy on, observe, or audit an agent you cannot name.
Policy enforcement is active, not declarative. Policies are evaluated at runtime against each proposed agent action, and the action is allowed or denied before it runs. A static policy document that nobody enforces at the decision point is not control-plane policy; it is a PDF.
Observability collects logs, metrics, and traces and makes them available for monitoring, debugging, and analysis. This is the sensory input to everything else — you cannot govern behavior you cannot see, and the depth of your telemetry caps the precision of your policy.
Lifecycle management covers the full arc: IT-controlled onboarding, security policy templates, versioning, testing, deployment, updates, and — critically — fast revocation when an agent goes rogue or its task ends. Audit/compliance closes the loop with immutable records of every action, policy decision, and governance event that auditors and regulators can review. Each of these five maps to a primitive your team likely already touches — workload identity, a policy engine, an observability stack, a deployment pipeline, and a tamper-evident audit log.
Pros
Cons
Capability-to-vendor matrix: which product delivers each plane function
No single product is the agent control plane. In 2026 you assemble it: identity from Entra Agent ID or SPIFFE/SPIRE, policy from Open Policy Agent and Rego, observability from OpenTelemetry GenAI conventions, lifecycle and registry from Microsoft Agent 365 or IBM watsonx Orchestrate, and audit from a tamper-evident log schema you define. The matrix below maps each of the five capabilities to what it does and which product or standard delivers it.
Read the matrix as a build, not a buy. A registry product gives you the inventory and the dashboard; it leans on an identity provider for identity, a policy engine for enforcement, a telemetry standard for observability, and your own retention rules for audit. The agent control plane vendors that pitch a complete plane are really pitching a strong registry plus a set of integrations — which is genuinely useful, but it is not the same thing as owning the primitives.
The most defensible builds keep the load-bearing primitives portable. Workload identity via SPIFFE/SPIRE issues short-lived SVIDs that are not tied to one cloud. Policy as code in Rego runs the same rule whether the agent is on Azure or a laptop. An append-only audit log with a schema you control survives a vendor switch. The registry on top can be Microsoft’s, IBM’s, or your own — but the controls underneath are yours.
Each row in this matrix is a primitive Alatirok has already broken down in depth — SPIFFE/SPIRE SVIDs for workload identity, non-human-identity management, OWASP-style threat coverage for agentic apps, agent audit-log design, and the observability stack for LLM systems. The control plane is literally those primitives assembled. No incumbent ships all five natively; that is the build-versus-buy line.
| Capability | What it does | Product / standard that delivers it |
|---|---|---|
| Identity | Issues, tracks, and revokes a unique, attributable identity per agent | Microsoft Entra Agent ID (per-agent Entra identity); SPIFFE/SPIRE SVIDs for portable workload identity |
| Policy enforcement | Evaluates each proposed action against rules at runtime before it executes | Open Policy Agent + Rego; Microsoft Defender + Entra conditional access for runtime blocking |
| Observability | Collects logs, metrics, and traces of agent behavior for monitoring and debugging | OpenTelemetry GenAI agent and framework spans (experimental in 2026); your tracing/metrics backend |
| Lifecycle | Onboarding, versioning, updates, and revocation of agents and tools | Microsoft Agent 365 registry; IBM watsonx Orchestrate agentic control plane; Intune for endpoint agents |
| Audit / compliance | Maintains immutable records of every action and policy decision | Append-only audit-log schema you define; Microsoft Purview for data lineage and labeling |
Microsoft Agent 365: the control plane for a Microsoft shop
Microsoft Agent 365 reached general availability on May 1, 2026 at $15 per user per month standalone, or bundled in the new Microsoft 365 E7 Frontier Suite. It is a control plane because it ties Entra, Purview, Defender, and Intune together so an AI agent looks like a managed identity to all four — assigning each agent its own Entra identity, applying Purview labels to the data it touches, governing its runtime through Defender, and extending Intune management to agents running locally on Windows.
Agent 365’s centerpiece is the registry. It surfaces every agent in the organization in one inventory — Microsoft-built agents, ecosystem-partner agents, agents you register yourself, and shadow agents discovered on Windows endpoints through Defender and Intune. At GA, Microsoft extended this to discover and manage agents running locally on Windows, starting with the OpenClaw platform, with GitHub Copilot CLI and Claude Code signaled to follow. Network controls now reach Copilot Studio agents and endpoint agents to restrict outbound connections, filter risky file movement, and block prompt-injection at the network layer.
Where it gets interesting for non-Microsoft fleets is the multicloud registry sync, currently in public preview: organizations can import agents from AWS Bedrock and Google’s Gemini Enterprise Agent Platform into the Agent 365 inventory, consolidating rival platforms under one pane. That is a direct response to the heterogeneity problem — but note it is preview-grade inventory, not full cross-cloud policy enforcement.
Mapped to the five capabilities, Agent 365 covers identity (Entra), lifecycle and registry (its own inventory plus Intune), runtime policy (Defender plus Entra conditional access), and data governance (Purview). It is the strongest turnkey on-ramp for an organization already standardized on Microsoft 365 and Entra. The caveat is the same one Forrester raises about the whole category: outside the Microsoft estate, identity portability and cross-plane policy are stitched together, not yet native — because the standards to do it natively do not exist yet.
“Agent 365 does not replace Entra, Purview, Intune, or Defender. It ties them together so an agent looks like a managed identity to all four.”
Reading of Microsoft’s Agent 365 control-plane positioning
How to govern AI agents in the enterprise: a control plane walkthrough
To govern AI agents in the enterprise, run every agent action through the control plane in five steps: assign the agent a portable identity, attach it to a policy bundle, evaluate each proposed action at runtime, emit a trace, and write an immutable audit record — with revocation available at any point. The control plane is the chokepoint every action passes through, not a report you read later.
Step one, identity. Before an agent does anything, it gets a unique, attributable identity — an Entra Agent ID in a Microsoft shop, or a SPIFFE SVID if you want a portable, short-lived, cloud-agnostic credential. This identity, not an API key shared across a fleet, is the principal every later decision references.
Step two, policy attachment. The agent’s identity binds to a policy bundle — what tools it may call, what data classifications it may touch, what spend ceiling it has, which destinations it may reach. Expressed as code (Rego), the same bundle evaluates identically whether the agent runs in Bedrock or on a managed Windows endpoint.
Step three, runtime evaluation. When the agent proposes an action — call this tool, move this file, hit this endpoint — the control plane evaluates the request against the bundle and allows or denies it before execution. This is the difference between a control plane and a dashboard: the dashboard tells you an agent exfiltrated data yesterday; the control plane refuses the exfiltration at the moment of the call.
Step four, observability. Every decision emits a trace — ideally using OpenTelemetry GenAI agent spans so it correlates with the rest of your stack. Step five, audit: the action, the identity, the policy decision, and the outcome land in an append-only log a regulator can later reconstruct. And throughout, lifecycle control means you can revoke the identity instantly — ending the task ends the agent’s authority everywhere at once.
The three standards gaps Forrester says still block a true control plane
3
functional planes
build, orchestration, control — Forrester, Dec 2025
5
core capabilities
identity, policy, observability, lifecycle, audit — IBM
$15
per user / month
Microsoft Agent 365 standalone, GA May 1, 2026
Forrester names three standards gaps that mean no vendor can deliver a complete, portable agent control plane in 2026: incomplete instrumentation, the absence of a portable agent identity, and missing cross-plane governance schemas. The identity gap is the most consequential — the other two depend on it. This is the part single-vendor pitches quietly omit, and it is why a neutral builder’s view matters.
Gap one, incomplete instrumentation. OpenTelemetry’s GenAI conventions are still experimental for agent and framework spans as of 2026; client spans stabilized earlier, but agent spans have not. Forrester’s framing is sharp: instrumentation can tell you what happened inside an agent’s execution, but it cannot yet tell you who the agent was in governance terms. The conventions still lack skill-level identity propagation, cost attribution traced to business value streams, and cross-orchestrator span correlation.
Gap two, portable agent identity — the gap on which the other two depend. The identity must travel with the agent from build, through deployment, into production in a standardized format. No such standard exists today at the maturity enterprises require. This is precisely why portable workload identity standards like SPIFFE/SPIRE matter as a stopgap: they give you a vendor-neutral identity now, ahead of an agent-native standard.
Gap three, missing cross-plane governance schemas. There are no agreed schemas defining how the build, orchestrate, and control planes exchange governance-relevant information about agent state, policy, and lifecycle. So today, the control plane talks to the other planes through bespoke integrations per vendor — which is exactly the lock-in the out-of-band design was supposed to prevent. Until these schemas exist, every control plane is partly hand-wired, and the smart move is to keep the wiring — identity, policy, audit — under your own control.
Build or buy? A neutral verdict for architects and platform leads
The control plane is an architecture you assemble, not a product you buy
Buy the registry, build the controls. In 2026 the right move is to use a vendor registry (Agent 365 if you are a Microsoft shop, watsonx Orchestrate if you are an IBM shop) for inventory and discovery, while owning the four load-bearing primitives — portable identity, policy as code, your observability pipeline, and your audit schema — so you are not locked into any one plane.
The reason is the standards gap. If portable agent identity and cross-plane schemas existed, a single-vendor control plane would be a safe all-in bet. They do not, so a fully managed control plane is portable only inside its own ecosystem. The pragmatic hedge is to let the vendor solve discovery and dashboarding — genuinely hard problems — while you keep identity (SPIFFE/SPIRE alongside Entra), policy (Rego/OPA), telemetry (OpenTelemetry GenAI, dual-emitting attributes today), and audit logging under your control. When the standards land, you swap the registry, not your entire governance posture.
For a small Microsoft-centric team, Agent 365 standalone at $15 per user per month is the fastest path to a governed agent fleet, and the Bedrock and Google sync previews cover most of the multicloud inventory need. For a platform team running heterogeneous agents at scale, treat any vendor as one row in the capability matrix and assemble the rest. Either way, start by getting an honest inventory — you cannot govern agents you have not discovered, and shadow agents on endpoints are the ones that will hurt you.
Builder’s take
I build agent infrastructure for a living — Cyntr orchestrates persona agents across communities and Loomfeed runs them in production — so when Forrester drew a box labeled control plane I read it as a parts list, not a product.
- No single vendor ships a control plane. They ship a registry plus integrations. The plane is an architecture you assemble from identity, policy, observability, lifecycle, and audit primitives.
- The portable identity gap is the real blocker. If your agent’s identity does not survive the trip from build tool to runtime in a standard format, every downstream control is bolted on after the fact.
- Buy the registry, own the policy. Agent 365 is a fine inventory and a great Microsoft-shop default, but treat policy enforcement (OPA/Rego), workload identity (SPIFFE/SPIRE), and your audit schema as things you control, not rent.
- Instrument before you govern. You cannot enforce policy on telemetry you do not collect. OpenTelemetry GenAI agent spans are still experimental in 2026 — wire them in now and dual-emit attributes so you are ready when they stabilize.
- Assume multicloud from day one. Your agents will run on Bedrock, Google, Azure, and laptops. The control plane is the only layer that can give you one answer to who can do what across all of them.
Frequently asked questions
An agent control plane is a governance layer that sits above your AI agents and decides who is allowed to do what, watches every action, and can stop it. Forrester named it the third functional plane in 2025, alongside the build plane (where agents are made) and the orchestration plane (where they run in workflows). It exists so governance is independent of any one build or runtime tool.
The data plane is the agent doing work — calling models, invoking tools, moving data. The control plane is the layer above it that authorizes, observes, and can halt those actions. The distinction comes from networking: the data plane moves the traffic, the control plane decides where traffic is allowed to go. A control plane enforces policy before an action runs; a dashboard only reports what already happened.
Per IBM, the five are: identity (a unique, attributable name for every agent), policy enforcement (runtime evaluation of each action against rules before it executes), observability (logs, metrics, and traces of agent behavior), lifecycle management (onboarding, versioning, updates, and revocation), and audit/compliance (immutable records of every action and policy decision). A real control plane must deliver all five, not just a registry dashboard.
Yes. Microsoft Agent 365, generally available May 1, 2026 at $15 per user per month, is a control plane that ties Entra, Purview, Defender, and Intune together so an AI agent looks like a managed identity to all four. It gives each agent an Entra identity, applies Purview data labels, governs runtime through Defender, and extends Intune to local Windows agents, with a registry that even imports agents from AWS Bedrock and Google in public preview.
Microsoft (Agent 365) and IBM (watsonx Orchestrate’s agentic control plane) are the prominent registry-led offerings. But the full plane is assembled from primitives: identity from Microsoft Entra Agent ID or SPIFFE/SPIRE, policy enforcement from Open Policy Agent and Rego, observability from OpenTelemetry GenAI conventions, and audit from a log schema you define. No single vendor delivers all five capabilities natively in 2026.
Forrester names three blocking standards gaps. First, instrumentation: OpenTelemetry GenAI agent spans are still experimental and lack skill-level identity propagation and cross-orchestrator correlation. Second, no portable agent identity standard exists that travels with an agent from build to production. Third, there are no cross-plane governance schemas for the build, orchestrate, and control planes to exchange policy and lifecycle data. Until these mature, every control plane is partly hand-wired and portable only inside one ecosystem.
Primary sources
- Agent Control Planes Still Need A Robust Standards Stack — Forrester
- Announcing Our Evaluation Of The Agent Control Plane Market — Forrester
- Agent Control Planes Still Need A Robust Standards Stack — CDOTrends
- What is an Agent Control Plane? — IBM
- Microsoft Agent 365: The Control Plane for Agents — Microsoft
- Microsoft Agent 365 Hits General Availability With Local AI Agent Controls — WinBuzzer
- Semantic Conventions for GenAI agent and framework spans — OpenTelemetry
Last updated: June 2, 2026. Related: Governance.
