Codex-Sicherheitsleitfaden

Verwenden Sie diese Anleitung, wenn sich Mitarbeiter über den ChatGPT-Workspace Ihres Unternehmens bei Codex anmelden sollen und persönliche ChatGPT-Konten sowie die Authentifizierung mit API key auf verwalteten Endgeräten untersagt sind.

Angestrebtes Ergebnis

Auf unternehmensverwalteten Geräten akzeptiert Codex ausschließlich die ChatGPT-Anmeldung beim ChatGPT-Workspace des Unternehmens.

Voraussetzungen

• Die UUID des genehmigten ChatGPT Enterprise-Workspace.

• Eine Möglichkeit, die verwaltete Codex-Konfiguration auf Endgeräten zu verteilen.

• Eine Entscheidung, die Authentifizierung mit API key auf verwalteten Endgeräten zu untersagen.

Konfigurieren

1. Dokumentieren Sie die UUID des genehmigten Workspace in Ihrem internen Konfigurations-Repository.

2. Fügen Sie der lokalen requirements.toml erzwungene Authentifizierungsanforderungen hinzu:

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

Der erste Schlüssel erlaubt nur die ChatGPT-Authentifizierung; der zweite beschränkt die Anmeldung auf den genehmigten Workspace. Ersetzen Sie die Beispiel-UUID durch die UUID Ihres Workspace. Siehe die Anforderungsreferenz.

3. Stellen Sie die Anforderungen über die lokale requirements.toml oder macOS MDM bereit und verwenden Sie dabei die Pfade unter Wo die Konfiguration hingehört. Diese Authentifizierungsanforderungen gelten, bevor Zugangsdaten geladen und Cloud-Richtlinien abgerufen werden; Codex ignoriert sie in über die Cloud verwalteten Anforderungen. Schützen Sie die Datei und ihr übergeordnetes Verzeichnis vor Änderungen durch Benutzer. Veraltete managed_config.toml-Standardwerte setzen diese Einschränkung nicht durch.

4. Melden Sie Benutzer während der Pilotphase ab oder entfernen Sie zuvor gespeicherte persönliche Codex-Sitzungen. Gehen Sie nicht davon aus, dass eine neue Richtlinie eine bestehende Sitzung nachträglich ungültig macht.

5. Kombinieren Sie die Anmeldebeschränkung mit Workspace-Rollen und Gruppenzugriff. Die Authentifizierung bestimmt, welche Identität sich anmeldet; RBAC bestimmt, welche Codex-Funktionen diese Identität verwenden darf. Siehe Authentifizierung.

Überprüfen

• Melden Sie sich von Codex ab.

• Versuchen Sie, sich mit einem persönlichen ChatGPT-Konto anzumelden. Erwartet: Die Anmeldung beim persönlichen Workspace wird abgelehnt.

• Versuchen Sie die Codex-Anmeldung mit API key. Erwartet: Die Anmeldung mit API key wird abgelehnt.

• Melden Sie sich mit dem Unternehmenskonto beim genehmigten Workspace an. Erwartet: Die Anmeldung ist erfolgreich.

• Starten Sie die Desktop-App, die CLI und die IDE-Erweiterung neu und wiederholen Sie die Prüfung.

Zurücksetzen

Stellen Sie die vorherigen lokalen Authentifizierungsanforderungen wieder her und stellen Sie das geprüfte Paket erneut bereit.

Grenzen

Diese Kontrolle gilt für verwaltete Codex-Clients auf verwalteten Endgeräten. Kombinieren Sie sie mit Anwendungskontrollen auf Endgeräten und Netzwerkrichtlinien, wenn die Anforderung lautet: „Keine persönliche Codex-Nutzung mit Unternehmensressourcen“.

Verwenden Sie diese Anleitung, wenn Entwickler schreibgeschützten oder auf den Workspace beschränkten Zugriff benötigen und Sie verhindern möchten, dass sie Full Access auswählen oder Genehmigungen und Sandboxing mit --yolo umgehen.

Angestrebtes Ergebnis

Benutzer können nur genehmigte schreibgeschützte oder auf den Workspace beschränkte Profile auswählen. Sie können danger-full-access, approval_policy = "never" oder --yolo nicht auswählen.

Konfigurieren

1. Definieren Sie ein genehmigtes Workspace-Profil:

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Erzwingen Sie die zulässigen Profile und Genehmigungsrichtlinien:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

Die Positivliste ist vollständig: Profile, die nicht darin enthalten oder auf false gesetzt sind, werden abgelehnt. Dies gilt auch für Profile, die in zukünftigen Versionen hinzukommen. Siehe die Konfigurationsreferenz.

3. Verwenden Sie für ältere Clients, die noch sandbox_mode nutzen, Folgendes:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Stellen Sie dies als administrativ erzwungene Anforderungen bereit, nicht als eine vom Benutzer bearbeitbare Konfigurationsdatei.

5. Wenn Sie später Auto-review zulassen, fügen Sie es nach entsprechenden Tests bewusst hinzu. Auto-review ändert, wer eine Grenzüberschreitung prüft; eine entfernte Grenze wird dadurch nicht wiederhergestellt. Siehe Auto-review.

Überprüfen

• Öffnen Sie die Berechtigungsauswahl. Erwartet: Full Access ist nicht verfügbar oder wird abgelehnt.

• Starten Sie mit --dangerously-bypass-approvals-and-sandbox. Erwartet: Codex lehnt den Start ab oder erzwingt ein kompatibles Profil.

• Starten Sie mit --sandbox danger-full-access --ask-for-approval never. Erwartet: Der Start wird abgelehnt.

• Führen Sie eine normale Workspace-Aufgabe aus. Erwartet: Die Aufgabe ist erfolgreich; Grenzüberschreitungen erfordern weiterhin eine Genehmigung.

Zurücksetzen

Stellen Sie das vorherige Anforderungspaket wieder her. Lassen Sie uneingeschränkten Zugriff gesperrt, sofern keine gesondert genehmigte Ausnahme vorliegt.

Grenzen

Dies steuert die Laufzeitberechtigungen von Codex. Ein privilegiertes Betriebssystemkonto verliert dadurch seine Privilegien nicht.

Verwenden Sie diese Anleitung, wenn Ihr Unternehmen festlegen muss, welche MCP-Server Codex verwenden darf, und eine Liste genehmigter Server durchsetzen möchte.

Das Zulassen und das Konfigurieren eines Servers sind getrennte Schritte. Ein Eintrag in der Positivliste erlaubt einen passenden Server; er erstellt keine Serverkonfiguration. Konfigurieren Sie den Server separat mit dem passenden Namen und der passenden Identität sowie der erforderlichen Authentifizierung.

Angestrebtes Ergebnis

Codex aktiviert nur MCP-Server, deren konfigurierter Name und Identität mit der vom Unternehmen genehmigten Liste übereinstimmen.

Konfigurieren

1. Erfassen Sie für jeden genehmigten Server: Verantwortliche, Zweck, Transport, genaue ausführbare Datei oder URL, Authentifizierung, Datenklassifizierung und Tools mit Schreibzugriff.

2. Beginnen Sie mit einer vollständigen Sperre. Eine leere verwaltete Tabelle deaktiviert alle MCP-Server:

   [mcp_servers]

