Berechtigungen von KI-Coding-Agents und YOLO-Modus: ein sichereres Setup

Berechtigungsmodi in drei Tools

Jeder KI-Coding-Agent wägt zwei Dinge gegeneinander ab: wie oft er Sie unterbricht und wie viel er ohne Nachfrage tun darf. Die Einstellungen heißen in jedem Tool anders, folgen aber demselben Muster: ein Modus, der fragt, ein Modus, der einen automatischen Prüfer entscheiden lässt, und ein Modus, der alles überspringt, umgangssprachlich YOLO-Modus genannt.

Was Modi ohne Freigaben wirklich überspringen

Modi, die alles überspringen, entfernen mehr als nur die Abfragen. In Codex entfernt das Flag sowohl die Freigaben als auch die Sandbox. Cursor beschreibt Run Everything so, dass jeder Tool-Aufruf automatisch ausgeführt wird, ohne Sandbox und ohne Prüfer. Der Bypass-Modus von Claude Code überspringt außerdem die Abfragen für Schreibzugriffe auf das eigene Verzeichnis .claude und auf .git.

Die Hersteller sind sich einig, wohin diese Modi gehören: Claude Code empfiehlt den Bypass-Modus nur in isolierten Umgebungen wie Containern oder VMs, und Codex kennzeichnet sein Flag als erhöhtes Risiko und nicht empfohlen. Selbst in einem Container ist alles, was hineingemountet wird, etwa Cloud-Zugangsdaten oder ein SSH-Agent, frei zugänglich. Der Leitfaden dazu, worauf Agents zugreifen können listet auf, was das üblicherweise umfasst.

Was ein Repository ändern kann

Agent-Konfiguration liegt zunehmend im Repository, direkt neben dem Code: Einstellungen in .claude/, .codex/config.toml, .cursor/mcp.json, Hook-Definitionen und Anweisungsdateien wie AGENTS.md und CLAUDE.md. Für Teams ist das praktisch, und es bedeutet, dass ein git clone das Verhalten eines Agents verändern kann.

• Vertrauensabfragen helfen. Codex lädt die .codex/-Ebene eines Projekts erst, nachdem Sie dem Projekt vertraut haben. Claude Code wendet die allow-Regeln eines Repositorys erst an, nachdem jedes Teammitglied dem Ordner vertraut hat, und ignoriert bypassPermissions als Standardmodus in Projekteinstellungen.
• Nicht alles ist gleich abgesichert. Hooks, MCP-Server-Definitionen und Anweisungsdateien kommen weiterhin mit dem Repository; MCP-Server haben eine eigene Freigabeabfrage, und Workspace Trust ist in Cursor deaktiviert, solange Sie es nicht einschalten.
• Ältere Versionen verhalten sich anders. Eine Einstellung, die aktuelle Releases ignorieren, wird von einem älteren Client auf dem Rechner eines Kollegen womöglich noch beachtet, und schon ihr Vorhandensein zeigt, dass das Projekt erwartet, dass Agents unbeaufsichtigt laufen.

Agent-Einstellungen, die nicht committet werden sollten

Diese Muster sollten Sie im Review abfangen, bevor sie den Hauptbranch erreichen:

• Deaktivierte Freigaben: bypassPermissions als Standardmodus, ein Subagent mit permissionMode: bypassPermissions oder ein Paket-Skript, das einen Agent mit --dangerously-skip-permissions oder --dangerously-bypass-approvals-and-sandbox startet.
• Allow-Regeln, die alles vorab freigeben: Bash(*) oder Wildcards auf Shells, Interpreter, Package Runner und Netzwerk-Tools wie Bash(curl:*) oder Bash(npx:*).
• Hooks, die ein Skript herunterladen und ausführen, zum Beispiel curl per Pipe an eine Shell.
• Nicht gepinnte MCP-Server, die über ein Remote-Skript gestartet, über unverschlüsseltes HTTP angesprochen oder mit fest eingetragenen Zugangsdaten konfiguriert werden.
• Versteckter Text in Anweisungsdateien: HTML-Kommentare oder unsichtbares Unicode in AGENTS.md oder CLAUDE.md, die ein Reviewer nicht sieht, der Agent aber liest.

{  "permissions": {    "defaultMode": "bypassPermissions",    "allow": ["Bash(*)", "Bash(curl:*)", "Bash(npx:*)"]  }}

Eine sicherere Grundkonfiguration

1. Behalten Sie auf Laptops den Standard- oder Auto-Modus bei; Modi ohne Freigaben gehören in Wegwerf-Umgebungen.
2. Committen Sie enge Allow-Regeln für genau die Befehle, die Ihr Projekt ausführt, und verbieten Sie Lesezugriffe auf Secrets.
3. Pinnen Sie die Versionen von MCP-Servern und halten Sie deren Zugangsdaten in Umgebungsvariablen, nicht in der Datei.
4. Schalten Sie die Sandbox ein, wo sie optional ist, und beschränken Sie Netzwerkzugriff auf eine Allowlist.
5. Behandeln Sie Änderungen an Agent-Konfiguration und Anweisungsdateien im Review als sicherheitsrelevant.

{  "permissions": {    "allow": ["Bash(npm run test:*)", "Bash(npm run lint)"],    "deny": ["Read(./.env)", "Read(./secrets/**)"]  }}

Allow-Regeln mit einer Wildcard am Ende sind nur so sicher wie der Befehl davor: Eine Regel für npm run test ist eng, eine Regel für node oder curl nicht.

Wo vetkit ins Spiel kommt

Das Repository-Audit von vetkit prüft committete Agent-Konfiguration als Teil seiner Suite für KI-Code-Risiken: Einstellungen und Flags zum Umgehen von Freigaben, Allow-Regeln, die beliebige Shell- oder Netzwerkbefehle vorab freigeben, Hooks, die Remote-Skripte ausführen, nicht gepinnte oder aus der Ferne gestartete MCP-Server, MCP-Server über unverschlüsseltes HTTP oder mit fest eingetragenen Zugangsdaten sowie versteckte Kommentare oder Unicode in Anweisungsdateien für Agents. Dieselben Regeln nutzen auch der @vetkit/mcp-Server und Agent Watch, das meldet, was Agents auf Team-Rechnern tatsächlich tun; der Leitfaden zum Monitoring behandelt diese Seite.

Quellen

Die Aussagen zu jedem Tool haben wir am 10. November 2026 aus dessen eigener Dokumentation entnommen:

• Claude Code: Berechtigungen, Einstellungen und Sicherheit
• OpenAI Codex: Agent-Freigaben und Sicherheit und Grundlagen der Konfiguration
• Cursor: Ausführungsmodi und Agent-Sicherheit

Produktnamen sind Marken ihrer jeweiligen Inhaber. vetkit ist mit ihnen weder verbunden noch wird es von ihnen unterstützt oder gesponsert. Etwas veraltet? Schreiben Sie an contact@vetkit.dev, und wir korrigieren es.