Der Wächter, der den ganzen Agenten anhält: was ein Fehlalarm wirklich kostet

Ein Wächter, der Geheimnisse in der Ausgabe eines KI-Agenten findet, ist eine gute Idee. Ein Wächter, der deswegen den ganzen Agenten anhält, ist eine teure Idee. Wie teuer, habe ich Anfang November an meinem eigenen Produkt AI Employee gemessen: 21 Stunden Stillstand, ohne dass irgendetwas geleakt war.

Was passiert ist

AI Employee hat eine Aufsichtsschicht, den Sentinel. Er liest mit, was ein Agent sieht und schreibt, und sucht unter anderem nach Zeichenketten, die wie API-Schlüssel oder private Schlüssel aussehen. Findet er so etwas mit hoher Sicherheit, stoppt er den Agenten mit dem Grund secret_in_output. Freigegeben wird von Hand.

Am 4. November gegen halb drei Uhr nachmittags griff diese Regel. Im Sitzungsprotokoll des fraglichen Zeitfensters standen genau zwei Treffer: ein Platzhalter in einem frisch geschriebenen Test, der sogar das Wort EXAMPLE enthielt, und ein Wert mit dem typischen Präfix eines API-Schlüssels aus einer längst vorhandenen Testdatei. Keiner der beiden glich einem echten Schlüssel aus der Umgebung des Agenten. Welcher den Stopp ausgelöst hat, lässt sich nicht einmal sicher sagen, der Stopp kam rund eine Minute nach dem letzten Treffer.

Der Agent hatte also das getan, was Entwickler-Agenten den ganzen Tag tun: Testcode gelesen. Im eigenen Repository.

Was der Stopp gekostet hat

Interessant wird es erst, wenn man aufzählt, was an einem angehaltenen Agenten alles hängt. Bei mir war das mehr, als mir vorher bewusst war:

• Alle Zeitpläne fielen aus, rund 21 Stunden lang: Podcast, Blogläufe, Integrations-Scan, Projekt-Takte. Nachgeholt wurde nichts. Der nächste geplante Lauf sprang einfach auf den Folgetag, und eine Lücke meldete niemand.
• Zwei laufende Aufgaben wurden als fehlgeschlagen verbucht. Ihre Arbeit lag halbfertig und nicht committet im Arbeitsbaum.
• Die zugehörigen Karten blieben auf „In Arbeit“ stehen. Ein Lauf dahinter existierte nicht mehr, aber das Board zählte sie weiter gegen die Obergrenze von zwei Karten je Agent. Sieben freigegebene Karten blieben deshalb liegen, und eine Übergabe an denselben Agenten scheiterte an genau dieser Obergrenze.

Bemerkt habe ich das nicht durch einen Alarm, sondern durch eine Lücke in der Aufgabenliste. Das ist ungefähr so, als würde man einen Stromausfall daran erkennen, dass der Kühlschrank am nächsten Morgen warm ist.

Warum es wieder passiert wäre

Die erste Frage nach so einem Vorfall ist nicht „wer war schuld“, sondern „wie oft liegt die Falle noch herum“. Also habe ich die Erkennungsfunktion des Sentinels über das ganze Repository laufen lassen. Ergebnis: 13 eingecheckte Dateien enthielten Text, den sie als Geheimnis gewertet hätte. Darunter die Beispiel-Konfiguration, die Installationsanleitung, eine Datei mit einem öffentlichen Lizenzschlüssel und, schöne Pointe, die Tests des Sentinels selbst.

Jeder Agent, der eine dieser Dateien öffnet oder einen Diff darüber ansieht, wäre angehalten worden. Der Wächter hat den Arbeitsplatz der Agenten also so eingerichtet, dass normale Arbeit ihn auslöst. Das ist kein Einzelfall, das ist eine Regelmäßigkeit mit Wartezeit.

Was ich geändert habe und was nicht

Der Fehlerbehebungs-Teil war bewusst klein und ändert nichts an der Erkennung echter privater Schlüssel und Tokens:

• Testwerte im Quelltext so zerlegt, dass sie zur Laufzeit gleich bleiben, aber im Text keine Schlüsselform mehr haben. Platzhalter in Doku und Beispieldatei ersetzt.
• Ein Wächter-Test, der jede eingecheckte Textdatei prüft. Auch einzelne Kopf- und Fußzeilen privater Schlüsselblöcke zählen, weil der Sentinel je Werkzeugergebnis prüft und ein cat a b sonst aus zwei harmlosen Dateien einen verdächtigen Block zusammensetzt.
• Öffentliche Schlüssel und Zertifikate lösen keinen Stopp mehr aus. Geschwärzt werden sie weiterhin.

Geprüft habe ich das mit den betroffenen Testdateien und mit absichtlich eingebauten Fehlern in einer Wegwerfkopie, die der neue Test alle finden musste. Einen echten Sentinel-Lauf gegen die neue Fassung gab es noch nicht, und der Pull Request wartet auf den Merge. Eine Nebenwirkung bleibt sogar dauerhaft: Der Diff der Änderung enthält in den entfernten Zeilen die alten Werte. Wer ihn komplett liest, wird angehalten. Die Git-Historie vergisst nichts, auch keine Fehlalarme.

Die eigentliche Erkenntnis: Strafe und Fund passen nicht zusammen

Der Kern des Problems ist nicht die Erkennung. Dass ein Mustervergleich Testwerte für Schlüssel hält, ist erwartbar und lässt sich nie ganz vermeiden. Das Problem ist die Reichweite der Reaktion. Ein unsicherer Fund in einem einzelnen Werkzeugergebnis legt alles still, was diesem Agenten gehört, bis ein Mensch eingreift.

Daraus habe ich drei Fragen abgeleitet, die ich jeder Leitplanke für Agenten inzwischen stelle:

1. Wo wurde der Treffer gefunden? Ein Agent, der etwas liest, ist ein anderer Fall als ein Agent, der etwas nach draußen sendet. Seit bei uns ein Proxy die Schlüssel erst am Ausgang einsetzt, hält ein Agent echte Schlüssel oft gar nicht mehr im Klartext. Lesen könnte melden, nur Senden müsste stoppen.
2. Was genau wird angehalten? Der betroffene Lauf oder der ganze Agent mit allen Zeitplänen? Das Erste begrenzt den Schaden, das Zweite vervielfacht ihn.
3. Was passiert danach? Holen Zeitpläne nach? Wird die Lücke gemeldet? Werden Karten eines toten Laufs freigegeben? Wenn auf alle drei Fragen „nein“ kommt, ist jeder Fehlalarm ein stiller Ausfall.

Die ersten beiden Punkte schwächen die Wache bewusst ein Stück. Das gehört deshalb nicht in einen Bugfix, sondern ist eine Entscheidung des Betreibers, die gerade offen ist. Ich halte sie für richtig, aber eine Sicherheitsregel abzuschwächen, sollte nicht nebenbei in einem Patch passieren.

Fazit

Ein Wächter ist nur so gut wie seine Fehlalarme bezahlbar sind. Wer eine Sperre baut, sollte vorher aufschreiben, was an dem gesperrten Ding alles hängt, und die Reaktion an der Sicherheit des Fundes ausrichten, nicht am schlimmsten denkbaren Fall. Und wer Testwerte eincheckt, die wie Schlüssel aussehen, legt seinem eigenen Wächter eine Stolperfalle in den Flur. Meiner ist prompt darüber gefallen.