3. Fügen Sie genehmigte HTTP-Server anhand ihrer exakten URL hinzu:

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Fügen Sie genehmigte stdio-Server anhand ihrer ausführbaren Datei und Positionsargumente hinzu:

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

Der strukturierte Abgleich prüft die ausführbare Datei, die Anzahl der Argumente und deren Reihenfolge. Er schränkt cwd, env oder env_vars nicht ein. Setzen Sie die Kontrolle über den vollständigen Startkontext als Voraussetzung für die Genehmigung eines stdio-Servers voraus: Schützen Sie seine ausführbare Datei und Abhängigkeiten und verhindern Sie, dass nicht vertrauenswürdige Benutzer- oder Projektkonfigurationen ein Arbeitsverzeichnis oder eine Umgebung vorgeben, die sein Verhalten ändern können. Wenn Sie diese Grenze nicht unabhängig durchsetzen können, lassen Sie den stdio-Server ungenehmigt und verwenden Sie stattdessen einen geprüften HTTP-Server.

5. Fügen Sie mit Plugins gebündelte MCP-Identitäten separat unter plugins.<plugin>.mcp_servers.<server> hinzu.

6. Speichern Sie die genehmigte Liste in einem geprüften Konfigurations-Repository und stellen Sie sie über administrativ erzwungene Anforderungen bereit.

Der Client aktiviert einen Server nur, wenn sowohl sein Name als auch seine Identität mit einem genehmigten Eintrag übereinstimmen. Siehe Verwaltete Konfiguration.

Überprüfen

• Konfigurieren Sie den genehmigten Server exakt wie vorgegeben. Erwartet: Der Server startet.

• Ändern Sie ein Zeichen der URL. Erwartet: Der Server wird deaktiviert.

• Ändern Sie die Anzahl oder Reihenfolge der stdio-Argumente oder geben Sie ein Argument an, das außerhalb der konfigurierten Argumentregeln liegt. Erwartet: Der Server wird deaktiviert. Werte, die weiterhin einem zulässigen Präfix entsprechen, bleiben erlaubt.

• Testen Sie in einem entbehrlichen, vertrauenswürdigen Projekt harmlose Überschreibungen von cwd, env und env_vars und behalten Sie dabei die passende ausführbare Datei und die passenden Argumente bei. Der Identitätsabgleich allein lehnt diese Überschreibungen nicht ab. Überprüfen Sie, ob Ihre unabhängige Kontrolle des Startkontexts unsichere Überschreibungen ablehnt oder der stdio-Server ungenehmigt bleibt; verwenden Sie keine echte Injection-Payload.

• Fügen Sie einen nicht genehmigten Namen hinzu. Erwartet: Der Server wird deaktiviert.

• Testen Sie einen mit einem Plugin gebündelten Server. Erwartet: Der Server funktioniert nur mit der genehmigten Identität.

Zurücksetzen

Entfernen Sie den neu hinzugefügten Eintrag. Um die gesamte MCP-Nutzung sofort zu unterbinden, stellen Sie eine leere mcp_servers-Tabelle bereit.

Grenzen

Eine Identitätspositivliste belegt nicht, dass die Tools, vorgelagerten Daten, Zugangsdaten oder die Startumgebung eines Servers sicher sind. Lokale stdio-MCP-Prozesse laufen außerhalb der lokalen Befehlssandbox; die Übereinstimmung einer ausführbaren Datei und ihrer Argumente schränkt den Zugriff des Servers nicht ein und verhindert kein umgebungsbasiertes Laden von Code. Prüfen Sie den vollständigen Startkontext und die Serverberechtigungen unabhängig davon. Siehe MCP-Identitätsanforderungen.

Verwenden Sie diese Anleitung, wenn Ihr Sicherheitsteam nachvollziehen muss, was Codex auf Endgeräten und in Ihrem Netzwerk tut. Sie führt Ausführungs- und Tool-Ereignisse, Genehmigungsentscheidungen, Workspace-Auditdatensätze und Netzwerkprotokolle für Untersuchungen zusammen.

Angestrebtes Ergebnis

Sicherheitsteams können Codex-Ausführungen, Tool-Entscheidungen, Genehmigungen, Workspace-Auditdatensätze und tatsächlichen ausgehenden Netzwerkverkehr miteinander korrelieren, ohne sich auf die Darstellung des Modells selbst zu verlassen.

Vier Nachweisquellen verwenden

1. Codex OpenTelemetry: Ereignisse zu Ausführungen, API, Modell, Sandbox, Genehmigungen und Tools.

2. Verwaltete Lebenszyklus-Hooks: Aufzeichnungen auf Endgeräten rund um Tool-Nutzung und Berechtigungsanfragen.

3. Netzwerkproxy- oder Gateway-Protokolle: tatsächliche DNS/HTTP-Ziele und Verbindungsergebnisse.

4. Compliance API: Audit- und Untersuchungsdatensätze auf Workspace-Ebene.

Keine einzelne Quelle bietet eine vollständige Netzwerküberwachung.

Konfigurieren

1. Senden Sie Codex-OpenTelemetry-Protokolle mit geschwärzten Roh-Prompts an Ihren Collector:

   [otel]
   environment = "enterprise"
   log_user_prompt = false

   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

Stellen Sie dem Codex-Prozess OTLP_TOKEN vor dem Start des Clients über Ihre genehmigte Geheimnisverwaltung oder die Prozessumgebung bereit. Halten Sie das Token aus bereitgestellten TOML-Dateien und der Quellcodeverwaltung heraus.

Codex kann Gesprächsstarts, API-Anfragen, Streaming-Ereignisse, Prompt-Metadaten, Tool-Entscheidungen und Tool-Ergebnisse ausgeben. Siehe Erweiterte Konfiguration.

2. Stellen Sie OTel außerhalb der projektlokalen Konfiguration bereit. .codex/config.toml-Dateien eines Projekts können das Telemetrie-Routing nicht überschreiben.

3. Fügen Sie verwaltete Lebenszyklus-Hooks für SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop und SessionEnd hinzu.

4. Installieren Sie Hook-Skripte in einem administrativ verwalteten Verzeichnis und setzen Sie allow_managed_hooks_only = true, wenn Benutzer-, Projekt- und Plugin-Hooks ignoriert werden sollen.

5. Leiten Sie den Datenverkehr von Befehlen in der Sandbox über einen unabhängig protokollierenden Proxy. OTel zeichnet auf, dass ein Tool ausgeführt wurde; der Proxy zeichnet auf, wohin der Unterprozess eine Verbindung herstellen wollte.

6. Konfigurieren Sie separate Telemetrie für Websuche, Apps, Konnektoren, MCP-Server, Browseraktivitäten und Codex Cloud. Lokale Befehlsproxy-Regeln decken diese nicht automatisch ab.

7. Übertragen Sie unterstützte Compliance API-Datensätze kontinuierlich in das SIEM und wenden Sie Ihre eigenen Aufbewahrungsregeln und Vorgaben zur rechtlichen Aufbewahrung an. Siehe Compliance API und Audit-Ereignisse.

8. Korrelieren Sie Benutzer- oder Dienstkonto, Host oder Runner, Gesprächs-ID, Modell, Client-Version, Berechtigungsprofil, Genehmigungsentscheidung, Ziel und Tool-Name.

Überprüfen

