Wie kontrolliert man, wohin ein KI-Agent im Netz darf?

Legen Sie in covey eine Organisation an, dann steht in ihrer Allowlist genau ein Eintrag: api.anthropic.com. Das ist der Endpunkt der Claude-Runtime. Ein frisch eingestellter Agent kann also mit dem Modell sprechen und sonst mit niemandem.

Das ist Absicht, und es ist unbequem: der erste Agent, der npm install ausführt, steht vor einer Wand. Für solche Fälle liegen dreizehn Vorlagen bereit — github, npm, pypi, go, rust, composer, maven-gradle, container und debian-ubuntu unter ihnen. Wer die passende an einen Agenten hängt, öffnet ihm genau diesen Weg und keinen anderen.

Bis Juli stand api.anthropic.com fest im Quelltext. Dass die Basisliste heute konfigurierbar ist, war eine unserer ersten Korrekturen: eine Liste, die man nicht ändern kann, wird umgangen statt gepflegt.

Bleibt die Frage, wie fest so eine Liste ist.

Der Proxy ist ein Versprechen

Die erste Stufe haben wir zuerst gebaut, weil sie naheliegt. COVEY_EGRESS_ENFORCE schaltet sie ein. Der gesamte Verkehr der Sandbox läuft über einen Proxy, der die Allowlist durchsetzt. Was nicht daraufsteht, wird abgelehnt.

Das kostet keinen zusätzlichen Aufwand, und es hält — solange die Sandbox mitmacht.

Genau da sitzt die Grenze. Kooperativ heißt: der Weg über den Proxy ist eingerichtet, nicht erzwungen. Ein Prozess, der sich seine eigene Route sucht, umgeht ihn dabei.

Das ist keine Schwäche der Umsetzung. Mehr kann ein Proxy nicht leisten, und wer ihn als Sicherheitsgrenze verkauft, verkauft eine Vereinbarung als Mauer.

Die zweite Stufe nimmt die Möglichkeit weg

Deshalb haben wir am selben Tag die harte Stufe nachgezogen. COVEY_EGRESS_ISOLATION=network setzt die Sandbox auf ein internes Docker-Netz ohne Internetzugang. Der Proxy-Container ist der einzige Ausgang, und umgehen lässt er sich nicht, weil es keinen zweiten Weg gibt.

Diese Stufe kostet ein eigenes Image, das make egress-image aus Dockerfile.egress baut. Der Proxy darin lädt seine Allowlist aus Datenbank und Umgebung und hält sie laufend nach, statt sie beim Start einzufrieren.

Der Unterschied zwischen beiden Stufen ist keine Feinheit der Konfiguration. Die eine ist eine Regel, an die sich die Sandbox hält. Die andere ist eine Eigenschaft des Netzes, die ihr keine Wahl lässt.

Netzisolation pro Kunde, Allowlist pro Agent

Wer covey über mehrere Runner betreibt, bekommt die harte Isolation pro Runner und nicht pro Agent. Internes Netz und Proxy-Container gibt es einmal je Runner.

Weil ein Runner genau einer Organisation dient, teilen sich zwei Kunden nie ein Netzsegment: das --internal-Flag kappt den Weg nach draußen, nicht den Weg zur Seite. Seine Allowlist holt sich der Proxy von der Control Plane, authentifiziert mit dem Runner-Token, das bei jedem Start der Control Plane erneuert wird.

Geteilt wird dabei nur das Netzsegment. Zwei Agenten derselben Organisation sitzen im selben internen Netz, aber nicht an derselben Liste.

Bei jeder Verbindung liest der Proxy den Proxy-Authorization-Kopf und weiß dadurch, welcher Agent gerade fragt. Die Control Plane beantwortet die Anfrage für genau diesen einen. Die Netzisolation trennt Mandanten, die Allowlist trennt feiner: pro Agent, pro Verbindung.

Warum das keine Nebensache ist

Egress ist nicht das einzige Guard-Rail. Daneben steht ein Budget pro Agent, das ihn stoppt, sobald es aufgebraucht ist.

Ein überschrittenes Budget trifft die Rechnung. Ein offener Ausgang trägt Daten nach draußen. Deshalb steht die harte Stufe überhaupt zur Wahl, obwohl sie ein zweites Image verlangt.

Wer heute kooperativ startet, sollte das als Übergang lesen. Es ist die Stufe, mit der man anfängt — nicht die, auf der ein Agent mit Zugriff auf echte Daten dauerhaft läuft.