The control plane is a catalog, not a cage

The three cloud giants announced agent registries within the same 30 days. The API docs reveal what they're actually selling: a filing cabinet, not a kill switch.

In April 2026, something unusual happened in enterprise AI: three hyperscalers announced near-identical products within the same 30-day window. AWS released its Agent Registry in preview on April 8. Google unveiled its Gemini Enterprise Agent Platform — including Agent Identity, Agent Registry, and Agent Gateway — on April 22. Microsoft put Agent 365 into general availability on May 1. All three were described, in press releases and keynotes, as control planes for enterprise AI: the layer that manages, governs, and restrains the agents enterprises are now deploying at scale.

The implication in every announcement was the same. Pick a platform. Lock it in. Whoever controls the control plane wins the enterprise AI market for the next decade.

There's just one problem with that pitch: read the API documentation.

What the docs actually say

AWS Agent Registry is, in its own words, "a fully managed discovery service that provides a centralized catalog for organizing, curating, and discovering resources" (AWS Bedrock AgentCore Documentation). Its governance primitives are approval workflows — administrators decide which agents can be found in the catalog, and can remove agents from discovery if they develop problems. This is useful. It is not a kill switch.

Here is the specific passage that matters, from AWS's own documentation: "When a curator needs to remove a resource from discovery — whether due to a newly discovered issue, a deprecation, or a policy change — they can deprecate existing approved records, ensuring those resources can no longer be found by builders." An agent that has already been deployed and is running inside a workflow does not receive this message. It continues executing. Deprecating the registry entry removes it from the catalog. The agent keeps working.

AWS does offer a runtime termination API: StopRuntimeSession, which immediately terminates an active agent session. But the operational model reveals the constraint. To call StopRuntimeSession, an operator must already know the session ID — and there is no documented API to list active sessions across an enterprise deployment. An operator who wants to stop a runaway agent cannot see what is running. They can only stop a session whose ID they already possess. If an agent has spawned autonomous sub-agents, terminating the parent session does not terminate the child sessions. The runtime primitive exists; the runtime visibility does not.

Google's Agent Platform documentation tells a similar story. Its Govern section covers Agent Gateway (routing, security, monitoring), semantic policies, content filtering, and IAM identity assignment. These are meaningful controls. But they operate at the catalog and routing layer — deciding which agents can be discovered, which traffic gets through, what identity an agent carries. There is no documented primitive for terminating a running agent mid-action.

Microsoft's Agent 365 positions Entra Agent ID as the foundation of its governance model, integrating with Purview for compliance and Defender for security. The architecture is more complete than the others in its Entra-native identity model. But even here, the core abstraction is the agent identity card: what the agent is allowed to do based on who it is. Whether that identity grants the ability to interrupt an agent already mid-flight through a multi-step workflow is not answered in the documentation.

None of this means the platforms are worthless. Registry, discovery, approval workflows, IAM-based identity — these are real governance primitives. They solve real problems. An enterprise that cannot discover what agents its teams have built is already in trouble. Adding a catalog with discoverability controls and an approval gate before agents go live is genuinely better than nothing.

But "better than nothing" is not the same as "cage."

The gap that matters

Here is the scenario that exposes the difference. A financial services firm deploys an agent to process loan applications. The agent has access to customer data, runs credit checks, and makes approval recommendations. At 2 a.m., a security team discovers the agent has a prompt injection vulnerability — an attacker can craft inputs that make the agent exfiltrate data to an external endpoint.

On Google or Microsoft's control planes, what can the security team actually do? They can remove the agent from the registry. Future deployments cannot discover it. Existing agents that have been instantiated in running workflows continue executing. They can file a ticket. They can alert the team that owns the agent. The agents keep working. The catalog says they are deprecated. The agents do not read the catalog.

On AWS, the team can invoke StopRuntimeSession — if they know the session ID. If the agent was designed to honor interruption signals and if the workflow exposes the session ID to the operator console. If the agent is running autonomous sub-agents that have already delegated tasks downstream, stopping the parent session may not stop the children. The operator is working blind: the termination primitive exists; the inventory of what is running does not.

This is not a hypothetical edge case. It is the definition of a production agentic workload: long-running, potentially spawning sub-agents, acting across multiple systems, without a human in the loop for every decision. The control planes being sold as enterprise governance solutions were built for this world. But their enforcement model is catalog-level, not runtime-level. The gap between those two things is exactly the gap between a moat and a blueprint for one.

The timing problem

