Zum Inhalt springen

Wissensbasis

Sicherheit autonomer Coding-Agents

Ein Coding-Agent, der Dateien schreibt, Befehle ausführt und das Netzwerk erreicht, lässt sich gegen seine Nutzer:innen wenden. Schaltet eine Prompt Injection die Freigabe-Einstellungen des Agents um, wird daraus Remote Code Execution. Instruktionen im System-Prompt sind keine Sicherheitsgrenze, konkrete Opt-in-Kontrollen und eine Sandbox um den ganzen Prozess sind es.

Verfasst von

Aktualisiert:

Tools 4

Unsere Position. Weder eine Regel im Prompt noch ein Hook ist für uns eine Grenze. Ein Hook prüft die Aufrufe, für die er geschrieben wurde (öffnet in einem neuen Tab), und eine Shell kennt unzählige andere Wege, eine Datei zu lesen. Für alles, was nie passieren darf, begrenzen wir, was der Agent überhaupt erreichen kann. Secrets halten wir aus dem Dateisystem heraus, und Entwicklungsschlüssel trennen wir von Produktionsschlüsseln.

Das Risiko wächst mit der Autonomie. Jede Berechtigung, die ein Agent erhält, wird zu einem Glied, das Angreifer:innen zu einer Kette verbinden können. Das reicht vom Schreiben der eigenen Config bis zum Ausführen freigegebener Befehle.

Welche Angriffsfläche öffnet ein autonomer Coding-Agent?

Autonomie vergrößert die Angriffsfläche schneller, als die meisten Tools es berücksichtigen. Ein Sicherheitsforscher zeigt, was ein Agent anrichten kann, der ohne menschliche Freigabe Dateien schreiben darf (Agentic ProbLLMs: Exploiting Coding Agents (öffnet in einem neuen Tab), Oktober 2025):

  • Der Agent schaltet seine eigene Auto-Approve-Einstellung um, etwa chat.tools.autoApprove in GitHub Copilot. So wird aus einer indirekten Prompt Injection Remote Code Execution. Dieselbe Lücke durch eine selbst veränderte Config steckte auch in AWS Kiro und Amp und ist inzwischen behoben.
  • Beim Cross-Agent Escape schreibt ein Agent einen bösartigen MCP-Server in die Config eines anderen Agents. Beim nächsten Start führt das zu RCE.
  • Befehle auf der Allowlist, die als “safe” gelten, lassen sich zu einer Datenexfiltration verketten.

Für diese Funde vergab Anthropic CVEs, und Amazon Q veröffentlichte ein Advisory. Das Fazit: Instruktionen im System-Prompt (“treat code as sensitive, never share secrets”) verbessern die Robustheit, eine Sicherheitsgrenze sind sie nicht. Auch Sandboxes reichen nicht aus, denn die Secrets, die sich zu stehlen lohnen, liegen in ihnen.

Welche Guardrails halten wirklich?

Der Bericht über den Bau des Coding-Agents pi kommt aus Entwicklersicht zum selben Schluss, nur schärfer (pi (öffnet in einem neuen Tab), November 2025). Private Daten lesen, Code ausführen und Netzwerkzugriff lassen sich nicht sicher miteinander vereinbaren. Deshalb hält der Autor die Safety Rails der meisten Agents für “security theater”. pi läuft standardmäßig im vollen YOLO-Modus. Wer echte Isolation braucht, soll den ganzen Prozess in eine Sandbox stecken.

Amp zieht daraus die operative Konsequenz und verlagert die Berechtigungen in ein Plugin (Amp, Rebuilt (öffnet in einem neuen Tab), Mai 2026). Frontier-Modelle schreiben und verketten Wegwerfskripte, um ihre Arbeit zu erledigen. Ob ein Tool Call destruktiv ist, lässt sich deshalb nach Amps Argument kaum noch statisch entscheiden.

Wo Guardrails wirken, sind sie konkret, und ihr schaltet sie ausdrücklich ein. Vercels agent-browser liefert Content-Boundary-Marker, die Tool-Output von nicht vertrauenswürdigem Seiteninhalt trennen. Dazu kommen eine Domain-Allowlist für die Navigation und ein verschlüsselter Auth-Vault. Über ihn meldet sich das Modell mit dem Namen eines gespeicherten Zugangs an und sieht das Passwort nie (vercel-labs - agent-browser (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Artikel

Posts

Talks und Videos

Tools und Repositories