Because you cannot investigate agents you do not know exist.

In my previous post on forensic readiness, I argued that evidence architecture must be designed in from day one. The blog closed with a line that should be called out and looked into futher.

“Govern AI agent sprawl before it becomes your next compliance incident. Because you cannot investigate agents you do not know exist.”

This is the Agent Registry Problem and is the upstream dependency that makes forensic readiness, compliance reporting and incident investigation either possible or impossible.

Get this wrong and everything downstream could fail silently.

The Sprawl Is Already Here

Inside a Fortune 500 insurer’s claims department, 340 AI agents process customer disputes, flag fraud and authorise payouts. No single executive can name them all. This is not a future scenario. Agent sprawl (agents created, deployed or connected faster than the enterprise can inventory, own, permission, monitor and retire them) has become the defining governance challenge of the decade.

The growth curve is vertical. Gartner projects that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024. Microsoft reported at Ignite 2024 that users of Copilot Studio alone had created more than 100,000 agents within one month of general availability, with CEO Satya Nadella subsequently projecting scaling toward a million agents across the ecosystem. Despite this explosive growth, governance and monitoring coverage has not kept pace.

The confidence gap is striking. Organisations consistently overestimate their visibility into AI agent deployments. The Cloud Security Alliance’s research into AI organisational responsibilities and governance has documented a persistent disconnect between perceived and actual visibility. Organisations report high confidence in their AI oversight while simultaneously discovering unsanctioned AI systems operating within their environments.

A blind spot masquerading as self-assurance.

Agent Sprawl Is the New Shadow IT

The patterns are familiar:

• A Teams bot for HR questions.
• An incident helper for DevOps.
• A BI agent that explains KPI changes.
• A support agent that drafts replies.
• A Power Automate flow with an LLM step.
• A Copilot Studio agent owned by one department.

Each looks harmless on its own.

Six months later, nobody knows how many agents exist, which credentials they use, which data sources they access or whether anyone still owns them.

As I argued in Why Shadow AI is the Defining Enterprise Risk, Shadow AI and agent sprawl are deeply connected but not identical. Shadow AI is the broader phenomenon , unsanctioned AI usage across theenterprise.

A shadow agent with production access is not a policy violation. It is an uncontrolled actor in your enterprise with no accountability, no monitoring, no forensic trail and no kill switch.

“Once agents can call tools and change things, they are no longer a chat feature. They are automation with a blast radius.”

Why the CMDB Cannot Save You

Enterprise IT has decades of experience managing servers, applications and services. We have CMDBs, service catalogues and asset registers. The instinct is to extend them, however, the instinct is wrong.

Dimension	Traditional IT Asset	AI Agent
Creation speed	Weeks (procurement, provisioning)	Minutes (low-code platforms, API calls)
Creator profile	IT professionals with change control	Business users, developers, other agents
Boundary clarity	Runs on defined infrastructure	Spans systems, APIs, trust boundaries
Behaviour predictability	Deterministic, testable	Non-deterministic, context dependent
Lifecycle visibility	Procurement → deployment → retirement	Often no formal lifecycle at all
Identity model	Service accounts, managed credentials	Inherited permissions, delegated authority, ambient access
Dependency mapping	Network topology, API contracts	Prompt chains, tool invocations, agent-to-agent delegation
Retirement trigger	EOL, refresh cycle, decommission request	Unknown, often never retired

The CMDB was built for a world where assets were expensive, slow to provision and managed by specialists. Agents are cheap, fast to create and increasingly built by anyone with access to a platform. The governance model must match the creation model.

The Root Cause: Binary Governance

Industry research consistently identifies the same failure pattern: enterprises treat AI agent governance as binary, either locked down or fully trusted.

Gartner’s AI TRiSM (AI Trust, Risk and Security Management) framework, maintained as a core research stream since 2023, explicitly advocates for risk-proportionate governance rather than blanket policies. Their research positions organisations that fail to implement graduated AI governance as significantly more exposed to both security breaches and innovation stagnation.

In March 2025, Gartner predicted that 25% of enterprise breaches will be traced to AI agent abuse by 2028, driven precisely by this governance gap.

“The emergence of AI agents introduces a new attack surface that traditional security measures are not designed to address.” Source: Jeremy D’Hoinne, VP Analyst, Gartner (March 2025)

This binary approach produces two failure modes:

Over-restriction kills innovation. Agents are blocked entirely, Shadow AI proliferates and the organisation loses visibility completely. The agents still exist, they just exist outside governance.

The EU AI Act (Regulation (EU) 2024/1689) explicitly rejects this approach, establishing four graduated risk tiers precisely because blanket prohibition is both impractical and counterproductive.

Over-trust creates uncontrolled risk. Agents are deployed without boundaries, accumulate permissions over time, delegate to other agents without oversight and operate in production with no one accountable for their behaviour.