Führen Sie eine kontrollierte Sitzung mit folgenden Schritten durch:

• Eine erlaubte Datei lesen.

• Einen blockierten Dateizugriff versuchen.

• Einen erlaubten Befehl ausführen.

• Eine blockierte ausgehende Anfrage versuchen.

• Eine Genehmigung anfordern und eine Ablehnung erhalten.

• Die Sitzung beenden.

Erwartete Ergebnisse nach Nachweisquelle:

• OTel zeigt Ausführungs- und Tool-Ereignisse.

• Hooks zeigen den Sitzungslebenszyklus.

• Proxy-Protokolle zeigen erlaubte und blockierte Ziele.

• Die Compliance-Datenaufnahme empfängt unterstützte Datensätze.

• Das SIEM korreliert diese Datensätze mit dem Benutzer oder der Workload.

Zurücksetzen

Deaktivieren Sie den Exporter und die Hooks, indem Sie die vorherige Konfiguration wiederherstellen. Entfernen Sie die unabhängige Proxy-Protokollierung nicht im Rahmen eines Telemetrie-Rollbacks.

Grenzen

Versprechen Sie nicht, dass die Codex-Telemetrie jedes Befehlsargument, jedes Ausgabebyte oder jedes Netzwerkpaket erfasst. Dokumentieren Sie die Abdeckung jeder Ebene.

Verwenden Sie diese Anleitung, wenn Codex keinen Internetzugriff haben oder nur genehmigte Ziele erreichen soll. Wählen Sie das lokale oder das Cloud-Verfahren passend zur Umgebung, die Sie konfigurieren, und beachten Sie die unterschiedlichen Geltungsbereiche ihrer Richtlinien.

Angestrebtes Ergebnis

Codex hat entsprechend der gewählten Konfiguration keinen Internetzugriff oder erreicht nur genehmigte Domains. Umgebungen in Codex Cloud (Legacy) können zusätzlich HTTP-Methoden einschränken.

Aktuelles Codex Cloud konfigurieren

1. Erstellen Sie separate Umgebungen für unterschiedliche Vertrauensstufen, beispielsweise no-internet-review, approved-dependencies-build und cyber-lab.

2. Lassen Sie in der Umgebungskonfiguration Internetzugriff für Codex zulassen deaktiviert, sofern der Arbeitsablauf keinen Internetzugriff benötigt.

3. Wenn Zugriff erforderlich ist, aktivieren Sie Internetzugriff für Codex zulassen. Wählen Sie unter Domains zulassen die Option Nur benutzerdefinierte Domains und fügen Sie dann unter Zusätzlich erlaubte Domains die exakt benötigten Hosts hinzu.

4. Speichern und testen Sie die Dienste während der Einrichtung. Veröffentlichen Sie die Umgebung oder veröffentlichen Sie sie erneut und testen Sie anschließend in einer neuen Aufgabe den Zugriff auf genehmigte und nicht genehmigte Ziele. Prüfen Sie Einrichtungsskripte separat: Fixieren Sie Abhängigkeitsversionen, bevorzugen Sie genehmigte Spiegelserver und vermeiden Sie ungeprüfte Downloads ausführbarer Dateien.

Siehe Verbindung mit Diensten herstellen. Die aktuellen Codex Cloud-Einstellungen bieten keine Auswahl für HTTP-Methoden wie in Legacy.

Codex Cloud (Legacy) konfigurieren

1. Lassen Sie den Internetzugriff des Agenten Aus, wenn er nicht benötigt wird. Legacy Cloud blockiert den Internetzugriff während der Agentenphase standardmäßig; Einrichtungsskripte werden zur Installation von Abhängigkeiten weiterhin mit Internetzugriff ausgeführt.

2. Wenn der Agent Zugriff benötigt, schalten Sie ihn mit einer eng gefassten Positivliste Ein. Beginnen Sie mit Keine und fügen Sie exakte Domains hinzu.

3. Erlauben Sie für reine Download-Arbeitsabläufe nur GET, HEAD und OPTIONS. Dies blockiert POST, PUT, PATCH, DELETE und andere Methoden. Prüfen Sie Einrichtungsskripte separat, da die Einschränkung der Agentenphase deren Internetzugriff nicht regelt.

Siehe Internetzugriff des Legacy-Agenten. Diese Voreinstellungen und HTTP-Methodenkontrollen gelten nur für Legacy Cloud.

Lokales Codex konfigurieren

1. Definieren und wählen Sie in der administrativ verwalteten requirements.toml das genehmigte Netzwerkprofil und beschränken Sie Benutzer auf dieses Profil:

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Stellen Sie das geprüfte Anforderungspaket mithilfe von Verwaltete Konfiguration bereit. Ein benanntes Profil allein ist inaktiv; default_permissions wählt es aus, und die Positivliste verhindert die Auswahl anderer Profile.

3. Aktivieren Sie den administrativ verwalteten Proxy im selben Anforderungspaket, damit Domainbeschränkungen durchgesetzt werden und Benutzer sie nicht erweitern können. Stellen Sie den Proxy und das Profil mit aktiviertem Netzwerk gemeinsam bereit; ein Profil mit aktiviertem Netzwerk ohne aktiven Proxy gewährt direkten Netzwerkzugriff, ohne seine Domainregeln durchzusetzen:

   Achtung: [experimental_network] ist experimentell und kann sich ändern. Validieren Sie es vor einer breiteren Einführung für jede unterstützte lokale Client-Version und jedes unterstützte Betriebssystem. Die Windows-Unterstützung ist eingeschränkt; wenden Sie diese Richtlinie erst auf Windows-Benutzer an, nachdem Sie die Durchsetzung in Ihrer Umgebung getestet haben.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Lassen Sie die Bindung an lokale Ports deaktiviert, sofern der Arbeitsablauf sie nicht benötigt. Konfigurieren Sie den Zugriff auf private Netzwerkziele separat; das Zulassen einer Domain genehmigt nicht automatisch deren private Adressen. Siehe Anforderungen für den Netzwerkzugriff.

5. Konfigurieren Sie Websuche, Apps, MCP-Server, Browseraktivitäten und Codex Cloud separat. Lokale Sandbox-Regeln steuern diese nicht.

Überprüfen

• Senden Sie eine Anfrage an eine genehmigte Domain und bestätigen Sie, dass sie erfolgreich ist.

• Senden Sie eine Anfrage an eine nicht genehmigte Domain und bestätigen Sie, dass sie blockiert wird.

• Senden Sie Anfragen an localhost, eine private IP und einen Cloud-Metadaten-Endpunkt. Bestätigen Sie, dass jede Anfrage blockiert wird, sofern sie nicht ausdrücklich genehmigt wurde.

• Versuchen Sie in Codex Cloud (Legacy) eine POST-Anfrage an eine erlaubte Domain. Bestätigen Sie, dass die Anfrage blockiert wird, wenn nur GET, HEAD und OPTIONS erlaubt sind.

• Bestätigen Sie, dass Proxy- oder Gateway-Protokolle Einträge sowohl für erlaubte als auch für abgelehnte Anfragen enthalten.

Zurücksetzen

Setzen Sie den Internetzugriff der Umgebung wieder auf Aus oder stellen Sie die vorherige Domainrichtlinie wieder her. Vermeiden Sie eine Rückkehr zu uneingeschränktem Internetzugriff.

