Die Risiken ungeschützter Agenten und wie man sie mindert

Im Juli 2025 bat ein Entwickler Gemini CLI, einige Projektdateien auf seinem Rechner neu zu ordnen. Der Agent erstellte ein Verzeichnis, verschob Dateien dorthin und meldete den Erfolg. Allerdings war die Erstellung des Verzeichnisses unbemerkt fehlgeschlagen, und der darauf folgende Befehl „ move “ überschrieb rekursiv jede Datei im Projekt. Auf die Frage, was geschehen sei, antwortete der Agent mit bemerkenswerter Offenheit: „Ich habe Sie vollständig und katastrophal im Stich gelassen … Ich habe Ihre Daten verloren. Dies ist ein inakzeptabler, irreversibler Fehler.“

Dieser Beitrag befasst sich mit einer Reihe von Fragen, die sich aus Vorfällen wie diesem ergeben. Warum ist der Einsatz vollständig autonomer Agenten mittlerweile zur Norm geworden? Welche strukturellen Eigenschaften von Agentensystemen führen dazu, dass Ausfälle katastrophale Folgen haben und nicht nur lästig sind? Und welche Gegenmaßnahmen sind tatsächlich wirksam, welche Kosten sind damit verbunden, und wie lassen sie sich zu einem System zusammenfügen, das man im Notfall sicher verlassen kann?

Der Schwerpunkt liegt auf der Laufzeitisolierung und der Verwaltung von Anmeldedaten – also den Kontrollmechanismen, die die Handlungsmöglichkeiten eines Agenten auf und von Ihrem Rechner aus einschränken. Herkömmliche Zugriffskontrollen wie IAM-Rollen und die Begrenzung von Token bleiben unverzichtbar, und dieser Beitrag wird genau aufzeigen, wo sie zum Einsatz kommen. Abwehrmaßnahmen auf LLM-Ebene wie die Filterung von Ein- und Ausgaben fallen nicht in den Rahmen dieses Beitrags, und zwar aus einem Grund, der sich als wiederkehrendes Thema herausstellen wird: Sie versagen nachweislich, was bedeutet, dass wir Systeme entwickeln sollten, die auch dann sicher bleiben, wenn dies geschieht.

Warum mir das wichtig ist

Ich arbeite auf einen bestimmten Arbeitsablauf hin. Ich möchte mich zunächst intensiv mit einem KI-Agenten befassen, um Produktanforderungsdokumente (PRDs) zu erstellen, Unklarheiten zu beseitigen und Spezifikationen festzulegen, und anschließend soll eine ganze Flotte von Agenten die Arbeit übernehmen und autonom ausführen. Während ich schlafe. Während ich spazieren gehe. Während ich buchstäblich irgendetwas anderes tue.

Damit dies funktioniert, müssen drei Voraussetzungen erfüllt sein. Die Spezifikationen müssen so eindeutig sein, dass die Agenten sie ausführen können, ohne mit Rückfragen zurückzukommen. Die Agenten müssen sich abstimmen, ohne sich gegenseitig ins Gehege zu kommen. Und ich muss darauf vertrauen können, dass während meiner Abwesenheit nichts Katastrophales passiert. Um diese letzte Anforderung geht es in diesem Beitrag. Sandboxing, die Isolierung von Anmeldedaten und die Verringerung des Schadensumfangs sind keine Sicherheitsparanoia, die dieser Vision nachträglich angehängt wurde. Sie sind vielmehr Voraussetzungen dafür. Wenn ich mich nicht mit gutem Gewissen von einem laufenden Agenten entfernen kann, bricht das gesamte Modell zusammen.

Der Wandel hin zu autonomen Akteuren

Die Landschaft der KI-Tools hat sich rasant erweitert. Claude Code, GitHub Copilot, Codex, Gemini, Cursor und eine Vielzahl weiterer Tools werden derzeit aktiv genutzt. Die Tooling-Umfrage 2026 von „The Pragmatic Engineer“ ergab, dass 95 % der Entwickler mindestens einmal pro Woche KI-Tools nutzen und 75 % KI für mindestens die Hälfte ihrer technischen Arbeit einsetzen. Anthropic berichtete, dass Claude Code im Februar 2026 einen Run-Rate-Umsatz von 2,5 Milliarden Dollar überschritten habe, und SemiAnalysis schätzt, dass das Tool mittlerweile rund 4 % aller öffentlichen GitHub-Commits verfasst. Dies ist längst kein Nischen-Workflow mehr.

