Schutzregeln konfigurieren

Diese Anleitung zeigt, wie du Schutzregeln konfigurierst: die Regeln, die entscheiden, ob die Aktion eines Agenten läuft, zuerst um Freigabe fragt oder abgelehnt wird.

Die Schutzregeln decken die dreizehn Effektklassen ab, die jedes verändernde Werkzeug deklariert. Durchgesetzt werden sie serverseitig an der Stelle, an der das Werkzeug aufgerufen wird, nie durch eine Anweisung im Prompt.

Eine Entscheidung für eine Aktionsklasse setzen

Öffne Einstellungen → Arbeitsbereich → Agent-Berechtigungen.
Wähle einen Geltungsbereich über die Segmentsteuerung: Arbeitsbereich, Agent (dann den Agenten) oder Bereich (dann den Bereich).
Wähle in der Zeile der Aktionsklasse Zulassen, Zuerst fragen oder Verweigern.
Um eine gesetzte Regel zu verwerfen, drücke die Zurücksetzen-Schaltfläche am Ende dieser Zeile (Auf geerbten Wert zurücksetzen) — die Entscheidung fällt auf den weiteren Geltungsbereich zurück.

Jede Zeile zeigt die wirksame Entscheidung als Status-Tag und ein Badge für die Herkunft: Dieser Bereich, Geerbt oder Standardwert. Die Matrix löst im Modus Agent (chat) auf, deshalb erscheint Modus-Voreinstellung hier nie — nimm die Prüfung „Was wäre wenn?“ mit einem ausgewählten Nur-Lese-Modus, um diese Schicht zu sehen.

Zum Schreiben einer Regel brauchst du die Rolle admin. Zum Lesen der Matrix nicht.

Kontrollpunkt: Setze Zu einem Remote pushen im Geltungsbereich Arbeitsbereich auf Verweigern und führe danach die Prüfung „Was wäre wenn?“ unten für git push origin main aus. Das Ergebnis lautet deny mit Herkunft workspace.

Wie eine Entscheidung aufgelöst wird

Die Auflösung geht zuerst nach Spezifität, dann nach Strenge:

Bereich, dann Agent, dann Arbeitsbereich. Der erste Geltungsbereich mit einer passenden Regel entscheidet, und die Auflösung endet dort.
Trifft keine Regel, gilt die Modus-Voreinstellung — ein Nur-Lese-Modus (Plan, Review, Orchestrate) verweigert elf der dreizehn Klassen.
Hat der Modus nichts zu sagen, gilt der Standardwert.

Innerhalb eines einzelnen Geltungsbereichs trifft eine Befehlsregel auf den längsten passenden Präfix, und ein gleich spezifischer Konflikt löst sich am strengsten auf — Verweigern schlägt Zuerst fragen, Zuerst fragen schlägt Zulassen. Eine Aktion, die mehrere Klassen deklariert, löst jede einzeln auf und verbindet sie dann auf die strengste Weise.

Eine Entscheidung Zuerst fragen zeigt eine Freigabeanfrage, die jede Klasse abdeckt, die auf prompt aufgelöst wurde. Ohne verbundene freigebende Person wird sie abgelehnt, für Shell-Befehle und für Werkzeugaufrufe des Harness. Das ist Absicht: Ein Lauf ohne Tor ist schlimmer als ein abgelehnter.

Aktionsklassen und eingebaute Standards

Aktionsklasse	Eingebauter Standard
Eine Datei löschen	Zuerst fragen
Außerhalb des Arbeitsbaums schreiben	Zulassen
Einen Commit erstellen	Zulassen
Zu einem Remote pushen	Zuerst fragen
Einen Pull Request öffnen	Zuerst fragen
Eine Review veröffentlichen oder mergen	Zuerst fragen
In einen externen Tracker schreiben	Zuerst fragen
Auf das Netzwerk zugreifen	Zulassen
Ein Geheimnis lesen	Zulassen
Ein Paket installieren	Zulassen
Einen Prozess ausführen	Zulassen
Arbeitsbereichsstruktur ändern	Zulassen
Eine Kapsel (Rig) steuern	Zulassen