Grenzen

Eine genehmigte vollständige Sandbox-Eskalation kann den lokalen Befehlsproxy umgehen. Testen Sie normale Befehle in der Sandbox und genehmigte eskalierte Befehle separat, bevor Sie sich auf die Einschränkung verlassen.

Eine erlaubte Domain kann weiterhin Prompt Injection, kompromittierte Pakete oder unsichere Dokumentation bereitstellen.

Verwenden Sie diese Anleitung, wenn Codex Zugriff auf genehmigte Quellcodeverzeichnisse benötigt, während Geheimnisse, .env-Dateien, SSH-Schlüssel und nicht zugehörige Repositorys unzugänglich bleiben sollen. Sie behandelt die Einschränkung des Dateizugriffs und die Verringerung der Anzahl von Umgebungsvariablen mit Zugangsdaten, die an gestartete Befehle übergeben werden.

Angestrebtes Ergebnis

Codex kann in genehmigten Quellcodeverzeichnissen arbeiten, aber keine gängigen Dateien mit Geheimnissen lesen und keinen umfangreichen Satz von Umgebungsvariablen mit Zugangsdaten erben.

Konfigurieren

1. Definieren Sie Muster zum Verweigern von Lesezugriffen in einem Workspace-Profil:

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. Fügen Sie exakte Sperrpfade für bekannte Verzeichnisse mit Zugangsdaten, Signaturschlüssel, Produktionskonfigurationen und benachbarte Repositorys hinzu.

3. Reduzieren Sie in der systemweiten /etc/codex/config.toml oder der benutzerspezifischen ~/.codex/config.toml die Umgebungsvariablen, die an gestartete Befehle übergeben werden:

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

Dies ist ein vom Benutzer konfigurierbarer Standardwert, keine erzwungene Anforderung. Er reduziert geerbte Variablen, verhindert aber nicht den Zugriff auf Zugangsdaten-Dateien, Hilfsprogramme, Shell-Startinhalte oder andere Identitäten. Siehe Erweiterte Konfiguration.

4. Wählen Sie in der administrativ verwalteten requirements.toml das eingeschränkte Profil aus und erlauben Sie nur dieses Profil. Integrierte Profile erben dessen Sperren für Geheimnisdateien nicht:

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Wählen Sie das Verfahren für Zugangsdaten in Ihrer Cloud-Umgebung:

   • Verwenden Sie im aktuellen Codex Cloud Netzwerkgeheimnisse für Zugangsdaten, die an einen erlaubten HTTPS-Dienst gesendet werden. Programme erhalten einen Platzhalter, und der Proxy ersetzt diesen während der Einrichtung und bei Aufgaben für genehmigte Ziele auf Port 443 durch den tatsächlichen Wert. Die eigentlichen Zugangsdaten werden weder in einem lokalen Prozess noch in einer Datei abgelegt. Direkte Umgebungsvariablen sind für Programme zugänglich. Siehe Umgebungsvariablen und Netzwerkgeheimnisse.
   • In Codex Cloud (Legacy) unterstützen Geheimnisse die Authentifizierung während der Einrichtung und werden vor der Agentenphase entfernt; Umgebungsvariablen bleiben während des gesamten Chats erhalten. Siehe Legacy Cloud-Umgebungen.

6. Wenn der Agent eine Authentifizierung benötigt, verwenden Sie einen unabhängigen Broker, um kurzlebige Zugangsdaten bereitzustellen, die auf das genaue Ziel und die genaue Aktion beschränkt sind. Siehe Empfohlene Konfiguration.

Überprüfen

Erstellen Sie harmlose Testköder:

.env.test
test-key.pem
.aws/credentials
.kube/config

Bitten Sie Codex anschließend um Folgendes:

• Eine normale Datei lesen.

• Jeden Testköder lesen.

• Rekursiv nach Geheimnissen suchen.

• Die Befehlsumgebung ausgeben.

• Ein benachbartes Repository lesen.

Erwartet: Das Lesen einer normalen Datei ist erfolgreich; gesperrte Dateien und benachbarte Repositorys bleiben unzugänglich, und ausgeschlossene Variablen fehlen in der Befehlsumgebung.

Zurücksetzen

Stellen Sie das vorherige Profil wieder her, behalten Sie aber eindeutig begründete Sperren für Geheimnisdateien bei, während Sie Fehler in Arbeitsabläufen untersuchen.

Grenzen

Dateisystemsperren entfernen keine Geheimnisse, die bereits in Prompts eingefügt, in lesbaren Quellcode eingecheckt, von Konnektoren zurückgegeben oder in für das Modell zugängliche Protokolle geschrieben wurden.

Verwenden Sie diese Anleitung, wenn Aktionen wie git push, Bereitstellungen, Datenbankmigrationen und Cloud-CLI-Befehle vor ihrer Ausführung eine Genehmigung benötigen. Entscheiden Sie, welche Befehle eine Prüfung anfordern sollen und welche verboten sein müssen, und konfigurieren Sie anschließend Regeln für diese Befehle.

Angestrebtes Ergebnis

Sensible Befehle warten konsequent auf eine Genehmigung oder sind verboten, selbst wenn das Modell sie für angemessen hält.

Konfigurieren

1. Entscheiden Sie, welche Befehle eine Genehmigungsabfrage erfordern und welche verboten sind.

2. Fügen Sie administrativ erzwungene Befehlsregeln hinzu:

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

Anforderungsregeln können eine Genehmigungsabfrage verlangen oder einen Befehl verbieten; sie können keinen Befehl erlauben. Siehe Verwaltete Konfiguration.

3. Fügen Sie für Profile mit hohem Risiko einen Shell-Wrapper-Eintrag zum selben prefix_rules-Array hinzu, wenn Wrapper einen sensiblen Befehl verschleiern könnten:

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

Der Shell-Wrapper-Eintrag erzeugt viele zusätzliche Abfragen; setzen Sie ihn gezielt ein.

4. Wenn ein Mensch Befehle genehmigen muss, erzwingen Sie diese Einstellungen:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

Auto-review ändert die prüfende Instanz; es ist keine deterministische Sicherheitsgarantie. Siehe Auto-review.

5. Senden Sie PermissionRequest-, Tool-Entscheidungs- und Tool-Ergebnisereignisse an die Sicherheitspipeline.

Überprüfen

• Führen Sie git status aus. Erwartet: Es erscheint keine Genehmigungsabfrage.

• Führen Sie git push aus. Erwartet: Eine Genehmigungsabfrage erscheint.

• Führen Sie terraform apply aus. Erwartet: Eine Genehmigungsabfrage erscheint.

• Führen Sie kubectl delete pod test aus. Erwartet: Eine Genehmigungsabfrage erscheint.

• Führen Sie rm -rf test-directory aus. Erwartet: Der Befehl ist verboten.

• Lehnen Sie eine Genehmigungsanfrage ab. Erwartet: Der Befehl wird nicht ausgeführt, und die Ablehnung wird protokolliert.

• Starten Sie den Client neu und wiederholen Sie die Prüfungen. Erwartet: Die Regel wird weiterhin durchgesetzt.

Zurücksetzen

Stellen Sie das vorherige Anforderungspaket wieder her. Grenzen Sie ein zu weit gefasstes Token-Muster ein, statt eine ganze Klasse sensibler Befehle zu entfernen.

