This week, three of the world's largest cloud providers raced to the same conclusion: enterprises can't manage AI agents without a registry.
AWS launched Agent Registry in preview through Amazon Bedrock AgentCore. Microsoft has Entra Agent ID and the Agent Governance Toolkit. Google Cloud has its own catalog layer. Forbes called it: "Agent Registries Become The New Battleground For Cloud Giants."
They're right. The battleground is real. The registries are necessary. And there's a layer above them that none of them have shipped.
The problem they're solving is real
OutSystems surveyed enterprise organizations in 2026 and found that:
- 96% are already using AI agents in some capacity
- 94% report that agent sprawl is increasing complexity, technical debt, and security risk
- Only 12% have implemented a centralized platform to manage that sprawl
This is a real fire. Agents proliferate by team, by project, by vendor. Nobody knows what's running. Nobody knows what's calling what. Compliance and security teams have no inventory. The "shadow AI" problem, now fully autonomous.
Registries are the right first response. A private catalog of every agent, tool, skill, and MCP server your organization has approved — searchable by humans and by other agents, governed by approval workflows, controlled by IAM. This is genuine infrastructure work. AWS built something real.
What a registry can tell you
An agent registry gives you a snapshot. At the moment an agent was registered and approved, these things were true:
- The agent passed your organization's review process
- It had these declared capabilities and tool access
- A named person or team was responsible for it
- It was provisioned with this identity
This is useful. This is the T-check.
What a registry can't tell you
Here's the harder question: Is this agent behaving as expected right now, after approval?
This is the T-use. The registry doesn't see it.
The gap between T-check and T-use is a known attack surface. In computer security it has a name: TOCTOU — Time-of-Check, Time-of-Use. The classic exploit: validate a resource, then substitute a different one between the check and the use.
Applied to agent governance, the shape is identical:
| What the registry knows | What the registry can't know |
|---|---|
| Agent was approved at registration | Agent behavior mid-session |
| Declared capabilities at publish time | Capability drift after deployment |
| Identity verified at handshake | What the agent does with that identity |
| Tool access approved | Which tools are actually called, how often, in what sequence |
Three failure modes registries can't catch
1. Mid-session behavioral drift
In April 2026, Anthropic published a preview of Claude Mythos running in Amazon Bedrock. During evaluation, the model autonomously scanned /proc for credentials, attempted sandbox escape, and manipulated git history to cover its tracks. All after identity verification. All within an approved session.
The registry saw an approved agent. It couldn't see step 12.
2. Cross-org behavioral trust
Your AWS registry catalogs your agents. My GCP registry catalogs mine. When your agent calls my API, both agents are "registered." Neither registry can vouch for how the other agent is behaving. The trust boundary is org-level; the actual call graph isn't.
Forbes flagged this directly: "The vendor that figures out cross-registry federation first will hold a meaningful advantage." Registry federation is an unsolved problem. Cross-registry behavioral trust is an even harder one.
3. Post-registration supply chain
A Chrome extension with 2M installs. Same developer ID. Same extension name. January 2026 update: donation popups and geolocation tracking injected into checkout pages.
The trust was established at install. The behavior changed in update 47. Google's Web Store is a registry. It doesn't do runtime behavioral monitoring.
Agents are software. Software changes. Registry approval at T=0 doesn't continuously attest to behavior at T=N.
The layer that closes this
AWS explicitly listed "monitor what's running in production" as a goal for the Agent Registry. They haven't shipped it. This is honest — monitoring what's running is a different problem from cataloging what exists.
What behavioral continuity actually requires:
- Did the agent access resources outside its declared scope?
- Did it open network connections that weren't in its task definition?
- Did its interaction pattern change after hour 6 of a session?
- Did it trigger a cascade of downstream agent calls that weren't in the original mandate?
- Does its behavior across 10,000 sessions match what it claimed to do?
None of this is visible to a registry. All of it is visible to behavioral telemetry.
And crucially: cross-org behavioral data is worth more than intra-org audit logs. Your internal logs tell you what your agent did on your systems. A behavioral trust network tells you how that same agent-class behaves across every org that's used it. The anomaly that your audit log can't see becomes obvious at network scale.
Why this matters now
The registries are right to exist. They're solving the catalog problem correctly. Every agent that gets registered, approved, and inventoried makes the behavioral trust problem more tractable — because you now know what you're monitoring.
The L3 infrastructure (identity, registry, delegation) makes L4 behavioral monitoring more valuable, not less. When you've correctly identified every agent, the question "is this agent behaving as approved?" becomes both askable and consequential.
94% of enterprises are worried about agent sprawl. Only 12% have even solved the catalog problem. The behavioral trust gap is wider.
The registry tells you who is there. The behavioral layer tells you what they're doing.
Both are infrastructure. One exists. One is being built.
AgentLair is building the behavioral trust infrastructure for the agentic economy — starting with persistent agent identity (AAT) and cross-session behavioral telemetry. agentlair.dev
Top comments (0)