Agent Sprawl: What Happens When Hundreds of Agents Operate Without a Central Registry

Agent sprawl rarely arises from negligence. It stems from decentralisation without guardrails. In most corporations, the process follows the same stages:

 

1. The 1st agent: A manageable showcase. The model is hard-coded, with security assumed by default. Because only a few people have access, the lack of role management goes unnoticed.
2. The 5th agent: Two more departments follow suit. The first interfaces to internal databases are built. Most often, generic service accounts are shared because creating individual service accounts would take too long.
3. The 20th agent: The first employees leave the project or the department. No one knows exactly which server a script is running on, which prompt was stored in version 3, or why a particular agent has write access to the SAP system.
4. The 50th to 100th agents: Multiple instances access the same base models via uncoordinated endpoints. Token invoices are posted to collective cost centers. If errors occur, such as an incorrect discount calculation or a service ticket closed in error, the decision-making process can no longer be reconstructed.

 

At this point, the system is no longer controllable. You’re not operating an automation landscape, but rather a patchwork of black boxes.

Anyone who wants to keep hundreds of agents running in production doesn’t need lengthy policy documents gathering dust on the intranet. What’s needed is a technical infrastructure that makes governance a runtime property. Seven building blocks form the foundation:

 

1. The Central Registry (Agent Registry)

 

The registry is the inventory of all agents active within the company. Each agent is assigned a unique identity, a defined version, a business owner, and a description of its task. Anything not listed in the registry is denied network access and access to interfaces. An entry clarifies: Who approved this agent? Which model does it use? Which business process does it serve?

 

 

2. Identities and Permissions (Least Privilege)

 

An agent must never operate with the privileges of a generic administrator or system account. It requires its own, non-human identity with strictly limited privileges. An agent that reads invoices needs read access to the document archive but no write access to supplier master data. Permissions must be able to be revoked centrally as soon as an anomaly occurs.

 

 

3. Mandatory Policies (Policy Enforcement)

 

Prompts are not security barriers. Rules such as “Do not disclose personal data” or “Do not process transactions exceeding 10,000 euros” must not appear as text instructions in system prompts, where they can be circumvented by unexpected user input. They must be implemented as hard validation rules both before and after execution.

 

 

4. Complete Observability and Tracing

 

Traditional log files are not sufficient. In agent-based systems, it must be possible to trace what information the agent received as context, what intermediate steps it planned, which API call was triggered, and what result was returned. Only with complete traces can erroneous decisions be audited and explained to auditors or regulatory authorities.

 

 

5. Lifecycle Management and Deprovisioning

 

Agents are not perpetual entities without an expiration date. Models become obsolete, interfaces change, and business processes are adapted. A regulated lifecycle defines test phases, staging, approvals, regular quality checks, and, above all, the orderly decommissioning (sunset) of retired versions.

 

 

6. Cost and Token Control (FinOps)

 

Every call costs money. Without centralised usage monitoring, infinite loops, oversized context windows, or inefficient retry logic can lead to skyrocketing bills. Budget limits are necessary per agent, per team, and per process, combined with automatic shutdown mechanisms when limits are exceeded.

 

 

7. Audit-Proof Audit Trails

 

If an agent makes a decision or prepares to make one, this path must be logged in an unalterable manner. When inquiries arise months later, it must be clear: What was the data state at the time? Which model was running at that moment? What validation took place?

Many architectures attempt to embed governance directly into the code of each individual agent. In practice, this fails immediately as soon as developers use different libraries, programming languages, or cloud services.

 

The solution to this disconnect is a central agent gateway.

 

The gateway acts as a control layer between the agents, the language models, and the connected enterprise systems. All calls must go through this instance. This offers decisive advantages:

 

• Model independence: The agent communicates with the gateway. The gateway uses routing rules to determine which LLM answers the request in the background, whether it’s a cloud model or a locally hosted open-source variant.
• Centralised filtering: The gateway checks inputs and outputs for confidential company data, protects against data leakage, and blocks unauthorised command patterns before they reach the model.
• Rate and cost limits: Budgets and limits are enforced in a single location, regardless of the framework in which the agent was written.
• Unified telemetry: Metrics, latencies, error rates, and token consumption are collected in a standardised manner in one place.

 

Those who omit the gateway must reinvent security and cost checks for every single project—and inevitably lose track of the big picture.

Agent governance must not be an after-the-fact verification step that stifles innovation. If developers and business units have to wait four weeks for approval of a simple experiment, they will once again migrate to shadow IT.

 

Successful organisations embed governance directly into the platform’s design (“Governance by Design”). Developers are provided with pre-built, approved connectors, standardised authorisation templates, and an environment where logging, tracing, and cost monitoring are automatically enabled. The safest path must also be the most convenient one for the team.

 

This directly links risk control to business value (“Value by Design”): An agent is only put into production if it is assigned to a clear process step, saves measurable time, and meets defined quality criteria. The Scheer PAS overview page on Agentic Process Orchestration helps explain this idea: Autonomy does not arise from a lack of rules, but from a uniform execution environment with clear control points and human oversight.

How you get started depends on the current state of your organisation:

 

• Scenario A: Few to no agents in use
  This is the best starting point. Create the agent registry and the identity rules before the second agent is built. Setting up a registry for two agents takes an afternoon. Retrospectively cataloging eighty unmanaged installations takes months.

 

• Scenario B: 10 to 30 agents already active across various teams
  Do not impose an immediate development freeze; instead, initiate an inventory. Focus primarily on three things: Which external interfaces and data sources does the agent use? Which service account does it use? Who is technically responsible for the accuracy of the results? At the same time, implement a central gateway for all model calls.

 

• Scenario C: Widespread uncontrolled proliferation with unclear access rights
  Here, risk minimisation is the top priority. Immediately separate write access to core systems from generic accounts. Require temporary human approval (human-in-the-loop) for every automated system change until the traceability and error rates of the agents involved are proven beyond a doubt.

 

Hundreds of agents in a company are not a threat, but rather an enormous lever for value creation. They only become a burden when no one knows who built them, what they’re allowed to do, and who pulls the plug if they go off track.