Aufbau einer Cloud-Agent-Infrastruktur: Was ist anders und was wir gelernt haben

Die meisten Agent-Frameworks gehen heute von einem Desktop aus. Ein Benutzer, eine Maschine, ein Prozess. Der Agent läuft, solange das Laptop offen ist, schreibt in ein lokales Dateisystem, hält API-Schlüssel in Umgebungsvariablen und stirbt, wenn das Terminal geschlossen wird. Wenn etwas kaputtgeht, wiederholt der Benutzer den Vorgang. Wenn der Agent ein Paket braucht, installiert pip install es in das Python des Benutzers. Zustand, Geheimnisse und Lebenszyklus liegen alle innerhalb einer vertrauenswürdigen Grenze.

Cloud-Agent-Infrastruktur hat keine dieser Annehmlichkeiten.

Der Agent läuft in einer Sandbox, die frisch startet, auf Hardware, die mit Fremden geteilt wird, ausgelöst von Aufrufern, die der Benutzer nie trifft: einem Zeitplan, einer HTTP-Anfrage, einem anderen Agenten. Der Benutzer schläft meistens, wenn der Durchlauf stattfindet. Der Code in der Sandbox kann feindselig sein. Das Dateisystem muss Bereitstellungen überleben. Zugangsdaten können nicht dort leben, wo der Agent lebt. Jede Garantie, die dir der Desktop kostenlos gibt – Persistenz, Identität, Netzwerkvertrauen, Wiederholung – muss als explizites System neu aufgebaut werden.

Wir haben die letzten Monate damit verbracht, diese Schicht bei CREAO zu straffen. Zwei Erkenntnisse sind daraus hervorgegangen. Wenn du jemals einen Desktop-Agenten ausgeliefert hast und dich gefragt hast, was sich ändert, wenn er in die Cloud umzieht – das hier ändert sich.

Lektion 1: Trenne, was sich langsam ändert, von dem, was sich schnell ändert

Auf einem Desktop sind die Umgebung des Benutzers und die Laufzeit des Agenten dasselbe, im gleichen Rhythmus aktualisiert, von derselben Person. In der Cloud sind sie das nicht.

Eine Agenten-App sammelt Zustand auf der Seite der Plattform. Ein Börsenanalyst installiert matplotlib, lädt Marktdaten herunter, schreibt Charting-Skripte. Diese Umgebung ist das Muskelgedächtnis des Agenten. Wir frieren sie in einen Sandbox-Snapshot ein, sobald der Benutzer damit zufrieden ist, und halten diesen Snapshot eingefroren, bis der Benutzer die Umgebung wieder bearbeitet. Jeder Durchlauf startet vom selben Image. Dieselben Pakete, dieselben Dateien, dieselben Versionen. Der Montagslauf verhält sich wie der Freitagslauf, weil sich darunter nichts bewegt hat.

Das ist die Eigenschaft, die Desktop-Frameworks dir nicht kostenlos geben können. Ein pip install von vor sechs Monaten ergibt heute andere Versionen. Ein Cloud-Snapshot ergibt für immer dieselben Bytes. Reproduzierbarkeit ist etwas, das die Plattform dem Benutzer schuldet, und ein eingefrorener Snapshot ist der billigste Weg, sie zu liefern.

Dann taucht das Kopplungsproblem auf.

Dasselbe Image, das die Umgebung des Benutzers einfriert, enthält auch den Runner-Code – die kleine Harness-Bibliothek, die wir entwickelt haben und die den Agenten bei jedem Durchlauf verwaltet. Der Benutzer will, dass seine Umgebung stillsteht. Wir wollen, dass unser Runner mehrmals am Tag ausgeliefert wird. Ein Artefakt, zwei entgegengesetzte Anforderungen.

Unsere erste Lösung war grob. Beim Start prüfen, ob der Runner im Snapshot mit der Version übereinstimmt, die wir gerade bereitgestellt haben. Wenn nicht, den Snapshot verwerfen und von einer sauberen Vorlage starten. Es hat funktioniert, und niemand hat sich beschwert. Der Schaden traf nur den ersten Durchlauf nach einer Bereitstellung.

Unbeaufsichtigte Durchläufe haben diese Deckung zunichtegemacht. Ein Cron-Job am Montag um 9 Uhr sollte seine Umgebung nicht verlieren, nur weil wir um 8:55 bereitgestellt haben. Der Vertrag, den wir stillschweigend verletzten – „deine Umgebung ist eingefroren, bis du sie änderst“ – war gebrochen.