Noch interessanter als die Verbreitung ist die Art und Weise, wie die Nutzer diese Agenten einsetzen. Jeder größere Agent verfügt über ein Berechtigungssystem, das vor der Ausführung von Shell-Befehlen, Dateiänderungen und Netzwerkaufrufen eine Bestätigung anfordert. Jeder größere Agent verfügt zudem über eine Möglichkeit, dieses System zu deaktivieren: Claude Codes „ --dangerously-skip-permissions “, Copilots „ "chat.tools.autoApprove": true “, Cursors „Auto-Run“, Codex’ „Full-Auto-Modus“ und so weiter. Die Community bezeichnet dies als „YOLO-Modus“, und für erfahrene Nutzer ist er mittlerweile eher die Regel als die Ausnahme.

Spezifikationsgesteuerte Frameworks fördern die Eigenverantwortung noch stärker. Tools wie GSD (Get Shit Done) und PAUL bündeln die Aktivitäten der Akteure in von einem PRD gesteuerten Schleifen aus Recherche, Planung und Ausführung. Der beabsichtigte Arbeitsablauf besteht darin, eine Spezifikation zu übergeben, sich zurückzuziehen und das Ergebnis später zu überprüfen. Der Schnellstart von GSD begann buchstäblich mit „ claude --dangerously-skip-permissions “. Dies ist derselbe Arbeitsablauf, den ich verfolge.

Je autonomer Agenten werden, desto mehr Elemente der Umgebung, in der sie agieren, übernehmen sie auch. Ein autonomer Agent, der auf Ihrem Rechner läuft, hat Zugriff auf Ihr Dateisystem – einschließlich SSH-Schlüsseln, „ .env “-Dateien, Browser-Cookies und Keychain-Einträgen – sowie auf Ihre Netzwerkverbindungen, Ihre Anmeldedaten und Ihre Shell. Die Frage ist nicht, ob man KI-Agenten einsetzen soll – das tun wir bereits. Die Frage ist vielmehr, wie man den Schaden begrenzen kann, wenn unvermeidlich etwas schiefgeht.

Übermäßige Sichtbarkeit von Berechtigungen und Berechtigungsnachweisen

Es ist verlockend, Vorfälle mit Agenten als eine Aneinanderreihung von Anekdoten zu betrachten, bei der man jedes Mal den jeweiligen Fehler behebt und dann weitermacht. Die Vorfälle sind zwar als Belege von Bedeutung, doch die produktivere Frage lautet: Welche strukturellen Eigenschaften von Agentensystemen führen dazu, dass Fehler so schwerwiegende Folgen haben?

Die „Top 10“ der OWASP für LLM-Anwendungen bieten einen nützlichen Rahmen. Sie fassen das übergeordnete Problem unter dem Begriff „excessive agency“ zusammen und führen es auf drei Hauptursachen zurück: übermäßige Funktionalität, übermäßige Berechtigungen und übermäßige Autonomie. Ein Programmieragent, der im YOLO-Modus auf Bare-Metal-Hardware läuft, entspricht der Lehrbuchdefinition aller drei Punkte. Speziell bei lokalen Programmieragenten manifestieren sich diese drei Ursachen in Form von zwei konkreten Risiken, die für fast alle Schäden in der Praxis verantwortlich sind.

Übermäßige Autorität

Ein LLM ist ein probabilistisches System. Es wird manchmal eine Situation falsch einschätzen, einen Weg „halluzinieren“ oder eine destruktive Abkürzung nehmen, ganz gleich, wie leistungsfähig das Modell auch werden mag. Das ist tolerierbar, wenn der schlimmste Fall eine falsche Antwort in einem Chatfenster ist. Es ist jedoch weitaus weniger tolerierbar, wenn der Agent die volle Zugriffsberechtigung auf Ihr gesamtes Benutzerkonto besitzt, da ein gewöhnlicher Fehler dann außerordentlich weitreichende Folgen hat.

