Agent sprawl is the new shadow IT: why enterprises need an agent registry

We have seen this adoption pattern before. In the 2010s, employees adopted SaaS faster than IT could govern it, creating shadow IT. In the early 2020s, employees adopted generative AI faster than organizations could establish clear data, risk, and usage controls, creating shadow AI. The next iteration is already taking shape: agents are being created faster than organizations can inventory, own, secure, and control them.

This iteration is different. A shadow SaaS application stores data and exposes functions to a user. A shadow agent may have its own identity, credentials, memory, tools, model dependencies, and delegated authority. It may initiate actions, call other agents, and continue working after the person who started it has moved on.

What agent sprawl actually means

Agent sprawl occurs when agents proliferate across internal development teams, employee automations, coding environments, SaaS products, vendor platforms, embedded copilots, MCP servers, and multi-agent workflows without a common system of record. Some are centrally built. Some arrive inside software the organization already buys. Some are configured by business users. Some are created dynamically by other agents.

• Internal agents: HR, finance, procurement, customer service, software delivery, security, and analytics.
• Embedded agents: capabilities introduced through CRM, productivity, service-management, and enterprise SaaS platforms.
• Employee agents: personal assistants, low-code automations, coding agents, and browser-based workflows.
• Vendor and partner agents: externally operated systems that act inside enterprise processes.
• Ephemeral sub-agents: short-lived workers created by orchestrators to complete a task or delegate specialized work.

The problem is not necessarily the number of agents. A large portfolio can be intentional and well controlled. The problem is the absence of visibility, ownership, and an enforceable description of what each agent may do.

Why agent sprawl is more dangerous than shadow IT

The hidden agent attack surface

An agent connected only to public information has a very different consequence surface from an agent that can retrieve customer records, prepare a purchase order, send a message, modify source code, or initiate a payment. Capability accumulates across the system: identity, credentials, enterprise data, retrieval, memory, tools, MCP servers, delegated authority, and other agents.

Each new connection changes what failure means. A bad answer becomes an incorrect update. An untrusted instruction becomes a tool call. An over-broad token becomes access to a second system. A compromised MCP server becomes a path into the enterprise. A delegated sub-agent becomes another actor whose behavior must be attributed and constrained.

• Identity surface: Which principal authenticates, and can activity be attributed to the agent rather than a human or generic service account?
• Data surface: What records, retrieval indexes, prompts, files, and memory stores can the agent read or modify?
• Tool surface: Which actions are available, what side effects do they create, and where are arguments validated?
• Delegation surface: Can the agent create sub-agents, call remote agents, or transfer authority?
• Supply-chain surface: Which models, libraries, connectors, MCP servers, and vendor services can change independently?
• Operational surface: Can the organization observe, suspend, revoke, recover, and explain the agent’s actions?

The questions most enterprises cannot answer yet

A useful governance test is to ask how quickly the organization can answer a small set of operational questions:

• How many agents are running or available in the organization?
• Who is the accountable business sponsor and technical owner for each one?
• Which agents are third-party, employee-created, or dynamically generated?
• Which models, data sources, memory stores, tools, and MCP servers do they use?
• Which identities and credentials do they use, and when do those credentials expire?
• Which agents can delegate work or create real-world consequences?
• Which agents have current evaluations, security reviews, approvals, and incident history?
• Which agents have materially changed, become orphaned, or should already have been retired?

If these questions require weeks of investigation, the organization does not yet have operational agent governance. It has governance intentions distributed across architecture documents, identity systems, source repositories, vendor portals, tickets, and policy files.

Why the CMDB is not enough

A configuration management database remains useful for applications, servers, databases, APIs, owners, and environments. But an agent is not only another application component. Its relevant governance state includes purpose, identity, autonomy, models, tools, data access, memory, delegations, evaluations, policies, incidents, and current approval status.

The CMDB may tell you that a procurement service exists. It usually cannot tell you that version 3.2 of the procurement agent can create purchase orders up to a defined limit, uses a specific model and MCP server, carries bounded delegated authority, passed its last evaluation on a particular date, and must stop operating when its sponsor leaves.

