Zero-Trust-Ausführungsumgebung für Agenten#

Runabot ist eine Zero-Trust-Ausführungsumgebung für KI-Agenten, Entwicklungsumgebungen, CI/CD-Jobs und Paket-Builds. Sie stellt benötigte Workloads bereit und verwaltet sie, ohne echte Zugangsdaten oder weitreichenden Netzwerkzugriff innerhalb der Ausführungsumgebung verfügbar zu machen.

Die Ausführungsumgebung richtet sich an KI-Agenten, Entwicklungsumgebungen, CI/CD-Jobs und Paket-Builds, die externe Abhängigkeiten benötigen, ohne dafür echte Tokens offenzulegen.

Entwurfsziel#

Runabot geht davon aus, dass Agenten bösartige Inhalte lesen, fehleranfällige Werkzeuge ausführen und mitunter durch Prompt-Injection-Angriffe oder kompromittierte Abhängigkeiten manipuliert werden.

Die Ausführungsumgebung ist deshalb so konzipiert, dass ein kompromittierter Agent möglichst wenig Verwertbares vorfindet:

• keine echten Upstream-Zugangsdaten im Container
• standardmäßig kein offener Internetzugriff
• standardmäßig kein weitreichender Tool-Zugriff
• kein Netzwerkzugriff ohne ausdrückliche Freigabe
• keine unbemerkte Nutzung nicht verwalteter externer Systeme

Proxybasierte Architektur#

Der Zugriff auf wichtige Systeme erfolgt über dedizierte Proxys.

flowchart LR
    Agent["Agenten-Ausführungsumgebung<br/>eingeschränktes Runabot-Token"]
    Proxy["Runabot-Proxy<br/>Authentifizierung, Autorisierung,<br/>Inspektion, Audit"]
    Secret["Echte Upstream-Zugangsdaten<br/>außerhalb des Agenten"]
    System["Externes oder internes System<br/>Git, MCP, LLM, Web, API"]
    Telemetry["Observability-Backend<br/>Protokollierung, Monitoring,<br/>Tracing"]

    Agent -->|eingeschränkte Anfrage| Proxy
    Proxy -->|wendet Richtlinien an| Secret
    Proxy -->|genehmigte Anfrage| System
    System -->|Antwort| Proxy
    Proxy -->|Logs, Metriken, Traces| Telemetry
    Proxy -->|gefilterte/protokollierte Antwort| Agent

Der Agent kann den Proxy verwenden, aber nicht die Upstream-Zugangsdaten auslesen, die der Proxy nutzt. Gibt der Agent sein eigenes Token preis, ist es ohne direkten Zugang zum Proxy nutzlos.

Kontrollebenen#

Agenten mit menschlicher Steuerung#

Agenten mit menschlicher Steuerung sind leistungsfähig, weil Entwickler sie interaktiv lenken können. Sie bergen jedoch auch Risiken, da sie häufig auf eine Shell und Git zugreifen, Pakete installieren, das Web durchsuchen und mit Issue-Trackern arbeiten müssen.

Runabot behandelt solche Agenten als abgeschirmte Arbeitsumgebungen:

• Entwickler können sich über SSH oder das Web-Terminal verbinden
• der Agent erhält eingeschränkten Git- und Tool-Zugriff
• ausgehender Netzwerkverkehr bleibt standardmäßig blockiert
• Zugangsdaten werden durch Proxys vermittelt
• Backups und Wiederherstellung sorgen dafür, dass sich die Umgebung reproduzieren lässt

Für viele Teams eignet sich dieses Modell besser, als einen Coding-Agenten direkt auf dem Laptop eines Entwicklers mit weitreichenden lokalen Zugangsdaten auszuführen.

Autonome Agenten#

Autonome Agenten benötigen strengere Kontrollen, weil sie handeln können, ohne für jeden einzelnen Schritt eine Genehmigung einzuholen.

Runabots Modell sieht vor, autonomen Agenten nur eng zugeschnittene Berechtigungen zu erteilen:

• ausgewählte Tools statt ganzer Tool-Server
• ausgewählte Repositories statt einer gesamten Git-Organisation
• ausgewählte Domains statt des gesamten Internets
• ausgewählte API-Operationen statt eines umfassenden Service-Tokens

Die Ausführungsumgebung sollte unerwünschte Aktionen nach Möglichkeit unmöglich machen, statt sie lediglich zu erschweren.

