KI-Agenten zwischen Hilfe und Kontrollverlust im eigenen Netzwerk

Du willst nur, dass ein Assistent Tickets vorsortiert, Termine koordiniert oder im internen Wiki nachschlägt. Dann bekommt das System Zugriff auf Slack, E-Mail, ein CRM oder ein Code-Repository. Ab diesem Moment ist es nicht mehr nur eine Textmaschine, sondern ein Akteur, der zwischen Personen, Teams und Systemen vermittelt. Genau dort entsteht das Spannungsfeld: Die gleiche Fähigkeit, die dich entlastet, kann auch Nebenwirkungen haben, die du nicht sofort siehst.

In internen Netzwerken treffen KI-Anwendungen auf menschliche Gewohnheiten: schnelle Freigaben, wenig Zeit für Kontrolle, wiederverwendete Links, Copy-and-paste aus Chatverläufen. Dazu kommen technische Muster wie Tool-Use (das Modell ruft Funktionen auf) und Retrieval (das Modell liest Inhalte aus Datenquellen, oft über Vektorsuche). Das Ergebnis kann sich so anfühlen, als würde der Agent ein eigenes soziales Netzwerk bilden: Er kennt viele Kontaktpunkte, lernt, wem er was fragt, und baut Abkürzungen über wiederkehrende Interaktionen.

Der Kern dieses Artikels ist deshalb nicht die Frage, ob Agenten nützlich sind, sondern unter welchen Bedingungen sie verlässlich bleiben. Wir klären, was Autonomie in diesem Kontext bedeutet, warum netzwerkartige Strukturen entstehen können, welche Risiken in etablierten Sicherheits- und Risiko-Katalogen beschrieben sind und welche konkreten Leitplanken du in Architektur, Betrieb und Organisation setzen kannst.

Im Alltag wird fast alles, was mit einem Sprachmodell arbeitet, schnell als Agent bezeichnet. Technisch ist aber eine Unterscheidung hilfreich: Ein Chatbot beantwortet vor allem Texteingaben. Ein Agent hingegen ist so gebaut, dass er Aufgaben auch über mehrere Schritte verfolgt, Entscheidungen trifft und dabei Werkzeuge nutzt, etwa Suche, Datenbankzugriff oder das Erstellen von Tickets. Die kritische Zutat ist nicht die Sprache, sondern die Fähigkeit, Handlungen auszulösen.

Offizielle Rahmenwerke definieren dabei weniger einen festen Begriff, sondern fokussieren auf Risiken und Kontrolle über den gesamten Lebenszyklus. In NISTs Profil für generative KI wird Risikomanagement als Prozess verstanden, der von Governance über Messung und Tests bis zu Betrieb und Incident-Handling reicht. Das ist für Agenten besonders wichtig, weil ihr Verhalten oft nicht nur aus einem Modellaufruf besteht, sondern aus Ketten von Entscheidungen, Tool-Aufrufen und Datenzugriffen.

Ein System-Prompt ist kein Autorisierungsmechanismus. (sinngemäß nach OWASP)

Für deine Praxis heißt das: Autonomie ist kein Schalter, sondern ein Bündel aus Fähigkeiten und Grenzen. Besonders greifbar wird das, wenn du Autonomie als Zusammenspiel aus Wirkung und Aufsicht denkst. Wirkung beschreibt, wie weit ein System handeln kann. Aufsicht beschreibt, ob und wie diese Handlungen begrenzt, beobachtet und freigegeben werden. Schon kleine Konfigurationsentscheidungen verändern die Balance: Darf der Agent nur lesen oder auch schreiben? Darf er nur Vorschläge machen oder auch direkt ausführen? Gibt es feste Stopps, Logs und Freigaben, oder läuft alles still im Hintergrund?

Die Idee, dass Agenten ein eigenes soziales Netzwerk bilden, klingt zunächst nach Science-Fiction. In der Praxis geht es meist um etwas Bodenständigeres: Beziehungen entstehen, weil ein System wiederholt Interaktionen strukturiert. Sobald ein Agent Aufgaben verteilt, andere Spezialagenten aufruft oder Informationen bei bestimmten Diensten abholt, entstehen stabile Kontaktmuster. Das ist ein Netzwerk im funktionalen Sinn, auch wenn es nicht wie ein klassisches Social-Media-Profil aussieht.

Forschung zu Multi-Agenten-Systemen beschreibt seit Jahren, dass Normen, Rollen und Kooperationsmuster aus lokalen Interaktionen entstehen können. Eine systematische Übersicht betont, dass Topologie (wer mit wem interagiert), Propagation (wie sich Verhalten ausbreitet, etwa über Reputation) und Lernmechanismen (wie Agenten ihr Verhalten anpassen) entscheidend sind. Das passt überraschend gut zu agentischen LLM-Systemen: Auch dort bestimmen Schnittstellen, Rollenmodelle und Zugriffspfade, welche Beziehungen überhaupt möglich sind.

