Automatische Überprüfung

Die automatische Überprüfung ersetzt die manuelle Genehmigung an der Sandbox-Grenze durch einen separaten Prüfer-Agenten. Der Codex-Hauptagent wird weiterhin innerhalb derselben Sandbox ausgeführt, mit denselben Genehmigungsrichtlinien sowie denselben Netzwerk- und Dateisystembeschränkungen. Der Unterschied besteht darin, wer zulässige Eskalationsanfragen prüft.

Wenn Sie in der ChatGPT-Desktop-App ein genehmigtes Daybreak-Modell auswählen, wird die Berechtigungssteuerung automatisch auf Für mich genehmigen umgestellt, sofern dieser Modus für Ihr Konto verfügbar und gemäß den Organisationsrichtlinien zulässig ist. Dies gilt auch, wenn Sie den Befehl /model der Desktop-App verwenden. Wenn dieser Modus nicht verfügbar ist, bleibt der aktuelle Berechtigungsmodus unverändert. Die Modellauswahl setzt verwaltete Organisationsanforderungen niemals außer Kraft.

Bevor Sie Vollzugriff für ein genehmigtes Sicherheitsmodell aktivieren, zeigt die ChatGPT-Desktop-App eine modellspezifische Warnung vor gefährlichen Aktionen an. Die Warnung empfiehlt stattdessen Für mich genehmigen und verlinkt auf die Konfiguration der Prüfrichtlinie. Die Warnung stellt die Sandbox-Grenze nicht wieder her und setzt die Organisationsrichtlinie nicht außer Kraft.

Funktionsweise der automatischen Überprüfung

Auf hoher Ebene läuft der Vorgang wie folgt ab:

1. Der Hauptagent arbeitet innerhalb von read-only oder workspace-write.
2. Wenn er die Sandbox-Grenze überschreiten muss, fordert er eine Genehmigung an.
3. Wenn approvals_reviewer = "auto_review", leitet Codex diese Genehmigungsanfrage an einen separaten Prüfer-Agenten weiter, anstatt auf eine Person zu warten.
4. Der Prüfer entscheidet, ob die Aktion ausgeführt werden soll, und gibt eine Begründung zurück.
5. Wird die Aktion genehmigt, wird die Ausführung fortgesetzt. Wird sie abgelehnt, erhält der Hauptagent die Anweisung, einen wesentlich sichereren Weg zu finden oder anzuhalten und den Benutzer zu fragen.

Die automatische Überprüfung tauscht den Prüfer aus, sie erteilt keine Berechtigungen. Sie erweitert writable_roots nicht, aktiviert keinen Netzwerkzugriff und schwächt keine geschützten Pfade. Sie ändert lediglich, wie Codex mit Aktionen umgeht, die bereits eine Genehmigung erfordern.

Wann sie ausgelöst wird

Die automatische Überprüfung bewertet Genehmigungsanfragen, die andernfalls auf eine menschliche Entscheidung warten würden. Dazu gehören:

• Aufrufe von Shell- oder Ausführungswerkzeugen, die erweiterte Sandbox-Berechtigungen anfordern.
• Netzwerkanfragen, die von der aktuellen Sandbox oder Richtlinie blockiert werden.
• Dateiänderungen außerhalb der zulässigen beschreibbaren Stammverzeichnisse.
• Aufrufe von MCP- oder App-Werkzeugen, die aufgrund ihrer Werkzeugannotationen oder des konfigurierten Genehmigungsmodus eine Genehmigung erfordern.
• Computer Use-Zugriff auf eine neue Website oder Domain.

Die automatische Überprüfung wird nicht für Routineaktionen ausgeführt, die innerhalb der Sandbox bereits zulässig sind. Wenn ein Befehl unter dem aktiven sandbox_mode ausgeführt werden kann oder ein Werkzeugaufruf innerhalb der zulässigen Richtlinie bleibt, fährt der Hauptagent ohne Überprüfung fort.

