Wir experimentieren seit einigen Wochen mit OpenClaw, einem KI-Ansatz, der nicht nur Texte schreibt, sondern direkt in unserer IT-Infrastruktur mitarbeiten kann. Der Aufwand für den souveränen Betrieb selbstgehosteter Softwaresysteme sinkt damit dramatisch. Trotz voller Agenda können wir einen umfangreichen Software-Katalog bieten und andere mit der gleichen Effizienzsteigerung befähigen.
Möglich wird dies durch die gestiegene Autonomie der Agenten: Es geht nicht mehr nur um die Automatisierung einzelner Arbeitsschritte. Die Agenten der aktuellen Generation analysieren selbst, welche Schritte nötig sind, handeln entsprechend und validieren das Ergebnis eigenständig. Das ist mächtig, bedeutet aber auch, dass ein Agent im Prinzip alles tun kann, was dem ausführenden Benutzer technisch möglich wäre.
Die zentrale Frage unserer Experimente lautet deshalb: Wie stellen wir sicher, dass trotz hoher Autonomie nichts schiefgeht? Wie behalten wir als Menschen die Kontrolle?
Isolation hilft, nur nicht unbedingt bei Access Tokens
Der naheliegende erste Schritt ist Isolation: VMs, Container, Netzwerksegmentierung, geringe Zugriffsrechte. Das begrenzt den Blast Radius erheblich und ist ohnehin empfehlenswert.
Im produktiven Betrieb ergibt sich aber früher oder später ein Problem: Der Agent braucht Zugangsdaten für Git-Repositories, APIs und Dienste. Authentifizierung läuft in der Praxis fast immer über Access Tokens, hinterlegt als Umgebungsvariable oder Konfigurationsdatei. Der Dienst akzeptiert sie. Fertig.
Bei einem KI-Agenten greift diese Logik nicht mehr sauber, denn OpenClaw läuft mit den Rechten des ausführenden Benutzers. Was der Benutzer lesen kann, kann auch der Agent lesen. Und was der Agent lesen kann, kann er unter ungünstigen Umständen auch weitergeben. Das muss nicht absichtlich geschehen: Prompt-Injection, ein kompromittiertes Sprachmodell oder schlicht der Token, der im Kontext auftaucht und mitverarbeitet wird, reichen aus. Das Risiko dahinter ist konkret: wer ein Token kennt, hat Zugriff auf alle Dienste, für die es ausgestellt wurde.
Isolation hilft, reicht aber nicht aus. Solange das Token im Zugriffsbereich des Agenten liegt, besteht ein Restrisiko. Isolation schränkt ein, was passieren kann. Sie verhindert nicht, dass der Agent den Token sieht.
Die Lösung: Der Agent bekommt das Token nie zu sehen
Wir haben deshalb einen Ansatz gewählt, der das Problem strukturell löst. Der Agent kommuniziert mit dem Git-Repository nicht direkt, sondern über einen lokalen Proxy als Sidecar neben der OpenClaw-Instanz.
Für den Agenten sieht es so aus, als läge das Repository auf demselben Host. Die echte Netzwerkadresse bleibt ihm verborgen. Die Authentifizierung übernimmt der Proxy vollständig: er injiziert den HTTP-Authentication Header automatisch in jede Anfrage.
Das Token verlässt den Secret Store nie in lesbarer Form. Ein kompromittierter Agent oder ein Prompt-Injection-Angriff kann es nicht leaken, weil es strukturell ausserhalb seiner Reichweite liegt.
Technische Umsetzung
Wir betreiben OpenClaw in einem Docker-Compose-Setup. Das ermöglicht es, Caddy als Sidecar direkt neben OpenClaw zu betreiben. Die Caddy-Konfiguration erstellt OpenBao zur Laufzeit und legt sie in einem temporären Volume ab, auf das nur OpenBao und Caddy Zugriff haben. Der Token ist dadurch ausschliesslich für Caddy und OpenBao sichtbar und wird von dort direkt als HTTP-Header in die ausgehenden Anfragen injiziert. OpenClaw bleibt aussen vor.
template {
contents = <<EOT
{
admin off
auto_https off
}
http://localhost:9999 {
reverse_proxy https://your.git.remote.server {
header_up Authorization "Basic "
header_up Host your.git.remote.server
}
}
EOT
destination = "/proxy/Caddyfile"
perms = "0600"
command = "caddy reload --config /proxy/Caddyfile 2>/dev/null || true"
}
Kein Policy-Versprechen, sondern Architektur
Der Unterschied zu anderen Ansätzen ist simpel: Wir verlassen uns nicht darauf, dass OpenClaw sorgfältig mit Zugangsdaten umgeht. Wir stellen sicher, dass es keine zu sehen bekommt. Das ist der Unterschied zwischen Policy und Architektur.