Grenzen

Präfixregeln sind keine vollständige Richtlinien-Engine für das Betriebssystem. Kombinieren Sie sie mit Sandboxing, Betriebssystemkonten mit minimalen Berechtigungen, Netzwerkbeschränkungen, Cloud-IAM, Branch-Schutz, Bereitstellungsgenehmigungen und Datenbankautorisierung.

Verwendet diese Konfigurationsanleitungen: Berechtigungsprofile und Full Access einschränken; Geheimnisse und nicht zugehörige Repositorys schützen; Genehmigung für sensible Befehle verlangen.

Entwickler haben berechtigten Zugriff auf die Produktionsumgebung, aber Sie möchten, dass Codex bei der Entwicklung hilft, ohne ungeprüfte Änderungen an der Produktionsumgebung vorzunehmen.

• Definieren Sie ein genehmigtes Workspace-Profil und erzwingen Sie die zulässigen Profile und Genehmigungsrichtlinien. Stellen Sie diese Einstellungen als administrativ erzwungene Anforderungen bereit, damit Benutzer sie nicht überschreiben können.

• Führen Sie Codex unter einer separaten Identität mit geringeren Berechtigungen oder in einer Umgebung aus, die nicht auf Zugangsdaten mit Schreibrechten für die Produktionsumgebung zugreifen oder diese erhalten kann. Entwickler können ihren Produktionszugriff über einen separaten autorisierten Arbeitsablauf behalten.

• Minimieren Sie die Umgebungsvariablen, die an gestartete Befehle übergeben werden. Wenn der Agent eine Authentifizierung benötigt, verwenden Sie einen unabhängigen Broker, um kurzlebige Zugangsdaten bereitzustellen, die auf das genaue Ziel und die genaue Aktion beschränkt sind.

• Entscheiden Sie, welche Befehle eine Genehmigungsabfrage erfordern und welche verboten sind. Verlangen Sie für ausgewählte Befehle mit großen Auswirkungen eine Genehmigung durch einen Menschen, etwa für git push, terraform apply, Kubernetes-Änderungen und Datenbankmigrationen; verbieten Sie Befehle, die niemals ausgeführt werden dürfen.

• Setzen Sie Produktions-IAM, Branch-Schutz und Bereitstellungsgenehmigungen unabhängig von Codex durch.

Berechtigungsprofile einschränken und eine menschliche Prüfung verlangen

Erlauben Sie in der administrativ verwalteten requirements.toml die integrierten Workspace- und schreibgeschützten Profile und verlangen Sie für genehmigungspflichtige Aktionen eine Prüfung durch den Benutzer:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Das Workspace-Profil erlaubt Arbeiten im Workspace innerhalb seiner Sandbox; für enger begrenzte Arbeiten steht das schreibgeschützte Profil zur Verfügung. Profile mit Vollzugriff stehen nicht auf der Positivliste.

Setzen Sie approval_policy = "on-request" in der Client-Konfiguration, wenn der Client eine explizite kompatible Auswahl benötigt. on-request erlaubt bei Bedarf eine Genehmigungsabfrage; es fordert nicht für jeden Befehl eine Genehmigung an. Fügen Sie explizite Regeln für die Aktionen hinzu, die eine Prüfung benötigen, und behalten Sie eine unabhängige Autorisierung für die Produktionsumgebung bei.

Verwaltete Profilpositivlisten erfordern Codex 0.138.0 oder höher; verwenden und testen Sie für ältere Clients die dokumentierten Anforderungen für den bisherigen Sandbox-Modus.

Starten Sie jeden Pilot-Client neu, überprüfen Sie, ob das genehmigte Profil funktioniert, und prüfen Sie, ob ein unzulässiges Profil mit Vollzugriff abgelehnt wird.

Die Codex-Identität von Produktionszugangsdaten trennen

Erstellen Sie in Ihrer Geräteverwaltung oder Ihrem Bereitstellungssystem für Entwicklungsumgebungen einen dedizierten Codex-Benutzer, Container oder Entwicklungshost, der nur auf den benötigten Quellcode und die benötigten Entwicklungsdienste zugreifen kann. Binden Sie die Produktionszugangsdaten-Dateien, Token-Hilfsprogramme oder Schlüsselbunde des Entwicklers nicht in diese Umgebung ein und verhindern Sie, dass die Identität Schreibrollen für die Produktionsumgebung erlangen kann.

Wenn der Agent Dienstzugriff benötigt, konfigurieren Sie den Zugangsdaten-Broker Ihres Unternehmens so, dass er kurzlebige Zugangsdaten ausstellt, die auf die Entwicklungsressource und die Aktion beschränkt sind. Der Entwickler kann seine normale Identität über einen separaten autorisierten Produktionsarbeitsablauf verwenden.

Öffnen Sie beispielsweise in AWS IAM Rollen, wählen Sie die Codex-Entwicklungsrolle aus und fügen Sie unter Berechtigungen eine geprüfte Inline-Richtlinie wie diese hinzu. Ersetzen Sie dabei Konto und Rolle durch Ihre eigenen:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

Dieses Beispiel verweigert Versuche, die benannte Rolle anzunehmen, verweigert aber keine Versuche, andere Rollen anzunehmen. Entfernen Sie außerdem direkte Produktionsberechtigungen, schränken Sie andere Produktionsrollen und Zugangsdatenquellen ein und prüfen Sie Vertrauensrichtlinien sowie Kontrollen auf Organisationsebene.

Testen Sie die Entwicklungsrolle anhand repräsentativer Entwicklungs- und Produktionsberechtigungen, ohne eine Änderung in der Produktion vorzunehmen. Siehe Beispiele für AWS IAM-Rollenrichtlinien.

Shell-Umgebung minimieren

Konfigurieren Sie in /etc/codex/config.toml für eine systemweite Ausgangskonfiguration oder in ~/.codex/config.toml für einen einzelnen Benutzer, welche Umgebungsvariablen gestartete Befehle erben:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Dies ist eine konfigurierbare Standardeinstellung, keine erzwungene Schutzgrenze für Zugangsdaten. Benutzereinstellungen, Shell-Startkonfigurationen oder Snapshots, Hilfsprogramme für Zugangsdaten und andere Quellen können weiterhin Zugangsdaten zugänglich machen.

Verwenden Sie in requirements.toml die folgenden optionalen Einschränkungen, um Login-Shells und Shell-Snapshots zu deaktivieren, sofern sie mit Ihrem Workflow kompatibel sind:

allow_login_shell = false

[features]
shell_snapshot = false

Erproben Sie diese Einstellungen zunächst, da einige Workflows von der Initialisierung der Login-Shell abhängen.

Starten Sie Codex mit harmlosen synthetischen Variablen, die den Filtern entsprechen, und prüfen Sie die Umgebung eines gestarteten Befehls. Prüfen Sie außerdem, ob die Anforderung einer Login-Shell abgelehnt wird, wenn diese deaktiviert ist. Überprüfen Sie unabhängig davon, dass die Ausführungsidentität nicht auf echte Produktionszugangsdaten zugreifen kann. Siehe Richtlinie für die Shell-Umgebung.

Genehmigung für ausgewählte Befehle mit weitreichenden Auswirkungen anfordern