Computer Use ist ein Sonderfall. App-Genehmigungen für Computer Use werden weiterhin direkt dem Benutzer angezeigt, daher ersetzt die automatische Überprüfung diese Aufforderungen auf App-Ebene nicht.

Was die automatische Überprüfung blockiert

Auf hoher Ebene ist die automatische Überprüfung dafür vorgesehen, Aktionen wie die folgenden zu blockieren:

• Senden privater Daten, Geheimnisse oder Anmeldedaten an nicht vertrauenswürdige Ziele
• Suchen nach Anmeldedaten, Token, Cookies oder Sitzungsmaterial
• weitreichende oder dauerhafte Schwächung der Sicherheit
• destruktive Aktionen mit einem erheblichen Risiko irreversibler Schäden

Die genaue Richtlinie befindet sich im Open-Source-Repository von Codex: policy_template.md und policy.md. Diese Richtlinie kann pro Unternehmen mit guardian_policy_config oder pro Benutzer mit einer lokalen [auto_review].policy angepasst werden.

Was der Prüfer sieht

Der Prüfer ist selbst ein Codex-Agent mit einer enger gefassten Aufgabe als der Hauptagent: Er entscheidet, ob eine bestimmte Aktion ausgeführt werden soll, die eine Grenze überschreitet.

Der Prüfer sieht ein kompaktes Transkript zusammen mit der genauen Genehmigungsanfrage. Dieses enthält normalerweise Benutzernachrichten, angezeigte Aktualisierungen des Assistenten, relevante Werkzeugaufrufe und Werkzeugausgaben sowie die Aktion, die nun zur Genehmigung vorgeschlagen wird. Er kann außerdem schreibgeschützte Prüfungen durchführen, um fehlenden Kontext zu erfassen, tut dies jedoch nur selten.

Verborgene Überlegungen des Assistenten sind nicht enthalten. Die automatische Überprüfung sieht gespeicherte Chat-Elemente und Werkzeugnachweise, keine privaten Gedankengänge.

Ablehnungen und Verhalten bei Fehlern

Eine ausdrückliche Ablehnung wird nicht wie ein gewöhnlicher Sandbox-Fehler behandelt. Codex gibt die Begründung der Prüfung an den Hauptagenten zurück und fügt eine nachdrücklichere Anweisung hinzu:

• Verfolgen Sie dasselbe Ziel nicht durch eine Umgehung, indirekte Ausführung oder Umgehung der Richtlinie weiter.
• Fahren Sie nur mit einer wesentlich sichereren Alternative fort.
• Halten Sie andernfalls an und fragen Sie den Benutzer.

Codex wendet außerdem pro Durchlauf einen Schutzschalter für Ablehnungen an. In der aktuellen Open-Source-Implementierung unterbricht die automatische Überprüfung den Durchlauf nach 3 aufeinanderfolgenden Ablehnungen oder 10 Ablehnungen innerhalb eines gleitenden Fensters der letzten 50 Überprüfungen im selben Durchlauf.

Jedes Ergebnis, das keine Ablehnung ist, setzt den Zähler für aufeinanderfolgende Ablehnungen zurück. Wenn der Schutzschalter auslöst, gibt Codex eine Warnung aus und bricht den aktuellen Durchlauf durch eine Unterbrechung ab, anstatt den Agenten weitere Eskalationsversuche in einer Schleife durchführen zu lassen.

Zeitüberschreitungen werden getrennt von ausdrücklichen Ablehnungen angezeigt, und der Hauptagent wird darüber informiert, dass eine Zeitüberschreitung allein kein Beweis dafür ist, dass die Aktion unsicher ist.

