Aus den Assessments3 min Lesezeit
Kein Protokoll, kein Schlüssel
Ein Agent, den man ständig beobachten muss, ist keine Automatisierung. Drei Stellen, an denen wir Kontrolle aus der Anweisung in die Bauart verlegt haben.
Von Maik Tran
Man kann einem Agenten sagen, was er nicht tun soll. Oder man baut ihn so, dass er es nicht kann. Das erste ist eine Bitte, das zweite ist Bauart. Auf Bitten verlassen wir uns nicht.
Laufzeiten für Coding-Agenten sind ein Massenmarkt: Ein quelloffenes Projekt dieser Art hat über 40.000 GitHub-Sterne. Sie lösen, dass Agenten im Hintergrund weiterlaufen. Was ein Agent darf, ist eine andere Frage, und sie beantwortet sich nicht von selbst.
Haki Dock führt Coding-Agenten lokal aus, jeden in einer eigenen Sandbox mit eigenem Arbeitsverzeichnis. Drei Stellen daraus, an denen die Kontrolle in der Konstruktion steckt und nicht im Prompt.
Das Netz: was nicht erlaubt ist, hat keine Gegenstelle
Der Netzwerkverkehr des Agenten läuft über einen Proxy, dessen Regeln für jeden Lauf neu erzeugt werden: ein Eintrag pro erlaubtem Ziel. Am Ende der Liste steht eine Kette, die auf nichts zeigt. Eine Verbindung, die zu keiner Regel passt, scheitert, und es gibt nichts, worüber ein Agent verhandeln könnte. Fällt der Proxy aus, startet der Agent gar nicht erst.
Der Schlüssel: kein Protokoll, kein Schlüssel
Ein Agent braucht einen API-Schlüssel, um zu arbeiten. Der liegt im Tresor des Betriebssystems (Keychain unter macOS, DPAPI unter Windows, eine verschlüsselte Datei unter Linux), nicht im Projekt und nicht im Prompt. Bevor er herausgegeben wird, schreibt das System auf, wer ihn wofür angefragt hat. Gelingt das Aufschreiben nicht, bekommt niemand den Schlüssel.
In der Sandbox liegt er dann als Datei im Arbeitsspeicher, und die Umgebungsvariable enthält nur den Pfad dorthin. Solange die Sandbox läuft, kann der Agent ihn also lesen. Das zu verschweigen wäre unredlich. Deshalb steht das Netz davor: Schicken kann er ihn nur an Ziele, die auf der Liste stehen.
Die Freigabe: ein Knopf, der nicht lügen darf
Die erste Fassung unseres Freigabe-Schritts zeigte der Person, die freigeben soll, was der Agent über seine eigene Arbeit geschrieben hatte. Das ist das Wort des Agenten über sich selbst, keine Kontrolle.
Heute steht über „Freigeben“ und „Ablehnen“ die Evidenz: welche Dateien sich geändert haben und der Diff selbst, verglichen mit dem Start der Aufgabe und nicht mit dem letzten Lauf. Denn bei der Freigabe lautet die Frage nicht, was der letzte Lauf getan hat, sondern was in die Welt kommt, wenn ich zustimme.
Eine Kleinigkeit im Code zeigt, worum es geht. Kann git nicht antworten, zeigt die Oberfläche keinen leeren Diff, sie sagt, dass sie es nicht weiß. Ein leerer Diff liest sich als „nichts geändert“, und das ist die eine Lüge, die eine Freigabe wertlos macht. Ein Gate, das bei Unwissen „nichts“ sagt, ist Theater.
Wer freigibt, haftet. Ein Knopf, der nichts weiß, macht diese Person haftbar für etwas, das sie nicht sehen konnte.
Was noch fehlt
Haki Dock ist in Entwicklung. Drei Dinge, die wir nicht überspringen wollen:
- Die Evidenz wird auf dem Rechner berechnet, auf dem der Agent arbeitet. Wer auf einem anderen Rechner prüft, sieht sie noch nicht.
- Zwei Schnittstellen zum Server sind noch nicht angeschlossen, darunter die zentrale Ablage der Freigabe-Entscheidung.
- Der Auslieferungsweg für signierte Updates steht aus.
Wir verlassen uns nicht darauf, dass ein Agent sich an Regeln hält. Wir bauen die Regeln in das, was er berühren kann.
Agenten im Haus, aber niemand weiß, was sie dürfen?
Wir schauen uns an, was eure Agenten heute können und was nicht, auch wenn die Antwort unbequem ist. Ich melde mich innerhalb von 24 Stunden.
