Codex en privacy: sandboxing, training, retentie en de AVG-kant

Het model

Sandbox en approvals zijn twee losse lagen, en daar gaat het meestal mis

Voor je één instelling aanraakt: Codex regelt toegang met twee controls die samenwerken maar niet hetzelfde doen. De sandbox bepaalt wát mag (welke bestanden, welk netwerk). De approvals bepalen wannéér Codex pauzeert om te vragen. De documentatie zegt het zelf in één zin: "Changing who reviews a request doesn't expand the sandbox." Een soepelere goedkeuringsmodus geeft de agent dus geen extra toegang, alleen minder onderbrekingen.

Vier naamgevingsstelsels voor dezelfde materie

Wat het verwarrend maakt: OpenAI hanteert vier parallelle namenreeksen die niet één-op-één samenvallen. De sandbox-modi heten read-only, workspace-write en danger-full-access. De approval policies heten untrusted, on-request en never. De permissiemodi in de interface heten Ask for approval, Approve for me en Full access. En de permissieprofielen heten :read-only, :workspace en :danger-full-access. Tutorials die die vier door elkaar halen geven verkeerde instructies. Op deze pagina houden we ze uit elkaar, laag voor laag.

Waar je begint

De docs adviseren voor het meeste werk te starten met Ask for approval: die laat ChatGPT binnen je huidige workspace werken en pauzeert voordat die grens wordt overschreden. Vanaf daar bouw je op: eerst kijken welke prompts je écht krijgt, dan pas versoepelen. Wie meteen naar Full access springt, slaat de fase over waarin je leert wat de agent in jouw repo wil doen.

Sandbox

De drie sandbox-modi, en welke standaard aanstaat

De sandbox is de harde grens. Codex kiest zelf een startmodus op basis van je map: staat de map onder versiebeheer, dan is workspace-write de standaard; staat hij dat niet, dan is read-only de standaard. Dat verschil is met opzet zo: zonder Git kun je niets terugdraaien.

workspace-write is de dagelijkse stand

De documentatie noemt workspace-write de "default low-friction mode for local work". De agent werkt binnen de grenzen van je werkmap en het netwerk staat uit. Prettig detail dat weinig mensen kennen: ook binnen workspace-write blijven .git, .agents en .codex read-only. Je Git-historie en je eigen Codex-configuratie kan de agent dus niet stilletjes herschrijven, ook al mag hij de rest van de map wel aanpassen.

danger-full-access heet niet voor niets zo

Deze modus haalt zowel de bestandssysteem- als de netwerkgrens weg. De docs zetten er letterlijk "not recommended" bij en schrijven dat je hem alleen inzet wanneer die brede toegang bewust bedoeld is. In de praktijk betekent dat: een wegwerp-VM of een container waarin niets staat wat je erg vindt om kwijt te raken. Op je werklaptop met klantcode en SSH-sleutels hoort deze modus niet thuis.

De combinatie die je nooit per ongeluk aanzet

Sandbox-modus en approval policy stapelen. danger-full-access samen met approval_policy = "never" is de stand waarin de agent alles autonoom doet, inclusief netwerktoegang, zonder ooit te stoppen om iets te vragen. Dat is geen stand waar je in verzeild raakt: je moet hem in je configuratie bewust neerzetten. De veilige stand is de fabrieksinstelling, en dat is precies het uitgangspunt dat je in een team wilt verankeren. Wie deze combinatie nodig heeft voor een specifieke taak, draait die in een wegwerpomgeving en zet hem daarna terug.

Zo start je expliciet in een modus

Vertrouw niet op de standaard, kies bewust. De gedocumenteerde aanroepen:

codex --sandbox read-only --ask-for-approval on-request
codex --sandbox workspace-write --ask-for-approval on-request

En de vlag die je laat staan tenzij je in een wegwerpomgeving zit: --dangerously-bypass-approvals-and-sandbox (alias --yolo). Wil je testen wat de sandbox in jouw situatie tegenhoudt zonder de agent te starten, dan draai je een commando onder dezelfde regels met codex sandbox macos --log-denials [COMMAND]. Dat log met geweigerde operaties is de snelste manier om te zien of jouw buildscript straks tegen de sandbox aanloopt.

Onder de motorkap

Wat de sandbox technisch is, en waar hij stukloopt

Codex verzint geen eigen beveiligingslaag maar gebruikt de handhaving van het besturingssysteem zelf. Dat is goed nieuws voor je securityteam: het is dezelfde techniek die het OS voor andere afgeschermde processen gebruikt.

Drie valkuilen die je vooraf wilt weten

Ontbreekt bwrap op Linux of in WSL2, dan waarschuwt Codex bij het opstarten. Op Ubuntu 24.04 kan het nodig zijn een AppArmor-profiel te installeren voordat de sandbox werkt. En in Docker kunnen namespace- of setuid-operaties geblokkeerd worden, waardoor de sandbox niet opstart. De docs noemen daar --dangerously-bypass-approvals-and-sandbox als workaround bij, en dat is precies het moment om even stil te staan: die workaround schakelt de sandbox volledig uit. In een container die verder niets gevoeligs bevat is dat te verdedigen; als noodgreep op een machine met klantdata niet.

