Harte Kontrollen · Agenten · Entwurf

Ein winziger Host-Agent: kein Modell, kein eingehender Port

Status: Dies ist ein schriftlicher Entwurf; noch nicht gebaut und nicht im Einsatz. Der Rollout ist geplant: zuerst nur Fakten und rein lesend, Befehle zuletzt.

Die meisten Gespräche über KI-Agenten drehen sich darum, was sie können. Dieser Artikel handelt von einem Baustein, der bewusst darauf ausgelegt ist, sehr wenig zu tun: ein kleiner Agent, der auf einem Host leben würde. Er würde kein Modell enthalten. Er würde Fakten über den Host melden, nur Befehle aus einer festen Liste ausführen, seine Anweisungen als signierte Nachrichten über git entgegennehmen und an keinem eingehenden Port lauschen.

Er ist das kleinste Beispiel für die Idee, die sich durch diese Reihe zieht: Wenn man eine Komponente nicht vertrauenswürdig machen kann, indem man sie nett bittet, macht man sie so klein, dass es wenig gibt, dem man vertrauen muss.

Wofür er gedacht ist

Manche Hosts werden überhaupt nicht von einem KI-Assistenten gesteuert. Sie müssen trotzdem bekannt sein und in engen Grenzen verwaltet werden: was auf ihnen läuft, in welchem Zustand sie sind und eine Handvoll Routineaktionen. Der winzige Host-Agent ist darauf ausgelegt, auf einem solchen Host zu sitzen und genau das zu tun und nichts darüber hinaus.

Er würde drei Dinge tun. Er würde Host-Fakten melden. Er würde Anweisungen als signierte Nachrichten empfangen. Er würde einen Befehl nur ausführen, wenn der Befehl auf seiner Allow-List steht.

Links ein Host-Agent-Roboter, in der Mitte ein git-Dienst, rechts ein Signierer-Roboter. Der Signierer schiebt signierte Nachrichten an den git-Dienst, der Host holt sie ab und meldet Fakten dorthin zurück. Ein Band besagt, dass der Host immer nach außen greift und nichts nach innen: kein eingehender Port. — Abbildung 1: der Host holt ab, der Signierer schiebt, der Host lauscht nie

Warum jede Entwurfsentscheidung

Jede Entscheidung ist da, wegen dessen, was sie der Angriffsfläche nimmt.

Kein Modell. Mit einem Modell kann man diskutieren: Text, den es liest, kann steuern, was es tut. Ein kleines festes Programm lässt sich nicht zu einer Aktion überreden, und es ist klein genug, dass ein Mensch es in einer Sitzung lesen und prüfen kann. Das Modell wegzulassen entfernt eine ganze Klasse von Manipulation vom Host.

Eine Allow-List. Der Agent würde jeden Befehl verweigern, der nicht auf seiner Liste steht. Ein Fehler, eine schlechte Nachricht oder eine gefälschte Anfrage kann dann nur erreichen, was die Liste erlaubt. Unbekannt heißt abgelehnt.

Signierte Nachrichten. Der Host würde nur auf Anweisungen handeln, deren Signatur er prüfen kann. Den Kanal erreichen zu können, genügt nicht; nur wer den Signaturschlüssel besitzt, kann den Host anweisen.

Git als Kanal. Der Host würde git nach neuen Nachrichten fragen, statt darauf zu warten, aufgerufen zu werden. Jede Anweisung wird zu einem Commit, sodass die Historie festhält, was von wem verlangt wurde, und der Transport nichts Besonderes braucht.

Kein eingehender Port. Weil der Host immer nach außen greifen würde und nichts nach innen, gibt es keinen lauschenden Dienst, den man aus dem Netz scannen, abtasten oder ausnutzen könnte.

Fünf Zeilen. Jede Entwurfsentscheidung links, kein Modell, Allow-List, signierte Nachrichten, git als Kanal und kein eingehender Port, verweist rechts auf das, was sie der Angriffsfläche nimmt. Ein Band besagt, dass jede Entscheidung etwas wegnimmt und das nächste Bild zeigt, was übrig bleibt. — Abbildung 3: was jede Entwurfsentscheidung entfernt

Eine Nachricht, fünf feste Schritte

Jede Nachricht würde dieselben Schritte in derselben Reihenfolge durchlaufen: abholen, die Signatur prüfen, den Befehl gegen die Allow-List prüfen, den einen aufgeführten Befehl ausführen, das Ergebnis und die Host-Fakten melden. Scheitert ein Schritt, endet die Nachricht dort. Unsigniert, unbekannt oder nicht aufgeführt heißt, dass nichts läuft, und in der Mitte gibt es keinen Ermessensspielraum, auf den sich jemand stützen könnte.

