Bezpieczeństwo OpenAI Codex: Jak chronić kod firmy?

Twój agent AI pisze kod, uruchamia testy i tworzy pull requesty. Brzmi świetnie — dopóki nie zdasz sobie sprawy, że ma dostęp do całego repozytorium. Jeden źle sformułowany prompt może skończyć się wyciekiem wrażliwych danych lub nieodwracalnymi zmianami w kodzie produkcyjnym.

OpenAI zaprojektowało Codex z myślą o bezpieczeństwie od pierwszego dnia. W tym artykule pokażę, jak działa dwuwarstwowy model ochrony i jak skonfigurować go dla swojego zespołu.

1. Dlaczego Codex wymaga przemyślanego podejścia do bezpieczeństwa
2. Dwuwarstwowy model ochrony: sandbox + approval policy
3. Trzy tryby sandbox: od read-only do pełnego dostępu
4. Chronione ścieżki: .git, .agents i .codex
5. OpenTelemetry: monitoring i audyt każdej operacji
6. Praktyczna konfiguracja dla zespołów

Dlaczego Codex wymaga przemyślanego podejścia do bezpieczeństwa

Codex to nie zwykły chatbot do generowania fragmentów kodu. To pełnoprawny agent, który może edytować pliki, uruchamiać komendy w terminalu i komunikować się z zewnętrznymi serwisami przez MCP.

Ta moc ma swoją cenę. Źle skonfigurowany agent może:

• Nadpisać pliki konfiguracyjne bez pytania
• Wykonać destrukcyjne komendy (rm -rf, drop tables)
• Wysłać dane przez sieć do zewnętrznych źródeł
• Zmodyfikować historię Git w nieodwracalny sposób

Dlatego OpenAI wprowadził dwuwarstwowy system kontroli — sandbox mode i approval policy. Działają niezależnie i wzajemnie się uzupełniają.

Dwuwarstwowy model ochrony: sandbox + approval policy

System bezpieczeństwa Codex opiera się na dwóch niezależnych warstwach.

Warstwa pierwsza: Sandbox Mode określa techniczne limity — co agent fizycznie może zrobić. To twardy limit egzekwowany przez system operacyjny (Seatbelt na macOS, Landlock na Linux).

Warstwa druga: Approval Policy określa, kiedy agent musi poprosić o zgodę przed wykonaniem akcji. To warstwa kontroli ludzkiej.

Te dwie warstwy działają niezależnie. Możesz mieć agenta z pełnym dostępem do plików (sandbox), który i tak zapyta przed każdą zmianą (approval). Albo odwrotnie — agenta w trybie read-only, który nigdy nie pyta (bo i tak nic nie może zepsuć).

Jeśli dopiero zaczynasz pracę z Codexem, sprawdź najpierw czym jest OpenAI Codex i jak zmienia pracę programistów.

Trzy tryby sandbox: od read-only do pełnego dostępu

Sandbox określa granice możliwości agenta na poziomie systemu operacyjnego.

Read-only — bezpieczna analiza

W trybie read-only agent może jedynie czytać pliki. Nie edytuje, nie uruchamia komend, nie wysyła żadnych danych przez sieć. To idealny tryb do:

• Odpowiadania na pytania o istniejący kod
• Wyjaśniania złożonej logiki legacy
• Przeglądu architektury bez ryzyka zmian

Workspace-write — balans bezpieczeństwa i produktywności

Domyślny tryb workspace-write pozwala na edycję plików w katalogu roboczym, ale blokuje dostęp do sieci. Agent może pisać kod i uruchamiać lokalne testy, ale nie wyśle nic na zewnątrz.

Danger-full-access — pełna moc, pełna odpowiedzialność

Tryb danger-full-access (uruchamiany flagą --yolo) daje agentowi pełny dostęp do systemu, włącznie z siecią. Używaj tylko wtedy, gdy dokładnie wiesz, co robisz — na przykład przy instalacji pakietów npm lub komunikacji z zewnętrznym API.

Chronione ścieżki: .git, .agents i .codex

Nawet w trybie workspace-write pewne katalogi pozostają chronione. Agent może je odczytywać, ale nie może ich modyfikować.

Ścieżki chronione domyślnie:

• /.git — historia repozytorium (read-only)
• /.agents — definicje agentów i umiejętności (read-only)
• /.codex — konfiguracja projektu (read-only)

Dlaczego to ważne? Wyobraź sobie, że atakujący wstrzykuje złośliwe instrukcje do prompta (prompt injection). Bez ochrony tych ścieżek mógłby zmodyfikować AGENTS.md, żeby zmienić zachowanie agenta na przyszłość, albo przepisać historię Git.

Ochrona ścieżek działa na poziomie systemu operacyjnego — nawet jeśli model „postanowi" zmodyfikować .git, system mu na to nie pozwoli.

Więcej o zabezpieczeniach danych w środowiskach AI znajdziesz w artykule o bezpieczeństwie i prywatności danych w ChatGPT.

OpenTelemetry: monitoring i audyt każdej operacji

Sama konfiguracja to połowa sukcesu. Druga połowa to wiedza o tym, co agent faktycznie robi. OpenAI Codex wspiera eksport zdarzeń przez OpenTelemetry (OTel).

Konfiguracja eksportu OTel

Dodaj do ~/.codex/config.toml:

[otel]
environment = "staging"
exporter = "otlp-http"
log_user_prompt = false  # Nie loguj pełnych promptów

[otel.exporter.otlp-http]
endpoint = "https://otel.twoja-firma.pl/v1/logs"

Ważne: Domyślnie prompty użytkownika są redagowane (log_user_prompt = false). To chroni przed przypadkowym logowaniem wrażliwych danych w promptach.

Praktyczna konfiguracja dla zespołów

Oto rekomendowane ustawienia dla typowych scenariuszy.

Scenariusz 1: Nowy programista w zespole

sandbox_mode = "workspace-write"
approval_policy = "untrusted"

Agent edytuje tylko w workspace i pyta przed każdą nietypową akcją.

Scenariusz 2: Senior developer na własnym branchu

sandbox_mode = "workspace-write"
approval_policy = "on-request"
network_access = true

Więcej swobody, ale nadal z ochroną przed destrukcyjnymi akcjami.

Scenariusz 3: Automatyzacja CI/CD

sandbox_mode = "read-only"
approval_policy = "never"

Agent tylko analizuje kod i raportuje — nie ma uprawnień do zmian.

Planując koszty wdrożenia, warto też przeanalizować cennik OpenAI Codex i możliwości optymalizacji.