Versiebeheer is je tweede vangnet

De officiële aanbevelingen voor veilig werken staan los van de sandbox en zijn simpel: werk op feature branches, houd je git status schoon, gebruik patch-gebaseerde workflows met git diff en git apply, en commit regelmatig zodat je kunt terugrollen. De samenvattende zin uit de docs is de beste vuistregel die er is: "Treat Codex suggestions like any other PR: run targeted verification, review diffs." De sandbox voorkomt dat de agent buiten de lijntjes kleurt; versiebeheer voorkomt dat een fout bínnen de lijntjes blijft staan.

Approvals

De approval policies: untrusted, on-request en never

De tweede laag bepaalt wanneer Codex pauzeert. Drie beleidsopties, met elk een duidelijk gebruiksmoment. Onthoud opnieuw: dit verandert niets aan wat er technisch mág, alleen aan hoe vaak je gestoord wordt.

never is minder eng dan het klinkt, mits

Bij never verdwijnen alleen de vragen, niet de grenzen. In combinatie met --sandbox read-only of workspace-write is dat een normale CI-configuratie: de pipeline mag niet wachten op een mens, maar de agent kan ook niet buiten zijn hok. Gevaarlijk wordt het pas als je never combineert met danger-full-access, want dan is er niets meer dat tegenhoudt en niemand meer die kijkt.

Granulair instellen per categorie

Er is ook een granulaire approval policy waarmee je per categorie kiest of er gevraagd wordt. De gedocumenteerde categorieën zijn sandbox_approval, rules, mcp_elicitations, request_permissions en skill_approval. Handig als je merkt dat één soort prompt je constant onderbreekt: je zet die categorie uit en houdt de rest interactief, in plaats van in één klap alles op never te zetten.

De namen in de interface

In de grafische interface zie je andere woorden voor dezelfde materie: Ask for approval, Approve for me (in de instellingen "Auto-review" genoemd) en Full access. Wie in de Codex-commandoreferentie zoekt naar /approvals komt bedrogen uit: dat commando is op 4 mei 2026 vervangen door /permissions.

Profielen

Permissieprofielen: één keer instellen, overal gebruiken

Sandbox en approvals per sessie meegeven werkt, maar wordt vervelend zodra je meerdere projecten hebt. Daarvoor bestaan permissieprofielen: benoemde bundels die je per project of team kiest.

Eigen profielen en overerving

Een eigen profiel definieer je onder [permissions.<naam>] in je configuratie. Met de key extends erf je van een ingebouwd profiel of van een ander eigen profiel, zodat je bijvoorbeeld ":workspace plus één extra map" kunt vastleggen zonder alles opnieuw op te schrijven. Welk profiel standaard geldt zet je met default_permissions. Het advies uit de docs is kort en duidelijk: "Set it explicitly for predictable behavior." Laat je die leeg, dan hangt het gedrag af van de map waarin je toevallig staat.

Voor beheerders: profielen zijn afdwingbaar

Vanaf Codex 0.138.0 kunnen beheerders met allowed_permission_profiles bepalen welke profielen beschikbaar zijn. Dat is een tabel die profielnamen op booleans mapt, en het gedraagt zich als een veilige default-deny: weggelaten profielen worden geweigerd, inclusief weggelaten ingebouwde profielen én profielen die in toekomstige Codex-versies bijkomen. Een nieuwe permissieve modus in een volgende release komt er dus niet stiekem doorheen.

Auto-review

Auto-review: een tweede model dat jouw goedkeuringen afhandelt

Wie de hele dag op "Allow" klikt, klikt op een gegeven moment ook op de verkeerde. Auto-review vervangt die handmatige goedkeuring door een reviewer-agent. Let op wat er níét verandert: de hoofdagent blijft in exact dezelfde sandbox draaien. Alleen wie de knoop doorhakt verandert.

Aanzetten

Twee instellingen in je configuratie: approval_policy = "on-request" samen met approvals_reviewer = "auto_review". Vanaf dat moment beoordeelt de reviewer de verzoeken die anders bij jou waren geland.

Waarop de reviewer toetst

De gedocumenteerde beoordelingscategorieën zijn: het versturen van privédata, secrets of credentials naar niet-vertrouwde bestemmingen (exfiltratie), het zoeken naar credentials, tokens, cookies of sessiemateriaal, brede of blijvende verzwakking van beveiliging, en destructieve acties met significant risico op onomkeerbare schade. Auto-review komt in actie bij geëscaleerde shell- of exec-aanroepen, geblokkeerde netwerkverzoeken, bestandsbewerkingen buiten de writable roots, MCP- of app-toolaanroepen die goedkeuring vereisen, en Computer Use-toegang tot nieuwe websites.

