Codex-Sicherheitsgrenzen in der Praxis: Berechtigungen, Sandbox und Schutz vor Secret-Leaks

Im Projektstamm liegt eine .env-Datei mit Datenbankpasswort und API keys von Drittanbietern. Sie öffnen Codex und wollen Tests refactoren lassen. Im Dropdown stehen read-only, workspace-write und danger-full-access. Was wählen Sie?

Nach workspace-write fordert Codex die Zustimmung zu npm install an. Sie klicken auf Freigeben. Haben Sie schon geprüft, ob das leicht übersehene postinstall-Skript in package.json in diesem Schritt Umgebungsvariablen lesen oder eine Anfrage an einen unbekannten Dienst senden kann?

Sie setzen Codex in GitHub Actions für automatisierte PR reviews ein. Im workflow steht OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}. Secrets wirken sicher. Aber haben Sie bedacht, dass Testskripte, third-party actions und install hooks im selben job diesen key ebenfalls lesen könnten?

Drei Grenzen beantworten diese Fragen direkt: Instructions sind keine Berechtigungen, Approval ist keine Isolation, sandbox ist kein Audit. Danach folgt die minimale Rechte-Checkliste für lokal, Cloud und CI.

Berechtigungen entstehen nicht durch mündliche Regeln: sandbox, approval und permission profile als drei Grenzschichten

Viele denken, eine Zeile in AGENTS.md wie „lies keine .env-Datei” verhindere den Zugriff von Codex auf sensible Informationen. Das ist keine Berechtigungskontrolle, sondern eine Projektanweisung. Die echte Sicherheitsgrenze entsteht aus drei Schichten: sandbox begrenzt den Bereich von spawned commands, approval policy entscheidet, wann angehalten und gefragt wird, und permission profile ist die erzwungene Zugriffskontrolle.

Codex-Sicherheit funktioniert nicht mit nur einer Schicht. Die sandbox bestimmt, worauf git, Paketmanager und test runner als spawned commands zugreifen dürfen. Die approval policy entscheidet, ob Codex vor kritischen Aktionen Ihre Zustimmung braucht. Das permission profile ist die Konfigurationsebene, auf der Sie wirklich "**/*.env" = "deny" schreiben können. Erst zusammen ergeben diese drei Schichten die tatsächlichen Rechte.

sandbox-Modi im Vergleich: read-only, workspace-write, danger-full-access

sandbox begrenzt spawned commands, nicht nur integrierte Dateioperationen von Codex. git, Paketmanager und test runner erben dieselbe sandbox-Grenze. Die Plattformvoraussetzungen beeinflussen die Zuverlässigkeit: Linux/WSL2 nutzt bubblewrap oder user namespace, macOS nutzt die System-sandbox, und unter Windows hängen die Möglichkeiten von der jeweiligen sandbox-Unterstützung ab.

approval policy legt fest, wann Codex anhält und fragt:

Niedrigrisiko-Kombinationen sind read-only + never für CI read-only und workspace-write + on-request für lokale Entwicklung. Hochriskant ist danger-full-access + never, und das gehört nur in kontrollierte Umgebungen.

permission-profile-Konfiguration: filesystem deny und network rules

permission profile ist erzwungene Zugriffskontrolle, keine mündliche Vorgabe. Filesystem-Berechtigungen unterstützen read/write/deny; spezifischere Regeln überschreiben breitere Regeln, und deny gewinnt.

Beispiel für .env deny glob:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

{
  "filesystem": {
    "rules": {
      "**/*.env": "deny",
      "**/.env.local": "deny",
      "**/secrets/**": "deny",
      "workspace/**": "write"
    }
  }
}

Mit dieser Konfiguration bleiben .env-Dateien auch unter workspace-write unlesbar, selbst wenn der workspace standardmäßig beschreibbar ist. deny gewinnt, und konkrete Regeln überschreiben breite Regeln.

Ein network profile kann enabled = true sowie domain allow/deny konfigurieren; auch hier gewinnt deny. Local/private network ist standardmäßig geschützt. localhost oder Docker socket zu erlauben ist eine explizite Ausnahme. Docker socket ist ein lokaler escape hatch: Er kann lokale Dienste, Container und Netzwerke erreichen und sollte nur sehr bewusst geöffnet werden.