What belongs in an Agent Registry?

An Agent Registry is a machine-readable system of record for the agents an organization builds, buys, exposes, or allows to operate. It does not need to replace every source system. It should connect identity, ownership, capability, authority, assurance, and lifecycle into one governable record.

The registry should include both declared metadata and discovered evidence. A developer may declare the intended tools and owner. Runtime discovery may reveal an unregistered MCP connection, a changed permission, or an agent identity with no sponsor. The difference between declared and observed state is itself a governance signal.

The Agent Card becomes the governance record

The emerging A2A protocol uses a JSON Agent Card to describe an agent’s identity, capabilities, skills, interfaces, and security requirements. That is a useful interoperability foundation. Enterprise governance needs to extend the idea with internal ownership, authority, risk, controls, evidence, and lifecycle metadata.

agent:
  id: procurement-agent
  version: 3.2
  environment: production

owner:
  business: Procurement
  technical: AI Platform

purpose: bounded purchasing
autonomy: A2
risk: high

tools:
  - vendor.read
  - po.prepare
  - po.create

authority:
  max_purchase: 15000
  delegation: false

mcp:
  - procurement-mcp@2.1

controls:
  policy: procurement-v7
  approval: risk-based
  kill_switch: true
  recertify_by: 2026-12-01

The important point is not the exact schema. The Agent Card should not become another PDF. It should be versioned, validated, queryable, linked to runtime identities, and consumable by CI/CD, policy engines, security tooling, and administrative workflows.

Registration should happen before deployment

Registration should be a delivery gate, not a cleanup activity. A new agent should be registered, assigned accountable owners, classified by autonomy and risk, matched to required controls, evaluated, and approved before it receives production authority.

Registration enables automatic routing. A read-only informational agent working over public documentation may follow a lightweight path. An autonomous finance agent that can write to systems, delegate tasks, or cross a financial threshold should trigger stronger evidence, approval, monitoring, and recovery requirements.

Not every agent deserves the same governance

A registry becomes useful when it helps the organization govern proportionately. Treating every chatbot like a payment agent creates bureaucracy; treating every payment agent like a chatbot creates risk. A practical autonomy ladder is:

This is not a universal risk equation; it is a design heuristic. The purpose is to make governance responsive to the consequence surface instead of uniformly heavy.

Third-party agents turn inventory into supply-chain governance

Enterprises will consume many agents through vendors rather than build them. A third-party agent may change its model, capabilities, memory behavior, tool set, or hosting arrangement outside the customer’s release process. The registry therefore needs to record both the agent and its dependency chain.

• Who publishes and operates the agent, and who owns the enterprise relationship?
• Where are prompts, memory, telemetry, and retrieved data processed or stored?
• Which model, framework, libraries, MCP servers, tools, and enterprise systems form the execution path?
• Can the provider change the model, permissions, or capabilities without customer approval?
• How are incidents reported, access revoked, evidence preserved, and the agent disabled?
• Which contractual, privacy, residency, retention, and audit obligations apply?

In this sense, agent inventory increasingly becomes AI supply-chain inventory: foundation model → agent framework → libraries → agent → MCP servers → tools → enterprise systems. Each link needs an owner, a trust decision, and a change signal.

Registration is not enough: agents drift

An approved agent does not remain static. Version one may use Model A, two tools, read-only permission, no persistent memory, and assisted execution. Three months later it may use Model B, a new tool and MCP server, write permission, persistent memory, and bounded autonomy. If the registry still says only “approved,” the approval has lost its meaning.

Material changes should include a new model, tool, MCP server, permission, data source, memory store, delegation path, external action, risk classification, or autonomy level. The change process can distinguish non-material updates, which receive regression checks, from material updates, which require reassessment and reapproval.

This turns governance into a continuous lifecycle. It also aligns with the NIST AI RMF emphasis on post-deployment monitoring, change management, incident response, recovery, and decommissioning—not one-time approval.

The registry should connect to runtime governance

