Deinen Coding-Agenten absichern: die fünf Schichten und welche Tools tatsächlich etwas blockieren

Dein Coding-Agent liest Dateien, führt Befehle aus und installiert Dinge in deinem Namen. Die meisten beliebten „KI-Sicherheits“-Tools dafür geben nur Ratschläge. Hier steht, wie du die stapelst, die tatsächlich etwas aufhalten, und wo die Ratgeber hineinpassen.

Die Idee ist einfach. Alles, was innerhalb des Agenten läuft, lässt sich überreden, weil eine Prompt Injection das Modell davon abbringen kann. Entscheidungen, die halten müssen, leben daher außerhalb des Agenten: im Betriebssystem, in einem Hook oder in der CI. Die Sternzahlen unten wurden am 24. Oktober 2026 auf GitHub geprüft, und sie sagen wenig darüber, welche Tools irgendetwas durchsetzen: Der Audit-Skill von Cloudflare hat mit 14 Commits mehr Sterne als alle blockierenden Tools hier zusammen.

1. Eindämmen: festlegen, was der Agent erreichen kann

Wenn alles andere versagt, entscheidet eine Sandbox immer noch, welche Dateien der Agent lesen oder schreiben und mit welchen Hosts er sich verbinden kann.

• Anthropic Sandbox Runtime (4,4) ist die Engine hinter /sandbox in Claude Code. Sie nutzt die eigene Sandbox des Betriebssystems, braucht keinen Container und ist kostenlos. Sie erlaubt absichtlich Schreibzugriffe innerhalb deines Projekts und hält daher keinen Hard Reset auf.
• NVIDIA OpenShell (4,1) ist schwerer: eine Sandbox pro Agent, Zugangsdaten, die der Agent nie sieht, und Richtlinienänderungen, die vor dem Inkrafttreten geprüft werden. Es passt zu Agenten, die du unbeaufsichtigt laufen lässt.

Wähle eine pro Arbeitslast. Beide auf demselben Agenten laufen zu lassen gibt dir nur zwei Regelwerke zum Debuggen.

2. Bewachen: gefährliche Aktionen blockieren, bevor sie laufen

• CC Safety Net (4,0) verweigert Force-Pushes, Hard Resets, rm -rf auf gefährliche Ziele und das Lesen deiner Keys und lässt sich nicht täuschen, indem man den Befehl in bash -c verpackt. Es deckt die Lücke ab, die die Sandbox offen lässt.
• security-guidance (4,2), Anthropics Plugin für Claude Code, prüft jede Änderung, jede Runde und jeden Commit mit einem frischen Modellaufruf. Es berät und blockiert nie, behandle es also als Frühwarnung, nicht als Schloss.

3. Prüfen: den Agenten nach Bugs jagen lassen

Hier sind Agenten wirklich gut, solange nichts davon abhängt, dass sie alles finden.

• Trail of Bits Skills (4,4) verpackt die Audit-Methoden einer Sicherheitsfirma; die besten Skills steuern CodeQL und Semgrep, statt dem Urteil des Modells zu vertrauen.
• Cloudflare Security Audit Skill (3,9) lässt einen zweiten Agenten versuchen, jeden Befund zu widerlegen. Cloudflare sagt, ein Durchlauf finde etwa die Hälfte dessen, was wiederholte Durchläufe finden, lass ihn also mehr als einmal laufen.

4. Überprüfen: kontrollieren, was du installierst

Jeder Skill, jedes Plugin und jeder MCP-Server ist Code und Anweisung, denen dein Agent vertrauen wird. Das macht sie zu einer Lieferkette.

• Cisco Skill Scanner (3,7) scannt Skills, bevor dein Agent sie liest, und veröffentlicht seine eigenen Erkennungsraten, die bescheiden sind.
• Snyk Agent Scan (3,8) findet jeden MCP-Server und jeden Skill, der auf einem Rechner schon installiert ist. Es schickt Tool-Beschreibungen zur Analyse an Snyk.
• ToolHive (4,1) führt jeden MCP-Server in einem eigenen abgeriegelten Container aus, sodass ein schlechter weniger anrichten kann.

5. Absperren: die Prüfung, an die der Agent nicht herankommt

KI-geschriebener Code sollte vor demselben Merge-Gate stehen wie menschlicher Code. Ein Modell lässt sich von einem Befund abbringen; ein fehlgeschlagener CI-Job nicht.

• Semgrep (4,3) als verpflichtender Status-Check, mit seinem MCP-Server oder Guardian-Plugin, damit der Agent während der Arbeit dieselben Regeln sieht.
• Ergänze in der kostenlosen Stufe von Semgrep OSV-Scanner für verwundbare Abhängigkeiten und Gitleaks für geleakte Secrets. Beide sind kostenlos und Open Source.

Wenn du nur drei übernimmst

Schalte die eingebaute Sandbox ein, installiere das Plugin security-guidance und mach Semgrep zu einem verpflichtenden CI-Check. Das ist eines, das durchsetzt, eines, das früh warnt, und ein Gate, das der Agent nicht überspringen kann.

Der Haken: Sicherheitstools sind auch Tools. Hooks laufen jedes Mal mit deinen Berechtigungen, wenn der Agent handelt, Scanner schicken Daten an Anbieter, und Installer ziehen @latest. Ein bösartiger „Sicherheits“-Hook ist gefährlicher als ein bösartiger Skill, weil seine Aufgabe dafür sorgt, dass Menschen ihm vertrauen. Pinne Versionen, ziehe das eigene Repository des Anbieters Forks vor und probiere neue Hooks zuerst in einer Sandbox aus.

Was keines davon löst

• Prompt Injection. Nichts erkennt sie zuverlässig. Eindämmung kommt zuerst, weil das Beste, was du tun kannst, ist, den Schaden zu begrenzen.
• Abfluss an erlaubte Hosts. Eine Allowlist entscheidet, wohin sich der Agent verbinden kann, nicht, was er sendet. Wenn GitHub erlaubt ist, ist ein öffentlicher Gist erlaubt. Platziere einen falschen Key in einem Wegwerf-Repo und lass die CI fehlschlagen, wenn er je im ausgehenden Verkehr auftaucht.
• Autorisierungslogik. Ob Kunde A die Daten von Kunde B lesen kann, ist eine Frage, die Scanner selten beantworten und KI-Reviewer uneinheitlich. Lass bei Auth-Code einen Menschen draufschauen.
• Durchgewunkene Freigaben. Jemand, der am Tag Dutzende Agent-Änderungen per Klick freigibt, ist keine Kontrolle. Schick nur die riskanten an Menschen und gib ihnen Zeit.

Unser Fazit: Probleme finden kann innerhalb des Agenten stattfinden. Gefährliche Aktionen verhindern muss außerhalb davon stattfinden, und Code für die Produktion freizugeben gehört ganz aus der Coding-Sitzung heraus. Installiere die Sandbox vor dem Sicherheits-Skill.