Fügen Sie Regeln in den Anforderungen für die Befehle hinzu, die Ihre Organisation verwendet. Zum Beispiel:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

Verwenden Sie forbidden für einen Befehl, der niemals ausgeführt werden darf. Ersetzen oder ergänzen Sie Muster für die tatsächlich verwendeten Bereitstellungs- und Migrationstools.

Diese Regeln gleichen Befehlspräfixe ab und decken nicht jede gleichwertige Aktion ab. Testen Sie absolute Pfade, Wrapper, andere Argumentreihenfolgen, andere Clients und andere Tools separat.

Führen Sie auf einem entbehrlichen Testziel einen normalen Befehl aus, fordern Sie eine aufgeführte Aktion an, lehnen Sie die Genehmigungsanfrage ab und prüfen Sie, dass die Aktion nicht ausgeführt wurde. Siehe Befehlsregeln durchsetzen.

Repository- und Bereitstellungsgenehmigungen außerhalb von Codex durchsetzen

Schützen Sie in Ihrer Versionsverwaltungsplattform Produktionsbranches wie main: Verlangen Sie geprüfte Änderungen sowie die erforderlichen Genehmigungen und Statusprüfungen und prüfen Sie, welche Rollen diese Anforderungen umgehen können. Konfigurieren Sie Bereitstellungsgenehmigungen im jeweiligen Bereitstellungssystem und Datenbankberechtigungen in der Datenbank selbst.

Prüfen Sie mit einem entbehrlichen Repository, dass eine geprüfte Änderung funktioniert und ein nicht autorisierter direkter Push abgelehnt wird. Diese Kontrollen gelten unabhängig davon, ob eine Aktion über Codex angefordert wurde.

Überprüfen

Auf einem entbehrlichen Testziel:

• Führen Sie eine normale Aufgabe im Arbeitsbereich aus. Erwartet: Die Aufgabe wird erfolgreich abgeschlossen.

• Versuchen Sie, einen repräsentativen sensiblen Befehl auszuführen, und lehnen Sie die Genehmigungsanfrage ab. Erwartet: Der abgelehnte Befehl wird nicht ausgeführt.

• Prüfen Sie, dass die Codex-Identität keinen Schreibzugriff auf die Produktion erlangen kann.

• Starten Sie den Client neu und wiederholen Sie die Prüfung.

Grenzen

Präfixregeln sind keine vollständige Richtlinien-Engine für das Betriebssystem. Kombinieren Sie sie mit Sandboxing, Betriebssystemkonten mit minimalen Berechtigungen, Netzwerkeinschränkungen, Cloud-IAM, Branchschutz, Bereitstellungsgenehmigungen und Datenbankautorisierung.

Verwendet diese Konfigurationsrezepte: Geheimnisse und nicht zugehörige Repositorys schützen; Netzwerkziele einschränken; Nur genehmigte MCP-Server zulassen; Genehmigung für sensible Befehle verlangen.

Entwickler verwenden Codex mit internen Repositorys, und Sie möchten das Risiko reduzieren, dass Code an ein öffentliches Repository, ein öffentliches Code-Snippet oder ein anderes nicht genehmigtes Ziel gesendet wird.

• Fügen Sie exakte Sperrpfade für bekannte Verzeichnisse mit Zugangsdaten und nicht zugehörige Repositorys hinzu und minimieren Sie die an gestartete Befehle übergebenen Umgebungsvariablen.

• Wenn der Agent Internetzugriff benötigt, verwenden Sie eine eng gefasste Positivliste genehmigter Domains. Lassen Sie nur genehmigte MCP-Servernamen und -Identitäten zu und verlangen Sie eine Prüfung für ausgewählte Veröffentlichungsbefehle oder verbieten Sie diese, etwa git push.

• Verwenden Sie Hooks und Berechtigungen der Versionsverwaltung, Richtlinien für öffentliche Repositorys und Code-Snippets sowie für Ihre Organisation geeignete Maßnahmen zur Verhinderung von Datenverlusten.

Zugriff auf nicht zugehörige Repositorys und Dateien mit Zugangsdaten verweigern

Fügen Sie in der administrativ verwalteten requirements.toml exakte Pfade hinzu, die der lokale Agent nicht lesen darf:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

Ersetzen Sie die Beispiele durch Pfade, die auf Ihren verwalteten Geräten vorhanden sind. Diese verwaltete Zugriffssperre gilt für alle zulässigen Berechtigungsprofile. Eine Sperre, die nur innerhalb eines benutzerdefinierten Profils konfiguriert ist, schützt keine Benutzer, die ein anderes Profil auswählen. Bevorzugen Sie exakte bekannte Pfade und testen Sie alle Glob-Muster auf den benötigten Verzeichnistiefen.

Unter nativem Windows deckt die verwaltete deny_read direkte Dateitools ab, verhindert aber allein keine Lesezugriffe durch Shell-Unterprozesse. Verwenden Sie zusätzlich Betriebssystemidentitäten und Dateizugriffssteuerungslisten.

Erstellen Sie harmlose Testdateien an den gesperrten Speicherorten. Prüfen Sie unter jedem zulässigen Profil, dass sowohl direkte als auch Shell-Lesezugriffe auf diese Dateien verweigert werden und eine genehmigte Quelldatei gelesen werden kann. Siehe Verwaltete Anforderungen zur Lesesperre.

Shell-Variablen mit Zugangsdaten minimieren

Legen Sie in /etc/codex/config.toml oder ~/.codex/config.toml eine eng begrenzte vererbte Umgebung fest:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Diese Einstellung reduziert die vererbten Variablen, ist jedoch vom Benutzer konfigurierbar und verhindert keinen Zugriff auf Dateien mit Zugangsdaten, Hilfsprogramme, Shell-Startkonfigurationen oder andere Identitäten.

Gegebenenfalls kann ein Administrator auch diese Einschränkungen zu requirements.toml hinzufügen und sie zunächst erproben, um ihre Auswirkungen auf Entwicklerworkflows zu beurteilen:

allow_login_shell = false

[features]
shell_snapshot = false

Testen Sie mit synthetischen Testvariablen und einer separaten Ausführungsidentität mit minimalen Berechtigungen. Verwenden Sie keine echten Zugangsdaten. Siehe Richtlinie für die Shell-Umgebung.

Nur genehmigte Netzwerkziele für lokale Befehle zulassen

Wenn lokale Befehle in der Sandbox Netzwerkzugriff benötigen, integrieren Sie sowohl die folgenden Profileinstellungen als auch die Einstellungen für den verwalteten Proxy in requirements.toml und ersetzen Sie die Domains durch genehmigte Endpunkte:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

Das Profil mit aktiviertem Netzwerkzugriff stellt dem Befehl in der Sandbox einen Netzwerkpfad bereit, während der verwaltete Proxy dessen Ziele einschränkt. Stellen Sie beide gemeinsam bereit. Ein Profil mit aktiviertem Netzwerkzugriff ohne den vorgesehenen verwalteten Proxy wendet nicht dieselben Zieleinschränkungen an. Wenn kein Internetzugriff erforderlich ist, lassen Sie den Netzwerkzugriff deaktiviert.

Kombinieren Sie die kanonische Tabelle domains nicht mit den älteren Einstellungen allowed_domains oder denied_domains. Migrieren und testen Sie die bestehende Richtlinie.