The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) addresses this through its GOVERN function. While the framework does not explicitly mandate agent registries, its accountability structures (GV-2) and documentation requirements (GV-1) logically imply that organisations must know which AI systems they operate. Making an inventory a practical prerequisite for compliance.

The correct approach is graduated governance.

Explicit authority boundaries defined per agent, proportionate to risk, enforced at runtime and auditable after the fact. Not binary and not bureaucratic, but architectural.

This principle is reinforced across multiple authoritative frameworks:

Framework	Graduated Governance Mechanism
EU AI Act (2024)	Four-tier risk classification: Unacceptable, High, Limited, Minimal
NIST AI RMF 1.0 (2023)	MAP-MEASURE-MANAGE-GOVERN functions scaled to impact
Gartner AI TRiSM (2023–2026)	Risk-proportionate controls across the AI lifecycle
ISO/IEC 42001:2023	AI Management System with graduated control objectives

What an Agent Registry Actually Is

An agent registry is not a spreadsheet, not a wiki page and is not a column in your CMDB. It is a live, queryable, authoritative system of record that answers seven questions at any point in time:

1. Which agents exist?
2. Who owns them?
3. Which identity do they use?
4. Which tools can they call?
5. Which data can they touch?
6. What did they do yesterday?
7. Who gets called when something goes wrong?

If those questions are hard to answer, the environment is not ready for broad agent adoption.

The Registry Schema

The minimum viable registry captures four domains:

Identity and Ownership

• Unique agent identifier (machine readable, immutable, cryptographically verifiable)
• Human-readable name and purpose statement
• Accountable owner (named individual, not a team or a role, but a person)
• Business sponsor who approved the agent’s existence
• Creation date, creator identity, approval chain
• Lifecycle state: Candidate → Approved → Active → Restricted → Deprecated → Retired

Capability and Authority

• Documented purpose and approved use cases
• Approved toolset with explicit per-tool permissions
• Data access scope (which systems, which data classifications)
• Decision boundaries (what the agent can and cannot do autonomously)
• Delegation authority (can it invoke other agents? which ones? under what conditions?)
• Trust level and autonomy classification (advisory, semi-autonomous, autonomous)
• Escalation triggers (conditions requiring human intervention)

Technical Configuration

• Model version and parameters (versioned, change controlled)
• System prompt (exact text, not a template reference, versioned with effective dates)
• Connected systems and API endpoints
• Retrieval sources and embedding index versions
• Runtime environment, hosting location, data residency
• MCP server connections and tool definitions

Governance Metadata

• Risk classification (aligned to EU AI Act risk tiers where applicable)
• Last review date and next review due
• Compliance obligations mapped (which regulations apply to this agent’s scope)
• Incident history (linked to forensic evidence stores)
• Change history (what changed, when, who approved, why)
• Forensic readiness score (per the checklist in the forensic readiness post)
• Cost and consumption metrics (token usage, API calls, compute)

The Four Governance Disciplines

A registry without operational disciplines is documentation. Four disciplines make it governable. I am deliberately keeping this practical rather than theoretical.

1. Registry: Know What Exists and Who Owns It

Discovery first. Most organisations already have agents they do not know about. Discovery requires:

• Network level detection of AI API calls (model endpoints, tool invocations, MCP connections)
• Platform level inventory of agents created on sanctioned platforms (Copilot Studio, Amazon Bedrock, Azure AI Foundry, custom frameworks)
• Credential audit identifying service accounts with AI related permissions
• Procurement analysis identifying AI platform subscriptions and API keys
• Amnesty programmes for undeclared agents (make it safe to register, dangerous not to)

Every discovered agent gets registered and passes through a registration gate before production. This provides the minimum viable control that makes all other governance possible.

2. Identity: Give Every Agent a Clear and Limited Blast Radius

Every agent gets a managed, scoped identity. Not inherited credentials, not shared service accounts, nor ambient permissions from the creating user.

The identity model must provide:

• Unique, auditable identity per agent instance
• Scoped permissions per action and per target system (least privilege, enforced)
• Time-bounded credentials with automatic rotation
• Delegation chains that preserve attribution (agent A invoked agent B on behalf of user C)
• Revocation that is immediate, complete and does not destroy forensic state

This connects directly to the forensic readiness architecture. Layer 1 of the AI Evidence Taxonomy (Identity and Context) requires knowing which agent processed an interaction. Without managed identity, attribution is impossible.

“Agentic identities differ from traditional machine identities in one critical way: they make decisions. They determine when to act, what to access and how to combine capabilities.” Source: UnoSecur Governance Strategies for Machine & AI Identities (2026)

3. Guardrails: Define and Enforce Boundaries at Runtime

