What is an AI agent control plane?

Why an agent estate needs a control plane

Organizations rarely operate every agent in one runtime. An agent's identity may live in an identity provider, its definition in an authoring platform, its tools in APIs or MCP servers, its work in business systems, and its cost and activity in still other sources. Each system can be accurate about its own record while no system answers who owns the whole agent or whether its authority is still justified.

A control plane doesn't replace those execution systems. It joins their observations into an accountable estate, preserves conflicts and unavailable evidence, and provides one governed path from a supported finding to a verified outcome.

The seven-stage operating loop

A useful control plane keeps observation, judgment, authority, action, and proof separate. Collapsing those states makes a recommendation look like an approval or an accepted API request look like a successful outcome.

What belongs in the canonical agent record

The record should be a provenance-preserving join, not a flattened guess. Every material value needs a source, observation time, and confidence or availability state. Contradictory source values should remain visible until a governed rule resolves them.

• Stable identity, user-shaped collaboration identity when present, and aliases across source systems
• Accountable business and technical owners, including an explicit unknown state
• Lifecycle state, publication state, assignments, and last meaningful activity
• Models, tools, connectors, MCP servers, credentials, and delegated permissions
• Data boundaries, environments, regions, and external dependencies
• Usage, cost, quality, safety, and security observations with source health
• Findings, proposed work, authority decisions, actions, receipts, and reconciliation history

Authority must be data, not an assumption

Agent tools can cross security and organizational boundaries. The Model Context Protocol authorization specification, for example, requires protected MCP servers to verify access tokens and audience rather than accepting tokens intended for another resource. That runtime check is necessary, but an estate control plane must also preserve why a particular actor or policy was allowed to approve a particular change. [2]

An authority decision should bind the approver, proposed work digest, target scope, constraints, expiration, and rationale. When the decision is missing, expired, or doesn't match the requested work, execution must fail closed.

Evidence quality is part of the risk model

The NIST AI Risk Management Framework organizes AI risk work around Govern, Map, Measure, and Manage, and describes governance as a cross-cutting function. An agent control plane turns that idea into inspectable operating state: the estate being governed, the evidence available to measure it, the decisions made, and the result of risk treatment. [1]

A source outage, stale observation, failed join, or inaccessible permission record changes what the system can responsibly conclude. Source health and collection time therefore belong beside the evidence, not in an internal log that disappears from the decision.

What is not an agent control plane

• A catalog that lists agents but can't explain ownership, authority, or evidence provenance
• An orchestration framework that runs multi-agent workflows but doesn't govern the surrounding estate
• A dashboard that converts unavailable observations into reassuring zeros
• A policy document with no connection to live source evidence or execution receipts
• An automation layer that treats approval as a UI click and an HTTP 200 as proof of success

How this applies to a Microsoft agent estate

In a Microsoft-centered estate, relevant evidence can span identity, Microsoft 365, Copilot Studio, Power Platform, Azure, GitHub, Azure DevOps, and the business systems an agent can reach. Celest's Agent Estate Review connects those records into one operating picture and a prioritized plan.

That canonical record may need both a runtime-facing agent identity and a linked user-shaped agent record. Microsoft Graph now distinguishes the service-principal-shaped agentIdentity from the user-shaped agentUser digital worker, and a control plane should preserve the pair instead of assuming one object can answer both execution and workforce questions. [3] [4]

Discover and diagnose are live in the Estate Review; proposal through reconciliation describe the operating model.

Limitations

• There is no universal industry definition of an AI agent control plane; this page states Celest's definition and design criteria.
• A control plane can't repair incomplete source data by inference without changing evidence into speculation.
• Cross-platform inventory doesn't itself grant authority to modify any source system.
• Controls must be adapted to the organization's risk, regulatory, identity, and operating context.

Sources

External claims on this page use the primary sources below. Celest-authored definitions and design criteria are identified as our operating model.

1. 1
   Artificial Intelligence Risk Management Framework (AI RMF 1.0)

   National Institute of Standards and Technology · Accessed 2026-07-27. The Govern, Map, Measure, and Manage framing and governance as a cross-cutting function.

2. 2
   Model Context Protocol authorization specification

   Model Context Protocol · Accessed 2026-07-27. Resource-server token validation, audience binding, and protected-resource authorization behavior.

3. 3
   agentIdentity resource type

   Microsoft Learn · Accessed 2026-08-07. The runtime-facing Microsoft agent identity model and its service-principal semantics.

4. 4
   agentUser resource type

   Microsoft Learn · Accessed 2026-08-07. The linked user-shaped digital worker model for Microsoft agents and its collaboration/workforce semantics.