Starten Sie den Client neu und prüfen Sie, dass ein genehmigter Endpunkt funktioniert und ein nicht genehmigter Endpunkt blockiert wird.

Diese Einstellungen sind experimentell. Prüfen Sie die Unterstützung durch Betriebssystem und Client und konfigurieren Sie den Zugriff auf private Netzwerke separat, wenn ein genehmigter Host zu einer privaten Adresse aufgelöst wird. Eine genehmigte vollständige Sandbox-Eskalation kann den Befehlsproxy umgehen.

Diese Netzwerkkontrolle für lokale Befehle deckt für sich genommen weder Websuche, Apps, MCP-Server, Browseraktivitäten noch Cloud-Umgebungen ab. Dafür sind separate Richtlinien erforderlich. Eine genehmigte Hosting-Domain kann auch öffentliche Repositorys oder öffentliche Code-Snippets enthalten. Eine Positivliste für Ziele allein schützt daher keine Inhalte. Siehe Anforderungen an den Netzwerkzugriff.

Netzwerkzugriff der Cloud-Umgebung separat konfigurieren

Öffnen Sie in der aktuellen Codex Cloud-Oberfläche die Umgebungskonfiguration. Lassen Sie Codex den Internetzugriff erlauben deaktiviert. Wenn Sie Internetzugriff benötigen, aktivieren Sie die Option und wählen Sie Nur benutzerdefinierte Domains. Fügen Sie unter Zusätzliche erlaubte Domains die exakt benötigten Hosts hinzu, speichern Sie anschließend die Konfiguration, veröffentlichen Sie die Umgebung oder veröffentlichen Sie sie erneut und testen Sie eine neue Aufgabe.

Prüfen Sie die Authentifizierung und die Funktionen der Dienste unabhängig davon.

Die ältere Version von Codex Cloud verwendet eine separate Einstellung für den Internetzugriff des Agenten pro Umgebung mit Steuerelementen für zulässige Domains und HTTP-Methoden. Einrichtungsskripte haben ein eigenes Zugriffsverhalten.

Testen Sie die Umgebungsversion, die Sie tatsächlich verwenden. Siehe Verbindung mit Diensten herstellen und ältere Interneteinstellungen.

MCP-Server einschränken und vor Git-Pushes eine Genehmigung anfordern

Lassen Sie in requirements.toml nur genehmigte lokale MCP-Serveridentitäten zu. Zum Beispiel:

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

Konfigurieren Sie den eigentlichen Server separat in der benutzerspezifischen oder als verwalteter Standard bereitgestellten config.toml. Verwenden Sie dabei den passenden Namen und die passende URL sowie die von Ihrem Server benötigte Authentifizierung:

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

Die Anforderung lässt lediglich einen passenden Server zu und erstellt ihn nicht. Prüfen Sie die eigenen Zugriffsrechte und Tools dieses Servers.

Prüfen Sie, dass der genehmigte Server eine Verbindung herstellen kann und ein Server mit einem anderen Namen oder einer anderen URL nicht zugelassen wird.

Fügen Sie eine verwaltete Befehlsregel hinzu, um vor einem repräsentativen Veröffentlichungsbefehl eine Prüfung anzufordern:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Kombinieren Sie dies mit allowed_approval_policies = ["on-request"] und allowed_approvals_reviewers = ["user"] als Anforderungen auf oberster Ebene, wenn eine Person die Prüfung vornehmen muss.

Lehnen Sie einen Test-Push ab und bestätigen Sie, dass er nicht ausgeführt wird.

Der Präfixabgleich deckt nicht jeden Wrapper, API-Client, jede App oder jeden alternativen Veröffentlichungsweg ab.

Öffentliche Veröffentlichungen durch Versionsverwaltungs- und DLP-Kontrollen einschränken

Schränken Sie in Ihrer Versionsverwaltungsplattform die Erstellung öffentlicher Repositorys ein und begrenzen Sie, wer die Sichtbarkeit von Repositorys ändern darf, sofern dies unterstützt wird. Prüfen Sie die Umgehungsberechtigungen privilegierter Benutzer. Prüfen Sie persönliche Konten, Code-Snippets, externe Organisationen und Token-Zugriff separat: Organisationseinstellungen regeln nicht jedes Ziel.

Verlangen Sie im jeweiligen Repository geprüfte Änderungen und prüfen Sie Branchschutz und Umgehungsberechtigungen.

Konfigurieren Sie in der DLP-Konsole Ihrer Organisation eine Pilotrichtlinie für sensible Quellcodeinhalte und die Upload- oder Repository-Kanäle, die Ihr DLP-Produkt tatsächlich abdeckt. Legen Sie als Aktion das Blockieren fest und testen Sie mit einem inerten synthetischen Marker.

Wenn die Versionsverwaltungsplattform serverseitige Kontrollen unterstützt, konfigurieren und erzwingen Sie geprüfte Hooks für Repositorys, die Pushes empfangen.

Verwenden Sie autorisierte Testziele und bestätigen Sie die Blockierung vor jeder Veröffentlichung.

Überprüfen

• Erstellen Sie harmlose Testdateien und bestätigen Sie, dass Versuche, gesperrte Dateien zu lesen, fehlschlagen.

• Wenn der Netzwerkzugriff aktiviert ist, prüfen Sie, dass der Zugriff auf ein genehmigtes Ziel gelingt und auf ein nicht genehmigtes Ziel blockiert wird. Prüfen Sie andernfalls, dass Netzwerkanfragen blockiert werden.

• Prüfen Sie mit einem harmlosen Marker und entbehrlichen Testkonten oder Testzielen, dass repräsentative Versuche einer öffentlichen Veröffentlichung vor der Veröffentlichung blockiert werden.

Grenzen

Eine zulässige Domain kann weiterhin öffentliche Inhalte hosten. Konfigurieren Sie Websuche, Apps, MCP-Server, Browseraktivitäten und Codex Cloud separat. Lokale Sandbox-Regeln kontrollieren diese nicht.

Verwendet diese Konfigurationsrezepte: Berechtigungsprofile und Full Access einschränken; Nur genehmigte MCP-Server zulassen; Netzwerkziele einschränken; Geheimnisse und nicht zugehörige Repositorys schützen; Genehmigung für sensible Befehle verlangen.

Sie möchten, dass die für Codex geltenden Einschränkungen wirksam bleiben, wenn Codex in einem Repository arbeitet oder ein Benutzer lokale Konfigurationen ändert.

• Stellen Sie unterstützte Einschränkungen für Berechtigungen, Genehmigungen, MCP, Netzwerk und Befehle als administrativ durchgesetzte Anforderungen bereit.

• Installieren Sie Hook-Skripte in einem administrativ verwalteten Verzeichnis und verwenden Sie ausschließlich verwaltete Hooks, wenn Benutzer-, Projekt- und Plugin-Hooks ignoriert werden sollen.

• Schützen Sie Richtliniendateien und den Verteilungsweg der Konfiguration durch Betriebssystem- und Geräteverwaltungskontrollen. Führen Sie Codex ohne die Berechtigungen aus, die zum Ändern dieser Schutzmaßnahmen erforderlich sind.

• Prüfen Sie die wirksame Konfiguration für jeden betroffenen Client und jede betroffene Umgebung.

