Nicht der Prozess trennt die Agents — ihr Schlüssel
Wenn ein Prozess alle Agents hält, wie verhindert man dann, dass der Shell-Befehl des einen die Geheimnisse des anderen liest? Die Antwort war nicht, die Geheimnisse zurück in den Prozess zu holen. Eine Notiz über eine Entscheidung: Isolation gehört an die Stelle, wo das Tool läuft — und der Schlüssel des Agents ist die eigentliche Grenze.
Sobald ein Prozess alle Agents hält, kommt eine unbequeme Frage. Wenn Agent A einen Shell-Befehl ausführt — was hindert ihn daran, die Geheimnisse von Agent B zu lesen? Beide laufen jetzt im selben Prozess, und der läuft mit vollen Rechten.
Die naheliegende Antwort ist falsch, und das zu sehen war der ganze Punkt.
Die naheliegende, falsche Antwort
Der Reflex: Der zentrale Prozess hält für jeden Agent dessen Geheimnisse im Speicher und reicht sie beim Tool-Aufruf an den richtigen Agent durch. Dann hat A seine, B seine, und niemand kommt an die des anderen.
Zwei Dinge sprechen dagegen. Erstens müsste dann der zentrale Prozess die Klartext-Geheimnisse aller Agents im Speicher halten. Das macht aus dem einen Prozess ein lohnendes Ziel — wer ihn knackt, hat alles. Zweitens funktioniert der Durchreich-Weg technisch nicht so einfach, wie er klingt: Wenn man auf den User des Agents heruntersteigt, wird die Umgebung dabei ohnehin gestrippt. Die Geheimnisse über diesen Kanal mitzugeben, scheitert an der Mechanik selbst.
Also nicht durchreichen.
Die Entscheidung
Die Isolation wandert an die Stelle, wo ein Tool tatsächlich läuft. Nur Tools mit Nebenwirkung — Shell, Datei, Spawn — steigen herunter; lesende Tools wie ein HTTP-Get brauchen das nicht. Wenn ein solches Tool läuft, steigt der Aufruf auf den OS-User des Agents herunter, und in diesem heruntergestiegenen Kontext entpackt sich der Agent seine Geheimnisse selbst.
Das Entscheidende ist das „selbst". Der Agent besitzt seinen eigenen Schlüssel — er liegt in seinem Home, nur für seinen User lesbar. Seine Geheimnisse liegen verschlüsselt daneben, versiegelt auf seinen Schlüssel. Niemand sonst kann sie öffnen, auch nicht der zentrale Prozess, der den Tool-Aufruf angestoßen hat. Der Klartext entsteht erst im heruntergestiegenen Kontext, im Moment der Ausführung, und nur dort.
Der zentrale Prozess hält damit kein einziges Klartext-Geheimnis und keine Umgebungs-Maps der Agents. Wer ihn knackt, findet nichts zu entschlüsseln. Den Schlüssel hat nur der Agent, in seinem Home.
Was sich dadurch dreht
Vorher dachte ich, der OS-User isoliere, weil er einen Prozess trägt. Tatsächlich ist es umgekehrt. Der User isoliert über Dateirechte — er kann das Home eines anderen Users nicht lesen, der Kernel sorgt dafür. Der Prozess war nie nötig. Er war nur der Ort, an dem das Tooling zufällig lief.
Damit fällt auch ein alter Aufwand weg. Früher hat sich jeder Agent beim Anlegen seine eigene Umgebung materialisiert — Tooling, das eingerichtet wurde, ob es gebraucht wurde oder nicht. Jetzt entsteht das, was ein Tool braucht, erst wenn das Tool läuft. Aus „eifrig beim Spawn" wird „faul bei Bedarf". Das eine kostet bei jedem Agent, das andere nur bei tatsächlicher Arbeit.
Die Grenze ist am Ende nicht der Prozess und nicht einmal der User für sich. Es ist der Schlüssel. Wer ihn hat, kommt an die Geheimnisse — und ihn hat genau ein Agent, in genau einem Home.
Wo das gerade steht
Diese Entscheidung ist getroffen und in einem ersten Versuch belegt: in einem Prozess zwei Agents, jeder steigt auf seinen User herunter, jeder entpackt korrekt seine eigenen Geheimnisse, und der Quer-Zugriff auf das Home des anderen scheitert mit „Permission denied". Das ist die Eigenschaft, auf die es ankommt, und sie hält.
Was noch aussteht, ist der Umbau, der diesen Mechanismus in den laufenden Tool-Pfad einzieht — heute laufen die Sessions im neuen Modell noch ohne Tools. Ich schreibe das hin, weil es ehrlich dazugehört: die Richtung steht und ist geprüft, der Einbau läuft noch. VERIFY: Implementierungsstand des Tool-Drops vor Publikation bestätigen
Eine Stelle bleibt heikel und gehört genannt. Die ganze Garantie hängt daran, jedes Tool richtig einzuordnen — hat es eine Nebenwirkung und muss heruntersteigen, oder ist es lesend und darf oben laufen? Ein falsch eingeordnetes Tool, das mit vollen Rechten oben läuft, hebelt die Trennung aus. Diese Einordnung ist eine Sicherheitsgrenze und muss als solche getestet werden, gegnerisch, nicht nebenbei.
Schluss
Die einfache Antwort wäre gewesen, die Geheimnisse zurück in den Prozess zu holen und durchzureichen. Sie hätte den einen Prozess zum Tresor gemacht und an der Mechanik gescheitert. Die bessere Antwort verschiebt nicht die Geheimnisse, sondern den Ort der Trennung: hinunter zu dem Moment, in dem ein Tool läuft, und damit zu dem Einzigen, das wirklich trennt — dem Schlüssel, den nur der Agent hält.