Sicherheitsfunktionen#

Runabots Sicherheitsmodell basiert auf Zero Trust für KI-Agenten und Entwicklungs-Workloads: keine echten Zugangsdaten in der abgeschirmten Ausführungsumgebung, standardmäßig kein externer Netzwerkzugriff und jede wichtige Tool-Grenze wird durch einen Proxy vermittelt.

Diese Seite beschreibt die für Benutzer sichtbaren Sicherheitskontrollen. Eine umfassendere Produktübersicht finden Sie unter Zero-Trust-Ausführungsumgebung für Agenten.

Überblick über die Sicherheitsgrenze#

Bei der Workload kann es sich um einen Coding-Agenten, einen VS-Code-Server, ein Web-Terminal oder ein anderes Entwicklerwerkzeug handeln, das in einem von Runabot verwalteten Container ausgeführt wird. Die Workload verbindet sich nicht direkt mit externen Systemen. Jede Verbindung durchläuft zunächst einen von Runabot verwalteten Proxy, ein Addon oder eine Richtliniengrenze. Dort werden Richtlinien geprüft und Zugangsdaten angewendet, bevor Daten die Umgebung verlassen dürfen.

Keine Offenlegung echter Zugangsdaten#

Agenten sollen keine Upstream-Zugangsdaten für SSH, GitHub, Azure DevOps, Salesforce, MCP-Server, LLM-Anbieter oder interne Geschäfts-APIs speichern.

Stattdessen erhält der Agent von Runabot Proxy-Zugangsdaten mit eng begrenztem Geltungsbereich. Die echten Upstream-Zugangsdaten verbleiben in der Runabot-Steuerungsebene oder in einem dedizierten Proxy-Dienst. Der Proxy validiert die Anfrage des Agenten, prüft die Richtlinien und stellt erst danach eine Verbindung zum Zielsystem her.

Dadurch wird der potenzielle Schaden einer Kompromittierung begrenzt:

ein offengelegtes Agenten-Token ist im öffentlichen Internet nicht gültig
das Token kann auf einen einzelnen Proxy und einen engen Satz von Operationen begrenzt werden
Upstream-Zugangsdaten können zentral ausgetauscht werden, ohne das Dateisystem des Agenten zu verändern
der Zugriff kann entzogen werden, ohne sich beim Agenten anmelden zu müssen

Standardmäßig blockierter ausgehender Netzwerkverkehr#

Runabot verwendet die Netzwerkisolierung von Kubernetes, um ausgehenden externen Netzwerkverkehr für Agenten- und Addon-Workloads standardmäßig zu blockieren.

Erlaubte Ziele werden ausdrücklich festgelegt. Benutzer und IT-Administratoren können Freigabelisten anhand von Domains und Dienstrichtlinien verwalten und prüfen, statt Workloads weitreichenden Internetzugriff zu gewähren.

Ein Agent kann daher nicht unbemerkt beliebige ausgehende Verbindungen öffnen, nur weil er im Cluster ausgeführt wird. Externer Zugriff ist eine bewusste Richtlinienentscheidung.

MCP-Proxy-Muster#

MCP bietet Agenten eine einheitliche Schnittstelle zur Nutzung von Tools. Ein uneingeschränkter MCP-Server kann ihnen jedoch zu weitreichende Befugnisse gewähren.

Runabots MCP-Proxy-Muster setzt eine kontrollierte Grenze zwischen dem Agenten und den nachgelagerten, über MCP angebundenen Systemen:

der Agent erhält ein von Runabot ausgestelltes Token, das nur gegenüber dem Proxy gültig ist
echte Zugangsdaten für Systeme wie Salesforce, Azure DevOps, GitHub oder interne APIs bleiben außerhalb des Agent-Containers
der Proxy kann für eine bestimmte Agentenidentität ausschließlich ausgewählte MCP-Tools freigeben
der Tool-Zugriff kann zentral geändert werden, ohne die abgeschirmte Agentenumgebung neu zu erstellen

Wenn eine Prompt Injection den Agenten dazu bringt, sein MCP-Token preiszugeben, oder Schadsoftware Dateien aus dem Agenten-Container stiehlt, bleibt das Token dennoch auf den Runabot-Proxy und die zugewiesenen Richtlinien beschränkt. Gestohlene Tokens sind außerhalb des Runabot-Containers ungültig.