Wat er wel en niet doorgelaten wordt

De uitkomst hangt aan een risiconiveau: laag en middelmatig mogen door, kritiek wordt altijd geweigerd en hoog risico vereist alsnog jouw toestemming. Er zit bovendien een circuit breaker op: 3 opeenvolgende weigeringen, of 10 weigeringen binnen 50 reviews, breken de beurt af. Codex bewaart tot 10 recente weigeringen per taak, en in de TUI keur je een geblokkeerde actie alsnog handmatig goed met /approve. Doe dat pas nadat je zelf hebt gekeken wát er geblokkeerd werd; het commando bestaat om een terechte blokkade te kunnen overrulen, niet om er blind langs te klikken.

Eigen beleid

De standaard reviewer-policy staat in de open-source Codex-repository, dus je kunt hem nalezen voordat je erop vertrouwt. Organisaties overschrijven hem met guardian_policy_config; lokaal zet je [auto_review].policy in config.toml. Dat is de plek om bedrijfsspecifieke regels toe te voegen, bijvoorbeeld over interne domeinen of over mappen waar niets uit mag.

Netwerk

Netwerktoegang staat uit, en dat is je sterkste rem

De meeste privacyrisico's bij een coding-agent lopen via het netwerk: code die naar buiten gaat, instructies die naar binnen komen. Codex zet netwerktoegang daarom standaard uit, tenzij je hem expliciet inschakelt. Lokaal doe je dat met [sandbox_workspace_write] network_access = true. Denk twee keer na voordat je die regel toevoegt en laat hem daarna niet permanent staan.

Wel netwerk nodig? Zet er een proxy met domeinregels voor

Uitgaand verkeer kan door een netwerkproxy die per domein toestaat of blokkeert. In configuratievorm: [features.network_proxy] enabled = true met bijvoorbeeld domains = { "api.openai.com" = "allow", "example.com" = "deny" }. De matchingregels staan in de tabel hierboven; let vooral op het verschil tussen één en twee sterretjes, want dat bepaalt of je apex-domein wel of niet meedoet.

De bescherming die je niet ziet

Binden aan lokale en private adressen is standaard geblokkeerd via allow_local_binding = false. Belangrijker: hostnames die naar niet-publieke adressen resolven worden geblokkeerd, óók als ze op de allowlist staan. Dat is een bewuste bescherming tegen DNS-rebinding en tegen verzoeken naar interne services (SSRF). Er bestaan twee opties die dat opzij zetten, dangerously_allow_non_loopback_proxy en dangerously_allow_all_unix_sockets; de naam is het advies.

Wat dit voor je bedrijfsnetwerk betekent

Draait Codex op een laptop die via VPN aan je interne netwerk hangt, dan is de standaard-uit-stand precies wat je wilt. Zet je netwerktoegang aan, doe het dan met een allowlist die alleen je package-registry en je eigen Git-host bevat. Een agent die npm mag bereiken heeft nog geen reden om ook een willekeurige pastebin te kunnen bereiken.

Cloud

Codex cloud: containers, secrets en internet per fase

Delegeer je een taak naar de cloud, dan verschuift het hele plaatje. Codex maakt een container aan en checkt je repository uit op de branch of commit-SHA die je kiest. Vanaf dat moment gelden andere regels dan lokaal, en die wil je kennen voordat je klantcode naar boven stuurt.

Het verschil tussen secrets en omgevingsvariabelen is een privacybeslissing

Secrets zijn alleen beschikbaar voor je setup-scripts en worden om veiligheidsredenen verwijderd voordat de agentfase begint. Omgevingsvariabelen blijven de hele sessie staan en zijn dus wél zichtbaar voor de agent. Zet een API-sleutel daarom in secrets, niet in een omgevingsvariabele, ook al is dat laatste sneller opgeschreven.

Internettoegang instelbaar per omgeving

De documentatie is expliciet: "By default, Codex blocks internet access during the agent phase." Zet je het aan, dan kies je uit drie voorgedefinieerde allowlists: None (je begint met een lege lijst en voegt zelf domeinen toe), Common dependencies (vooraf goedgekeurde domeinen voor ontwikkeltools) of All (onbeperkt). Extra domeinen toevoegen kan altijd.

De instelling die exfiltratie het meest afremt

Je kunt de toegang beperken tot de HTTP-methoden GET, HEAD en OPTIONS. POST, PUT, PATCH en DELETE worden dan geblokkeerd. Dat is een simpele maar effectieve rem: de agent kan wel documentatie en pakketten ophalen, maar niets naar buiten schrijven. Voor teams die twijfelen of ze cloudtaken aandurven, is dit de instelling om mee te beginnen.

Prompt injection

Prompt injection: wat OpenAI zelf toegeeft en adviseert