Registration is a point-in-time control. Agents drift. Their behaviour changes with prompt modifications, retrieval corpus updates and model version changes. Guardrails must be continuous and runtime-enforced:

• Policy compliance checks on every tool invocation (is this action within the agent’s approved scope?)
• Rate limiting and budget enforcement (token consumption, API call frequency, cost ceilings)
• Trust boundary enforcement (is this delegation permitted? does this cross a data classification boundary?)
• Circuit breaking (automatic pause when anomaly thresholds are exceeded)
• Human-in-the-loop gates for high consequence actions

The guardrails connect to the governance gateway pattern: every agent-to-system and agent-to-agent interaction passes through a policy enforcement point that validates, logs and can halt execution.

4. Observability: Know What They Did Yesterday

Monitoring must answer not just “is it running?” but “is it behaving within its registered purpose?”

• Runtime behaviour compared against registered purpose and approved scope
• Permission usage analysis (what does the agent actually access versus what it is approved for?)
• Drift detection (has behaviour changed without a corresponding governance approval?)
• Agent-to-agent interaction monitoring (delegation chains, trust boundary crossings, cascading actions)
• Cost and consumption tracking with alerting on anomalies
• Forensic evidence capture (feeding the evidence architecture described in the previous post)

The Regulatory Imperative

All three jurisdictions covered in the forensic readiness post are converging on registry requirements through different mechanisms:

Jurisdiction	Mechanism	Registry Implication
EU	AI Act Article 49, mandatory registration of high-risk AI systems in EU database	You need an internal registry before you can comply with the external one
EU	AI Act Article 12, logging that identifies the AI system throughout its lifetime	System identification requires a registry as the authoritative source
EU	AI Act Article 9, documented risk management per system	Risk management requires knowing what systems exist
UK	ICO accountability principle	You must demonstrate which AI systems process personal data
UK	FCA SM&CR, named individuals personally accountable	Accountability requires mapping agents to owners
UK	AI Safety Institute reporting expectations	Incident reporting requires system identification
US	NIST AI RMF Govern function	Inventory and documentation of AI systems implied by accountability requirements
US	Colorado AI Act, SB 24-205	Risk management and impact assessments per system
US	SEC AI risk disclosure	Material AI risks must be documented, requires knowing what exists

The EU AI Act’s Article 49 is the most explicit: high-risk AI systems must be registered in an EU database before being placed on the market. You cannot register externally what you have not inventoried internally.

Architecture Patterns

Three architecture patterns address the registry problem at the infrastructure level rather than the process level:

Pattern 1: The Control Plane

Separate the agent control plane from the agent execution plane. The control plane manages agent lifecycle, permission grants, configuration versioning, monitoring and evidence collection. No agent reaches production without passing through the control plane. No permission is granted except through the control plane. No configuration change takes effect without control plane approval.

This mirrors how we govern infrastructure. Kubernetes has a control plane. Networks have a management plane. Agents need the same architectural separation.

Pattern 2: The Identity Mesh

Cryptographic identifiers for every agent action. A unified identity layer that spans all agent platforms, all tool connections, all delegation chains. The identity mesh ensures that every action in the enterprise can be attributed to a specific agent, operating under a specific identity, with specific permissions, on behalf of a specific human.

Google’s Gemini Enterprise Agent Platform has formalised this as three primitives: Agent Identity (cryptographic identifiers for every action), Agent Gateway (unified policy enforcement for all agent-to-tool calls) and Agent Registry (centralised catalogue for managing agents, tools and MCP servers). The pattern is converging across vendors.

Pattern 3: The Governance Gateway

Every agent-to-system and agent-to-agent interaction passes through a governance gateway. The gateway enforces policy, captures evidence, applies rate limits, validates trust boundaries and provides the circuit-breaking capability described in the forensic readiness post’s containment hierarchy.

The gateway is where the registry becomes operational. It is the runtime enforcement of what the registry declares.

The Maturity Model

Score your organisation:

Level	State	Characteristics	Regulatory Sufficiency
0	Unaware	No inventory. Agents created ad hoc. No ownership. No lifecycle.	Non-compliant
1	Reactive	Partial inventory. Discovered after incidents. Manual tracking. Spreadsheet-based.	Non-compliant
2	Documented	Registry exists. Registration process defined. Periodic review. Ownership assigned.	Minimum viable (UK principles-based)
3	Controlled	Automated discovery. Enforced registration gate. Continuous monitoring. Managed identity.	Compliant (EU AI Act Article 49)
4	Optimised	Predictive governance. Automated lifecycle. Forensic readiness integrated. Real-time observability.	Full compliance across jurisdictions

Most enterprises are at Level 0 or 1. The regulatory environment demands Level 2 minimum by end of 2026. The forensic readiness requirements from the previous post demand Level 3.

“Trusting AI agents isn’t enough. If you can’t prove they stayed within their limits, your governance isn’t working.”