Die Taxonomie ist geschlossen. Ein neues Werkzeug, das ohne deklarierte Klassen ausgeliefert wird, fällt in der CI durch einen Ratchet-Test, deshalb kommt nichts mit einer still leeren Effektmenge an.

Eine Regel mit der Prüfung „Was wäre wenn?“ testen

Bevor du eine Regel änderst, prüfe, wie die aktuelle Richtlinie sie schon auflöst.

Scrolle auf derselben Seite zu Was wäre wenn?.
Wähle eine Aktion (eine der dreizehn Klassen).
Fülle bei Bedarf Befehl (optional) aus (zum Beispiel git push origin main), dazu Agent (optional), Bereich (optional) und Modus.
Lies das Ergebnis: die Entscheidung, den Grund und Quelle:.

Die Prüfung läuft über dieselbe Auflösung wie der Durchsetzungspfad, gegen deine geltenden Regeln, deshalb ist die Antwort exakt. Überrascht sie dich, ändere eine Regel in der Matrix darüber und prüfe erneut.

Den Autonomieregler eines Bereichs setzen

Der Regler gilt je Agent und je Bereich und setzt sich mit den Regeln zusammen, statt sie zu ersetzen.

Öffne den Bereich.
Öffne Teilnehmer verwalten in der Kopfzeile des Bereichs.
Wähle unter Autonomie in der Zeile des Agenten eine Stufe:

Stufe	Wirkung
Standard	Keine Einstellung am Bereich — verhält sich wie Mit Genehmigung handeln
Nur vorschlagen	Jedes durch das Tor laufende Werkzeug wird rundweg abgelehnt, mit der Aufforderung, die Aktion stattdessen vorzuschlagen
Mit Genehmigung handeln	Riskante Aktionen treffen das Fail-closed-Freigabetor
Frei handeln	Gibt im Voraus alles frei, was nicht auf ein hartes deny aufgelöst wurde

Der Regler erreicht nur den eingebauten Harness. Der Adapter Claude Code führt seine eigenen Werkzeuge außerhalb dieses Tors aus.

Wo die Schutzregeln nicht hinreichen

Die Tabelle Wo Regeln durchgesetzt werden unten auf derselben Seite ist die Fassung in der App: je Effektklasse sagt sie, ob jeder Runner sie an der Richtlinienkontrolle fängt, sie der Sandbox überlässt oder sie gar nicht abfangen kann.

Der Adapter Claude Code ist an seinen eigenen Werkzeugaufrufen nur zum Teil durch ein Tor gebunden. Claude Code wird mit --dangerously-skip-permissions gestartet, deshalb laufen seine Aufrufe zum Lesen, Schreiben und Bearbeiten nie durch die Schutzregel. Seine Shell-Befehle erreichen sie über einen Hook, der die Befehlszeile einordnet, und seine Pushes laufen wie die jedes Agenten durch das Push-Gateway. Durch das Tor laufen außerdem die MCP-Werkzeugfläche, in die er zurückruft, und der Shell-Befehl, mit dem Control Center ihn startet.
Das eigene Ausgabe-Verb eines Modus (submit_plan, propose_orchestration) ist fest verankert und lässt sich nie verweigern — sonst wäre ein Modus strukturell unfähig, sein einziges Lieferergebnis zu erzeugen.
Ob die Sandbox diese Regeln unterfüttert, hängt vom Host ab. Wo cc_server ein Backend findet, umhüllt es die Claude-Code-CLI und das bash-Werkzeug des Harness, sodass eine Regel, die du nicht geschrieben hast, trotzdem eine Betriebssystem-Untergrenze unter sich hat. Unter Windows gibt es keine, und unter Linux oder WSL2 ohne bwrap und socat ebenfalls keine — dort sind die Schutzregeln plus die Werkzeugfläche des Modus die gesamte Durchsetzung, nicht eine zweite Linie davon. In welchem Fall du bist, siehst du unter Sandbox-Richtlinien konfigurieren.