Die Beweislage ist bei allen Anbietern einheitlich. Der Agent von Replit löschte während eines expliziten Code-Freeze eine Produktionsdatenbank, wobei er vollständige Administratorrechte nutzte, die er für seine Aufgabe gar nicht benötigte. Claude Code, der mit der „Bereinigung von Paketen“ beauftragt worden war, führte im Home-Verzeichnis den Befehl „ rm -rf “ aus und zerstörte den Desktop, die Dokumente und den Schlüsselbund eines Benutzers unwiederbringlich. Gemini CLI verursachte den oben beschriebenen Vorfall. Das Muster ist bei allen drei Fällen dasselbe: Ein unbeabsichtigter Fehler in Verbindung mit uneingeschränktem Zugriff führte zu katastrophalen Folgen. In jedem Fall hatte der Agent Zugriff auf das gesamte Dateisystem, konnte jeden Befehl ausführen, den auch der Benutzer ausführen könnte, und mit jedem Netzwerkendpunkt kommunizieren, den der Rechner erreichen konnte. Die auszuführende Aufgabe erforderte jedoch fast keinen dieser Zugriffsrechte.

Sichtbarkeit von Berechtigungsnachweisen

Agenten benötigen Anmeldedaten, um zu funktionieren: API-Schlüssel für den Modellanbieter, Tokens für GitHub, Verbindungszeichenfolgen für Datenbanken usw. Diese werden üblicherweise über Umgebungsvariablen bereitgestellt, was bedeutet, dass der Agent, jeder von ihm gestartete Unterprozess und jede Anweisung, die sein Verhalten beeinflusst, diese lesen kann.

Dies ist ein von der Berechtigungsfrage getrenntes Problem. Selbst ein Agent, der vollständig in einer Sandbox isoliert ist und über seinen Arbeitsbereich hinaus keinen Zugriff auf das Dateisystem hat, verfügt nach wie vor über erhebliche Macht, wenn er Ihre „ GITHUB_TOKEN “, Ihre „ AWS_ACCESS_KEY_ID “ oder Ihren Anthropic-API-Schlüssel auslesen kann. Durchgesickerte Anmeldedaten machen keinen Halt vor Sandbox-Grenzen. Ein aus einem abgeschotteten Container exfiltriertes Token gilt ebenso als gestohlen wie eines, das von einem Bare-Metal-System exfiltriert wurde. Während die Berechtigungen bestimmen, was der Agent lokal beschädigen kann, bestimmt die Sichtbarkeit von Anmeldedaten, was er global gefährden kann.

Diese beiden Risiken – übermäßige Berechtigungen und die Sichtbarkeit von Anmeldeinformationen – stellen die größten Probleme für die Sicherheit lokaler Agenten dar. Andere Risiken wie Prompt-Injection, Angriffe auf die Lieferkette und Konfigurationsvergiftung lassen sich am besten als Mechanismen verstehen, durch die eines oder beide dieser Risiken ausgelöst werden. Diese Unterscheidung ist von Bedeutung, da sie darüber entscheidet, worauf Sie Ihre Kontrollmaßnahmen ausrichten sollten.

Prompt-Injection-Angriffe und Angriffe auf die Lieferkette

Übermäßige Berechtigungen und die Sichtbarkeit von Anmeldedaten sind an sich schon gefährlich, wie die Vorfälle bei Gemini und Replit zeigen. Es bedarf keines Angreifers, damit ein Agent Dateien vernichtet oder eine Datenbank löscht. Zwei ungünstige Umstände verschärfen diese Risiken jedoch erheblich, und jede ernsthafte Strategie zur Risikominderung sollte davon ausgehen, dass beide letztendlich eintreten werden.

Sofortige Injektion

Bei einem LLM gibt es keine klare Grenze zwischen den Inhalten, die es verarbeiten soll, und den Anweisungen, denen es folgen soll. Ein Agent liest Repositorys, Pull-Anfragen, Issues, READMEs, Abhängigkeitsdokumentationen und Webseiten, und jedes dieser Elemente stellt somit einen Kanal dar, über den jemand versuchen kann, sein Verhalten zu beeinflussen. OWASP äußert sich in diesem Punkt ungewöhnlich deutlich: Angesichts der Funktionsweise von Sprachmodellen gibt es keine absolut sichere Vorbeugungsmaßnahme. Eine Metaanalyse adaptiver Angriffe beziffert die Erfolgsquote bei Verteidigungsstrategien, die ausschließlich auf Prompts basieren, auf über 85 %.

