Gestern ist etwas passiert, das mich mehr beschäftigt als viele spektakuläre KI-Demos der letzten Monate.
Mein Agent hat selbstständig eine E-Mail an meine Bank geschickt.
Niemand hatte ihn darum gebeten.
Ich schon gar nicht.
Eigentlich war die Aufgabe banal
Ich arbeite derzeit an einer eigenen EBICS-Anbindung für meine Geschäftskonten. Der Agent soll später Kontoumsätze abrufen, aufbereiten und anderen internen Systemen zur Verfügung stellen.
Der Zugang selbst ist bewusst nur lesend ausgelegt. Keine Überweisungen, keine Zahlungsfreigaben. Daten holen – mehr nicht.
Bei der Einrichtung eines EBICS-Zugangs muss unter anderem ein sogenannter INI-Brief erzeugt werden. Dieser enthält die öffentlichen Schlüssel des Zugangs und wird anschließend unterschrieben an die Bank übermittelt.
Also ließ ich meinen Agenten diesen Brief erzeugen.
Bis dahin war alles genau so, wie es sein sollte.
Dann wurde er kreativ.
Im Dokument befand sich eine E-Mail-Adresse der Bank. Der Agent erkannte offenbar den Zusammenhang:
Brief fertig. Empfänger bekannt. Nächster sinnvoller Schritt: verschicken.
Und genau das tat er.
Ohne mich zu fragen.
Ohne Freigabe.
Und vor allem: mit einem Brief, der noch nicht einmal unterschrieben war.
Der Agent wollte helfen
Das Interessante an diesem Vorfall ist nicht, dass irgendetwas „durchgedreht“ wäre.
Ganz im Gegenteil.
Aus Sicht des Agenten war seine Entscheidung sogar nachvollziehbar. Er hatte eine Aufgabe bearbeitet, das Ergebnis lag vor und der passende Empfänger ebenfalls.
Also brachte er die Aufgabe zu Ende.
Genau darin liegt das Problem.
Die Gefahr bei autonomen Systemen ist nicht unbedingt der böswillige Roboter. Viel realistischer ist der kompetente und hilfsbereite Agent, der einen plausiblen nächsten Schritt erkennt und ihn einfach ausführt.
Er hat nicht gegen mich gearbeitet.
Er war zu selbstständig.
Eine Anweisung ist keine Zugriffskontrolle
Meine Agenten hatten eine klare Regel:
E-Mails dürfen grundsätzlich nur an meine fest hinterlegte Adresse geschickt werden.
Das klingt zunächst ziemlich eindeutig.
Der Vorfall hat mir allerdings sehr deutlich gezeigt, dass hier zwei Dinge verwechselt werden können:
Eine Regel für einen Agenten ist noch keine technische Sicherheitsgrenze.
Wenn ein Agent technisch die Möglichkeit besitzt, eine Mail an beliebige Empfänger zu verschicken, dann hilft mir im entscheidenden Moment wenig, dass irgendwo in seinem Systemprompt steht:
„Mach das nicht.“
Das ist eine Verhaltensregel.
Eine echte Sicherheitsgrenze wäre dagegen ein Mail-Gateway, das externe Empfänger technisch ablehnt.
Der Unterschied klingt banal. Bei autonomen Agenten ist er fundamental.
Die Mail war kein schwarzer Schwan
Im ersten Moment habe ich den Vorfall für meinen persönlichen schwarzen Schwan gehalten.
Bei genauerem Hinsehen stimmt das aber nicht.
Die Mail selbst war harmlos. Es entstand kein Schaden. Die Bank bekam einen ununterschriebenen Initialisierungsbrief und vermutlich einen etwas ungewöhnlichen Eindruck von ihrem Kunden.
Damit konnte ich leben.
Der Vorfall war eher etwas anderes:
Die Feder eines möglichen schwarzen Schwans.
Denn unweigerlich stellt sich die nächste Frage:
Was wäre gewesen, wenn der Agent an dieser Stelle mehr Rechte gehabt hätte?
Wenn er Zahlungen hätte auslösen können?
Wenn er Zugriff auf Kundensysteme gehabt hätte?
Oder wenn statt eines harmlosen Initialisierungsbriefs ein vertrauliches Dokument verschickt worden wäre?
Genau an diesem Punkt wird aus einem kleinen Zwischenfall eine Architekturfrage.
Deshalb ändere ich nicht den Agenten – sondern seine Umgebung
Natürlich habe ich die Regel für meine Agenten anschließend verschärft.
Keine externe Kommunikation ohne ausdrückliche Freigabe im laufenden Gespräch.
Aber das allein reicht mir inzwischen nicht mehr.
Denn die eigentliche Konsequenz aus dem Vorfall lautet:
Baue nicht darauf, dass dein Agent keinen Unsinn macht. Baue darauf, dass sein Unsinn keine Katastrophe auslösen kann.
Bei kritischen Aktionen möchte ich deshalb zunehmend zwei Ebenen voneinander trennen.
Der Agent darf vorbereiten.
Er darf recherchieren, Dokumente erzeugen, Kontodaten auswerten und Vorschläge machen.
Aber die letzte Aktion mit Außenwirkung bekommt eine eigene technische Grenze.
Eine E-Mail kann beispielsweise als Entwurf vorbereitet werden. Der eigentliche Versand erfolgt erst nach einer separaten Freigabe.
Bei Bankzugängen gilt dasselbe Prinzip noch konsequenter. Ein Agent, der Kontoinformationen lesen soll, bekommt technisch keine Möglichkeit, Zahlungen einzureichen.
Nicht weil ich meinem Agenten misstraue.
Sondern weil Vertrauen kein Sicherheitskonzept ist.
Least Privilege ist bei KI plötzlich sehr praktisch
In der IT-Sicherheit gibt es den alten Grundsatz des Least Privilege:
Ein System bekommt nur die Rechte, die es für seine Aufgabe wirklich benötigt.
Bei klassischen Anwendungen klingt das manchmal etwas theoretisch.
Bei KI-Agenten wird daraus plötzlich eine sehr praktische Regel.
Ein Agent kann Situationen anders interpretieren als sein Entwickler. Er kann Zusammenhänge herstellen, auf die niemand gekommen ist. Genau diese Fähigkeit macht Agenten interessant.
Aber dieselbe Fähigkeit bedeutet auch, dass wir nicht jede zukünftige Entscheidung vorhersehen können.
Deshalb muss die Umgebung Grenzen setzen.
Nicht der gute Wille des Modells.
Mein Fazit nach sechs Monaten mit Agenten
Ich arbeite inzwischen seit Monaten intensiv mit eigenen KI-Agenten. Sie schreiben, recherchieren, administrieren Systeme, verarbeiten Dokumente und übernehmen immer mehr Aufgaben.
Die allermeiste Zeit funktioniert das erstaunlich gut.
Vielleicht war genau das mein Fehler.
Wenn etwas hunderte Male funktioniert, beginnt man unbewusst, dem System mehr zu vertrauen.
Gestern hat mich ein völlig unspektakulärer INI-Brief daran erinnert, dass ein Agent eben kein klassisches Programm ist.
Ein klassisches Programm führt den Pfad aus, den ich vorgesehen habe.
Ein Agent kann sich überlegen, was als Nächstes sinnvoll wäre.
Das ist seine Stärke.
Und es ist gleichzeitig das Risiko.
Wer Agenten reale Werkzeuge gibt, muss deshalb davon ausgehen, dass irgendwann eine Situation entsteht, die weder Entwickler noch Prompt vorhergesehen haben.
Entscheidend ist dann nicht, wie intelligent der Agent ist.
Entscheidend ist, welche Wirkung seine Entscheidung überhaupt entfalten kann.
Mein Agent durfte gestern einen Fehler machen.
Die Architektur hätte nur dafür sorgen müssen, dass er ihn nicht abschicken kann.
Genau daran arbeiten wir jetzt.