Dit is geen theoretisch risico dat wij erbij verzinnen: OpenAI benoemt het in de eigen documentatie. Zodra Codex webinhoud leest, kan die inhoud instructies bevatten die de agent probeert over te nemen. De documentatie zegt letterlijk: "Prompt injection can cause the agent to fetch and follow untrusted instructions" en "Use caution when enabling network access or web search in Codex."

De officiële aanbeveling, in één zin

"Point Codex only to trusted resources and keep internet access as limited as possible." Aanvullend adviseert OpenAI om de output en de werklogboeken van de agent te reviewen, en om domeinen en HTTP-methoden te beperken tot wat strikt nodig is. Dat sluit precies aan op de allowlist en de GET-only-instelling uit de vorige sectie.

Webzoeken verlaagt het risico, het verdwijnt niet

Over websearch is de documentatie ongewoon eerlijk: "Treat all web results as untrusted input." De cached modus gebruikt een door OpenAI onderhouden index in plaats van willekeurige pagina's live op te halen, en dat "lowers, but doesn't remove, prompt injection risk". Lees dat laatste zoals het er staat: een index maakt het kleiner, niet nul. Behandel wat de agent van internet meebrengt als input van een onbekende, niet als een feit.

Wat dit praktisch betekent voor je team

Drie werkafspraken die het meeste opleveren. Eén: zet netwerktoegang alleen aan voor taken die het nodig hebben, en zet hem daarna weer uit. Twee: lees de diff, niet alleen de samenvatting van de agent, want een geslaagde injectie ziet er in de samenvatting normaal uit. Drie: laat de agent geen taken doen waarbij hij zowel gevoelige data ziet als naar buiten mag schrijven. Die combinatie is waar exfiltratie mogelijk wordt.

Computer Use

Computer Use, browsergebruik en Developer mode

Codex kan verder gaan dan bestanden: met Computer Use ziet en bedient hij grafische interfaces op macOS of Windows, inclusief vensters, menu's, toetsenbordinvoer en de clipboardstatus. Dat is de functie met de grootste privacyafdruk, want er worden screenshots van je scherm gemaakt.

Waar die screenshots onder vallen

Screenshots die Computer Use maakt vallen onder je ChatGPT data controls. Staat modeltraining bij jou aan, dan geldt die instelling dus ook voor wat er op je scherm stond. Bestandsbewerkingen en shellcommando's blijven daarnaast gewoon de approval- en sandboxinstellingen volgen waar die van toepassing zijn.

De officiële adviezen bij Computer Use

Vermijd taken waarvoor secrets nodig zijn. Blijf aanwezig bij gevoelige flows in plaats van de agent alleen te laten. Houd gevoelige applicaties gesloten tijdens een run. En annuleer de taak zodra ChatGPT met het verkeerde venster begint te interacteren. Als beheerder zet je de hele functie uit met features.computer_use = false.

De ingebouwde browser is bewust afgeschermd

Bij browsergebruik waarschuwt OpenAI: "Instructions on a page can be misleading or malicious. A website permission lets ChatGPT interact with that site; it doesn't make the site's content trustworthy or approve every action." De ingebouwde browser gebruikt een profiel dat gescheiden is van je gewone browser, deelt niet automatisch je tabbladen of sessie, en kan niet inloggen, niet om credentials vragen en je bestaande ingelogde sessie niet gebruiken. Browsergebruik zit alleen in ChatGPT web en de desktop-app; de Codex CLI en de IDE-extensie ondersteunen het niet.

Developer mode en volledige CDP-toegang

Voor diepere browserdebugging bestaat Developer mode, die Codex gecontroleerde toegang geeft tot het Chrome DevTools Protocol. Je zet het aan via Settings, dan Browser, dan "Enable full CDP access" onder Developer mode. De waarschuwing uit de docs: "Full CDP access lets Codex inspect and control sensitive browser internals that may put your data at risk." Codex vraagt expliciet om goedkeuring voordat hij volledige CDP-toegang gebruikt. Beheerders zetten het uit met browser_use_full_cdp_access = false; wie browsergebruik helemaal uitschakelt, schakelt CDP daarmee ook uit.

Cyber-safety draait op de achtergrond mee

Naast jouw instellingen draait er monitoring van OpenAI zelf: "Automated classifier-based monitors detect signals of suspicious cyber activity and route high-risk traffic to a less cyber-capable model (GPT-5.2)." Het model is bovendien getraind om duidelijk kwaadaardige verzoeken te weigeren, zoals het stelen van credentials. Loop je als securityprofessional tegen valse positieven aan, dan bestaat het programma Trusted Access for Cyber: individuele verificatie via chatgpt.com/cyber, enterprises via hun OpenAI-contactpersoon. Valse positieven meld je met /feedback.

Training

Traint OpenAI op je code? Dat hangt volledig van je abonnement af

Hier zit het grootste verschil tussen thuisgebruik en werkgebruik, en het is scherper dan veel mensen denken. OpenAI noemt Codex expliciet bij de diensten voor individuen: "When you use our services for individuals such as ChatGPT and Codex, we may use your content to train our models." Voor zakelijke producten geldt het omgekeerde.