A registry becomes strategically important when it informs enforcement. The registry describes what the agent is supposed to be: identity, owner, risk, permissions, policy, dependencies, autonomy, and status. A governance control plane evaluates whether a proposed action fits that registered boundary in the current context.

The model should not silently certify its own correctness or authorize its own action. The agent proposes. A policy layer evaluates identity, action, resource, context, risk, and current status. The tool boundary enforces the decision. The system records the identity chain, policy version, evidence, decision, and outcome.

The MCP authorization specification reinforces an important part of this architecture: access tokens must be audience-bound to the intended server, validated by the resource server, and must not simply be passed through to downstream systems. Registry metadata cannot replace protocol security, but it can tell security tooling which MCP servers, scopes, identities, and trust relationships are expected.

From Agent Registry to Agent Control Plane

The maturity path is not about buying five products. It is about answering progressively harder questions. Inventory establishes visibility. A registry adds ownership and authority. Lifecycle governance establishes approval and currency. Runtime governance decides whether actions should execute. Continuous governance tests whether controls remain effective as agents and their environments change.

Governance-as-code changes the operating model

Manual review cannot keep pace with a growing agent portfolio. The registry record should be validated in the same delivery workflow as code, infrastructure, evaluations, and policy. A pull request can check that ownership exists, dependencies are registered, risk is classified, required controls passed, approvals remain current, and critical findings are resolved.

assert agent.owner.business
assert agent.owner.technical
assert agent.risk_tier
assert dependencies_registered(agent)
assert required_controls_pass(agent)
assert approval_is_current(agent)
assert critical_security_findings == 0

Governance-as-code does not remove human judgment. It reserves human attention for exceptions, uncertainty, significant trade-offs, and consequential decisions while making routine evidence collection and policy checks consistent.

Agent discovery may become a security capability

Declared registration will never be sufficient on its own. Organizations will increasingly need to discover agent processes, identities, API calls, MCP connections, tool calls, service accounts, and agent-to-agent traffic. The security analogy is a combination of cloud asset management, CMDB discovery, identity discovery, and endpoint detection—but focused on autonomous actors and their authority chains.

Microsoft’s current Agent Registry and Agent ID documentation already reflects this direction: centralized agent inventory, owners and sponsors, lifecycle management, risk signals, metadata, discovery, identity controls, and support for agents from multiple creation channels. The implementation details will vary across ecosystems, but the operating requirement is broader than any one vendor platform.

The metrics that matter

The most useful metrics expose gaps between what the organization believes and what is operating. A declining inventory count is not inherently good; a declining count of unknown, unowned, stale, over-privileged, or untested agents is.

What enterprises should do now

• 1 — Inventory existing agents. Start with identity systems, SaaS platforms, source repositories, low-code environments, MCP configurations, and network or API telemetry. Do not wait for a perfect platform.
• 2 — Assign accountable owners. Every production agent needs a business sponsor and a technical owner with defined lifecycle and incident responsibilities.
• 3 — Define a standard Agent Card. Make the record machine-readable, versioned, and extensible. Separate public interoperability metadata from sensitive internal governance metadata.
• 4 — Classify autonomy and risk. Use consequence, access, reversibility, uncertainty, and delegation to determine the governance path.
• 5 — Register tools, MCP servers, and dependencies. Treat agents as supply chains and track both declared and observed connections.
• 6 — Connect registration to delivery. Require governance metadata, evaluations, security checks, and current approvals before production deployment.
• 7 — Detect material changes. Do not allow approval to survive a major capability, permission, model, memory, or autonomy change automatically.
• 8 — Connect the registry to runtime policy. Move from visibility toward enforceable decisions, rapid suspension, evidence, and recovery.

You cannot govern what you cannot see

Shadow IT taught enterprises that they cannot secure applications they do not know exist. Shadow agents add a more consequential lesson: organizations cannot govern autonomous authority they do not know exists.

Before enterprises race to deploy thousands of AI agents, they need the infrastructure to know which agents exist, who owns them, what they can access, what authority they carry, how they have been evaluated, whether they have changed, and whether they should still be running.

Primary references