Für abgelehnte Aktionen gibt es außerdem einen ausdrücklichen Überschreibungspfad. Führen Sie in der aktuellen Open-Source-TUI /approve aus, um die Auswahl Ablehnungen der automatischen Überprüfung zu öffnen, und wählen Sie anschließend eine kürzlich abgelehnte Aktion aus, um sie für einen erneuten Versuch zu genehmigen. Codex speichert bis zu 10 kürzlich erfolgte Ablehnungen pro Aufgabe. Diese Genehmigung ist eng begrenzt: Sie gilt für die exakt abgelehnte Aktion, nicht für ähnliche zukünftige Aktionen; sie wird für einen erneuten Versuch im gleichen Kontext gespeichert; und der erneute Versuch durchläuft weiterhin die automatische Überprüfung. Intern fügt Codex für diese exakte Aktion eine Genehmigungsmarkierung mit Entwickler-Geltungsbereich ein. Der Prüfer sieht diese ausdrückliche Überschreibung durch den Benutzer anschließend als Kontext, folgt jedoch weiterhin der Richtlinie und kann die Aktion erneut ablehnen, wenn die Richtlinie vorsieht, dass der Benutzer diese Art von Ablehnung nicht überschreiben darf.

Konfiguration

Einzelheiten zur Einrichtung finden Sie unter Verwaltete Konfiguration.

Die standardmäßige Prüfrichtlinie befindet sich im Open-Source-Repository von Codex: core/src/guardian/policy.md. Unternehmen können den mandantenspezifischen Abschnitt durch guardian_policy_config in verwalteten Anforderungen ersetzen. Einzelne Benutzer können außerdem eine lokale [auto_review].policy in ihrer config.toml festlegen, verwaltete Anforderungen haben jedoch Vorrang:

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

Um die Richtlinie anzupassen, kopieren Sie zunächst den vollständigen Wortlaut der Standardrichtlinie und passen Sie ihn anschließend schrittweise an Ihr individuelles Risikoprofil an.

Einen autorisierten Cybersicherheitseinsatz konfigurieren

Kombinieren Sie für autorisierte Sicherheitsarbeiten die automatische Überprüfung mit einem schriftlich festgelegten Einsatzumfang und einem Berechtigungsprofil nach dem Prinzip der geringsten Rechte. Verwenden Sie ein genehmigtes Laborziel, dokumentieren Sie die Aktionen und das Einsatzzeitfenster und schließen Sie Produktionssysteme, nicht zugehörige Hosts, Anmeldedaten und dauerhafte Änderungen aus dem Umfang aus, sofern sie nicht ausdrücklich autorisiert wurden.

Sowohl [auto_review].policy als auch guardian_policy_config ersetzen Ihre aktuelle Prüfrichtlinie. Sie werden nicht mit Richtlinien zusammengeführt, die mit Ihrem Modell gebündelt sind oder von Ihrer Organisation verwaltet werden. Die integrierten Prüfanweisungen und das Antwortformat gelten weiterhin. Kopieren Sie vor der Verwendung eines der Beispiele die vollständige aktuelle Richtlinie, behalten Sie jede vorhandene Regel bei und fügen Sie die Regeln für Ihre genehmigten Arbeiten hinzu. Ersetzen Sie den großgeschriebenen Platzhalter durch diese vollständige Richtlinie. Wenn Sie nicht auf die aktuelle Richtlinie zugreifen können, überschreiben Sie sie nicht.

Die folgende lokale Vorlage für config.toml aktiviert die Überprüfung und fügt nach der vorhandenen Prüfrichtlinie bereichsspezifische Bedingungen hinzu:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"

