Agent Sprawl: Was passiert, wenn hunderte Agenten ohne Register laufen

Agent Sprawl entsteht selten aus Nachlässigkeit. Er entsteht aus Dezentralisierung ohne Leitplanken. Der Ablauf folgt in den meisten Konzernen denselben Stationen:

 

1. Der 1. Agent: Ein überschaubarer Showcase. Das Modell wird fest verdrahtet, die Sicherheit per Annahme vorausgesetzt. Weil nur wenige Personen Zugriff haben, fällt fehlendes Rollenmanagement nicht auf.
2. Der 5. Agent: Zwei weitere Abteilungen ziehen nach. Erste Schnittstellen zu internen Datenbanken werden gebaut. Meistens teilt man sich generische Service-Accounts, weil das Anlegen individueller Dienstkonten zu lange dauern würde.
3. Der 20. Agent: Die ersten Mitarbeiter verlassen das Projekt oder die Abteilung. Niemand weiß mehr genau, auf welchem Server ein Skript läuft, welcher Prompt in Version 3 hinterlegt wurde und warum ein bestimmter Agent Schreibrechte im SAP-System besitzt.
4. Der 50. bis 100. Agent: Mehrere Instanzen rufen dieselben Basismodelle über unkoordinierte Endpunkte ab. Token-Rechnungen laufen auf Sammelkostenstellen auf. Treten Fehler auf – etwa eine fehlerhafte Rabattberechnung oder ein fälschlich geschlossenes Serviceticket –, lässt sich der Entscheidungsweg nicht mehr rekonstruieren.

 

An dieser Stelle ist das System nicht mehr steuerbar. Man betreibt keine Automatisierungslandschaft, sondern einen Flickenteppich aus Blackboxes.

Wer hunderte Agenten im produktiven Betrieb halten will, benötigt keine langen Richtliniendokumente, die im Intranet verstauben. Nötig ist eine technische Infrastruktur, die Governance zur Laufzeiteigenschaft macht. Sieben Bausteine bilden das Fundament:

 

1. Das zentrale Register (Agent Registry)

 

Das Register ist die Bestandsliste für alle im Unternehmen aktiven Agenten. Jeder Agent erhält eine eindeutige Identität, eine definierte Version, einen fachlichen Owner und eine Beschreibung seiner Aufgabe. Was nicht im Register steht, erhält keinen Netzzugang und keinen Zugriff auf Schnittstellen. Ein Eintrag klärt: Wer hat diesen Agenten freigegeben? Welches Modell nutzt er? Welchen Geschäftsprozess bedient er?

 

 

2. Identitäten und Berechtigungen (Least Privilege)

 

Ein Agent darf niemals mit den Rechten eines generischen Administrator- oder Systemkontos agieren. Er benötigt eine eigene, nicht-menschliche Identität mit eng begrenzten Rechten. Ein Agent, der Rechnungen liest, braucht Lesezugriff auf das Dokumentenarchiv, aber keinen Schreibzugriff auf Lieferantenstammdaten. Berechtigungen müssen sich zentral entziehen lassen, sobald eine Anomalie auftritt.

 

 

3. Verbindliche Richtlinien (Policy Enforcement)

 

Prompts sind keine Sicherheitsbarrieren. Regeln wie „Gib keine personenbezogenen Daten heraus“ oder „Führe keine Buchungen über 10.000 Euro durch“ dürfen nicht als Textanweisung im Systemprompt stehen, wo sie durch unerwartete Eingaben umgangen werden können. Sie gehören als harte Validierungsregeln vor und hinter die Ausführung.

 

 

4. Vollständige Observability und Tracing

 

Klassische Logdateien reichen nicht aus. Bei agentischen Systemen muss nachvollziehbar sein, welche Information der Agent als Kontext erhalten hat, welche Zwischenschritte er geplant hat, welcher API-Aufruf ausgelöst wurde und welches Ergebnis zurückkam. Nur mit lückenlosen Traces lassen sich Fehlentscheidungen auditieren und gegenüber Revision oder Behörden erklären.

 

 

5. Lifecycle Management und Deprovisioning

 

Agenten sind keine Dauerläufer ohne Verfallsdatum. Modelle veralten, Schnittstellen ändern sich, Geschäftsprozesse werden angepasst. Ein geregelter Lebenszyklus definiert Testphasen, Staging, Freigaben, regelmäßige Qualitätsprüfungen und vor allem das geordnete Abschalten (Sunset) ausgemusterter Versionen.

 

 

6. Kosten- und Token-Kontrolle (FinOps)

 

Jeder Aufruf kostet Geld. Ohne zentrale Verbrauchsüberwachung führen Endlosschleifen, überdimensionierte Kontextfenster oder ineffiziente Retry-Logiken zu explodierenden Rechnungen. Notwendig sind Budgetgrenzen je Agent, je Team und je Vorgang, kombiniert mit automatischen Abschaltmechanismen bei Grenzüberschreitung.

 

 

7. Revisionssichere Audit Trails

 