Git-Proxy-Addon#

Das Git Proxy-Addon ermöglicht einem Bot den Zugriff auf Upstream-Git-Repositories, ohne die eigentlichen Upstream-Git-Zugangsdaten direkt im Dateisystem des Bots zu speichern. Der Bot verwendet ein einziges von Runabot ausgestelltes Proxy-Token. Der Proxy entscheidet bei jeder Anfrage, ob der Bot einen bestimmten Repository-Pfad lesen oder schreiben darf.

Dadurch wird der potenzielle Schaden offengelegter Zugangsdaten begrenzt:

ein gestohlenes Bot-Token ist nur gegen den Runabot-Git-Proxy nutzbar
der Zugriff kann auf ausgewählte Repository-Pfade begrenzt werden
Lese- und Schreibrechte sind getrennt
Berechtigungen können zentral geändert werden, ohne das Dateisystem des Bots anzupassen

(zum Lesen klicken) Anwendungsbeispiel: Schreibgeschützter Git-Proxy für github.com

Ein sinnvolles Muster besteht darin, einen schreibgeschützten Proxy-Pfad für github.com einzurichten. Wenn der Bot dem Git-Proxy-Addon über ein Repository-Zugriffsprofil zugewiesen wird, konfiguriert Runabot Git im Bot so, dass gewöhnliche GitHub-Clone-URLs über den Proxy umgeleitet werden.

Runabot wendet automatisch eine Einstellung an, die der folgenden entspricht:

git config --global url."https://git-proxy.kuka.runa.bot/github/".insteadOf "https://github.com/"

Mit dieser Regel wird ein Befehl wie:

git clone https://github.com/someorg/repo.git

von Git transparent umgeschrieben zu:

git clone https://git-proxy.kuka.runa.bot/github/someorg/repo.git

Der Bot erreicht GitHub dann über den Runabot-Git-Proxy, statt direkt mit github.com zu sprechen.

Runabot konfiguriert das Proxy-Token im Bot für https://git-proxy.kuka.runa.bot, richtet die transparente insteadOf-Umschreibung ein und installiert einen auf die URL des Proxy-Hosts begrenzten Zugangsdaten-Helfer. Das Token bleibt dadurch außerhalb der umgeschriebenen Repository-URL, während Git sich weiterhin beim Proxy authentifizieren kann.

Empfohlene Konfiguration in der Runabot-Oberfläche:

Öffnen Sie die Einstellungen des Git Proxy-Addons.
Erstellen Sie einen Eintrag unter Upstream Git credentials für GitHub.
Setzen Sie den Proxy-Pfad-Präfix auf github.
Wählen Sie als Typ Generic HTTPS.
Setzen Sie den Hostnamen auf github.com.
Wählen Sie einen Authentifizierungsmodus.
Fügen Sie eine Regel für Repository-Pfade hinzu, zum Beispiel someorg/repo.git oder einen regulären Ausdruck für eine kontrollierte Gruppe von Repositories.
Erteilen Sie dieser Pfadregel in einem Repo access profile die Berechtigung read.
Weisen Sie dieses Repository-Zugriffsprofil dem gewünschten Bot zu.

Für öffentliche Repositories können Sie Auth type = None verwenden. In diesem Fall leitet der Proxy schreibgeschützte Anfragen an öffentliche GitHub-Repositories weiter, ohne Upstream-Zugangsdaten zu senden.

Warum das nützlich ist:

der Bot kann Quellcode von GitHub abrufen, ohne direkte GitHub-Zugangsdaten zu besitzen
der Proxy kann Lesezugriff erzwingen, selbst wenn der Bot durch von Angreifern kontrollierte Prompts gesteuert wird
Prompt Injection kann aus einer schreibgeschützten Proxy-Regel keine GitHub-Zugangsdaten mit Schreibberechtigung machen
ein Supply-Chain-Angriff innerhalb des Bots kann das Runabot-Proxy-Token höchstens für die erlaubten Proxy-Pfade wiederverwenden
ausgehender Git-Zugriff wird nachvollziehbar und kann zentral widerrufen werden

