Empfohlene Konfiguration

Welche Sicherheitskontrollen für einen Cybersicherheits-Workflow angemessen sind, hängt vom Modell, den möglichen Aktionen, den zugänglichen Systemen und der Vertraulichkeit der betroffenen Daten ab.

Für die meisten Daybreak Blue-Workflows können die bestehenden Sicherheitspraktiken Ihrer Organisation – etwa Zugriffskontrollen, der Schutz von Anmeldedaten und die Überprüfung sensibler Aktionen – ausreichend sein.

Daybreak Red-Workflows, autonome Sicherheitstests sowie Aktivitäten, die Produktionssysteme, sensible Daten oder externe Tools betreffen, können stärkere Schutzmaßnahmen erfordern. Die folgenden Empfehlungen richten sich vor allem an diese Szenarien mit höherem Risiko.

Trusted Access regelt den genehmigten Modellzugriff, konfiguriert jedoch weder Ihre Umgebung noch erzwingt es Beschränkungen für genehmigte Systeme und Aktionen. Ihr Team muss angemessene Kontrollen für Isolation, Berechtigungen, Überprüfung, Überwachung und menschliche Aufsicht einrichten. Gehen Sie davon aus, dass das Modell, seine Tools und jedes verbundene System kompromittiert werden könnten, und konfigurieren Sie die Umgebung so, dass sie dennoch nicht auf nicht autorisierte Systeme zugreifen, Anmeldedaten offenlegen, Schutzmaßnahmen deaktivieren oder nach Abschluss der Arbeit fortbestehen können.

Umgebung isolieren

Führen Sie offensive Sicherheitsarbeiten in einem dedizierten Labor oder einer Sandbox aus. Beginnen Sie ohne uneingeschränkten Internetzugriff sowie ohne Zugriff auf sensible Produktionssysteme, Unternehmensnetzwerke, nicht zugehörige Workloads oder Host-Verwaltungsschnittstellen. Halten Sie Geheimnisse, Anmeldedaten, dauerhaften Zugriff und beständige Systemänderungen außer Reichweite, sofern Ihre genehmigte Arbeit sie nicht ausdrücklich erfordert und autorisiert.

Verwenden Sie für Arbeiten mit höherem Risiko oder reduzierten Schutzmaßnahmen bei jedem Versuch eine neue, stark isolierte Umgebung. Trennen Sie Rechenressourcen, Speicher, Netzwerk und Identitäten voneinander und vernichten Sie die Umgebung anschließend, anstatt sie zurückzusetzen oder erneut zu verwenden.

Testen Sie vor Beginn risikoreicherer Arbeiten die Dateisystem- und Netzwerkgrenzen. Berücksichtigen Sie jeden erreichbaren Host, jedes verbundene Tool, jeden delegierten Agenten und jeden nachgelagerten Dienst. Halten Sie die Host-Umgebung auch dann isoliert, wenn das Modell oder die prüfende Person eine einzelne Aktion genehmigt.

Genehmigte Grenzen definieren und durchsetzen

Dokumentieren Sie vor dem Start des Modells die für Ihre Arbeit genehmigten Systeme, Tools, Aktionen und Zeitlimits. Berücksichtigen Sie dabei:

• Genehmigte Zielsysteme, Hosts und Umgebungen.
• Ausgeschlossene Systeme, einschließlich Produktionssystemen und nicht zugehöriger Infrastruktur.
• Genehmigte Tools und verbundene Dienste.
• Genehmigte und untersagte Aktionen.
• Genehmigte Start- und Endzeiten sowie Anforderungen an die Datenverarbeitung.
• Offenlegung von Sicherheitslücken, Genehmigung von Patches und Koordination mit den Verantwortlichen.
• Abbruchbedingungen und Aktionen, die eine ausdrückliche menschliche Genehmigung erfordern.