Zulässige Profile, Genehmigungen, Serveridentitäten und Befehle durchsetzen

Integrieren Sie geprüfte Einstellungen in die administrativ verwaltete requirements.toml, anstatt sich auf die bearbeitbaren Einstellungen eines Benutzers oder Repositorys zu verlassen. Zum Beispiel:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

Dieses Beispiel lässt zwei Profile zu, verlangt bei erforderlicher Genehmigung einen menschlichen Prüfer, erlaubt eine passende MCP-Identität und fordert für ein bestimmtes Befehlspräfix eine Genehmigung an.

Konfigurieren Sie den MCP-Server selbst separat und ergänzen Sie die weiteren sensiblen Befehlsmuster der Organisation. Fügen Sie bei Bedarf globale Dateieinschränkungen und Netzwerkeinschränkungen hinzu. Anforderungen begrenzen unterstützte Einstellungen, können aber Identitäts-, Dienst- und Zielkontrollen außerhalb von Codex nicht ersetzen.

Verwaltete Positivlisten für Profile erfordern Codex 0.138.0 oder höher.

Versuchen Sie auf einem Pilotclient, ein unzulässiges Profil auszuwählen, eine eingeschränkte Benutzer- oder Projekteinstellung zu ändern und eine MCP-Identität zu verwenden, die nicht auf der Positivliste steht. Prüfen Sie jeweils, dass dies abgelehnt wird oder nach einem Neustart weiterhin eingeschränkt bleibt. Lehnen Sie die Genehmigung eines Testbefehls ab und prüfen Sie, dass der Befehl nicht ausgeführt wird.

Verwaltete Dateisystem- und Netzwerkeinschränkungen hinzufügen

Um den Zugriff auf sensible lokale Dateien in allen zulässigen Profilen zu verweigern, fügen Sie die folgende Tabelle zu requirements.toml hinzu und ersetzen Sie die Beispiele durch die Pfade Ihrer Organisation:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

Wenn lokale Befehle in der Sandbox Netzwerkzugriff benötigen, definieren Sie ein zulässiges Profil mit aktiviertem Netzwerkzugriff und verwaltete Ziele gemeinsam:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

Wählen Sie diese Profilrichtlinie anstelle des vorherigen Standards :workspace oder führen Sie beide Profilnamen bewusst zusammen. Fügen Sie keine doppelten Schlüssel oder Tabellen ein. Wenn Befehle keinen Netzwerkzugriff benötigen, lassen Sie ihn deaktiviert.

Prüfen Sie exakte gesperrte Pfade anhand harmloser Dateien und prüfen Sie genehmigte und nicht genehmigte Ziele.

Verwenden Sie unter nativem Windows zusätzlich Dateizugriffssteuerungslisten, da Lesezugriffe durch Shell-Unterprozesse nicht allein durch die verwaltete deny_read abgedeckt werden.

Der Netzwerkzugriff lokaler Befehle regelt keine anderen Clients, Apps, Konnektoren oder die Ausführung in der Cloud.

Administrativ verwaltete Hooks installieren und durchsetzen

Lassen Sie einen Administrator ein geprüftes Hook-Programm in einem von root verwalteten Verzeichnis wie /etc/codex/hooks/pre_tool_use_policy.py installieren und verhindern Sie, dass der Codex-Benutzer die Datei oder ihr Verzeichnis ändert. Aktivieren Sie in requirements.toml Hooks und ignorieren Sie Benutzer-, Projekt-, Sitzungs- und Plugin-Hooks:

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

Die Anforderung registriert den Hook, installiert ihn aber nicht. Speichern Sie für einen lokalen macOS-Integrationstest Folgendes als pre_tool_use_policy.py und lassen Sie einen Administrator die Installation mit den unten stehenden Befehlen vornehmen.

Es blockiert nur den synthetischen Marker. Ersetzen Sie es durch eine geprüfte organisationsspezifische Richtlinie, bevor Sie sich darauf verlassen. Bestätigen Sie, dass /usr/bin/python3 auf dem Ziel vorhanden ist, und passen Sie bei Bedarf den Interpreterpfad an:

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Starten Sie den lokalen Client neu und führen Sie anschließend folgende Schritte aus:

• Bestätigen Sie, dass ein harmloser Bash-Befehl ausgeführt wird.

• Bestätigen Sie, dass ein Befehl, der CODEX_HOOK_TEST_DENY enthält, blockiert wird.

• Prüfen Sie, dass die Richtlinie und ihre Abhängigkeiten nicht vom Codex-Benutzer geändert werden können.

allow_managed_hooks_only überspringt alle nicht verwalteten Benutzer-, Projekt-, Sitzungs- und Plugin-Hooks und kann andere Workflows beeinträchtigen.

Der Bash-Matcher deckt nicht jedes Tool und nicht jede Eingabe ab, die später an einen bestehenden Prozess übergeben wird. Fehler, Zeitüberschreitungen oder fehlerhafte Hook-Antworten können dazu führen, dass ein Tool-Aufruf fortgesetzt wird.

Cloud-orchestriertes Work verwendet andere unterstützte Hook-Handler. Behalten Sie unabhängige Betriebssystem- und Dienstschutzmaßnahmen bei. Siehe Verwaltete Hooks und Hook-Verhalten.

Richtlinie und ihre Verteilung schützen

Unter macOS kann ein Administrator eine geprüfte und zusammengeführte Anforderungsdatei in einem übergeordneten Verzeichnis im Besitz von root bereitstellen und Schreibzugriffe des Codex-Benutzers auf die Datei verhindern:

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

Verwenden Sie unter Linux die entsprechende Administratorgruppe. Schützen Sie unter Windows das ProgramData-Verzeichnis und die Datei mit administrativ verwalteten Zugriffssteuerungslisten. Schränken Sie ein, wer die MDM- oder Cloud-Richtlinie ändern darf, prüfen Sie Änderungen und bewahren Sie eine Kopie für ein Rollback auf.

Prüfen Sie mit einem Pilotkonto ohne Administratorrechte, dass das Konto weder die Richtlinie noch das übergeordnete Verzeichnis oder das verwaltete Hook-Programm ändern kann. Versuchen Sie eine weniger restriktive Benutzer- oder Projekteinstellung, starten Sie Codex neu und prüfen Sie, dass das erzwungene Verhalten bestehen bleibt.

Testen Sie jeden betroffenen Client und jede betroffene Umgebung, anstatt anzunehmen, dass alle Clients dieselbe Richtlinie laden.

Überprüfen

Mit einer Testidentität ohne Administratorrechte:

• Versuchen Sie, die verwaltete Richtlinie zu bearbeiten. Erwartet: Die verwaltete Datei kann nicht geändert werden.

• Versuchen Sie, eine Einschränkung durch Benutzer- oder Projektkonfiguration abzuschwächen. Erwartet: Weniger restriktive Einstellungen werden abgelehnt oder bleiben eingeschränkt.

• Starten Sie den Client neu und prüfen Sie, dass die Einschränkungen weiterhin gelten.

Grenzen

Ein Benutzer oder Agent mit ausreichenden Administratorrechten auf dem Host kann möglicherweise die umgebenden Schutzmaßnahmen ändern. Vom Benutzer bearbeitbare Einstellungen allein ersetzen keine administrativ verwalteten Anforderungen.