Ein anschaulicher Mechanismus ist das Delegieren. Ein Generalisten-Agent ruft für Teilaufgaben spezialisierte Komponenten auf, etwa einen Recherche-Agenten oder einen Code-Review-Agenten. Wenn das zuverlässig klappt, entsteht ein Muster: Bestimmte Aufgaben gehen immer an dieselbe Instanz. Ähnlich wirkt Retrieval: Wenn ein Agent merkt, dass eine bestimmte Wissensquelle ihm regelmäßig hilft, wird sie faktisch zu einem bevorzugten Knotenpunkt. Mit jedem weiteren Tool wächst die Zahl der Kanten im Netzwerk.

In experimentellen Multi-Agenten-Settings wird außerdem gezeigt, dass soziale Signale und Vorbilder die Lernkurve stark beeinflussen können. In einem bekannten Experiment-Setup lernen Agenten unter bestimmten Trainingsbedingungen, Hinweise von kompetenten Agenten zu nutzen, statt nur durch eigene Versuche zu lernen. Für Unternehmensagenten ist das eine gute Metapher: Wenn ein Agent Zugriff auf erfolgreiche Lösungswege in Tickets, Chatverläufen oder Runbooks hat, kann er diese Muster übernehmen und verstärken. Genau hier entstehen aber auch Risiken: Falsche oder manipulierte Hinweise können sich ebenso ausbreiten wie gute Praktiken.

Wichtig ist dabei eine nüchterne Erwartung: Die Forschung betont, dass solche emergenten Effekte oft fragil sind. Ergebnisse hängen von Umgebung, Regeln und Lernsetup ab. Übertragen auf Produktivsysteme heißt das: Netzwerkähnliche Muster sind plausibel, aber nicht automatisch stabil oder wünschenswert. Du solltest sie als Eigenschaft des Systems behandeln, die beobachtet, getestet und begrenzt werden muss.

Ein Agent wird riskant, wenn er nicht nur Texte schreibt, sondern als Steuerlogik dient. OWASP beschreibt dafür mehrere typische Risikoklassen. Besonders relevant für agentische Systeme sind Prompt Injection (direkt oder indirekt), Excessive Agency (zu viel Handlungsspielraum), System Prompt Leakage (Preisgabe interner Anweisungen) sowie Improper Output Handling (wenn Modell-Ausgaben ungeprüft weiterverarbeitet oder sogar ausgeführt werden). In Agenten-Architekturen treten diese Risiken oft kombiniert auf.

Prompt Injection ist dabei mehr als ein Trick im Chatfenster. Indirekte Prompt Injection kann auch über Inhalte kommen, die der Agent aus Dokumenten, Webseiten, Tickets oder Wissensdatenbanken zieht. Sobald Retrieval Teil des Systems ist, wird jede Datenquelle potenziell zu einem Eingangskanal für Manipulation. Das ist besonders kritisch, wenn der Agent anschließend Tools nutzt: Eine manipulierte Anweisung kann dann nicht nur die Antwort verfälschen, sondern Aktionen auslösen, etwa Datenabfragen oder das Erstellen neuer Inhalte in internen Systemen.

Excessive Agency ist das passende Schlagwort für das Gefühl von Kontrollverlust. Es entsteht, wenn Berechtigungen, Tool-Landschaft und Automatisierung nicht zusammenpassen. Häufige Muster sind: zu breite API-Scopes, fehlende Trennung zwischen Test und Produktion, oder ein Agent, der ohne verpflichtende Freigaben schreiben, löschen oder veröffentlichen darf. OWASP empfiehlt hier konsequent das Prinzip der minimalen Rechte und das Ausführen von Aktionen im Kontext der Person, die die Aufgabe wirklich verantwortet.

NIST adressiert solche Risiken weniger über einzelne Angriffsarten, sondern über Prozesse: Inventar, klare Rollen, Test und Validierung sowie Incident-Response. Gerade bei Agenten ist das wichtig, weil Fehler nicht nur in einem Modellaufruf stecken, sondern in Ketten: Ein kleiner Fehlschluss am Anfang kann sich in Tool-Aufrufen multiplizieren. Wenn du keine Telemetrie und keine nachvollziehbaren Protokolle hast, ist eine spätere Ursachenanalyse kaum möglich.