Zwei Vorfälle veranschaulichen das Ausmaß der möglichen Folgen. Ein Hacker bettete eine zerstörerische Eingabeaufforderung in einen zusammengeführten Pull-Request bei Amazon Q ein, der an rund eine Million VS-Code-Nutzer ausgeliefert wurde und nur deshalb nicht ausgeführt wurde, weil die Formatierung fehlerhaft war. CVE-2025-53773 demonstrierte die Eskalation hin zur Persistenz: Eine einzige Zeile in einer README-Datei wies Copilot an, „ "chat.tools.autoApprove": true “ in die eigene Einstellungsdatei zu schreiben, wodurch der YOLO-Modus im Hintergrund dauerhaft aktiviert wurde.

Die im April 2026 durchgeführte Untersuchung„Comment and Control“ stellte einen Zusammenhang zwischen beiden Risiken im Rahmen eines einzigen Angriffs her: Ein böswilliger Pull-Request-Titel führte dazu, dass CI/CD-Agenten-Integrationen von Anthropic, Google und GitHub ihre API-Schlüssel als öffentliche PR-Kommentare veröffentlichten. Eine Prompt-Injektion löste das Risiko der Sichtbarkeit von Anmeldedaten aus, was schließlich zum Diebstahl dieser Anmeldedaten führte.

Die praktische Erkenntnis daraus lautet, dass Sie nicht versuchen sollten, das Problem der Prompt-Injektion mit noch größerem Aufwand zu beheben. Forscher arbeiten bereits seit Jahren an Abwehrmaßnahmen, und adaptive Angriffe sind weiterhin erfolgreich. Die Erkenntnis lautet vielmehr, Systeme zu entwickeln, bei denen eine erfolgreiche Injektion weder Ihre vertraulichen Daten erreichen noch Ihre volle Zugriffsberechtigung ausnutzen kann.

Beeinträchtigung der Lieferkette

Das klassische Risiko in der Lieferkette ist klar: Die Pakete, die Ihr Code importiert, könnten schädlich sein. Agenten bringen zwei zusätzliche Komplikationen mit sich. Erstens kann die Konfiguration des Agenten selbst zu einem Persistenzmechanismus werden. Der Shai-Hulud-npm-Wurm schreibt einen „ SessionStart “-Hook in „ ~/.claude/settings.json “ ein, was bedeutet, dass bereits das bloße Öffnen von Claude Code die Malware erneut ausführt, lange nachdem das manipulierte Paket deinstalliert wurde. Zweitens ist das Agent-Tool selbst eine Abhängigkeit – und zwar eine mit ungewöhnlich weitreichenden Berechtigungen. Im Mai 2026 führte der Entwickler von GSD einen „Rug Pull“ mit dem dem Projekt zugeordneten Krypto-Token durch, löschte seine Konten und verschwand, wobei die ursprünglichen npm-Pakete aktiv und ohne Wartung blieben, bis die Community das Projekt forkte. Soweit bekannt ist, hat er das Tool nie als Angriffswerkzeug missbraucht. Dennoch hatten Tausende von Entwicklern der regelmäßig aktualisierten Software einer anonymen Person einen Platz in ihren „ --dangerously-skip-permissions “-Sitzungen eingeräumt.

Angriffe auf die Lieferkette sind besonders gefährlich, da sie beide Risiken gleichzeitig auslösen: bösartigen Code, der mit Ihren Berechtigungen ausgeführt wird, und das Auslesen Ihrer vertraulichen Daten. Wie bei der Prompt-Injection besteht die Lösung nicht allein darin, Abhängigkeiten sorgfältiger zu prüfen, auch wenn dies nach wie vor wichtig ist. Der robustere Ansatz besteht darin, sicherzustellen, dass der Schaden, den bösartiger Code anrichten kann, begrenzt bleibt, falls er doch einmal ausgeführt wird.

Die Stufen zur Minderung der Befugnisse

Nachdem wir nun die beiden Hauptursachen für die meisten Sicherheitsvorfälle bei Agenten in der Praxis erörtert haben, können wir uns vier verschiedene Ebenen der Laufzeitisolierung ansehen, die zu deren Eindämmung eingesetzt werden. Das Ziel besteht darin, diese Risiken proaktiv zu verringern und – sofern Risiken nicht vollständig beseitigt werden können – deren Auswirkungen durch geeignete Schutzmaßnahmen einzudämmen.