Stellen Sie dem Agenten diese genehmigten Grenzen als Aufgabenkontext bereit. Eine Dokumentation allein setzt sie nicht durch: Wenden Sie unabhängige Kontrollen für Dateisystem, Netzwerk, Identitäten und Tools an, um nicht autorisierte Aktionen nach Möglichkeit unmöglich zu machen.

Verwenden Sie Codex-Berechtigungsprofile, um eine Grenze nach dem Prinzip der geringsten Rechte zu schaffen. Wählen Sie :read-only, wenn die Aufgabe keine Änderungen erfordert, oder erweitern Sie :workspace, wenn Änderungen am Workspace erforderlich sind. Beispiel:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "cyber-lab"

[features]
network_proxy = true

[permissions.cyber-lab]
description = "Limit security testing to the approved lab and workspace."
extends = ":workspace"

[permissions.cyber-lab.filesystem]
glob_scan_max_depth = 3

[permissions.cyber-lab.filesystem.":workspace_roots"]
"**/.env*" = "deny"
"**/*.pem" = "deny"

[permissions.cyber-lab.network]
enabled = true
# Uncomment only for an approved host that resolves to a private address.
# allow_local_binding = true

[permissions.cyber-lab.network.domains]
"lab.example.com" = "allow"

Die Funktion network_proxy erzwingt die genehmigte Domain. Ohne sie ermöglicht network.enabled = true direkten Netzwerkzugriff, und die Zulassungsliste des Labors beschränkt die Ziele nicht. Websuche, Apps, Connectors, MCP-Server, Browseraktivitäten und die Codex-Cloud verwenden separate Kontrollen; beschränken oder deaktivieren Sie jede Oberfläche, die Ihr genehmigter Workflow nicht benötigt.

Ersetzen Sie lab.example.com durch ein genehmigtes Ziel. Der begrenzte Dateisystemscan ist so konzipiert, dass unter Linux, WSL und Windows nicht der gesamte Workspace durchsucht wird; erhöhen Sie die Tiefe oder verwenden Sie genaue Ablehnungspfade, wenn sensible Dateien tiefer liegen. Kombinieren Sie Berechtigungsprofile nicht mit veralteten sandbox_mode-Einstellungen; befolgen Sie die Anleitung zur Konfiguration von Berechtigungsprofilen.

Wenn der genehmigte Labor-Host in eine private Adresse aufgelöst wird, blockiert Codex ihn standardmäßig, selbst wenn der Host auf der Zulassungsliste steht. Legen Sie allow_local_binding = true nur für ausdrücklich genehmigte Arbeiten in privaten Netzwerken fest, halten Sie die Ziel-Zulassungsliste eng gefasst und lesen Sie die Anleitung zu lokalen und privaten Netzwerken. Sie können auch genau die genehmigte private IP-Adresse in die Zulassungsliste aufnehmen.

Blockieren Sie den Zugriff auf das offene Internet und Produktionsnetzwerke standardmäßig. Falls externer Zugriff erforderlich ist, leiten Sie ihn über ein unabhängig durchgesetztes Gateway oder einen Proxy mit eng gefassten Zulassungslisten, Anfrageprüfung und Protokollierung. Wenden Sie dieselben Einschränkungen auf indirekte Verbindungen über Paketmanager, Webhooks, Dienste zum Abrufen von URLs, Weiterleitungen, Cloud-APIs und verbundene Tools an. Laden Sie Abhängigkeiten vor der Ausführung oder verwenden Sie von einer administrierenden Person genehmigte Abhängigkeiten.

Anmeldedaten und sensible Daten schützen

Halten Sie wiederverwendbare API keys, Cloud-Anmeldedaten, Passwörter und Dienstkontotoken aus Prompts, Repositorys, Umgebungsvariablen, gemeinsam genutzten Dateisystemen und für das Modell zugänglichen Protokollen heraus. Wenn eine Authentifizierung erforderlich ist, verwenden Sie einen separaten Broker oder ein Gateway, um kurzlebige Anmeldedaten bereitzustellen, die genau auf das Ziel und die zulässige Aktion beschränkt sind, ohne die Anmeldedaten gegenüber dem Modell offenzulegen.