Zo zet je het uit op een consumentenabonnement

Twee routes. Via de interface: profielicoon, dan Settings, dan Data Controls, en zet "Improve the model for everyone" uit. De instelling synchroniseert over je hele account, ongeacht apparaat, en je mag hem op elk moment weer wijzigen. Je gesprekken blijven gewoon in je geschiedenis staan; dit gaat alleen over training. De tweede route loopt via het privacyportaal van OpenAI met het verzoek "do not train on my content". Na de opt-out worden nieuwe gesprekken niet meer voor training gebruikt.

De opt-out die je bijna zeker mist

Codex heeft aparte controls voor training op volledige omgevingen ("full environments"), te beheren in de Codex Settings. OpenAI waarschuwt er expliciet bij: aanpassingen in de ChatGPT-interface of in het privacyportaal hebben géén effect op deze full-environment-instellingen. Wie denkt dat één schakelaar in Data Controls alles afdekt, heeft deze dus laten openstaan. Loop hem apart na.

En het duimpje

Ook met training uitgezet geldt: geef je feedback op een antwoord, bijvoorbeeld een duim omhoog of omlaag, dan kan het volledige bijbehorende gesprek alsnog gebruikt worden om modellen te trainen. Voor een chat over je weekendplannen is dat prima. Voor een sessie waarin de agent door een klantrepository liep, is het dat niet.

Zakelijk is het simpeler

De formulering van OpenAI: "By default, we do not train on any inputs or outputs from our products for business users, including ChatGPT Business, ChatGPT Enterprise, and the API." Codex-specifiek bevestigt de FAQ het nog een keer: "Does using Codex change OpenAI's training policy for Business workspace data? No." Wat je verder wel moet weten: je ChatGPT data controls gelden ook voor content die door Codex verwerkt wordt, inclusief de screenshots van Computer Use. Lokale workflows draaien op je eigen apparaat, cloudtaken in door OpenAI beheerde omgevingen. Het bredere kader per abonnement staat op Privacy en zakelijk gebruik.

Retentie

Hoe lang alles blijft staan, per soort data

Retentie is geen enkel getal maar een verzameling termijnen die per datasoort verschillen. Dit is wat uit officiële bron hard te maken is.

Archiveren is geen privacymaatregel

Archiveren verbergt een chat alleen uit je zijbalk. Gearchiveerde chats vallen onder precies dezelfde retentieregels als de rest. Wil je iets echt weg hebben, dan verwijder je het; dat haalt de chat direct uit je account en plant permanente verwijdering uit de systemen van OpenAI binnen 30 dagen, tenzij die al gede-identificeerd is of langer bewaard moet blijven om beveiligings- of wettelijke redenen. Verwijderen is onomkeerbaar.

Chats en bestanden zijn twee aparte dingen

Bestanden die je in een gesprek uploadt gaan naar Library waar die beschikbaar is, en die worden apart beheerd. Een chat verwijderen verwijdert het Library-bestand dus niet. In Enterprise-, Edu- en Healthcare-workspaces volgen Library-bestanden de retentiepolicy van de workspace. Na verwijdering of vervallen is een bestand direct niet meer beschikbaar via de Compliance API, maar interne back-ups kunnen het nog tot 30 extra dagen bewaren.

Temporary Chat voor eenmalig gevoelig werk

Een Temporary Chat komt niet in je geschiedenis, maakt geen memories aan, wordt niet voor training gebruikt en verdwijnt binnen 30 dagen vanzelf. OpenAI mag hem alleen bekijken om misbruik te monitoren. Voor een eenmalige vraag over gevoelige code is dat de kortste route naar een schone situatie.

Voor compliance-teams

Compliance Logs zijn maximaal 30 dagen beschikbaar, dus wie langer moet kunnen terugkijken exporteert ze naar een eigen systeem. De documentatie zegt daar iets bij dat je in je beleid wilt overnemen: "Don't assume the source retention window replaces your organization's retention policy." Test de ingestie eerst in een niet-productie-SIEM of data lake en plan continue verzameling in met je eigen toegangs-, retentie- en legal-hold-controls.

Beheer

Wat je als organisatie kunt afdwingen met requirements.toml

Losse instellingen op de laptop van elke developer houden geen stand. Codex kent daarom managed configuration, met een onderscheid dat je meteen moet snappen: requirements zijn afgedwongen beperkingen die een gebruiker niet kan overschrijven, managed defaults zijn startwaarden die de gebruiker tijdens runtime wél mag aanpassen en die bij de volgende start opnieuw worden toegepast.

Waar de systeembestanden staan

Het systeem-requirements.toml verwacht Codex in /etc/codex/ op Unix-achtige systemen en in %ProgramData%\OpenAI\Codex\ op Windows. Legacy managed_config.toml-velden worden geherinterpreteerd als requirements, dus een oude uitrol blijft werken; controleer wel of die nog doet wat je bedoelt.