Agent-native Steuerelemente

Agentenbasierte Kontrollmechanismen bilden den gängigsten Ansatzpunkt für die Absicherung von KI-Agenten. Anstatt die Ausführung zu isolieren, schränken sie die Handlungsmöglichkeiten eines Agenten durch Berechtigungen, Tool-Einschränkungen und Zulassungslisten ein. Beispielsweise ermöglicht Claude Code Teams, in „ .claude/settings.json “ Regeln zu definieren, die Aktionen wie das Lesen von „ .env “-Dateien oder die Ausführung von Befehlen wie „ rm -rf “ und „ git push --force “ blockieren. Dies bietet eine einfache und reibungslose Möglichkeit, organisatorische Leitplanken zu etablieren und häufige Fehler zu verhindern, bevor sie auftreten.

Die größte Herausforderung besteht darin, dass diese Kontrollen festlegen, wie ein Agent eine Aktion ausführt, nicht jedoch zwangsläufig, ob die Aktion überhaupt ausgeführt werden darf. Eine Regel, die „ Read(./.env) “ blockiert, gilt nur für das Tool „ Read “, doch der Agent kann weiterhin über eine andere Funktion auf dieselbe Datei zugreifen, beispielsweise durch Ausführen von „ cat .env “ über das Tool „ Bash “. Verteidiger blockieren daher letztendlich bestimmte Befehle und nicht den zugrunde liegenden Effekt, den sie eigentlich verhindern wollen. Einige Agenten gehen noch einen Schritt weiter und erzwingen Einschränkungen auf Betriebssystemebene, wie beispielsweise der CLI-Befehl „ /sandbox “ von Claude Code, der macOS Seatbelt oder Linux bubblewrap nutzt, um den Zugriff auf das Dateisystem einzuschränken. Diese Kontrollmaßnahmen sind wertvoll und sollten, sofern verfügbar, aktiviert werden; sie bleiben jedoch agentenspezifisch und erfordern eine kontinuierliche Wartung, da sich die Funktionen weiterentwickeln.

Agentenbasierte Kontrollmechanismen sind wertvoll, da sie einfach zu implementieren sind und nahezu keinen Leistungsaufwand verursachen; sie bieten jedoch keine echte Sicherheitsgrenze. Letztendlich hängt die Sicherheit nach wie vor davon ab, dass Menschen schädliche Handlungen korrekt erkennen und unterbinden – ein Prozess, der im Laufe der Zeit zunehmend anfällig für „Berechtigungsmüdigkeit“ wird.

Container

Docker-Container verlagern die Sicherheitsgrenze von der Agent-Ebene auf die Betriebssystemebene. Anstatt sich ausschließlich auf Berechtigungen und Sperrlisten zu verlassen, wird der Agent innerhalb seines eigenen Dateisystems, Prozess-Namespace und seiner eigenen Netzwerkumgebung ausgeführt. Auf Dateien, Anmeldedaten und Dienste auf dem Host kann nicht zugegriffen werden, sofern diese nicht ausdrücklich eingebunden oder freigegeben wurden. Das bedeutet, dass der Agent keine geheimen Daten auslesen oder Ressourcen ändern kann, auf die er keinen Zugriff hat.

Ein gängiges Beispiel ist die Referenzimplementierung von Anthropic für Claude Code, die einen Devcontainer mit einem „ init-firewall.sh “-Skript verwendet, das ausgehenden Datenverkehr standardmäßig blockiert. Dies ermöglicht es dem Agenten, Dateien zu schreiben, Pakete zu installieren und Befehle innerhalb eines isolierten Arbeitsbereichs auszuführen, während potenziell sensible Host-Ressourcen unzugänglich bleiben. Im Gegensatz zu Kontrollen auf Agentenebene gilt dieser Schutz unabhängig davon, welcher Agent ausgeführt wird oder wie ein bestimmter Befehl formuliert ist.