Über Agenten hinaus: Abgesicherte Entwicklungs-Workloads#

Dasselbe Abschirmungsmodell ist auch außerhalb von KI-Agenten nützlich.

In der modernen Softwareentwicklung werden bereits große Mengen an nicht vertrauenswürdigem oder nur teilweise vertrauenswürdigem Code ausgeführt: Paketinstallationsskripte, Build-Plugins, Test-Fixtures, Compiler-Plugins, Codegeneratoren, Bots für Abhängigkeitsupdates, CI-Aktionen und Release-Automatisierung. Supply-Chain-Schadsoftware wie bei den Shai-Hulud-Vorfällen zielt genau auf diese Angriffsfläche, weil Entwicklungs- und CI-Umgebungen häufig wertvolle Zugangsdaten enthalten.

Runabot kann dieses Risiko senken, indem Entwicklungs-Workloads hinter denselben Sicherheitsbarrieren ausgeführt werden wie Agenten:

• IDE-Umgebungen können über SSH oder das Web-Terminal genutzt werden; Git-, Paket-Registry-, Issue-Tracker- und Cloud-Zugriffe werden durch Proxys vermittelt.
• CI/CD-Pipelines können beschränkte Proxy-Zugangsdaten statt echter Deploy-Keys, Cloud-Tokens, Tokens zur Paketveröffentlichung oder Git-Provider-Tokens erhalten.
• Installation und Builds von Abhängigkeiten können mit standardmäßig blockiertem ausgehendem Netzwerkverkehr laufen. Unerwartete ausgehende Verbindungen werden dadurch verhindert, sofern sie nicht ausdrücklich erlaubt sind.
• Release-Automatisierung kann auf bestimmte Repositories, Paketnamen, Umgebungen und Operationen beschränkt werden.
• Arbeitsumgebungen für Auftragnehmer oder temporär tätige Entwickler können mit eng begrenztem Zugriff bereitgestellt und anschließend wieder entfernt werden, ohne langlebige Geheimnisse auf Laptops zu hinterlassen.

Dadurch sinkt der Nutzen gestohlener Zugangsdaten. Schadsoftware kann zwar weiterhin in einem Entwicklungscontainer oder CI-Job ausgeführt werden, sollte dort aber keine wiederverwendbaren Upstream-Tokens vorfinden. Stiehlt sie ein Runabot-Proxy-Token, ist dieses nur über den Proxy, nur über den vorgesehenen Zugriffspfad der Ausführungsumgebung und nur für die laut Richtlinie erlaubten Aktionen gültig.

Die Firewall bildet eine zweite Barriere. Selbst wenn Schadsoftware versucht, Quellcode oder Build-Geheimnisse direkt an einen vom Angreifer kontrollierten Host auszuleiten, kann die standardmäßige Sperre für ausgehenden Netzwerkverkehr die Verbindung blockieren und das abgewiesene Ziel für eine Überprüfung sichtbar machen.

Damit ist Runabot ebenso eine Zero-Trust-Ausführungsumgebung für die Entwicklung wie für Agenten.

Community- und Quellcodezugang#

Integrationen sind zu spezifisch, als dass ein einzelner Anbieter sie allein entwickeln könnte. Jede Organisation hat unterschiedliche interne APIs, Genehmigungsabläufe, MCP-Server, Altsysteme und Audit-Anforderungen.

Runabots vorgesehenes Modell ist eine Gemeinschaft von Mitgliedsorganisationen: Sie können auf den Quellcode der Ausführungsumgebung zugreifen, ihn an ihre geschäftlichen Anforderungen anpassen und ihre Verbesserungen anschließend in den gemeinsam mit anderen Clubmitgliedern genutzten Code zurückführen. So können die Mitglieder auf der gehärteten Grundlage aufbauen und sie um die Adapter und Proxys zur Autorisierung ergänzen, die ihre jeweiligen Umgebungen erfordern.

Das Modell entspricht nicht dem klassischen öffentlichen Open-Source-Ansatz. Ziel sind ein kontrollierter Quellcodezugriff für Mitgliedsorganisationen, gemeinsam entwickelte Verbesserungen und gemeinschaftliche Sicherheitsprüfungen, ohne die gesamte Angriffsfläche im offenen Internet zu veröffentlichen.

Weiterführende Lektüre#

• Anthropic: Zero Trust für KI-Agenten
• Runabot: Sicherheitsfunktionen