De keys die er voor privacy toe doen

Met allowed_sandbox_modes beperk je de beschikbare modi, bijvoorbeeld tot ["read-only", "workspace-write"] om danger-full-access organisatiebreed onmogelijk te maken. Met allowed_approval_policies (bijvoorbeeld ["on-request"]) leg je vast wanneer er gevraagd moet worden. Met allowed_approvals_reviewers bepaal je wie beoordeelt: ["auto_review"] dwingt de reviewer-agent af, met "user" erbij mag het teamlid zelf kiezen. guardian_policy_config bevat je eigen beleidstekst voor auto-review. En met [[remote_sandbox_config]] plus hostname_patterns zet je host-specifieke overrides voor bijvoorbeeld build-machines.

Functies helemaal uitzetten

Wat je niet aanzet, kan ook niet lekken. Afdwingbaar: features.computer_use = false schakelt Computer Use volledig uit, features.plugins = false schakelt het pluginsysteem uit, browser_use_full_cdp_access = false blokkeert volledige Chrome DevTools Protocol-toegang, [rules] decision = "forbidden" blokkeert specifieke commando's (requirements-rules kennen geen "allow"), en [marketplaces] restrict_to_allowed_sources = true beperkt marketplace-operaties tot goedgekeurde bronnen. Voor macOS bestaat daarnaast allow_locked_computer_use.

Netwerk op organisatieniveau

Beheerders beschikken over [experimental_network] met de keys enabled, allowed_domains, denied_domains en managed_allowed_domains_only voor een exclusieve allowlist. Deny overschrijft allow. Twee kanttekeningen die de documentatie zelf maakt: dit blok is experimenteel en kan veranderen, en je test het expliciet voordat je uitrolt. Deze admin-requirements staan bovendien los van de gebruikersinstelling features.network_proxy.

MCP-servers en plugins

Allowlists voor MCP-servers vereisen dat zowel de naam als de identiteit overeenkomen; servers die niet matchen worden automatisch uitgeschakeld. Bij een conflict met een afgedwongen regel valt de lokale client terug op een compatibele waarde en wordt de gebruiker geïnformeerd. Eén eerlijke kanttekening: op de MCP-configuratiepagina van Codex staat geen expliciete securityguidance, geen waarschuwing over verbinden met niet-vertrouwde MCP-servers en geen beschrijving van welke data zo'n server kan benaderen. De enige trustvermelding is dat project-scoped configuraties bedoeld zijn voor "trusted projects". Wie MCP breed uitrolt, moet dat beleid dus zelf schrijven; hoe wij dat bij plugins en skills aanpakken staat daar beschreven.

Lokaal en cloud zijn apart te sturen, en alles is auditbaar

Managed workspaces kunnen Codex Local (CLI, IDE-extensie en desktop-workflows) en Codex Cloud afzonderlijk aanzetten. Remote Control kan aparte workspace-inschakeling of een RBAC-permissie vereisen, en het apparaat moet discovery en control toestaan in de ChatGPT desktop-instellingen. Toegang tot Codex zelf ken je toe via RBAC; startmodel, redeneerniveau, snelheid, beschikbaarheid van Fast Mode en nieuw-chatgedrag stel je in onder Workspace settings, dan Models. Bij conflicten geldt: afgedwongen requirements.toml gaat vóór workspace-startdefaults, en die gaan vóór de lokale keuze van het teamlid. Belangrijk voor je auditverhaal: Codex-gebruik zit in de Compliance API, inclusief lokale clients als de CLI en de IDE-extensie, dus ook wat op de laptop van een developer draait is terug te zien.

Telemetrie

Telemetrie staat uit; zet hem pas aan als je weet wat je logt

Codex verstuurt standaard geen telemetrie: lokale runs zijn self-contained. Wil je toch inzicht, dan schakel je OpenTelemetry expliciet in. Dat is een bewuste keuze met een privacyafweging erbij, want je bepaalt zelf hoeveel er in je logs belandt.

Wat er gelogd wordt

De geregistreerde eventtypes zijn: starts van gesprekken, API-verzoeken, tool-beslissingen en tool-resultaten. Dat is genoeg om gebruik en kosten te volgen zonder dat je de inhoud van het werk hoeft mee te sturen.

De officiële privacy-aanbevelingen

Drie regels uit de documentatie. Eén: "Keep log_user_prompt = false unless policy explicitly permits." Twee: stuur telemetrie alleen naar collectors die je zelf beheert. Drie: redigeer tool-argumenten en tool-outputs op collectorniveau, want daar kunnen bestandsinhoud en paden in zitten. Nog een praktisch gegeven: telemetrie kan niet geëxporteerd worden als netwerktoegang uitstaat. Wie de sandbox strak dichtzet, heeft dus geen telemetrie, en dat is een bewuste ruil.

Als beheerder uitrollen