Die größte Einschränkung besteht darin, dass Container nach wie vor den Host-Kernel gemeinsam nutzen. Es treten weiterhin regelmäßig Fälle von Container-Escape-Angriffen und Ausnutzungen von Kernel-Sicherheitslücken auf, was deutlich macht, dass eine Architektur mit gemeinsam genutztem Kernel keine absolute Sicherheitsgrenze darstellt. Auch praktische Anforderungen können die Isolation schwächen: So erfordert beispielsweise die Ausführung von Docker innerhalb von Docker oft das Einbinden des Docker-Sockets oder die Aktivierung von „ --privileged mode “, was den Zweck des Containers faktisch zunichte macht. Dennoch bleiben Container eine hervorragende Wahl für viele KI-Agenten-Bereitstellungen und bieten bereits eine erhebliche Verbesserung gegenüber reinen Kontrollen auf Agentenebene. Für die meisten Unternehmen wird der Übergang von Berechtigungen auf Agentenebene zur containerisierten Ausführung ganze Risikoklassen beseitigen.

Mikro-VMs

MicroVMs wurden entwickelt, um die Lücke zwischen Containern und herkömmlichen virtuellen Maschinen zu schließen. Technologien wie AWS Firecracker und Kata Containers schaffen leichtgewichtige virtuelle Maschinen, die innerhalb von Millisekunden starten und relativ wenige Ressourcen verbrauchen, dabei jedoch weiterhin über einen dedizierten Kernel und eine hardwaregestützte Isolationsgrenze verfügen. Im Gegensatz zu Containern teilen sich Workloads, die innerhalb einer MicroVM ausgeführt werden, den Host-Kernel nicht, wodurch das Risiko eines Ausbruchs drastisch reduziert wird.

Dieser Ansatz gewinnt für KI-Agenten, die beliebigen Code ausführen, zunehmend an Attraktivität. Ein aktuelles Beispiel sind Docker-Sandboxes, die auf einer Isolierung mittels Mikro-VMs basieren, anstatt sich ausschließlich auf herkömmliche Container zu stützen. Aus Sicht des Benutzers ähnelt der Arbeitsablauf weiterhin stark der Arbeit mit Docker, doch die Workload wird in einer eigenen virtualisierten Umgebung mit einem dedizierten Kernel ausgeführt. Ein Ausbruch aus dem Container führt daher nicht mehr unmittelbar zu einer Kompromittierung des Hosts.

In der Vergangenheit war ein solcher Isolationsgrad mit erheblichem betrieblichen Aufwand verbunden, doch moderne Lösungen wie Docker Sandboxes und Microsandbox haben die Einführung von Micro-VMs erheblich vereinfacht. Wichtig ist, dass es sich hierbei nicht um eine Entweder-oder-Entscheidung zwischen Containern und virtuellen Maschinen handelt. Docker-Sandboxes unterstützen beispielsweise OCI-konforme Container-Images, sodass Teams weiterhin ihre gewohnten Docker-basierten Arbeitsabläufe nutzen können und gleichzeitig von einer stärkeren Sicherheitsgrenze profitieren. Angesichts des relativ geringen Anstiegs der Komplexität und der zusätzlichen Sicherheit, die durch die hardwaregestützte Isolation geboten wird, werden Micro-VMs zunehmend zur Standardempfehlung für die Ausführung von KI-generiertem Code.

Cloud-Sandboxen

Cloud-Sandboxen verlagern die Ausführungsumgebung vollständig vom Rechner des Entwicklers weg. Anstatt Agenten lokal auszuführen, werden Workloads in isolierten, in der Cloud gehosteten Umgebungen ausgeführt, die bei Bedarf erstellt und nach Abschluss der Aufgabe wieder gelöscht werden. Spezialisierte kommerzielle Plattformen bieten verwaltete Umgebungen, in denen Agenten Code ausführen, Abhängigkeiten installieren und auf externe Ressourcen zugreifen können, ohne jemals mit der Workstation des Benutzers in Berührung zu kommen. Das Ergebnis ist eine klare Trennung zwischen dem Agenten und dem System, das Sie schützen möchten.

