Registry plus observability plus policy enforcement is the convergent answer; four independent parties describe the same three-part architecture under four names. The property that makes it a control rather than a service is interposition: an engine the agent may choose to call is not governance.

The mechanism

Three planes. Registry: which agents exist, owned by whom, with what scope. Observability: what they are doing now. Policy: what they are allowed to do, enforced before the action. McKinsey calls the assembly an agentic AI mesh, BCG a scalable AI backbone on four pillars, Microsoft ships it as Agent 365, and the academic literature calls it agent infrastructure: technical systems and shared protocols external to agents that mediate their interactions. Four groups with different incentives converging on the same decomposition is the strongest evidence this page has.

The load-bearing sentence comes from the runtime-governance literature: only enforced, architecturally interposed compliance provides verifiable guarantees; voluntary compliance falls short of governance. An agent that can complete its work without passing through the policy engine has been handed a service labelled as a control. That single distinction separates a real control plane from a dashboard, and it is why this sits in patterns/: an architecture decision rather than a product purchase.

Three design requirements follow, and the third is the one people skip:

• Two-phase evaluation. Register once, evaluating identity-only policies before any step runs (rejecting undocumented, modified or out-of-hours agents up front), then evaluate per step against a compact state vector updated in constant time. This is the answer to the “path-level evaluation won’t scale” objection, and it is analytic; the paper publishes no latency benchmark.
• Fail closed. Timeouts must default to BLOCK. A control plane is a single point of failure and has to be built like one: redundancy, health monitoring, and a default that denies. This is the most actionable design requirement in the whole bundle.
• Out-of-band control signalling. Microsoft’s red team documents an illustrative scenario in which a crafted prompt makes an agent emit a framework control keyword and ends the flow early, skipping part of it; a skipped part can be a security control. An orchestrator that parses control signals out of model output can be steered by untrusted text. Route control separately from content. (The scenario is Microsoft’s; the architectural inference is ours.)

The centralization objection has been answered empirically, which is newer than most write-ups assume. SAGA, a research architecture with a trusted central Provider explicitly modelled on Active Directory and Kerberos, measures cryptographic mediation overhead at 0.165 seconds of networking against task times of 27 to 364 seconds, under 0.6% on the fastest task. It scales to around 300 million agents with ten shard workers and 24-hour tokens (260 million measured on AWS with seven). Registry centralization has stopped being the bottleneck it once was. Two honest caveats. First, that measurement is cryptographic mediation in a research prototype rather than a production plane doing policy evaluation, logging and DLP, so what it rebuts is “crypto mediation is slow,” not “governance is free.” Second, the scaling figure circulates in secondary write-ups as “500 million”, while the paper itself says 300 million.

What is proveable is worth knowing precisely. SAGA formally verifies token secrecy and agent-to-agent authentication in ProVerif against an attacker who can observe, intercept, modify, replay and synthesize messages. The inter-agent authentication layer admits proof while the LLM behaviour layer does not, and that asymmetry runs through the whole field.

The shipping instance is instructive in both directions. Agent 365’s SDK layers identity, notifications, OpenTelemetry observability and governed tool access on top of agents built elsewhere, creating and hosting no agents itself. That is the interposition property in product form. Microsoft’s own registry documentation counts “unmanaged agents” created or managed outside Agent 365, and carries a “shadow agent” critical risk type for entries with no registry record, no owner or no Entra Agent ID. The leading vendor’s control plane documents its own coverage gap, and that is the strongest available support for treating a registry as a floor rather than a boundary. (The Graph API for registry details was still preview as of July 2026. And Microsoft’s control-plane branding attaches to Agent 365, not to Copilot Studio, whose governance runs through Power Platform policies, Purview and Sentinel, a naming error that circulates.)

Sequencing is the practical finding. A benchmarking report names three large firms that “invested in the control layer before they invested in autonomy,” including one pharma company whose chief data and technology officer describes an agentic control plane over more than 6,000 agents by the company’s own account. Take the sequencing claim; leave the number, which is a self-report in a vendor-sponsored report, undefined as to what counts as an agent, internally inconsistent with another page of the same document, and drawn from a company employing 50,000 people.

What to do

Build the cheap version out of what the firm already runs: a registry with owners, the existing SIEM ingesting agent events, and a written policy. That is all three planes, badly connected, and it beats none of them.

Then connect them; the value sits in the connection. Registry state should drive enforcement, and the test is whether an unregistered agent can obtain credentials or reach the network. If it can, the firm has three separate systems rather than a control plane. See agent inventory, logging and audit and runtime guardrails for each plane on its own.

Put the enforcement point where the agent cannot route around it. A gateway the agent must traverse to reach a model or a tool is interposed; an SDK it can decline to import is not.

Default to block on timeout, and load-test that path. A control plane that fails open under load is worse than none, because everyone believes it is working.

Keep control signalling out of the content channel, and treat any framework keyword the model can emit as attacker-controllable.

Use a pre-approved self-service catalog as the on-ramp. Low-expertise builders are made safe by a menu where every item is already governed, not by training, and the guardrails belong to the platform rather than the builder.

How you’d know it’s working

An unregistered agent cannot get credentials or egress. This is the single test that distinguishes a load-bearing registry from a decorative one, and it is binary.

The policy engine has denied something recently and someone can name it. A plane that has never blocked an action is a logging pipeline.

The firm can state what fraction of agentic solutions consume platform services rather than rolling their own. That ratio is BCG’s suggested measure and it is the honest coverage number.

What this doesn’t solve

A control plane governs agents it can see, and the vendor’s own documentation says so by counting unmanaged agents. Everything in shadow agents sits outside it, and the enforcement point that reaches those is the service edge, not the registry.

It says nothing about output quality. A fully registered, fully observed, policy-compliant agent can be confidently wrong all day. See unreliable output.

Containment is a separate layer. Blast radius is bounded by the environment an agent runs in and what its credentials reach; the control plane governs across those environments without replacing them, so see three-zone architecture.

Nothing here governs across vendors. Every major platform governs inside its own ecosystem: Agent 365 within Microsoft’s estate, and the equivalent trust layers within Salesforce, AWS and Google. A firm running agents on three platforms runs three control planes and reconciles them by hand. Cross-organization agent authentication has one articulated model in the literature, a cross-realm-Kerberos-style federation sketch that its own authors leave unimplemented, unevaluated and unverified; treat it as a gap rather than a roadmap.

Risk budgets state the tradeoff rather than acting as a control anyone runs. The formulation is elegant, maximizing expected task utility subject to an expected violation rate, and no firm has published a chosen budget, nor has the construct been calibrated anywhere. It is useful vocabulary for a board conversation and not yet a setting anyone configures.

And the orchestrator-as-choke-point picture that appears in consultancy writing describes a capability level its own source calls largely experimental. Cite it as a design illustration, never as observed practice.

See also

• Agent inventory and registry — the registry plane as a control in its own right.
• Logging and audit — the observability plane’s floor.
• Runtime guardrails and policy enforcement — the policy plane at execution time.
• Agent sprawl — the failure this architecture exists to prevent.
• Three-zone architecture — the containment underneath, which this governs across rather than replaces.
• Registry review cadence — the recurring work that keeps the registry true enough to be load-bearing.
• Technology platform — the dimension hub this serves.