[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
  and validate fixes within the documented engagement window.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
  engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
  persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
  approves the exact target, action, and side effects.
"""

Ersetzen Sie das Beispielziel und die zulässigen Aktionen durch den tatsächlich genehmigten Umfang. Setzen Sie Zielbeschränkungen mit unabhängigen Dateisystem- und Netzwerkregeln durch; Prüfanweisungen ersetzen diese Grenzen nicht.

Organisationen können dieselben Bedingungen in einer verwalteten requirements.toml durchsetzen:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"

guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only approved actions against the documented engagement target.
- Deny out-of-scope hosts, production access, credential theft, persistence,
  data exfiltration, destructive operations, and attempts to bypass policy.
- Deny ambiguous or high-impact actions until a human explicitly approves the
  exact target, action, and side effects.
"""

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

allowed_permission_profiles steuert die aktuellen Berechtigungsprofile. allowed_sandbox_modes verhindert außerdem den Vollzugriff in Bereitstellungen, die noch den veralteten sandbox_mode verwenden.

Die verwaltete Einstellung guardian_policy_config hat Vorrang vor der lokalen Einstellung [auto_review].policy eines Benutzers. Behalten Sie approval_policy = "on-request" oder eine andere geeignete interaktive Genehmigungsrichtlinie sowie eine durchsetzbare Sandbox-Grenze bei. Mit approval_policy = "never", :danger-full-access oder --yolo kann eine Aktion vermeiden, die für die Überprüfung erforderliche Genehmigungsanfrage zum Überschreiten der Grenze zu erzeugen.

Ein Netzwerkziel auf der Zulassungsliste löst nicht von sich aus eine Überprüfung aus. Fügen Sie explizite Befehlsregeln mit decision = "prompt" hinzu oder konfigurieren Sie vertrauliche MCP-Tools so, dass sie eine Genehmigung erfordern, wenn Aktionen innerhalb der Sandbox weiterhin dem Prüfer vorgelegt werden müssen.

Weitere Informationen finden Sie unter Modelle und Trusted Access sowie empfohlene Konfiguration zu Modellzugriff, Einrichtung von Einsätzen und benutzerdefinierten Agenten-Workflows. Informationen zu unternehmensweiten Prioritäten und unterstützten Client-Versionen finden Sie unter Verwaltete Konfiguration. Verwenden Sie für benutzerdefinierte API- oder Agents SDK-Harnesses Schutzmaßnahmen und menschliche Prüfung.

Prüfaufwand reduzieren, ohne die Sicherheit zu schwächen

Die automatische Überprüfung funktioniert am besten, wenn die Sandbox Ihre üblichen sicheren Arbeitsabläufe bereits abdeckt. Wenn zu viele alltägliche Aktionen eine Überprüfung erfordern, passen Sie zunächst die Grenze an, anstatt dem Prüfer dauerhaft beizubringen, unnötige Eskalationen zu genehmigen.

In der Praxis haben die folgenden Änderungen die größte Wirkung:

• Fügen Sie eng begrenzte writable_roots für temporäre Verzeichnisse oder benachbarte Repositorys hinzu, die Sie bewusst verwenden.
• Fügen Sie eng begrenzte Präfixregeln hinzu. Bevorzugen Sie präzise Befehlspräfixe wie ["cargo", "test"] oder ["pnpm", "run", "lint"] gegenüber weit gefassten Mustern wie ["python"] oder ["curl"]. Weit gefasste Regeln beseitigen häufig genau die Grenze, welche die automatische Überprüfung schützen soll.

Sitzungstranskripte der automatischen Überprüfung werden standardmäßig unter ~/.codex/sessions gespeichert. Daher können Sie Codex bitten, dort den bisherigen Datenverkehr zu analysieren, bevor Sie Richtlinien oder Berechtigungen ändern.

Einschränkungen

Die automatische Überprüfung verbessert den standardmäßigen Betriebsmodus für lang andauernde agentengestützte Aufgaben, ist jedoch keine deterministische Sicherheitsgarantie.

• Sie bewertet nur Aktionen, die das Überschreiten einer Grenze anfordern.
• Sie kann weiterhin Fehler machen, insbesondere in feindlichen oder ungewöhnlichen Kontexten.
• Sie sollte eine gute Sandbox-Gestaltung, Überwachung und organisationsspezifische Richtlinien ergänzen, nicht ersetzen.

Die wissenschaftliche Begründung und die veröffentlichten Bewertungsergebnisse finden Sie im Alignment Research-Beitrag zur automatischen Überprüfung.