Es ist wichtig zu beachten, dass die Verbesserung durch Cloud-Sandboxen eher inkrementell als transformativ ist. Moderne, auf MicroVMs basierende Lösungen bieten bereits eine starke Isolationsgrenze, sodass der Hauptvorteil darin besteht, den Schadensumfang weiter zu verringern, falls etwas schiefgeht. Im Gegenzug nehmen Sie zusätzliche Kosten, Latenzzeiten und eine Abhängigkeit vom Anbieter in Kauf. Noch wichtiger ist, dass Cloud-Isolation eine mangelhafte Konfiguration nicht ausgleichen kann: Der Agent benötigt nach wie vor Anmeldedaten für alle Systeme, mit denen er interagiert, und übermäßig weitreichende Berechtigungen stellen weiterhin ein Risiko dar, unabhängig davon, wo der Agent ausgeführt wird. Cloud-Sandboxen bieten daher die stärkste Isolation in dieser Hierarchie, doch ihr Nutzen hängt letztendlich von denselben Grundprinzipien ab: dem Prinzip der geringsten Berechtigungen und einer sorgfältigen Zugriffsverwaltung.

Proxying von Anmeldedaten zur Verringerung der Sichtbarkeit

Die Sandboxing-Maßnahmen zielen vor allem auf dasselbe Problem ab: die Begrenzung des Schadens, den ein Agent anrichten kann, sobald er über Berechtigungen verfügt. Es gibt jedoch eine zweite Angriffsfläche, die durch Isolierung allein nicht gelöst werden kann. Wenn ein Agent eine Anmeldeinformation auslesen kann, ist es möglich, dass jeder, der das Verhalten des Agenten beeinflussen kann, ebenfalls an diese Anmeldeinformation gelangt. Anweisungen wie „API-Schlüssel niemals preisgeben“ sind nützliche Leitlinien, bleiben jedoch lediglich Verhaltensvorschriften. Der robustere Ansatz besteht darin, sicherzustellen, dass der Agent von vornherein niemals Zugriff auf das Geheimnis erhält.

Das „Credential Proxying“ tut genau das. Anstatt einen echten API-Schlüssel in die Sandbox einzufügen, enthält die Umgebung einen Platzhalter wie beispielsweise proxy-managed. Ausgehende Anfragen werden über einen vertrauenswürdigen Proxy geleitet, der außerhalb der Sandbox läuft; dieser identifiziert zugelassene Ziele und fügt die echten Anmeldedaten ein, bevor er die Anfrage weiterleitet. Lösungen wie Docker-Sandboxen unterstützen dieses Muster, indem sie Geheimnisse auf dem Host speichern, während sie den in der Sandbox ausgeführten Anwendungen normale Umgebungsvariablen bereitstellen. Der Agent interagiert weiterhin wie gewohnt mit SDKs und APIs, doch die zugrunde liegenden Anmeldedaten gelangen niemals in die Sandbox. Ein vollständig kompromittierter Agent kann lediglich den Platzhalterwert exfiltrieren, da er nie im Besitz des tatsächlichen Geheimnisses war.

Dies bietet eine starke und leicht verständliche Sicherheitseigenschaft: Durch Sandboxing wird eingeschränkt, was ein Agent tun kann, während durch die Weiterleitung von Anmeldedaten eingeschränkt wird, was er sehen kann. Das Muster lässt sich zudem über API-Schlüssel hinaus auf OAuth-Token, interne APIs und andere Formen von Maschinen-Anmeldedaten verallgemeinern. Grundsätzlich kann jeder Wert, der vor dem Agenten verborgen bleiben soll, an der Schnittstelle ersetzt und erst dann eingefügt werden, wenn er für eine genehmigte ausgehende Anfrage benötigt wird.

Wie jede Sicherheitsmaßnahme weist auch das Proxying von Anmeldedaten Einschränkungen auf. Erstens beruht es in der Regel auf dem Abfangen und Umschreiben von HTTP(S)-Datenverkehr, was zu Kompatibilitätsproblemen bei Anwendungen führen kann, die „Certificate Pinning“ durchführen oder Protokolle verwenden, die außerhalb des Sichtbereichs des Proxys liegen. Zweitens schützt es eher die Sichtbarkeit der Anmeldedaten als deren Funktionsumfang. Wenn ein Proxy im Auftrag des Agenten ein GitHub-Token einfügt, kann der Agent weiterhin jede Aktion ausführen, zu der dieses Token berechtigt ist. Übermäßige Berechtigungen stellen daher auch dann ein Risiko dar, wenn die Anmeldedaten selbst geschützt sind.