De OTel-instellingen zijn als managed defaults uit te rollen: [otel].exporter, [otel].environment en log_user_prompt, waarbij de documentatie false aanbeveelt vanuit privacyoogpunt. Zet dat vast voordat je Codex breed uitrolt, in plaats van erop te vertrouwen dat niemand het aanzet.

AVG

De AVG-kant: DPA, dataresidentie en de uitzondering die je moet kennen

Voor een Nederlands bedrijf komt het neer op vier vragen: is er een verwerkersovereenkomst, waar staat de data, wie kan erbij, en wat moet je zelf documenteren. De eerste drie zijn deels uit officiële bron te beantwoorden; de vierde blijft jouw werk.

Dataresidentie in Europa, met één harde uitzondering voor Codex

Data residency (opslag in rust) voor ChatGPT is beschikbaar voor Europa (EER plus Zwitserland). Inference residency, waarbij de GPU-uitvoering in de regio blijft, is beschikbaar voor Europa (EER plus Zwitserland), de VS en de VAE, en vereist dat data residency in dezelfde regio aanstaat. Voor ChatGPT Enterprise en Education zit data residency zonder meerkosten inbegrepen. En dan de uitzondering die je moet kennen voordat je iets belooft aan je functionaris gegevensbescherming: Codex Web staat expliciet in de lijst van functies die niet in aanmerking komen voor data- of inference-residency, met de toevoeging "(the Codex app and CLI are supported)". Heb je residency in de EER nodig, dan gebruik je Codex dus via de app en de CLI, niet via de webvariant.

Wat residency niet dekt

Data residency dekt alleen customer content voor de ondersteunde functies. Buiten de regio kunnen worden opgeslagen: data die via externe integraties (Apps en MCP, Web Search) buiten de infrastructuur van OpenAI verwerkt wordt, transiënte verwerkingsstappen, en workspace-metadata zoals workspacenaam, factuurgegevens en gebruikerslogins. Inference residency garandeert alleen de GPU-uitvoering in de regio: CPU-verwerking, authenticatie, routering, indexering en logging zonder content kunnen elders plaatsvinden. Zodra data naar een externe provider gaat, valt die onder de residency-, beveiligings- en compliancevoorwaarden van díé provider.

Twee Codex-functies die in de EER niet bestaan

Sites in Codex is beschikbaar op betaalde ChatGPT-abonnementen behalve Free en Go, maar: "Sites is not currently available in the European Economic Area, Switzerland, or the United Kingdom." Record & Replay, waarmee je een workflow opneemt en omzet in een herbruikbare skill, draait in de macOS desktop-app, maar de initiële beschikbaarheid sluit de Europese Unie, Zwitserland en het Verenigd Koninkrijk uit. Het vereist bovendien dat Computer Use beschikbaar en ingeschakeld is. OpenAI adviseert opnames op de taak gericht te houden en tijdens het opnemen geen secrets of gevoelige data in te voeren.

EU AI Act

OpenAI publiceert conform artikel 53(1)(d) van de EU AI Act samenvattingen van de content die gebruikt is om general-purpose AI-modellen te trainen, en verwijst naar het eigen Frontier Governance Framework en Preparedness Framework. Er is een EU AI Act Reporting Form voor EU-klantondersteuning en het opvragen van modeldocumentatie. OpenAI zegt er expliciet bij dat klanten, ontwikkelaars en gebruikers zelf verantwoordelijk zijn voor het beoordelen en naleven van hun eigen verplichtingen, en dat de informatie geen juridisch advies is. Wat dat concreet voor jouw uitrol betekent, moet je dus zelf vastleggen. De bredere Nederlandse context, inclusief wat de Autoriteit Persoonsgegevens over generatieve AI zegt, staat op Privacy en zakelijk gebruik.

Ter vergelijking: Claude Code

Werk je in een team dat beide tools overweegt, dan is de vergelijking eerlijker als je dezelfde vragen aan beide stelt. Ons overzicht van de privacykant van de tegenhanger staat op Claude Code. Grote lijn: ook daar draait de client lokaal en het model niet, ook daar is de belangrijkste knop welk abonnement je hebt, en ook daar zit het risico in wat de agent mag doen, niet alleen in wat je typt.

Business

Twee dingen die ChatGPT Business niet kan, en één datum

Business is voor veel Nederlandse mkb-bedrijven het logische abonnement, maar er zijn drie punten die je vooraf wilt weten omdat ze je beleid raken.

De datum, precies

De formulering van OpenAI: "Starting June 24, 2026, Codex seats will no longer be available to new ChatGPT Business plans, or to Business workspaces that never added a Codex seat prior to June 24 2026." Workspaces die vóór die datum al een Codex-seat hadden toegevoegd, inclusief openstaande uitnodigingen op die dag, kunnen usage-based Codex-seats blijven beheren en toevoegen. Begin je nu als Business-workspace met Codex, dan is dit het eerste wat je moet uitzoeken.

Wat admins wél en niet zien