Trifft ein Agent eine Entscheidung oder bereitet er eine solche vor, muss dieser Pfad unveränderbar protokolliert werden. Bei Rückfragen nach Monaten muss feststehen: Welcher Datenstand lag vor? Welches Modell lief zu diesem Zeitpunkt? Welche Validierung fand statt?

Viele Architekturen versuchen, Governance direkt in den Code jedes einzelnen Agenten einzubauen. Das scheitert in der Praxis sofort, sobald Entwickler unterschiedliche Bibliotheken, Programmiersprachen oder Cloud-Dienste nutzen.

 

Die Lösung für diesen Bruch ist ein zentrales Agent Gateway.

 

Das Gateway sitzt als Kontrollschicht zwischen den Agenten, den Sprachmodellen und den angebundenen Unternehmenssystemen. Alle Aufrufe laufen zwingend über diese Instanz. Das bringt entscheidende Vorteile:

 

• Modellunabhängigkeit: Der Agent kommuniziert mit dem Gateway. Welches LLM im Hintergrund die Anfrage beantwortet – ob ein Cloud-Modell oder eine lokal gehostete Open-Source-Variante –, steuert das Gateway über Routing-Regeln.
• Zentrale Filter: Das Gateway prüft Ein- und Ausgaben auf vertrauliche Unternehmensdaten, schützt vor Datenabfluss und blockiert unerlaubte Befehlsmuster, bevor sie das Modell erreichen.
• Raten- und Kostenbegrenzung: Budgets und Limits werden an einer Stelle durchgesetzt, unabhängig davon, in welchem Framework der Agent geschrieben wurde.
• Einheitliche Telemetrie: Metriken, Latenzen, Fehlerraten und Token-Verbräuche fallen standardisiert an einem Ort an.

 

Wer das Gateway weglässt, muss Sicherheits- und Kostenprüfungen in jedem einzelnen Projekt neu erfinden – und verliert unweigerlich den Überblick.

Agent-Governance darf kein nachträglicher Prüfschritt sein, der Innovation abwürgt. Wenn Entwickler und Fachbereiche vier Wochen auf die Freigabe eines einfachen Experiments warten müssen, wandern sie erneut in die Schatten-IT ab.

 

Erfolgreiche Organisationen verankern Governance direkt im Design der Plattform (Governance by Design). Entwickler erhalten vorgefertigte, freigegebene Konnektoren, standardisierte Berechtigungsvorlagen und eine Umgebung, in der Logging, Tracing und Kostenüberwachung automatisch aktiv sind. Der sicherste Weg muss für das Team gleichzeitig der bequemste sein.

 

Damit verbindet sich die Risikokontrolle unmittelbar mit dem Geschäftsnutzen (Value by Design): Ein Agent wird nur dann produktiv geschaltet, wenn er einem klaren Prozessschritt zugeordnet ist, messbare Zeit spart und definierte Qualitätskriterien erfüllt. Auf der Scheer-PAS-Übersichtsseite zu Agentic Process Orchestration wird dieser Gedanke aufgegriffen: Autonomie entsteht nicht durch Regellosigkeit, sondern durch eine einheitliche Ausführungsumgebung mit klaren Kontrollpunkten und menschlicher Aufsicht.

Wie man startet, hängt vom aktuellen Zustand im Unternehmen ab:

 

• Szenario A: Wenige bis keine Agenten im Einsatz.
  Das ist die beste Ausgangslage. Legen Sie das Agenten-Register und die Identitätsregeln an, bevor der zweite Agent gebaut wird. Die Einführung eines Registers für zwei Agenten dauert einen Nachmittag. Die nachträgliche Inventarisierung von achtzig Wildwuchs-Installationen dauert Monate.
• Szenario B: Bereits 10 bis 30 Agenten in verschiedenen Teams aktiv.
  Verhängen Sie keinen sofortigen Entwicklungsstopp, sondern setzen Sie eine Inventur an. Erfassen Sie primär drei Dinge: Welche externen Schnittstellen und Datenquellen nutzt der Agent? Welches Dienstkonto verwendet er? Wer unterschreibt fachlich für die Richtigkeit der Ergebnisse? Führen Sie zeitgleich ein zentrales Gateway für alle Modellaufrufe ein.
• Szenario C: Breiter Wildwuchs mit unklaren Zugriffsrechten.
  Hier steht Risikominimierung an erster Stelle. Trennen Sie schreibende Zugriffe auf Kernsysteme sofort von generischen Konten. Verlangen Sie für jede automatisierte Systemänderung temporär eine menschliche Zwischenfreigabe (Human-in-the-Loop), bis Nachvollziehbarkeit und Fehlerraten der beteiligten Agenten zweifelsfrei belegt sind.

 

Hunderte Agenten in einem Unternehmen sind keine Bedrohung, sondern ein enormer Hebel für die Wertschöpfung. Zur Belastung werden sie nur dann, wenn niemand weiß, wer sie gebaut hat, was sie dürfen – und wer den Stecker zieht, wenn sie falsch abbiegen.