{"id":26872,"date":"2026-09-24T14:41:34","date_gmt":"2026-09-24T12:41:34","guid":{"rendered":"https:\/\/scheer-pas.com\/en\/?post_type=post_type_article&p=26872"},"modified":"2026-11-04T11:01:22","modified_gmt":"2026-11-04T10:01:22","slug":"agent-sprawl-central-registry","status":"publish","type":"post_type_article","link":"https:\/\/scheer-pas.com\/en\/blog\/article\/agent-sprawl-central-registry\/","title":{"rendered":"Agent Sprawl: What Happens When Hundreds of Agents Operate Without a Central Registry"},"content":{"rendered":"
<\/div>
\n
\n \"Agent <\/div>\n\n<\/div><\/div>
\n\t

BLOG<\/p>\n<\/div><\/div><\/div><\/div>

\n\n\t
\n\t\t

Agent Sprawl: What Happens When Hundreds of Agents Operate Without a Central Registry<\/h1>\t<\/div>\n\n<\/div><\/div>
\n\t

23 September 2026 | Sharam Dadashnia<\/p>\n<\/div><\/div><\/div><\/div><\/div>

<\/div><\/div>
<\/div>
\n\t
\n\t\t
<\/div>\n\t\t\t\t
<\/div>\n\t<\/div>\n<\/div><\/div><\/div><\/div>
<\/div><\/div>
<\/div>
\n\t

The first agent deployed in a company is almost always a showcase project. A small team builds a prototype, integrates a language model with a ticketing system or an email inbox, presents the solution to the steering committee, and receives applause. The setup is manageable, the benefits are tangible, and the risk seems small. That\u2019s exactly how the problem begins.<\/p>\n<\/div><\/div><\/div><\/div>

<\/div><\/div>
<\/div>
\n\t
\n\t\t
<\/div>\n\t\t\t\t
<\/div>\n\t<\/div>\n<\/div><\/div><\/div><\/div>
<\/div><\/div>
<\/div>
\n\t

Three quarters later, there isn\u2019t just a single agent anymore. Dozens of instances are running across five different departments. Marketing uses a text-generation tool, Sales has set up a lead classifier, Purchasing is testing quote comparisons, and IT is running scripts that analyse log files. Each team has chosen a different framework, stored its own API keys, and granted access rights that are usually far too broad.<\/p>\n

 <\/p>\n

In practice, this pattern is called agent sprawl<\/em>: the uncontrolled proliferation of autonomous or semi-autonomous software agents without a central inventory, without uniform guidelines, and without a defined operating model.<\/p>\n

 <\/p>\n

The scale of the problem is real. According to a Gartner survey on steps to combat AI agent sprawl<\/a>, only about 13 percent of organisations currently believe they have appropriate governance structures for agents, while the number of active instances is rising rapidly. When software not only generates output but also independently calls up tools, reads data, and modifies records in ERP or CRM systems, shadow IT becomes an immediate operational and liability risk.<\/p>\n<\/div><\/div><\/div><\/div>

<\/div><\/div>
<\/div>
\n
\n \"Single <\/div>\n\n<\/div><\/div><\/div>
<\/div><\/div>
<\/div>
\n\n\t
\n\t\t

The typical path: From experiment to loss of control<\/h2>\t<\/div>\n\n<\/div><\/div>
\n\t

Agent sprawl rarely arises from negligence. It stems from decentralisation without guardrails. In most corporations, the process follows the same stages:<\/p>\n

 <\/p>\n

    \n
  1. The 1st agent:<\/strong> 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.<\/li>\n
  2. The 5th agent:<\/strong> 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.<\/li>\n
  3. The 20th agent:<\/strong> 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.<\/li>\n
  4. The 50th to 100th agents:<\/strong> 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.<\/li>\n<\/ol>\n

     <\/p>\n

    At this point, the system is no longer controllable. You\u2019re not operating an automation landscape, but rather a patchwork of black boxes.<\/p>\n<\/div><\/div><\/div><\/div>

    <\/div><\/div>
    <\/div>
    \n
    \n \"Seven <\/div>\n\n<\/div><\/div><\/div>
    <\/div><\/div>
    <\/div>
    \n\n\t
    \n\t\t

    The seven building blocks of sustainable agent governance<\/h2>\t<\/div>\n\n<\/div><\/div>
    \n\t

    Anyone who wants to keep hundreds of agents running in production doesn\u2019t need lengthy policy documents gathering dust on the intranet. What\u2019s needed is a technical infrastructure that makes governance a runtime property. Seven building blocks form the foundation:<\/p>\n

     <\/p>\n

      \n
    1. The Central Registry (Agent Registry)<\/strong><\/li>\n<\/ol>\n

       <\/p>\n

      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?<\/p>\n

       <\/p>\n

       <\/p>\n

        \n
      1. Identities and Permissions (Least Privilege)<\/strong><\/li>\n<\/ol>\n

         <\/p>\n

        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.<\/p>\n

         <\/p>\n

         <\/p>\n

          \n
        1. Mandatory Policies (Policy Enforcement)<\/strong><\/li>\n<\/ol>\n

           <\/p>\n

          Prompts are not security barriers. Rules such as \u201cDo not disclose personal data\u201d or \u201cDo not process transactions exceeding 10,000 euros\u201d 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.<\/p>\n

           <\/p>\n

           <\/p>\n

            \n
          1. Complete Observability and Tracing<\/strong><\/li>\n<\/ol>\n

             <\/p>\n

            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.<\/p>\n

             <\/p>\n

             <\/p>\n

              \n
            1. Lifecycle Management and Deprovisioning<\/strong><\/li>\n<\/ol>\n

               <\/p>\n

              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.<\/p>\n

               <\/p>\n

               <\/p>\n

                \n
              1. Cost and Token Control (FinOps)<\/strong><\/li>\n<\/ol>\n

                 <\/p>\n

                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.<\/p>\n

                 <\/p>\n

                 <\/p>\n

                  \n
                1. Audit-Proof Audit Trails<\/strong><\/li>\n<\/ol>\n

                   <\/p>\n

                  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?<\/p>\n<\/div><\/div><\/div><\/div>

                  <\/div><\/div>
                  <\/div>
                  \n
                  \n \"Central <\/div>\n\n<\/div><\/div><\/div>
                  <\/div><\/div>
                  <\/div>
                  \n\n\t
                  \n\t\t

                  The gateway: The control centre that is so often missing<\/h2>\t<\/div>\n\n<\/div><\/div>
                  \n\t

                  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.<\/p>\n

                   <\/p>\n

                  The solution to this disconnect is a central agent gateway.<\/p>\n

                   <\/p>\n

                  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:<\/p>\n

                   <\/p>\n