network proxy begrenzt den Netzwerkzugriff bereits gestarteter Befehle und gibt nicht allein Netzwerk frei. Ein globales * allow ist breiter Netzwerkzugriff und sollte entsprechend vorsichtig behandelt werden.

Lokale Mindestberechtigungen: vom read-only Review bis full access

Lokale Entwicklung wird nicht dadurch besser, dass alles mehr Rechte bekommt. Approval kann manche Aktionen stoppen, aber echte Isolation entsteht durch sandbox und permission profile. Beginnen Sie mit den engsten Rechten und erweitern Sie sie nur, wenn die Aufgabe es verlangt.

Entscheidungstabelle: wann read-only, wann workspace-write

Schritte zum Schutz von .env und Secret-Dateien:

1. Ermitteln Sie den Pfad der genutzten permission-profile-Konfiguration anhand der Codex-Permissions-Dokumentation.
2. Ergänzen Sie in den filesystem permissions "**/*.env" = "deny".
3. Prüfen Sie, dass spezifischere Regeln breitere Regeln überschreiben und deny gewinnt.
4. Testen Sie es: Im workspace-write-Modus sollte ein Leseversuch auf .env abgewiesen werden.
5. Erweitern Sie bei Bedarf um "**/.env.local" = "deny" und "**/secrets/**" = "deny".

Verlassen Sie sich nicht auf mündliche Vorgaben. AGENTS.md ist Anleitung, keine erzwungene Zugriffskontrolle. Codex kann sich daran halten, kann aber aus anderen Gründen trotzdem lesen. Nur deny im permission profile ist eine harte Grenze.

Risiken bei Dependency-Installation: npm postinstall, pip hooks, Docker socket

Dependency-Installation ist nicht nur Dateidownload. postinstall und prepare von npm/pnpm sowie hooks von pip install laufen automatisch während der Installation. Diese Skripte können Umgebungsvariablen lesen, Netzwerkanfragen senden oder Systemdateien ändern.

Risikocheckliste:

• Unbekannte postinstall-Skripte können Umgebungsvariablen lesen. Selbst wenn .env deny gesetzt ist, läuft postinstall in der Umgebung der spawned commands und kann an environment variables kommen.
• Sie können Netzwerkanfragen senden: zusätzliche Binärdateien laden, Telemetrie senden oder private Repositorys kontaktieren.
• Sie können Systemdateien verändern: globale Konfiguration schreiben oder PATH anpassen.

Audit-Empfehlung:

1. Prüfen Sie zuerst Skripte und Herkunft: scripts in package.json und setup.py von pip-Paketen.
2. Nutzen Sie vertrauenswürdige Quellen: Versionen pinnen und automatische Updates auf unbekannte Versionen vermeiden.
3. Geben Sie nur in kontrollierter Umgebung frei: lokal workspace-write + on-request nutzen und vor der Zustimmung genau ansehen, was Codex installieren will.

Docker socket ist ein lokaler escape hatch. Wenn Docker socket erlaubt ist, können lokale Dienste, Container und Netzwerke erreicht werden. Konfigurieren Sie das nur bei echtem Bedarf, nicht standardmäßig.

Cloud-Grenzen: setup vs agent phase und der Lebenszyklus von secrets

Ein Cloud task läuft nicht lokal, sondern in einem von OpenAI gehosteten isolierten Container. sandbox kann spawned commands begrenzen, aber der eigentliche Secret-Schutz kommt aus dem Lebenszyklus der Cloud secrets: in der setup phase verfügbar, vor der agent phase entfernt. sandbox ist kein Audit; Sicherheit entsteht durch getrennte Schichten.

Lebenszyklus eines Cloud containers:

1. Container erstellen
2. repo checkouten
3. setup script ausführen
4. Netzwerkeinstellungen anwenden
5. agent führt die Befehlsschleife aus
6. answer/diff ausgeben

Grenze zwischen setup und agent phase: secrets nur im setup

In der setup phase sind Netzwerk, Dependency-Installation und secrets verfügbar. In der agent phase ist der Container standardmäßig offline, secrets sind entfernt, und nur environment variables bleiben vorhanden.

setup scripts laufen in einer separaten Bash session; export wird nicht automatisch in die agent phase übernommen. Wenn Sie im setup export MY_KEY=xxx setzen, erbt die agent phase diese Variable nicht. Zwischen den Phasen werden nur Cloud secrets und environment variables übergeben.

