What agent sprawl actually is
Sprawl is two-dimensional. The first dimension is count: a serious enterprise that adopted Microsoft 365 Copilot in 2024, started building internal LangGraph and CrewAI workflows in 2025, and rolled out coding agents to engineering in early 2026 is plausibly running several hundred agent identities by mid-2026. That is not a rhetorical number — it is what falls out of a few Copilot-enabled tenants, a few dozen internal workflows, a developer head-count multiplied by per-seat coding agents, and a handful of MCP servers per CI environment.
The second dimension — the one that makes sprawl genuinely hard — is the fragmentation of the runtime surface. Each runtime has a different identity model, a different lifecycle, a different telemetry shape, and a different idea of what it means for an agent to "exist." A Copilot agent is an Entra principal with a manifest in the Microsoft tenant. A LangGraph agent is a process with whatever credentials its YAML gives it. A Claude Code session is a desktop process holding an Anthropic API key and the developer's git credentials. An MCP server is a long-running process exposing tools over stdio or HTTP. A Devin task is a remote VM running on a third party's infrastructure.
No single inventory system sees all of those because no single identity system authenticates all of them. Sprawl is what you get when the agent population grows faster than the management plane that was supposed to cover it. The reason it didn't happen in classical IT is that classical IT had a few authoritative inventories (CMDBs, Entra/AD, MDM) and a finite number of approved runtimes. The agent world has neither yet.
Why discovery is unsolved
The standards that get cited as "agent discovery" — A2A Agent Cards and MCP manifests — are useful, but neither was designed to be an enterprise inventory. A2A Agent Cards solve peer discovery: an agent advertises its capabilities so another agent can find it and decide whether to delegate to it. That is a runtime concern, not an inventory concern. A card tells you what an agent claims to do; it does not tell you that the agent is running, where it is running, who deployed it, or whether it should exist at all.
MCP manifests solve tool listing: an MCP server advertises the tools it exposes so a client can decide which to use. Again, useful — but a manifest is a per-server statement of intent, not a federation of servers. Knowing "this MCP server exposes filesystem and shell tools" tells you nothing about how many MCP servers your organization is running, whose laptops they live on, or which of them have access to production credentials.
Identity-provider agent registries — the kind Entra and Okta are building out — solve a real problem but only within their identity boundary. Entra sees agents authenticated as Entra principals. Okta sees agents authenticated as Okta principals. Neither sees an MCP server installed by a developer that authenticates with a personal token, an agent on Devin's infrastructure operating under a service account, or a coding agent running locally with the developer's human OAuth tokens. Federating those views into a single authoritative inventory is the problem that nobody in the current control-tower category has fully solved.
What "AI Control Tower" means today
Two vendors are anchoring the term in 2026. ServiceNow positions its AI Control Tower around the ITSM-adjacent estate: agents that participate in ServiceNow workflows, agents whose actions correspond to ITSM change records, and integration with the existing CMDB. The model is workflow-approval-shaped — the same shape that ServiceNow has used for human change management for two decades, extended to agentic actions.
Microsoft Agent 365 takes the opposite end of the surface. It ships an agent registry bound to Entra, lifecycle hooks for agents built on Microsoft Agent Framework, identity issuance for Copilot agents, and integration with Defender for AI for runtime signals. For an organization whose agent estate is contained within Microsoft 365, Agent Framework, and Entra-issued identities, Agent 365 is the most coherent control plane available today.
| Control Tower | Inventory scope | Policy enforcement | Honest limitation |
|---|---|---|---|
| ServiceNow AI Control Tower | ITSM-adjacent agents | ITSM workflow approvals | Doesn't see Copilot or MCP servers |
| Microsoft Agent 365 | Entra-bound agents | Application-level (in-process) | Stops at the M365 estate boundary |
| Cordum + your registry of choice | Whatever your registry covers | Out-of-process pre-dispatch via Safety Kernel | Requires running the control plane |
Neither product is wrong about its scope. The trap is reading the marketing as if it covered the whole estate. An organization that buys ServiceNow's AI Control Tower and concludes it has solved agent governance has done nothing for the Copilot agents, the laptop-side coding agents, or the LangGraph workflows on AWS. An organization that buys Agent 365 and concludes the same has done nothing for the agents that live outside the Microsoft trust boundary. The unmanaged tail is the whole story.
Inventory drift is the silent killer
A registry that isn't authoritatively refreshed is wrong within weeks. This is not a hypothetical: it is the same drift problem that has plagued every CMDB ever built. With agents, drift is faster and the modes are different. Four matter operationally.
New MCP servers added without registration. An engineer wants their internal docs accessible from Claude Code, spins up a local MCP server, and points the client at it. The server now has access to whatever the engineer has access to. There is no path by which an enterprise registry learns about that server unless the registry is hooked into the MCP client's configuration.
Per-developer coding agents. Each engineer who installs Claude Code, Cursor, or a local Copilot adds an agent identity that holds the engineer's credentials. None of them are in the corporate agent registry because none of them registered. Their existence is observable only through proxy: API key issuance, network egress patterns, or repository action logs.
Agents spawned by other agents. A LangGraph workflow that dispatches a sub-agent to handle a step has, transiently, two agent identities. If the sub-agent is anonymous (no stable identity, no manifest), it is invisible to any registry. A2A's peer-discovery model encourages this pattern; inventory tooling has not caught up to it.
Retired agents still listed. The reverse failure mode: a workflow gets decommissioned, the manifest is forgotten, and the registry continues to show an agent identity that no longer corresponds to anything running. The drift here is the registry being a superset of reality, which is just as bad for audit purposes as being a subset.
What good discovery looks like
No single source of truth will work, because the agent population isn't in a single source. A workable discovery stack federates four signals.
Identity-provider integration. Pull the authoritative list of agent principals from Entra, Okta, Auth0, and any IAM roles or service accounts dedicated to agents. This is the strongest signal for the portion of the estate that authenticates through an enterprise IdP. It is also the part of the discovery problem that vendors like Microsoft and Okta are actively solving — use what they ship.
Runtime probes. For workloads on your own infrastructure — Kubernetes clusters, VMs, MCP servers — process-level and container-level probes can list agent processes, the credentials they hold, and the network egress they make. This is the only way to catch agents that don't register themselves and don't authenticate through a central IdP. It is a security-side problem (closer to EDR than to IAM).
Manifest scanning. Scan repositories and CI for MCP server configurations, A2A Agent Cards, and framework manifests. This is how you catch agents at definition time — before they are running — and link them back to ownership through git history. It does not replace runtime probes, but it gives you the design-intent picture that runtime probes lack.
Audit-log correlation. Cross-reference action logs across SaaS, repositories, and cloud audit trails for behavior consistent with agent activity (high-frequency API calls, machine-shaped access patterns) that doesn't correspond to a known agent identity. This is how you catch the unmanaged tail — agents using human credentials, agents authenticated through personal tokens, agents on third-party infrastructure.
None of these alone is enough. A discovery system that uses only IdP integration will miss everything outside the IdP. A system that uses only runtime probes will miss the agents on infrastructure you don't run. The honest answer is that discovery in 2026 is an integration problem, not a product purchase.
From inventory to policy
Discovery is the necessary condition; it is not sufficient. The crucial move — the one that separates an inventory dashboard from a control plane — is binding every discovered agent to a single policy decision point. Without that, the registry tells you what exists and you still have nothing that stops a bad action.
The model that survives compromise and audit is the same one we wrote about in In-Process vs Out-of-Process AI Agent Governance: pre-dispatch policy enforcement at a service that lives outside the agent runtime. Every action — tool call, API invocation, workflow handoff — is submitted to the decision point before it happens. The decision point returns ALLOW, DENY, REQUIRE_APPROVAL, or ALLOW_WITH_CONSTRAINTS. The agent never makes the decision itself, and the audit trail is produced by the decision point, not the agent.
This is the part of the AI Control Tower story that the current category mostly hand-waves. ServiceNow's policy model is workflow-approvals: well-suited to high-latency change management, badly suited to sub-second tool dispatch. Microsoft Agent 365's policy model is application-level — the Microsoft AGT pattern — which runs in-process Python middleware. For the M365 estate that is acceptable; for regulated multi-tenant deployments it is a trust boundary problem. The architecture that scales across the whole estate is registry-feeds-into-PDP, where the registry can be ServiceNow, Agent 365, Okta, or homegrown, and the PDP is an out-of-process service that every discovered agent routes through.
How Cordum approaches fleet governance
Cordum's position in this stack is the policy layer, not the registry. The Cordum Agent Protocol (CAP) gives every participating agent a verifiable identity on a NATS-based control plane. Each agent ships a capability descriptor declaring the tools and scopes it expects to use. The Safety Kernel renders the pre-dispatch decision for every action, in a separate process behind mTLS, with its own audit trail.
This composes with whatever registry an organization already runs. Agent 365 enumerates Entra-bound agents; those agents onboard to CAP, gain a CAP identity, and route their dispatches through the Safety Kernel. ServiceNow's AI Control Tower enumerates ITSM-adjacent agents; same pattern. An internal CMDB feed or an Okta agent inventory can be the source of truth for which agents exist. Cordum's job begins when an action is about to happen.
The reason the layers separate cleanly is that they solve different problems on different time horizons. Discovery is a slow, federated, integration-heavy problem — measured in days and weeks. Policy is a fast, deterministic, per-action problem — measured in milliseconds. Trying to build both into one product is what produces the dashboard-as-control-plane pattern that we see in the current category. Building them as two layers that compose is what makes a real control plane.
When a control tower alone is enough
The honest case for Agent 365 alone — without an out-of-process control plane in front of it — is real. If the estate is genuinely contained within Microsoft 365, Microsoft Agent Framework, and Entra-issued identities; if Defender for AI's telemetry is sufficient for the audit posture; if the policy model is "Entra conditional access plus application-level guardrails" and there is no regulator pushing for harder separation, then Agent 365 by itself is a coherent answer. The same logic applies to ServiceNow's AI Control Tower for organizations whose agent surface is entirely within ServiceNow workflows.
The case stops being clean the moment the estate crosses any of those boundaries. The moment you have one production LangGraph workflow running on EKS, one MCP server running on a developer's laptop with credentials it shouldn't have, or one regulated workload where an auditor wants the policy decision to live outside the application's trust boundary, the native control tower becomes the registry for one slice and you need something else to govern the rest.
This is not a knock on the native products. It is a statement about the shape of the problem. The unmanaged tail is what makes sprawl interesting; if the whole estate were inside one vendor's boundary, the vendor's native tooling would be the answer and the category would not exist.
Coding agents: the dark matter
Coding agents — Claude Code, Cursor, Devin, GitHub Copilot Workspace — are the hardest part of the sprawl problem and the one most often left out of control-tower marketing. They have repository access, CI/CD credentials, and frequently production read access. They run on infrastructure (developer laptops, third-party cloud VMs) that central security usually doesn't control. They authenticate with credentials that are often personal to the developer rather than scoped to an enterprise agent identity.
No registry catches them at install time. Even if a registry knows that Cursor is approved as software, it doesn't know which developers are running it, what API keys those developers are using, or what repositories those keys can touch. The runtime is on a laptop; the laptop is not in the security team's control plane.
The practical model is to govern their high-impact actions rather than their existence. A coding agent that wants to open a PR, push to a protected branch, invoke a deployment, read a secret, or call a production API can be required to route that action through a pre-dispatch decision point that lives on infrastructure the team does control. The agent process itself stays on the laptop; the action it requests must be approved by a service the laptop can't bypass. This is the model Cordum's CordClaw was built around — pre-dispatch governance for coding agents specifically, with the policy decision point in the enterprise control plane rather than in the agent runtime.
For organizations whose code is a regulated asset — fintech, healthcare, defense, anything with export-controlled IP — this is not an optional layer. It is the only credible answer to the question "what stops a compromised coding agent from exfiltrating the codebase or modifying production?" A registry alone does not answer that question. Pre-dispatch policy at the action level does.
A 3-step start
For a security or platform team starting on this problem in 2026, three concrete steps produce more value than choosing a control tower vendor.
Step 1 — Inventory the identity boundaries. List every identity provider that issues credentials agents use: Entra, Okta, Auth0, any cloud IAM that issues service-account keys, any SaaS that issues API tokens. For each, query for principals tagged or named as agents, and for service accounts whose access patterns look agent-shaped. This is the floor of the inventory: agents that authenticate through enterprise IdPs are at least visible to enterprise IdP tooling.
Step 2 — Inventory MCP servers on org infrastructure. Scan repositories, CI configurations, and developer-facing infrastructure for MCP server configurations and running processes. This catches the next tier — agents that run inside org boundaries but don't authenticate through an IdP. The output is a list of MCP servers, the credentials they hold, and the developers or systems that own them.
Step 3 — Pick one pre-dispatch decision point and route every discovered agent through it. The decision point can be Cordum's Safety Kernel, an internal OPA deployment with agent-shaped policies, or another out-of-process PDP — what matters is that it exists, that it is one of them, and that every agent identified in steps 1 and 2 routes its high-impact actions through it. The decision point is what turns the inventory into governance.
The temptation is to start by buying a control tower. The more durable starting point is to start by building the inventory the way the estate actually shapes it, and then to make sure there is one point of policy enforcement everything routes through. A control tower vendor can be the registry of record on top of that; it cannot replace the underlying federation.