Der wichtigste Perspektivwechsel lautet deshalb: Ein Agent ist wie ein neuer Mitarbeitender mit sehr schneller Ausführung, aber ohne Intuition für Unternehmenspolitik. Du würdest einer neuen Person nicht sofort Admin-Rechte geben. Bei Agenten ist die Versuchung größer, weil die Oberfläche so freundlich wirkt. Genau diese Diskrepanz ist das Einfallstor für Sicherheitsprobleme und operative Überraschungen.

Wenn du Agenten in deinem Netzwerk betreibst, brauchst du zwei Dinge gleichzeitig: klare Grenzen für Handlungen und gute Sichtbarkeit. Beides lässt sich pragmatisch umsetzen, ohne den Nutzen zu zerstören. Der erste Schritt ist ein nüchternes Systembild: Welche Datenquellen werden gelesen, welche Systeme werden beschrieben, welche Tools sind überhaupt erreichbar? NIST empfiehlt dafür ein strukturiertes Inventar und eine Governance, die Verantwortlichkeiten eindeutig macht. Das klingt nach Papier, spart aber in der Praxis Zeit, weil du Abhängigkeiten und Risiken nicht jedes Mal neu erraten musst.

Der zweite Schritt ist das Design von Autonomie. Lege fest, welche Aktionen nur als Vorschlag zurückkommen dürfen, und welche wirklich automatisch laufen dürfen. Alles, was Geld, Berechtigungen oder Öffentlichkeit betrifft, gehört typischerweise in einen Freigabeprozess. OWASP nennt dafür Human-in-the-Loop als sinnvolle Bremse bei hochwirksamen Aktionen. Ergänze das durch harte technische Limits: begrenzte Tool-Iterationen, Timeouts, Quoten und eine strikte Allowlist der erlaubten Funktionen. Ein Agent, der nur zehn definierte Aktionen kennt, ist leichter zu testen als einer, der theoretisch alles ausführen darf.

Der dritte Schritt ist sichere Tool-Ausführung. Behandle Modell-Ausgaben grundsätzlich als untrusted Input. Wenn der Agent beispielsweise SQL, Shell-Kommandos oder API-Calls erzeugt, müssen diese Ausgaben durch deterministische Validatoren laufen, bevor sie ausgeführt werden. Das gehört in eine Zwischenschicht, nicht in den Prompt. So setzt du OWASPs Empfehlung um, nicht auf Textanweisungen als Sicherheitsgrenze zu vertrauen.

Der vierte Schritt ist Beobachtbarkeit, die über Debug-Logs hinausgeht. Du brauchst nachvollziehbar: welche Quelle wurde gelesen, welches Tool wurde mit welchen Parametern aufgerufen, welche Entscheidung führte zur Aktion. Das ist nicht nur für Security wichtig, sondern auch für Produktqualität. Außerdem macht es netzwerkartige Effekte sichtbar: Du erkennst, ob der Agent immer dieselben Knotenpunkte nutzt, ob einzelne Wissensquellen übergewichtet werden oder ob sich ein Verhalten einschleicht, das du gar nicht geplant hast.

Zum Schluss: Teste Agenten nicht nur auf richtige Antworten, sondern auf robustes Verhalten. OWASP empfiehlt adversariales Testen für Prompt Injection und Tool-Missbrauch. NIST betont Test, Evaluation, Verification und Validation über den Lebenszyklus. Für dich bedeutet das ganz konkret: Baue Testfälle, die absichtlich widersprüchliche Dokumente enthalten, manipulative Anweisungen in Wissensartikeln simulieren und Tool-Aufrufe provozieren. Wenn das System dann sauber stoppt, nachfragt oder begründet ablehnt, ist das ein besseres Zeichen als eine perfekt klingende Antwort.

Agentische Systeme werden in internen Netzwerken schnell zu Vermittlern zwischen Menschen, Tools und Wissen. Dadurch entstehen netzwerkartige Muster: Der Agent lernt, welche Wege funktionieren, welche Quellen bevorzugt werden und welche Rollen andere Komponenten übernehmen. Das ist nützlich, kann aber auch kippen, wenn Autonomie und Berechtigungen nicht sauber begrenzt sind oder wenn untrusted Inhalte über Retrieval und Dateien in die Steuerlogik rutschen. Etablierte Empfehlungen aus Risikomanagement und Anwendungssicherheit zeigen einen klaren Weg: Rechte reduzieren, Aktionen absichern, Freigaben definieren, und alles so protokollieren, dass du im Zweifel rekonstruieren kannst, was passiert ist. So bleibt der Nutzen hoch, ohne dass du das Gefühl hast, ein System mit eigenem Innenleben unbemerkt im Netzwerk laufen zu lassen.