Elke gebruiker heeft een eigen chat- én Codex-geschiedenis; andere leden zien die niet automatisch. Spend-controls tonen operationele metrics zoals gebruik en credits, maar geven geen toegang tot privé-chatgeschiedenis. Tegelijk geldt wat hierboven al stond: workspace-admins kunnen gesprekken van eindgebruikers wel bekijken, openen, exporteren en verwijderen. Zet dat eerlijk in je interne AI-richtlijn, want het is precies het punt waarop medewerkers zich anders overvallen voelen.

Codex zit ook op de gratis abonnementen

Voor de volledigheid, en het is relevant voor je shadow-IT-risico: "Codex is included across ChatGPT plans, including Free and Go. Usage limits vary by plan." De clients zijn de ChatGPT desktop-app (Codex mode), de Codex CLI, de Codex IDE-extensie en Codex web. Iemand in je team kan Codex dus vandaag op een privéaccount installeren en op bedrijfscode zetten, met het consumententrainingsbeleid erbij. Dat maakt een expliciete afspraak over accounts belangrijker dan een technische blokkade.

Checklist

De instellingen die je vandaag zet

Alles hierboven samengebald tot wat je in een half uur kunt doen. Werk je op een consumentenabonnement, begin dan bij stap 1. Rol je Codex uit voor een team, begin dan bij stap 5.

Open punten

Wat wij niet uit officiële bron konden bevestigen

Deze pagina bevat alleen wat in de documentatie van OpenAI staat. Waar die documentatie zwijgt of zichzelf tegenspreekt, zeggen we dat, in plaats van een aannemelijk klinkend antwoord te verzinnen. Dit zijn de punten die op 1 augustus 2026 openstonden.

Geen Codex-specifieke retentietermijn

Er is geen document dat expliciet stelt hoe lang OpenAI Codex-taken, cloudtaaklogs of CLI-sessietranscripten bewaart. Hard bevestigd zijn alleen de generieke ChatGPT-retentie (30 dagen na verwijdering), de containercache van 12 uur en de compliance-logs van 30 dagen. Wie een exacte termijn in een verwerkingsregister moet zetten, vraagt die op bij OpenAI in plaats van hem af te leiden.

De full-environment-instelling is niet gelokaliseerd

OpenAI bevestigt dat er aparte trainingscontrols voor volledige omgevingen bestaan en dat die los staan van de ChatGPT-brede opt-out, maar de bron beschrijft niet welk scherm het precies is, wat de standaardwaarde is en welke data er exact onder valt. Loop je Codex Settings dus met eigen ogen na.

Twee inconsistenties tussen officiële pagina's

De docs zijn niet eenduidig over de toegestane waarden van web_search: op de ene pagina staat "cached" als standaard met "live" als alternatief, elders duiken "indexed" en "disabled" op. Wij noemen daarom geen configuratiewaarde die we niet kunnen garanderen; verifieer die in de config-reference voordat je hem overneemt. Daarnaast spreekt de Data Controls FAQ nog van "Team, Enterprise, and Edu", terwijl de trainings- en enterprise-pagina's consequent "ChatGPT Business, ChatGPT Enterprise" hanteren. Waarschijnlijk is dat een niet-bijgewerkte verwijzing naar de oude naam Team, maar wij leiden dat niet zelf af.

De approval policy on-failure hebben wij niet gevonden

Oudere artikelen noemen een vierde approval policy, on-failure. In de officiële pagina's die wij op 1 augustus 2026 gelezen hebben staan alleen untrusted, on-request en never. Neem on-failure dus niet als bestaand aan zonder verificatie in de config-reference.

Juridische details die achter een muur zitten

De sub-processorlijst van OpenAI (welke partijen data verwerken en in welke landen) staat achter het Trust Portal met authenticatie, en de DPA zelf achter een formulier. Welk transfermechanisme OpenAI hanteert voor doorgifte naar de Verenigde Staten is daardoor niet uit de openbare bronnen op te maken. Voor een volledige AVG-analyse, inclusief artikel 28 lid 4, heb je die documenten nodig; vraag ze op voordat je tekent.

Vier vragen die de documentatie niet beantwoordt

Eén: waar de data van de Codex CLI en de Codex-app precies landt bij een workspace met EER-residentie, en of cloudtaken die je vanuit de CLI delegeert onder die garantie vallen. Twee: of Zero Data Retention beschikbaar is voor Codex-gebruik via de API, en zo ja voor welke endpoints. Drie: retentietermijn en dataverwerking van Codex Enterprise Analytics. Vier: of en hoe OpenAI prompt injection binnen Codex zelf detecteert of blokkeert, buiten de cyber-safety-classifiers en de auto-review-policy om; auto-review noemt exfiltratie en credential probing wel, maar prompt injection niet als eigen beoordelingscategorie. Tot slot een werkafspraak die OpenAI zelf meegeeft voor je rapportages: "Don't build a durable reporting contract from dashboard labels or downloaded report fields; those can change as the product evolves."