Stellen Sie nur die für die genehmigte Aufgabe erforderlichen Daten bereit. Entfernen Sie unnötige sensible Informationen, blockieren Sie den Zugriff auf Cloud-Metadaten und Endpunkte für Anmeldedaten und behandeln Sie vom Modell generierte Dateien als nicht vertrauenswürdig.

Vermeiden Sie :danger-full-access und --yolo bei Cybersicherheits-Workflows. Full Access entfernt die durchsetzbare Sandbox-Grenze, von der die automatische Überprüfung abhängt. Verwaltete Organisationen können :danger-full-access und --yolo ausschließen, zulässige Genehmigungsrichtlinien beschränken und über die unternehmensweit verwaltete Konfiguration eine automatische Überprüfung vorschreiben.

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

Schutzmechanismen ergänzen einen kontrollierten Cybersicherheits-Workflow um eine richtlinienbasierte Überprüfung. Sie ersetzen weder die Isolation der Umgebung noch Berechtigungen nach dem Prinzip der geringsten Rechte, klar definierte Grenzen, Überwachung oder menschliche Aufsicht.

Sensible Codex-Aktionen überprüfen

Auto-review leitet geeignete Genehmigungsanfragen an der Sandbox-Grenze an eine separate Prüfinstanz weiter, bevor die vorgeschlagene Aktion ausgeführt wird. Die Prüfinstanz berücksichtigt die vorgeschlagene Aktion, den begrenzten Aufgabenkontext und die geltende Richtlinie und lässt die Anfrage dann zu oder lehnt sie ab. Organisationen können diese Richtlinie an ihre genehmigten Ziele, untersagten Aktionen und Bedingungen für eine erforderliche menschliche Überprüfung anpassen.

Verlangen Sie eine ausdrückliche menschliche Genehmigung für Aktionen, die Produktionssysteme, externe Systeme, sensible Daten, Rechteausweitungen, dauerhaften Zugriff oder irreversible Änderungen betreffen. Behandeln Sie Anweisungen, die in Websites, Repositorys, Dokumenten und Tool-Ausgaben eingebettet sind, als nicht vertrauenswürdig; sie können den autorisierten Umfang nicht erweitern oder Zugriffskontrollen außer Kraft setzen.

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

Damit die automatische Überprüfung ausgeführt wird, müssen alle drei Kontrollen bestehen bleiben:

1. Verwenden Sie eine interaktive Genehmigungsrichtlinie wie approval_policy = "on-request".
2. Legen Sie approvals_reviewer = "auto_review" fest.
3. Behalten Sie eine durchsetzbare Sandbox- oder Berechtigungsprofilgrenze bei.

Anfragen an ein Ziel auf der Netzwerk-Zulassungsliste bleiben innerhalb der Netzwerkgrenze und lösen nicht automatisch Auto-review aus. Um einen sensiblen Befehl auch dann zu überprüfen, wenn sein Ziel auf der Zulassungsliste steht, erstellen Sie unter ~/.codex/rules/ eine ausdrückliche Befehlsregel:

prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "Review requests to the approved cybersecurity target.",
)

Starten Sie Codex nach dem Hinzufügen der Regel neu. Mit approvals_reviewer = "auto_review" werden übereinstimmende Befehle vor der Ausführung an die Prüfinstanz weitergeleitet. Fügen Sie für jeden sensiblen Befehl entsprechende Prompt-Regeln hinzu oder verwenden Sie approval_mode = "prompt" für einzelne MCP-Tools. Aktionen, die die Entscheidung einer Person erfordern, benötigen weiterhin eine ausdrückliche menschliche Genehmigung.

Auto-review prüft keine routinemäßigen Aktionen, die innerhalb der Sandbox bereits zulässig sind. Mit approval_policy = "never" oder Full Access erzeugt eine sensible Aktion möglicherweise keine überprüfbare Genehmigungsanfrage. Die automatische Überprüfung kann Fehler machen und ersetzt weder Isolation noch klar definierte Grenzen, Überwachung oder ausdrückliche menschliche Aufsicht.