Das ist besonders hilfreich für Coding-Agenten, die Repositories analysieren sollen, aber niemals Code pushen, Tags erstellen oder auf andere Repositories zugreifen dürfen.

Aktuelle Supply-Chain-Angriffe zeigen, warum direkte Zugangsdaten in Entwicklungs- und Agentenumgebungen gefährlich sind:

Proxyzugriff für Web und Suche#

Agenten müssen häufig Webseiten, Suchergebnisse, Dokumentationen, Issue-Tracker und Paketmetadaten lesen. Diese Eingaben sind nicht vertrauenswürdig.

Runabots Sicherheitsmodell leitet diesen Zugriff durch kontrollierte Abruf- und Proxy-Komponenten. Dort können Antworten geprüft werden, bevor sie in den Agentenkontext gelangen. Ein sekundäres Modell oder ein Klassifikator kann verdächtige Anweisungen erkennen, zum Beispiel:

in Webinhalten versteckte Befehle
Aufforderungen, Skripte herunterzuladen und auszuführen
Versuche, Geheimnisse über URLs oder Tool-Aufrufe auszuleiten
Anweisungen, die das ursprüngliche Ziel des Benutzers überschreiben

Das Ziel besteht nicht darin, jede Webseite sicher zu machen. Nicht vertrauenswürdige Inhalte sollen vielmehr hinter einer Grenze bleiben, an der Richtlinien, Prüfung und Protokollierung angewendet werden können.

Rückverfolgbarkeit#

Proxyvermittelter Zugriff bietet Betreibern eindeutige Prüfpunkte.

Für LLM-Verkehr kann Runabot Inferenzanfragen über einen LLM-Proxy leiten und Traces der Anfragen und Antworten aufzeichnen. Für Git-, MCP- und Webzugriffe gilt dasselbe Prinzip: Die Proxy-Grenze erfasst die Anfrage, bevor sie das Ziel erreicht, und kann den Vorgang protokollieren.

Diese Traces sind sowohl für Sicherheitsuntersuchungen als auch für die Entwicklung nützlich. Datenwissenschaftler und Agentenentwickler können nachvollziehen, wie ein autonomer Agent eine Aufgabe zerlegt hat, welche Tools er aufgerufen hat, welche Modellantworten seinen nächsten Schritt beeinflusst haben und an welcher Stelle ein Ablauf langsam, teuer oder unzuverlässig wurde.

Das hilft, nach einem Vorfall Sicherheitsfragen zu beantworten:

Welcher Agent hat die Anfrage gestellt?
Welche Proxy-Zugangsdaten wurden verwendet?
Welches Upstream-System wurde angesprochen?
War die Anfrage schreibgeschützt oder schreibberechtigt?
Welche Antwort ist in den Agentenkontext gelangt?

Menschlich festgelegte Richtlinien, automatische Durchsetzung#

Bei Runabot behalten Menschen die Kontrolle über die Richtlinien, während deren Durchsetzung automatisch erfolgt.

Betreiber definieren erlaubte Domains, Repository-Pfade, Tool-Freigaben und die Geltungsbereiche von Zugangsdaten. Die abgeschirmte Ausführungsumgebung setzt diese Entscheidungen mithilfe von Netzwerkregeln, Proxy-Autorisierung und zentral verwalteten Zugangsdaten durch.

Abgelehnte Verbindungen können für Benutzer und Administratoren als konkrete Liste blockierter Ziele sichtbar gemacht werden, bevor der Zugriff erweitert wird.

Sicherheit mit einfacher Bereitstellung#

Die Zero-Trust-Kontrollen sind in dieselbe Bereitstellungsplattform eingebaut, die auch für den normalen Bot-Betrieb verwendet wird:

über die Weboberfläche gesteuerte Bereitstellung
isolierte Kubernetes-Namespaces
Sicherung und Wiederherstellung
SSH- und Web-Terminal-Zugriff
Addon-Zuweisung und Neukonfiguration
API-Grundlage

Das Ziel ist eine starke Sicherheitsgrenze, die für Teams, KMUs und einzelne Entwickler trotzdem praktisch betreibbar bleibt.