Fünf Kästen in einer Reihe, jeder mit einem kleinen Roboter: eine neue Nachricht abholen, ihre Signatur prüfen, den Befehl gegen die Allow-List prüfen, einen aufgeführten Befehl ausführen, Ergebnis und Host-Fakten melden. Ein Band besagt, dass jeder gescheiterte Schritt die Nachricht stoppt, sodass unsigniert, unbekannt oder nicht aufgeführt heißt, dass nichts läuft. — Abbildung 2: eine Nachricht, fünf feste Schritte

Was es kosten würde

Klein und streng hat seinen Preis.

Flexibilität. Eine neue Art von Aufgabe bedeutet einen neuen Eintrag auf der Allow-List, der geschrieben und geprüft werden muss. Das ist der Sinn der Sache und zugleich Reibung.
Schlüsselverwaltung. Signieren braucht Schlüssel: Jemand muss sie erzeugen, sicher aufbewahren, entscheiden, wer signieren darf, und sie bei Bedarf ersetzen. Der Entwurf verlangt, dass diese Arbeit gut gemacht wird; wie der Signaturschlüssel gehalten wird, ist ein offener Entwurfspunkt, und dieser Artikel beschreibt keinen Aufbau.
Geschwindigkeit. Ein Host, der abfragt, erfährt von einer Anweisung bei der nächsten Abfrage, nicht sofort.
Abhängigkeit von git. Der Kanal hängt davon ab, dass der git-Dienst erreichbar ist und sich korrekt verhält.
Diagnose. Ein festes Programm mit knapper Ausgabe sagt wenig, wenn etwas schiefgeht, daher brauchen Berichte und Protokollierung Sorgfalt.

Wovor dieser Entwurf nicht schützt

Die Grenzen zu benennen ist wichtiger, als die Stärken aufzuzählen.

Der Signaturschlüssel. Wer den Signaturschlüssel besitzt, kann gültige Nachrichten senden. Die Allow-List begrenzt, was verlangt werden kann, aber eine schädliche Aktion, die auf der Liste steht, würde ausgeführt. Wie der Schlüssel gehalten und wie er ersetzt würde, ist ein offener Entwurfspunkt.

Replay. Eine echte signierte Nachricht kann später erneut gesendet werden. Der Entwurf verlangt eine Möglichkeit, frische von alten Nachrichten zu unterscheiden, etwa ein Ablaufdatum oder einen Zähler; ohne sie ist Replay möglich.

Ein kompromittierter git-Dienst. Der Dienst kann keine Signaturen fälschen, aber er kann Nachrichten zurückhalten, verzögern oder alte zeigen. Das betrifft Verfügbarkeit und Aktualität, nicht Authentizität.

Eine schlechte Allow-List. Die Allow-List ist die eigentliche Berechtigungsgrenze. Sie ist nur so sicher wie ihre Einträge und die Argumente, die sie akzeptieren; ein breiter Eintrag ist eine breite Berechtigung.

Ein kompromittierter Host. Ein übernommener Host kann falsche Fakten über sich melden. Der Schaden beschränkt sich auf die eigenen Pfade dieses Hosts: Über diesen Entwurf würde er andere Hosts nicht erreichen.

Fünf Karten, jede mit einem kleinen Roboter: der Signaturschlüssel als offener Entwurfspunkt, Replay einer alten signierten Nachricht, ein kompromittierter git-Dienst, eine schlechte Allow-List und ein kompromittierter Host, der falsche Fakten melden kann, begrenzt auf seine eigenen Pfade. Ein Band besagt, dass kleine Allow-Listen, frische Nachrichten, sorgfältige Schlüssel und Überwachung den Schaden eingrenzen, diese Risiken aber bleiben. — Abbildung 4: wovor dieser Entwurf nicht schützt

Diese Risiken würden durch kleine Allow-Listen mit festen Argumenten, frische Nachrichten, sorgfältigen Umgang mit Schlüsseln und Überwachung dessen, was der Host meldet, eingegrenzt. Beseitigt sind sie nicht.

Wie er zum Rest der Reihe passt

Der Host-Agent wäre die unterste Ebene desselben Bildes. Agenten darüber schlagen vor, Menschen geben frei, und signierte, aufgezeichnete Nachrichten tragen die freigegebene Anweisung nach unten. Ganz unten stünde ein Baustein, der seiner Liste folgt und eine Aufzeichnung führt und kaum etwas sonst bietet, das sich angreifen ließe.