Informationen zu einer begrenzten Richtlinie und ihrer organisationsweiten Durchsetzung finden Sie unter Einen autorisierten Cybersicherheits-Workflow konfigurieren.

Unabhängig überwachen und sicher abbrechen

Protokollieren Sie Modellanfragen, Tool-Aufrufe, Netzwerkaktivitäten, die Verwendung von Anmeldedaten und sicherheitsrelevante Änderungen. Bewahren Sie Protokolle und Überwachungssysteme außerhalb der vom Modell kontrollierten Umgebung auf. Richten Sie Warnungen für nicht autorisierte Ziele, unerwartete Netzwerkanfragen, offengelegte Anmeldedaten, Richtlinienänderungen, fehlende Protokolle und Versuche zur Umgehung von Schutzmaßnahmen ein.

Halten Sie die Durchsetzung von Richtlinien, Broker für Anmeldedaten, Prüfsysteme und Notabschaltkontrollen vom Agenten unabhängig. Beenden Sie den Workflow, wenn eine wesentliche Kontrolle oder ein Überwachungssystem ausfällt.

Benutzerdefinierte Agenten-Workflows um Schutzmechanismen ergänzen

Wenn Sie mit der Responses API, dem Agents SDK oder einem anderen Harness entwickeln, fügen Sie eine Überprüfung an der Grenze zur Tool-Ausführung hinzu. Prüfen Sie sensible vorgeschlagene Aktionen vor der Ausführung anhand der genehmigten Systeme, Aktionen und Zeitlimits, leiten Sie mehrdeutige oder risikoreiche Aktionen an eine Person weiter, erzwingen Sie unabhängige Dateisystem- und Netzwerkbeschränkungen, führen Sie Audit-Protokolle und brechen Sie sicher ab, wenn die Prüfinstanz oder Richtlinie nicht verfügbar ist.

Codex Auto-review schützt benutzerdefinierte Tools oder externe Harnesses nicht automatisch. Verwenden Sie Schutzmechanismen und menschliche Überprüfung für das Muster des Agents SDK und die Open-Source-Prüfrichtlinie als Referenz.

Die produktseitige Sandbox und Überprüfung von Codex sind von den API-Cybersicherheitsprüfungen getrennt. API-Schutzmaßnahmen können cyber_policy-Fehler zurückgeben, und benutzerspezifische safety_identifier-Werte können dazu beitragen, die Auswirkungen einer Schutzmaßnahme zu begrenzen.

Bereinigen und Ergebnisse validieren

Widerrufen Sie nach Abschluss der Arbeit temporäre Anmeldedaten, beenden Sie Hintergrundprozesse, entfernen Sie dauerhaften Zugriff und vernichten Sie Umgebungen mit höherem Risiko. Stellen Sie sicher, dass keine Callbacks, offengelegten Artefakte, gemeinsam genutzten Zustände oder ausführungsübergreifenden Zugriffe verbleiben, und halten Sie separate Benutzer, Sitzungen und Evaluierungen voneinander isoliert.

Validieren Sie Erkenntnisse, bevor Sie auf ihrer Grundlage handeln, befolgen Sie Verfahren zur koordinierten Offenlegung und sorgen Sie dafür, dass Personen für die Behebung und Änderungen verantwortlich bleiben.

Bevor Sie beginnen

Bestätigen Sie die genehmigten Systeme und Aktionen, das geeignete Modell, die isolierte Umgebung, Berechtigungen nach dem Prinzip der geringsten Rechte, eingeschränkten Netzwerkzugriff, geschützte Anmeldedaten, die Überprüfung von Aktionen, unabhängige Überwachung, Notabschaltung und den Bereinigungsplan. Modellschutzmaßnahmen, Isolation, begrenzte Berechtigungen, Überprüfung von Aktionen, Überwachung und menschliche Aufsicht ergänzen einander; keine davon sollte die einzige Kontrolle darstellen.