The Databricks number that keeps surfacing in every analysis of this race is real and worth noting: multi-agent usage on the Databricks platform grew 327% in four months (SiliconANGLE). That statistic is being used as evidence that agentic AI has crossed from POC into production at scale. It has. But that inflection point arrived before the governance infrastructure to manage it was complete.

All three cloud providers only announced agent registries in April 2026. SiliconANGLE's own coverage noted this explicitly: "All three major cloud providers only just announced agent registries in April 2026, underscoring how rudimentary the foundational blocks still are" (SiliconANGLE). The industry shipped the cars before it built the brakes.

This is not unusual for a technology transition. The history of enterprise infrastructure is full of examples where adoption outpaced the governance layer built to control it. Cloud itself spent years in a state where shadow IT was the norm and IT departments were still building policy frameworks. DevOps preceded DevSecOps. The pattern repeats.

But the stakes are different at agentic scale. A shadow cloud workload is a VM running code that an IT team cannot see. A shadow agentic workload is an autonomous system that can spawn sub-agents, access data, make decisions, and take actions across multiple systems — without a human in the loop. The blast radius of an uncontrolled agent is categorically larger than the blast radius of an uncontrolled VM.

The commercial logic

So why are the hyperscalers racing to announce control planes that have catalog-level, not runtime-level, enforcement?

The most charitable reading is that this is version one of something that will get more sophisticated. Enterprise platforms ship early and iterate. The catalog is real; runtime enforcement may follow. The governance model is sound even if the enforcement primitives are incomplete.

The less charitable reading is commercial: lock in the enterprise before the gap becomes undeniable.

Every hyperscaler knows that enterprises are moving agentic workloads into production now, not in 2027. The buying decision is happening this year. The platform that gets adopted first sets the standard for how agents are built, how they are identified, how they are governed. That standard becomes the default — and defaults in enterprise infrastructure are extraordinarily durable. Once an enterprise has built hundreds of agents on Platform A, migrating to Platform B means rewriting every agent. The switching cost compounds.

This is the commercial logic of announcing in April 2026 a control plane that does not yet have complete runtime enforcement: be the default platform while the enforcement layer catches up. The catalog locks in the developers. The runtime enforcement can follow. By the time enterprises discover the gap, the migration cost is already too high.

Bain's analysis of Google Cloud Next put it plainly: "The winning platform may not be the one that builds the flashiest agent. It may be the one that can govern thousands of them" (Bain & Company). That is the right question. But governing thousands of agents requires more than a catalog. It requires the ability to stop them.

What actually exists

To be precise about what each platform actually offers:

AWS Agent Registry provides a discovery catalog with approval workflows, semantic and keyword search, MCP protocol support, and CloudTrail logging. It can deprecate records from discovery. Control plane operations require IAM credentials. The runtime termination API (StopRuntimeSession) exists at the session level but requires the session ID upfront with no documented API to enumerate active sessions — operators are blind to what is running without external tracking.

Google Agent Platform offers Agent Gateway for routing and traffic management, Agent Identity for cryptographic identity assignment, Agent Registry for discovery and catalog management, semantic policies for content governance, and Cloud Audit Logs. The enforcement model operates at the catalog and routing layer. The documentation does not describe runtime termination of a deployed agent.

Microsoft Agent 365 provides the most complete identity model through Entra Agent ID, integrated with Purview compliance policies and Defender threat protection. Agents built in Copilot Studio or Foundry onboard automatically. For custom agents, the integration path requires assigning an Entra Agent ID and registering in the Agent 365 registry. The runtime enforcement model depends on Entra's Conditional Access policies — which govern what an authenticated identity can do, not whether an already-executing action can be interrupted.

None of these descriptions are in dispute. They come from the platforms' own documentation.

The second wave

The enterprises that understand this gap are not waiting for the hyperscalers to close it. The open-source ecosystem around agentic governance — projects like the Model Context Protocol, A2A (Agent-to-Agent) protocol, and standalone agent governance frameworks — is building at a pace that suggests the proprietary control planes may face real competition in the enforcement layer.

FIDO Alliance's work on agent authentication standards, referenced in the context of APRA's recent warning about non-human identity management in financial services, points to the same gap. The industry knows the problem exists. The question is whether the hyperscalers will solve it first, or whether a new category of independent governance vendors emerges to fill the space between catalog and cage.

The bets are being placed now. The hyperscalers are asking enterprises to commit to their control planes before the enforcement primitives are complete. The enterprises that ask what "deprecate from discovery" actually means — and what it does not mean — may be the ones who avoid the rebuild.