secrets vs environment variables: der entscheidende Unterschied

secrets sind nur in setup scripts verfügbar und eignen sich für Dependency-Installation oder private Repositorys. In der agent phase sollten keine Produktionssecrets vorhanden sein. environment variables bleiben durchgehend bestehen und sind für nicht sensible Konfiguration gedacht.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Grenzen der Dependency-Installation:

• setup phase kann online Dependencies installieren.
• agent phase ist standardmäßig offline.
• setup scripts können secrets lesen; unbekannte Skripte können sie leaken.
• Empfehlung: Skripte und Herkunft zuerst prüfen, vertrauenswürdige Quellen nutzen und unbekannte Skripte nicht im setup laufen lassen.

Der container cache gilt höchstens 12 Stunden. Änderungen an setup, maintenance, env oder secrets lösen cache invalidation aus.

CI und GitHub Action: codex exec, API-key-Verbote und Sicherheitsstrategie der official Action

codex exec nutzt standardmäßig eine read-only sandbox, aber viele workflows legen OPENAI_API_KEY als job-level environment variable ab. Testskripte, third-party actions und dependency lifecycle scripts im selben job können diesen key dann lesen. sandbox ist kein Audit; Sicherheit entsteht durch minimale Rechte und key-Schutz.

API-key-Verbot: nicht als job-level env setzen

Setzen Sie OPENAI_API_KEY oder CODEX_API_KEY in workflows, die checkout machen oder Repository-Code ausführen, nicht als job-level environment variable. Repository-Code, Tests, dependency lifecycle scripts und third-party actions können im selben job weiterhin Umgebungsvariablen sehen.

Verbotsliste:

• OPENAI_API_KEY nicht als job-level env setzen.
• Keinen job-level key in workflows setzen, die checkout machen oder Repository-Code ausführen.
• auth.json / ChatGPT-managed auth eignet sich nicht für public/open-source repo workflows.
• Vertrauensunwürdigen Code nicht in derselben process environment mit dem key ausführen.

Richtige Vorgehensweise:

1. Einzelne invocation inline: CODEX_API_KEY nur für eine einzelne codex exec invocation setzen.

- name: Run Codex
  run: CODEX_API_KEY=${{ secrets.CODEX_API_KEY }} codex exec "review PR #${{ github.event.number }}"

2. official Action proxy: den proxy von openai/codex-action@v1 verwenden.

- uses: openai/codex-action@v1
  with:
    prompt: "review PR #${{ github.event.number }}"
    sandbox: read-only
    safety-strategy: drop-sudo

danger-full-access in CI eignet sich nur für isolated CI runner/container. Es sollte nicht der Standard sein, denn damit sind alle Ressourcen auf dem runner erreichbar.

GitHub-Action-Sicherheitscheckliste: Trigger begrenzen, key schützen, key rotieren

Parameter der official Action:

read-only bedeutet nicht, dass alle secrets auf dem runner geschützt sind. Die Action läuft weiterhin auf dem runner; nur das Dateisystem wird lesend begrenzt. drop-sudo entfernt sudo-Rechte. sandbox sollte der engste Modus sein, der die Aufgabe erledigt.

GitHub-Action-Sicherheitscheckliste:

• Trigger begrenzen: allow-users nur für bestimmte Nutzer, allow-bots vorsichtig aktivieren.
• PR/issue/prompt-Eingaben bereinigen: prompt injection vermeiden und untrusted input nicht direkt an Codex geben.
• API key schützen: nicht als job-level env setzen, sondern einzelne invocation inline oder proxy nutzen.
• Codex als letzten Schritt ausführen: die Expositionszeit des key verkürzen.
• Bei Leak-Verdacht key rotieren: nicht erst untersuchen, sondern zuerst Schaden begrenzen.

PR/issue/prompt-Eingaben gelten als untrusted. PR comments oder issue body sollten nicht unverändert in den Codex prompt fließen.

Umgang mit Secret-Leaks: der erste Schritt bei Verdacht

Wenn ein Leak möglich ist, ist der erste Schritt nicht Analyse, sondern key rotation. Erst Schaden begrenzen, dann auditieren. sandbox kann spawned commands begrenzen, aber nicht verhindern, dass Codex einen key in Logs, PR comments oder answer ausgibt.