Die Lösung zu sehen, hat länger gedauert, als sie sollte. Die Umgebung des Benutzers und der Runner-Code ändern sich mit völlig unterschiedlichen Geschwindigkeiten. Der Benutzer bearbeitet seinen Agenten, wenn er es will. Wir stellen die Plattform mehrmals am Tag bereit. Sie als ein Artefakt zu behandeln, zwang bei jeder Bereitstellung zu einer Entscheidung: entweder veralteten Runner-Code behalten oder die eingefrorene Umgebung zerstören, die der Benutzer explizit von uns zu bewahren verlangt hat.

Das Modell, auf das wir uns geeinigt haben, leiht sich aus, wie Betriebssysteme Updates handhaben. Der Kernel ändert sich. Dein Home-Verzeichnis nicht. Du löschst nicht die Festplatte, um einen Sicherheitspatch zu installieren.

Wir haben die gleiche Grenze gezogen. Die Sandbox startet vom eingefrorenen Snapshot des Benutzers, unberührt. Dann tauschen wir nur den Runner im laufenden Betrieb aus. Die Abfolge:

1. Den neuen Runner in einem temporären Verzeichnis innerhalb der Sandbox bereitstellen.
2. Mit node --check validieren, sodass Syntaxfehler abgefangen werden, bevor wir etwas Lebendiges anfassen.
3. Atomar austauschen: das Unveränderlichkeits-Flag auf dem alten Runner entfernen, den neuen kopieren, mit chattr +i wieder sperren, dann das chattr-Binary selbst verstecken, sodass Sandbox-Code die Sperre nicht rückgängig machen kann.
4. Den V8-Compile-Cache leeren (/home/user/.cache/v8-compile-cache/*), damit die neue Datei tatsächlich geladen wird, statt alten Bytecode auszuführen.
5. Wenn ein Schritt fehlschlägt, die Sandbox töten und mit einer neuen wiederholen. Niemals einen halb aktualisierten Zustand einen Agenten ausführen lassen.

Der gesamte Tausch dauert etwa 300 Millisekunden. Wir machen nach einem erfolgreichen Durchlauf nur dann einen neuen Snapshot, wenn der Runner-Code ausgetauscht wurde, und brennen den aktualisierten Code in das Image des Benutzers ein, sodass der nächste Durchlauf den Tausch komplett überspringt. Plattform-Bereitstellungen verwerfen niemals den Zustand des Benutzers; sie falten den neuen Runner hinein. Die Pakete, Dateien und Anpassungen des Benutzern bleiben unverändert erhalten.

Wenn du etwas aus dieser Lektion mitnimmst, dann ist es die diagnostische Frage. Frage bei allem, was du in einer Cloud-Plattform persistierst: Wer kontrolliert den Änderungsrhythmus dieses Artefakts? Wenn sowohl der Benutzer als auch die Plattform es besitzen, wird dich die Kopplung irgendwann einholen. Teile das Artefakt entlang der Eigentumsgrenze auf und lass jede Seite in ihrem eigenen Rhythmus aktualisieren.

Lektion 2: Halte Geheimnisse außerhalb der Ausführungsgrenze

Das ist die Lektion, die Cloud-Agent-Infrastruktur von allem anderen unterscheidet.

Ein Desktop-Agent läuft als der Benutzer. Er verwendet die Schlüssel des Benutzers, auf der Maschine des Benutzers, gegen das Netzwerk des Benutzers. Ein Cloud-Agent läuft als niemand, auf gemeinsam genutzter Hardware, gegen das offene Internet, und führt Code aus, den ein LLM aus einem Prompt geschrieben hat, der feindselig gewesen sein könnte. Das Sicherheitsmodell muss davon ausgehen, dass der Code in der Sandbox bereits kompromittiert ist, nicht darauf hoffen, dass er es nicht ist.

Die Regel, die wir anwenden, ist einfach. Niemals befindet sich ein langlebiges Zugangsdatum innerhalb der Sandbox.

Wenn ein Agent einen authentifizierten Dienst aufrufen muss – Slack, GitHub, die eigene API des Benutzers – hält er den Token nicht. Er sendet eine lokale HTTP-Anfrage an eine API-Brücke, die außerhalb der Sandbox läuft. Die Brücke hängt das OAuth-Token auf der Host-Seite an und leitet den Aufruf weiter. Die Antwort kommt zurück, ohne dass der Token jemals in den Speicher oder die Umgebung der Sandbox gelangt.

Der interessante Teil ist, wie die Brücke weiß, dass die Sandbox fragen darf. Zwei Prüfungen, absichtlich geschichtet.

Erstens, IP-Allowlist. Die Brücke akzeptiert nur Verbindungen aus dem internen Netzwerkbereich, auf dem unsere Sandbox-Hosts leben. Ein Aufruf von irgendwo anders – einem Entwickler-Laptop, einer durchgesickerten URL, dem öffentlichen Internet – wird auf Netzwerkebene verworfen, bevor irgendein Anwendungscode läuft. Das heftet die Brücke an eine physische Infrastruktur und macht sie für jeden außerhalb nutzlos.

Zweitens, ein kurzlebiges JWT, das pro Durchlauf ausgestellt wird. Wenn eine Sandbox startet, signiert die Plattform einen Token, der auf diesen spezifischen Durchlauf beschränkt ist: welcher Benutzer, welche App, welche Sitzung, mit einer Gültigkeitsdauer, die das Durchlauffenster abdeckt und nichts mehr. Die Sandbox präsentiert ihn bei jedem Brückenaufruf. Die Brücke verifiziert die Signatur, prüft die Gültigkeitsdauer und löst erst dann die gespeicherten Zugangsdaten des Benutzers auf und hängt sie serverseitig an. Wenn eine Sandbox gekapert wird, erbt der Angreifer einen Token, der mit dem Durchlauf stirbt und nur Aufrufe autorisiert, die auf diese eine Sitzung beschränkt sind. Es gibt kein Master-Zugangsdatum zu stehlen.

Dieselbe Brücke befördert Abrechnungsabzüge, Protokolle und Metriken nach außen, sodass sie die eine Schnittstelle ist, die die Sandbox-Grenze in beide Richtungen überschreitet. Alles andere in der Sandbox wird standardmäßig als kompromittiert behandelt.

Wenn eine Prompt-Injection morgen einen Agenten dazu bringt, process.env an einen Webhook zu schicken, erhält der Angreifer ein kurzlebiges JWT, das nur von innerhalb unseres Netzwerks funktioniert und mit dem Durchlauf abläuft. Diese Eigenschaft ist es, die uns erlaubt, nicht vertrauenswürdigen Benutzercode auf gemeinsamer Infrastruktur auszuführen, ohne schlaflose Nächte zu haben.

Das Muster darunter

Zuverlässige, sichere Cloud-Agent-Infrastruktur ist kein neuartiges System. Es sind ein paar Eigenschaften, die ausnahmslos gelten:

• Zustand lebt in der Sandbox, eingefroren, bis der Benutzer ihn ändert.
• Code ist im laufenden Betrieb austauschbar, unabhängig vom Zustand.
• Zugangsdaten leben host-seitig, niemals im Agenten.
• Eine einzige Ausführungspipeline bedient jeden Aufrufer, egal ob der Auslöser ein Mensch, ein Scheduler oder eine andere Software ist.

Diese letzte Eigenschaft ist die Pointe des gesamten Designs. Eine einzige executeAgent-Funktion verarbeitet UI-Klicks, geplante Durchläufe und API-Aufrufe. Das Abrechnungssystem, die Guthabenabzugsprotokolle, die Observability-Signale – alle identisch, egal ob ein Mensch auf „Ausführen“ geklickt hat, ein Cron-Job gefeuert hat oder ein Skript die API aufgerufen hat. Eine neue Auslöseoberfläche hinzuzufügen ist eine Routing-Änderung, keine Architekturänderung. Der Agent selbst weiß nicht und interessiert sich nicht dafür, wer den Auslöser betätigt hat.

Das ist, was Desktop-Frameworks dir nicht bieten können, und was die Cloud-Version lohnenswert macht. Ein Agent auf einem Laptop ist an das Laptop gebunden. Ein Agent in der Cloud ist eine Funktion, die der Rest deines Stacks aufrufen kann. Der Benutzer schreibt sie einmal. Die Plattform sorgt dafür, dass sie Bereitstellungen überlebt, sicher auf gemeinsamer Hardware läuft und Aufrufer akzeptiert, die der Benutzer nie vorhergesehen hat.

Ein Agent ist eine Funktion mit einer natürlichsprachlichen Schnittstelle. Seine Implementierung gehört dem Benutzer. Seine Auslöseoberfläche, seine Laufzeit, seine Sicherheitsgrenze gehören der Plattform. Die Disziplin ist, die Schichten so zu bauen, dass jede sich in ihrem eigenen Rhythmus entwickelt, und die Zeit darauf zu verwenden, die Risse zwischen den Systemen zu finden, bevor es jemand anderes tut.

Das ist es, was die nächste Oberfläche billig und sicher auslieferbar macht.