Wöchentliches KI-Briefing — direkt ins Postfach.
Danke! Schau in dein Postfach.
Mehr Newsletter-Formate →
Intelligence Brief
Teil 2 von 2 der Serie zum Outputrisiko. Teil 1 zu den Grundlagen: Was dein KI-Tool dir nicht sagt, und warum das teuer werden kann.
Agentische KI-Systeme sind gerade das heißeste Thema in der KI-Welt, und das aus gutem Grund. Agents können Aufgaben selbstständig planen, Tools aufrufen, Daten abrufen, Code ausführen und Aktionen in echten Systemen auslösen. Das ist ein echter Produktivitätssprung.
Aber es ist auch der Punkt, an dem klassisches Outputrisiko kippt: aus Worten werden Taten.
Dieser Artikel richtet sich an alle, die Agents bereits einsetzen oder planen, das zu tun, und die verstehen wollen, warum die Kontrolle agentischer Systeme mit herkömmlichen Mitteln nicht funktioniert. Ich sage dir, was stattdessen hilft.
KI-Agents sind in vielen Unternehmen keine Zukunftsvision mehr. Support-Agents beantworten Kundenanfragen und lösen Tickets. DevOps-Agents deployen Code und überwachen Systeme. Finance-Agents bereiten Berichte vor und lösen Buchungsprozesse aus. HR-Agents screenen Bewerbungen und koordinieren Interviews.
Das Grundgefühl dabei ist richtig: Agents müssen kontrolliert werden. Das spüren die meisten Teams intuitiv. Was wir bei Kunden sehen: viel Experimentierfreude, grundsätzlich richtige Intuition, aber dann der Versuch, agentische Systeme mit herkömmlichen Cybersicherheitsmaßnahmen und langen Einzelfreigabeprozessen zu erschlagen. Das funktioniert nicht. Nicht weil die Intention falsch ist, sondern weil das Kontrollmodell nicht zur Architektur passt. Warum genau, schauen wir uns gleich an.
Bei einem klassischen LLM endet Outputrisiko beim Menschen. Das Modell antwortet, ein Mensch liest, ein Mensch entscheidet. Selbst wenn der Output falsch ist: der Schaden entsteht erst, wenn jemand auf Basis dieses Outputs handelt.
Bei agentischen Systemen ist das anders. Hier ist der Output kein Text, den jemand liest. Der Output ist ein Befehl, den ein System ausführt.
Ein Agent arbeitet in einer Schleife: wahrnehmen → nachdenken (LLM-Output) → handeln (Tool-Aufruf) → Feedback. Jeder Schritt baut auf dem vorherigen auf. Das ist die Stärke agentischer Systeme, und ihr größtes Risiko.
Was das konkret bedeutet:
Halluziniert ein normales LLM ein falsches Datum, liest der Nutzer eine falsche Information. Halluziniert ein Agent ein Datum bei der Steuerung eines Buchungssystems, storniert er fälschlicherweise Termine oder tätigt kostenpflichtige Buchungen.
Halluziniert ein Agent einen API-Parameter, kann das eine Datenbankabfrage korrumpieren. Interpretiert er einen Auftrag zu weit, kann er Daten löschen, E-Mails versenden oder Konfigurationen ändern, ohne dass jemand es bemerkt, bis der Schaden da ist.
Und weil Agents iterativ arbeiten, der Output von Schritt 1 wird zum Input von Schritt 2, kann ein einziger halluzinierter Befehl zu Beginn der Kette eine sich selbst verstärkende Fehlhandlung auslösen. Kaskadeneffekte, die in klassischen Systemen nicht existieren.
Beispiel: Ein halluzinierter Parameter im ersten Schritt führt zu einer falschen Datenbankabfrage im zweiten Schritt, woraus der Agent im dritten Schritt die falschen Kundendaten löscht.
Die Intuition, Agents mit herkömmlichen Sicherheitsmaßnahmen zu kontrollieren, ist verständlich. Aber sie greift zu kurz, aus mehreren Gründen:
Prompt-Injection wird zur Aktionskaperei: Bei einem Chatbot kann Prompt-Injection dazu führen, dass das Modell etwas Falsches sagt. Bei einem Agenten kann es dazu führen, dass das System etwas Falsches tut: Daten exfiltriert, Konfigurationen ändert, externe Anfragen auslöst. Der Angriff landet nicht mehr im Text, sondern in der Infrastruktur.
Memory Poisoning: Agents nutzen Langzeitspeicher. Gelangen manipulierte oder fehlerhafte Outputs einmal in diesen Speicher, verzerrt das künftige Entscheidungen dauerhaft, wie ein schlechtes Gedächtnis, das nie gelöscht wird.
Erweiterte Angriffsfläche durch Tool-Orchestrierung: Jede Integration, jede API, jede Datenbank, jeder externe Service erweitert die potenzielle Schadensdomäne. AWS beschreibt das in seiner Agentic AI Security Scoping Matrix explizit: Klassische Input/Output-Filter reichen nicht mehr, wenn Agents selbstständig Tools orchestrieren.
Governance-Gap: Die meisten Governance-Programme wurden für Modell-Outputs entwickelt. Agentische Systeme führen aber autonome Entscheidungsautorität ein, und die braucht ein anderes Kontrollmodell. Palo Alto Networks bringt es auf den Punkt: Agentic AI Governance ist die strukturierte Verwaltung delegierter Autorität.
In der Praxis begegnet uns ein wiederkehrendes Muster: Das Team spürt, dass Agents kontrolliert werden müssen. Also werden Freigabeprozesse eingeführt, oft sehr manuelle, sehr granulare. Jede Aktion braucht ein OK. Jeder Tool-Aufruf wird einzeln genehmigt.
Das funktioniert, für zwei Wochen. Dann ist der Overhead zu groß. Die Freigaben werden pauschal erteilt. Ausnahmen werden zur Regel. Der Agent bekommt mehr Spielraum, und die Kontrolle, die eigentlich da sein sollte, existiert nur noch auf dem Papier.
Das ist kein Versagen der Menschen. Es ist ein Designproblem. Manuelle Einzelfreigaben sind kein skalierbares Kontrollmodell für autonome Systeme. Was gebraucht wird, sind technische Leitplanken, die Kontrolle in die Architektur einbauen, nicht in den Prozess.
Agentisches Risiko lässt sich nicht „weg-freigeben". Es muss „weg-designt" werden. Das bedeutet konkret:
Das ist das wichtigste Prinzip. Jeder Agent bekommt ausschließlich die Tools und Berechtigungen, die er für seine spezifische Aufgabe braucht, und nichts darüber hinaus.
Ein E-Mail-Agent darf Entwürfe erstellen, aber nicht eigenständig senden. Ein Analyse-Agent darf Daten lesen, aber nicht schreiben. Ein Buchungsagent darf Vorschläge machen, aber keine Transaktionen auslösen.
Das klingt selbstverständlich. In der Praxis sind overprivileged Agents eine der häufigsten Quellen agentischer Risiken, weil es bequemer ist, breite Berechtigungen zu vergeben, als granulare Rollen zu definieren.
Bevor der Output eines Agents, typischerweise ein JSON-Objekt mit einem Tool-Aufruf, an das Zielsystem übergeben wird, muss eine deterministische Prüfung stattfinden: Schema-Validation, Type-Checking, Boundary-Checks. Das ist keine KI-Aufgabe, sondern klassische Software-Engineering-Disziplin, und sie muss explizit eingebaut werden.
Nicht jeder Agent braucht dasselbe Kontrollniveau. NVIDIA und andere beschreiben ein Stufenmodell:
Der Schlüssel: Kontrollen werden nicht pauschal angewendet, sondern risikobasiert. Das macht sie skalierbar.
Klassische Output-Filter prüfen Text. Bei agentischen Systemen müssen Guardrails auf der Ebene von Tool-Aufrufen ansetzen, also prüfen, welche Aktionen der Agent ausführen will, bevor er sie ausführt. Das ist der entscheidende Unterschied.
Agents können in Schleifen geraten. Ein halluzinierter Befehl kann zu tausenden API-Anfragen führen, bevor jemand eingreift. Harte Obergrenzen für Handlungsschritte (Max Steps), Budget-Limits und automatische Abbruchbedingungen sind keine optionalen Features, sie sind Sicherheitsinfrastruktur.
HITL bedeutet nicht, dass jede Aktion manuell freigegeben werden muss. Es bedeutet: Du definierst Schwellenwerte. Aktionen mit hohem Schadenspotenzial (Überweisungen, Datenlöschung, externer E-Mail-Versand, Systemkonfigurationen) erfordern explizite menschliche Bestätigung. Alles andere läuft durch.
Das ist der Unterschied zwischen einem Kontrollmodell, das skaliert, und einem, das nach zwei Wochen aufgegeben wird.
Agenten-Verhalten ist nicht statisch. Es verändert sich mit den Tools, den Daten und den Nutzern. Kontinuierliches Monitoring, nicht periodische Reviews, ist nötig, um zu erkennen, wenn ein Agent von seinem erwarteten Verhalten abweicht.
Cleanlab zeigt: Nur 5 % der produktiv genutzten KI-Agenten verfügen über ausgereifte Überwachungssysteme. Das bedeutet: 95 % laufen im Blindflug.
Agentisches Outputrisiko ist kein neues Konzept, es ist in mehreren Frameworks bereits adressiert:
OWASP Top 10 for LLM Applications, LLM08: Excessive Agency: Wenn einem Agenten zu viele Berechtigungen, zu viel Autonomie oder unzureichend begrenzte Tools zur Verfügung stehen, führt er auf Basis fehlerhafter Outputs unbefugte oder schädliche Aktionen aus. Das ist die Definition von Excessive Agency, und eine der Hauptgefahren bei LLM-Agenten.
NIST AI RMF 1.0: NIST unterscheidet explizit zwischen Risiken durch reine Anzeige und Risiken durch die Einbettung von KI in automatisierte Entscheidungsketten. Letzteres erfordert eigene Maßnahmen im Bereich Measure & Manage.
Databricks DASF v3.0, Agentic AI Extension: 35 neue technische Sicherheitsrisiken und 6 neue Kontrollmechanismen speziell für agentische Systeme, inklusive Guidance für Multi-Agent-Architekturen und Model Context Protocol (MCP).
Agentische Systeme sind kein Chatbot mit mehr Features. Sie sind eine fundamental andere Risikoklasse. Outputrisiko, das Risiko, dass KI-Ausgaben zu Schaden führen, potenziert sich, wenn aus Ausgaben Aktionen werden.
Die gute Nachricht: Das ist beherrschbar. Aber nicht mit manuellen Einzelfreigaben und klassischen Cybersicherheitsmaßnahmen. Es braucht Kontrolle durch Architektur: Least Privilege, deterministische Validierung, abgestufte Autonomie, technische Guardrails auf Aktionsebene und kontinuierliches Monitoring.
Wer das jetzt einbaut, hat einen echten Vorteil. Wer wartet, bis etwas schiefgeht, zahlt einen anderen Preis.
Falls du Teil 1 noch nicht gelesen hast: Was dein KI-Tool dir nicht sagt, und warum das teuer werden kann. Und wenn du deine Agent-Setups strukturiert absichern willst:
Governance-Check buchen (30 Min mit Sarah)
Bei diesem Artikel hatte ich digitale Unterstützung: KI hat beim Research und beim Formulieren geholfen, die Endredaktion und inhaltliche Verantwortung liegen beim Autor.
.svg)
.svg)
Kai, Digital Governance Experte & Co-Founder von DECAID.secure, revolutioniert die sichere KI-Implementierung für Unternehmen. Sein Weg führte von Führungspositionen im Konzern bis zum erfolgreichen Unternehmertum, darunter die Leitung der Charter of Trust bei Siemens und die Förderung digitaler Transformation bei Identity Valley. Als einer der führenden Köpfe im Bereich Digital Trust entwickelt er mit der twinds foundation zukunftsweisende Vertrauenslösungen. Seine Expertise bringt er aktiv im World Economic Forum und Munich Security Network ein.
.svg)
0 Comments
Login or Register to Join the Conversation
Create an AccountLog in