Ablauf bei Secret-Leak: key rotation, Audit, Widerruf

Erster Schritt: key rotieren. Nicht zuerst die Ursache suchen, sondern den alten key ungültig machen.

Danach:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

1. Logs auditieren: key-Nutzung prüfen und nach ungewöhnlichen Aufrufen suchen.
2. Token widerrufen: sicherstellen, dass der alte key vollständig ungültig ist und keine gültige session übrig bleibt.
3. Ursache untersuchen: Codex log, GitHub-Action-Ausgaben, Dependency-Installationsskripte und third-party actions prüfen.

Prävention:

• API key nicht in Frontend-Code oder Repository ablegen.
• API key nicht als job-level env setzen (CI).
• .env deny im permission profile nutzen.
• key regelmäßig rotieren, wie es das OWASP Secrets Management Cheat Sheet empfiehlt.

Grenze von Codex Security: ersetzt kein SAST und wendet patches nicht automatisch an

Codex Security ist ein LLM-driven security analysis toolkit. Es läuft in einem ephemeral isolated container und gibt strukturierte findings sowie patch suggestions aus. Es kann beim Finden und Validieren von Schwachstellen helfen, ersetzt aber weder SAST noch manuelle Sicherheitsprüfung.

Grenzen:

• Ersetzt SAST nicht.
• Ersetzt manual security review nicht.
• proposed patch muss vom Nutzer reviewed werden und wird nicht automatisch angewendet.
• Zweck: Finden, Validieren und Vorschlagen unterstützen, nicht automatisch reparieren.

Behandeln Sie Codex Security nicht als Allzweck-Sicherheitsscanner. AI-driven analysis kann manche Probleme finden, aber echte Sicherheit entsteht aus Schichten: lesbarer Bereich, schreibbarer Bereich, Netzwerk, secrets, approval, review und Widerruf.

Fazit

Die Sicherheitsgrenze von Codex besteht aus drei Schichten: sandbox begrenzt spawned commands, approval policy entscheidet, wann angehalten und gefragt wird, und permission profile erzwingt Zugriffskontrolle. Zusammen ergeben sie die tatsächlichen Rechte.

Drei Grenzen sollten hängen bleiben:

• Instructions sind keine Berechtigungen: AGENTS.md ist Anleitung, keine erzwungene Zugriffskontrolle. Schützen Sie .env und API key nicht nur mit mündlichen Regeln.
• Approval ist keine Isolation: approval policy kann manche Aktionen stoppen, aber echte Isolation kommt von sandbox und permission profile.
• sandbox ist kein Audit: sandbox kann spawned commands begrenzen, aber nicht verhindern, dass Codex key in Logs, PR comments oder answer schreibt. Sicherheit entsteht durch Schichten.

Schnelle Selbstprüfung:

• Ist ein .env deny glob konfiguriert?
• Wird in CI job-level API key vermieden?
• Sind die Auslöser der GitHub Action begrenzt?
• Wurden Dependency-Installationsskripte geprüft?
• Gibt es einen Plan für key rotation?

Sicherheitsgrenzen verhindern keine Logikfehler. Codex kann alle Berechtigungsregeln einhalten und trotzdem Code mit bug erzeugen, Tests können fehlschlagen, und rollback muss vorbereitet sein. diff prüfen, Tests ausführen und einen rollback-Plan bereithalten ist die zweite Verteidigungslinie außerhalb der Sicherheitsgrenze.

Nächste Schritte:

• Fehleranalyse und Abnahmeprozess: Verstehen, wie Sie mit Codex-Fehlern umgehen, diffs prüfen und rollback planen.
• codex exec Automatisierung und CI: non-interactive mode, workflow design und Fehlerbehandlung in CI vertiefen.
• AGENTS.md-Projektregeln: Lernen, wie Projektregeln geschrieben werden, aber im Kopf behalten, dass sie Anleitung und kein Berechtigungssystem sind.

Weiterlesen:

• AI-coding-Tools im Überblick 2026: Das Gesamtökosystem der AI-coding-Tools verstehen.
• GitHub Actions CI Grundlagen: Grundbegriffe von CI workflows auffrischen.
• GitHub Actions Deployment-Strategie: Grenzen beim Einsatz von secrets im Deployment verstehen.
• Risiko von Frontend API key leaks: Warum keys nicht ins Frontend oder Repository gehören.