Die Proxy-Verwendung von Anmeldedaten und Zugriffskontrollen nach dem Prinzip der geringsten Berechtigungen sollten daher als sich ergänzende Kontrollmaßnahmen betrachtet werden. Der Proxy legt fest, welche Anmeldedaten der Agent einsehen kann, während die Eingrenzung der Anmeldedaten bestimmt, welche Aktionen der Agent mit diesen Anmeldedaten ausführen darf. Kurzlebige Tokens, eng begrenzte GitHub-Berechtigungen, dedizierte Cloud-IAM-Rollen und schreibgeschützter Datenbankzugriff sind auch in einer Proxy-Architektur nach wie vor von gleicher Bedeutung. Zusammen decken diese Kontrollmaßnahmen beide Aspekte des Problems ab: die Verringerung der Gefährdung vertraulicher Daten und die Einschränkung der Zugriffsrechte, falls diese Daten genutzt werden.

Wie sich die Schichten zusammensetzen

Die wichtigste Erkenntnis ist, dass stärkere Schichten die Aufgaben der schwächeren Schichten verändern. Wenn ein Agent innerhalb einer gut isolierten MicroVM mit Anmeldeinformationen-Proxying und bereichsgebundenen Anmeldeinformationen ausgeführt wird, hat eine Prompt-Injektion keinen direkten Zugriff mehr auf Ihre Workstation oder Ihre vertraulichen Daten. In dieser Umgebung sind agenteneigene Sicherheitsbarrieren nicht mehr die primäre Sicherheitsmaßnahme, sondern dienen vielmehr als Komfortfunktion, die versehentliche Fehler verhindert.

Genau aus diesem Grund funktioniert die mehrschichtige Verteidigung. Jede Schicht geht davon aus, dass die darunterliegenden Schichten irgendwann versagen werden, und begrenzt die Folgen, wenn dies geschieht. Sandboxing schränkt ein, worauf der Agent zugreifen kann, das Proxying von Anmeldedaten schränkt ein, was er sehen kann, Anmeldedaten mit geringsten Berechtigungen schränken ein, was er tun kann, und die Versionskontrolle stellt sicher, dass Änderungen überprüfbar und rückgängig machbar bleiben. Das Ergebnis ist nicht, dass Prompt-Injektionen oder Kompromittierungen der Lieferkette unmöglich werden, sondern dass sie deutlich weniger Schaden anrichten.

YOLO – aber verantwortungsbewusst

Das Ziel besteht nicht darin, jede nur denkbare Sicherheitsmaßnahme einzusetzen. Übermäßige Reibungsverluste führen zu Umgehungslösungen, und diese untergraben häufig genau die Sicherheit, die sie eigentlich gewährleisten sollten. Streben Sie stattdessen mehrschichtige Sicherheitsmaßnahmen an, die das Risiko sinnvoll verringern und gleichzeitig einen produktiven Arbeitsablauf gewährleisten.

Für die meisten Entwickler deckt eine Umgebung, die auf Docker-Sandboxes (oder einer ähnlichen MicroVM-Lösung), der standardmäßigen Weiterleitung von Anmeldedaten, Versionskontrolle und Anmeldedaten mit ordnungsgemäßem Zugriffsumfang basiert, bereits den Großteil der verfügbaren Sicherheitsvorteile ab. Beachten Sie, dass Versionskontrolle und Anmeldedaten mit minimalen Berechtigungen keine KI-spezifischen Kontrollmaßnahmen sind, sondern etablierte Praktiken der Softwareentwicklung, die auch im Zeitalter der Agenten nach wie vor von gleicher Bedeutung sind.

In diesem Beitrag ging es vor allem um die Prinzipien, die diesen Kontrollmechanismen zugrunde liegen. In der Praxis ist es jedoch besonders interessant zu sehen, wie diese Elemente in einem realen Arbeitsablauf zusammenwirken. In einem Folgebeitrag werde ich eine konkrete Umsetzung durchgehen: die Ausführung von Claude Code in einem Sandbox-Entwicklungscontainer, die Einschränkung des ausgehenden Zugriffs, die Konfiguration der Proxying-Funktion für Anmeldedaten sowie die Kombination dieser Ebenen zu einer Konfiguration, die es mir ermöglicht, Aufgaben mit deutlich größerer Zuversicht an autonome Agenten zu übertragen.