The Forensic Readiness Connection

The Agent Registry Problem and forensic readiness are two sides of the same architectural coin. They are not separate initiatives. They are the same initiative viewed from different angles.

The forensic readiness post described five layers of evidence. Layer 1 (Identity and Context ) asks: which agent processed this interaction? If you cannot answer that question because you do not have a registry that maps agent identifiers to owners, purposes, permissions and configurations, then your entire evidence taxonomy has no anchor.

Without a registry, you cannot:

• Attribute an action to a specific agent (Layer 1 fails)
• Determine what permissions that agent held at the time of the incident (Layer 2 fails)
• Reconstruct the configuration that produced the outcome (Layer 3 fails)
• Demonstrate to a regulator that the agent was operating within approved boundaries (Layer 5 fails)
• Contain the agent without cascading damage to unknown dependents (Containment hierarchy fails)

The registry is the forensic readiness prerequisite. It is also the compliance prerequisite, the incident response prerequisite and the accountability prerequisite.

The Offboarding Problem

Creation gets all the attention. Retirement gets none, but ungoverned retirement is where compliance incidents breed.

When an agent is retired, the registry must ensure:

• Credentials are revoked without destroying forensic state (the critical principle from the previous post)
• Downstream consumers are identified and notified (requires the registry to track dependencies)
• Evidence and audit trails are archived with appropriate retention
• The registration record is marked as retired, not deleted (the registry is itself an evidence store)
• No orphaned permissions remain in connected systems

When an agent’s owner leaves the organisation, the registry must trigger ownership transfer. An ownerless agent is an ungoverned agent. An ungoverned agent is a compliance incident waiting to happen.

The Action Sequence

If you are recognising your organisation in this post, here is the sequence. This is should not be considered as a transformation programme, but rather a series of concrete steps.

Week 1–2: Discovery

• Audit AI platform subscriptions and API key usage
• Identify all service accounts with AI related permissions
• Survey teams for undeclared agents (amnesty, not punishment)
• Map known agents to named owners
• Count the unknowns. That count is your governance debt.

Week 3–4: Registry Design

• Define the registry schema (use the four domains above)
• Select or build the registry platform (this can start as structured data and should not stay as a spreadsheet)
• Define the registration process (lightweight enough to not be bypassed)
• Establish risk classification criteria aligned to your regulatory obligations

Month 2: Registration and Identity

• Register all discovered agents
• Assign managed identities (replace inherited credentials)
• Classify risk levels
• Identify agents without forensic readiness
• Establish ownership for every agent (no exceptions)

Month 3: Guardrails and Observability

• Implement runtime monitoring for registered agents
• Deploy governance gateway for high-risk agents first
• Define review cadences proportionate to risk
• Connect registry to forensic evidence stores
• Establish circuit breaking thresholds

Ongoing: Enforcement and Lifecycle

• Block unregistered agents from production access
• Automate discovery of new agents
• Integrate registry with change management
• Report registry health to governance boards
• Retire agents that no longer serve their documented purpose
• Transfer ownership when people leave

What Comes Next

The Agent Registry Problem is not a technology problem. The technology exists. Platforms are shipping agent registries, identity meshes and governance gateways. The academic community has formalised registry architectures across centralised, enterprise and distributed approaches.

The problem is organisational. It is the recognition that you cannot govern what you cannot see, you cannot investigate what you do not know exists and you cannot demonstrate compliance for systems you have not inventoried.

The forensic readiness architecture from the previous post is meaningless without a registry. The evidence taxonomy has no anchor. The containment hierarchy has no target. The reconstruction capability has no baseline. The chain of custody has no starting point.

• Start with discovery
• Build the registry
• Enforce registration
• Monitor continuously
• Review periodically
• Retire deliberately

Because the next compliance incident will not be caused by an agent you knew about. It will be caused by the one you did not.

References

1. “Top 10 Strategic Technology Trends for 2025” (October 2024), Gartner
2. “Gartner Predicts 25% of Enterprise Breaches Will Be Traced to AI Agent Abuse” (March 2025), Gartner
3. “What Is AI TRiSM?”, Gartner
4. Copilot Studio Agent Creation Metrics, Microsoft Ignite 2024 
5. Regulation (EU) 2024/1689 (EU AI Act), European Parliament
6. “Artificial Intelligence Risk Management Framework (AI RMF 1.0)” (January 2023), NIST
7. “Information technology, Artificial intelligence Management system”, ISO/IEC 42001:2003
8. Colorado AI Act, SB 24-205
9. Cloud Security Alliance, AI Research Programme
10. “Governance Strategies for Machine & AI Identities” (2026), UnoSecur

AI Forensic Readiness: Evidence Architecture for the Agentic Enterprise

Why Shadow AI is the Defining Enterprise Risk