OpenAI Codex Governance: Controls die een developer niet kan uitschakelen

Waarom coding agents een op zichzelf staand governance-probleem zijn

Elke andere AI-workload draait op infrastructuur die uw eigendom is — uw cluster, uw netwerkbeleid, een credential die u kunt roteren. Codex is een CLI-proces op de laptop van een developer dat een TOML-bestand in hun home-directory leest en rechtstreeks communiceert met een model provider. Vijf eigenschappen maken dit een heel ander type probleem:

De gebruikelijke reflex is een beleidsdocument. Dat mislukt om één reden: alles wat daarin wordt gevraagd, staat in een bestand dat de developer kan bewerken.

Wat “gebeheerd” daadwerkelijk moet betekenen

Vier eigenschappen moeten bij elk request gelden:

• Identiteit. Het request bevat de individuele developer, niet een team-key. Een gedeelde key zorgt ervoor dat elke downstream control — rate limits, budgetten, toewijzingen, audit — herleid wordt tot één betekenisloze principal.
• Modelbeheer. Welke modellen een developer kan bereiken is een beveiligings- en kostenbeslissing. Prijzen verschillen met een factor tien tussen tiers; gegevensverwerkingsvoorwaarden verschillen per provider.
• Uitgaventoewijzing. Per developer, per team, per repository — de gebruikelijke verrassingspost op de factuur zodra dertig engineers een agent in gebruik nemen (AI coding agent pricing).
• Audit die de developer niet kan uitschakelen. Logging achter een lokale flag is geen audit; het is een verzoek.

Een gateway biedt u alle vier — maar alleen als de client daarnaar wijst en daarnaar blijft wijzen. Er zijn drie benaderingen daarvoor, en slechts één daarvan is enforcement:

Het vergrendelen van het bestand zonder de token te roteren pakt manipulatie aan, maar negeert diefstal van credentials; roteren zonder vergrendelen doet het omgekeerde. U heeft beide nodig.

Waar teams de fout in gaan

Het account bij de model provider zien als het controlepunt. Identiteit, SSO, workspace-lidmaatschap en beheerdersconsole-beleid voor Codex bevinden zich in de console van OpenAI, niet in uw gateway — net zoals de bewaartermijn van prompts en outputs, die "wordt beheerd door uw overeenkomst met OpenAI". Een gateway beheert routing, uitgaven, guardrails en de eigen logging, niet uw providercontract.

Ervan uitgaan dat één MDM-push gelijkstaat aan permanente enforcement. Clients wijzigen de configuratieprioriteit tussen releases. Codex v0.149.0 heeft managed_config.toml op Windows volledig laten vallen — het negeert het bestand nu met een opstartwaarschuwing (Ignoring deprecated managed config file), zonder equivalent in het register. Een fleet die vóór die release is geconfigureerd, is niet onderworpen aan enforcement en meldt geen fout.

Een gedeelde API key uitrollen. De snelste manier om dertig developers aan het werk te krijgen, en het vernietigt direct elke downstream control. U kunt een persoon niet rate-limiten of de vraag "wie heeft die prompt verzonden" beantwoorden vanuit een tenant-brede credential.

Wilt u zien hoe beheerd coding-agent-verkeer er in de praktijk uitziet?

Wijs één Codex-installatie naar een gateway en bekijk de trace.

Gratis aan de slag

Hoe dit werkt in TrueFoundry

Codex behandelt de TrueFoundry AI Gateway als een model provider; al het andere vloeit voort uit het feit dat verkeer aankomt op een plek die u beheert. De gateway-details zijn afkomstig uit het codesnippet in de UI.

Auth-mode 1 — API key

De vorm voor één developer: de token gaat in Authorization en de gateway herleidt deze naar een persoon.

model = "gpt-5.2-codex"
model_provider = "truefoundry"

[model_providers.truefoundry]
name = "TrueFoundry AI Gateway"
base_url = "{GATEWAY_BASE_URL}"
wire_api = "responses"

[model_providers.truefoundry.http_headers]
Authorization = "Bearer TFY_API_KEY"

Auth-mode 2 — ChatGPT Business/Enterprise

Het ChatGPT-abonnement van de developer betaalt voor inference en de gateway beheert nog steeds het verkeer. Twee dingen veranderen: requires_openai_auth = true is vereist, en de TrueFoundry-credential verhuist van Authorization naar x-tfy-api-key, omdat Codex Authorization nodig heeft voor de eigen ChatGPT OAuth-token.

model = "gpt-5.2-codex"
model_provider = "truefoundry"

[model_providers.truefoundry]
name = "TrueFoundry AI Gateway"
base_url = "{GATEWAY_BASE_URL}"
wire_api = "responses"
requires_openai_auth = true

[model_providers.truefoundry.http_headers]
x-tfy-api-key = "TFY_API_KEY"

Maak aan de gateway-zijde een provider aan onder Integrations → Providers van het type OpenAI, base-URL https://chatgpt.com/backend-api/codex, en laat het veld voor de API key leeg.

Het lege veld is het signaal, geen omissie. Als er een opgeslagen key aanwezig is, gebruikt de gateway die in plaats van de ChatGPT-credentials van de developer — waardoor de abonnementsflow wordt onderbroken en het verkeer mogelijk onder het verkeerde account wordt gerouteerd. Een beheerder die dat veld "behulpzaam" invult, verandert dertig individueel toegewezen developers in één anonieme API-key-tenant, zonder dat er foutmeldingen verschijnen.

Wanneer u het leeg laat, krijgt u dubbele toewijzing: TrueFoundry registreert de developer via x-tfy-api-key, OpenAI wijst het gebruik toe aan hun ChatGPT-seat. Model-IDs zien eruit als chatgpt-codex/gpt-5.2-codex.

Twee beperkingen vloeien voort uit het feit dat de credential is gekoppeld aan één ChatGPT-account. Slechts één van de targets van een virtueel model kan een ChatGPT-abonnementsmodel-account zijn; targets op basis van een API key kunnen er naast bestaan. En een 401, 403 of 429 per developer plaatst het gedeelde target niet in de load-balancer-cooldown, dus de verbruikte quota van één developer kan geen invloed hebben op iemand anders.

(De documentatie spreekt zichzelf tegen over welke abonnementen in aanmerking komen: de enterprise-security-pagina vermeldt Business of Enterprise, de CLI-pagina vermeldt ook Personal. [VERIFIËREN] alvorens een tier te garanderen.)

Waarom wire_api = "responses" verplicht is

Dit is de regel die teams verkeerd kopiëren en vervolgens een middag lang zitten te debuggen. De gateway voegt het /responses-endpoint alleen toe voor de Responses-wire. Stel wire_api = "chat" in en het request gaat naar /chat/completions tegen dezelfde base-URL, wat geen geldig endpoint is voor Codex-verkeer. Dit is tevens wat ervoor zorgt dat gpt-5.x-codex thinking-tokens correct werken.

De Codex CLI-pagina formuleert het wat milder — responses voor gpt-5.x-codex, chat voor andere modellen. Ze komen overeen: voor modellen uit de Codex-familie is de Responses-wire verplicht.

Virtual Model-slugs moeten overeenkomen met de echte model-ID

Codex stuurt thinking-tokens naar bepaalde modellen en identificeert deze door de model-string te vergelijken. Volledig gekwalificeerde namen — openai-main/gpt-5, azure-openai/gpt-5 — komen niet overeen, waardoor feature-detectie mislukt.

De regel: gebruik een slug die overeenkomt met de daadwerkelijke model-ID, bijv. gpt-5.2-codex. Codex herkent die IDs en schakelt de juiste functies in. Zet de volledig gekwalificeerde naam niet in de Codex-configuratie.

Slugs zijn uniek binnen de tenant en worden ingesteld in de Virtual Model Provider Group settings. Zowel de slug als het volledige groep/model-pad werken in een request body; Codex heeft de slug-vorm nodig.

Achter één slug kunt u targets wegen — openai-main/gpt-5 op 70, azure-openai/gpt-5 op 30 — en de verhouding aanpassen zonder een laptop aan te raken, zoals bij model deprecations and staged cutovers.

De naamgeving van slugs is ook het punt waar clients sterk van elkaar verschillen. Cursor kiest het request-formaat op basis van trefwoorden in de slug en wisselt stilzwijgend van formaat als de slug anthropic, claude, openai, gpt, gemini of vertex bevat. Codex wil de model-ID in de slug; Cursor wil die trefwoorden er juist uit.

Fleet-handhaving via MDM

Een configuratie per ontwikkelaar is een gedocumenteerde instelling, geen beheersmaatregel. Fleet-handhaving maakt gebruik van tfy-local-ai-setup, een binary die door uw MDM wordt gepusht en als root (Administrator op Windows) wordt uitgevoerd met een aanbevolen uurlijkse frequentie, vanaf github.com/truefoundry/tfy-local-ai-setup/releases; de Codex-scripts pinnen RELEASE_TAG="v1.3.5". Elke uitvoering doet vier dingen:

1. Slaat de configuratie op of laadt deze uit een bestand dat eigendom is van root — macOS /Library/Preferences/com.truefoundry.tfy-local-ai-setup.conf, Linux /etc/tfy/tfy-local-ai-setup.conf, Windows C:\ProgramData\TrueFoundry\tfy-local-ai-setup.conf (macOS: chown root:wheel, chmod 644).
2. Installeert of updatet de binary, wat wordt overgeslagen wanneer de geïnstalleerde tag overeenkomt met RELEASE_TAG.
3. Detecteert de ingelogde gebruiker en ververst stilzwijgend het token uit ~/.tf/refresh-token.
4. Schrijft en vergrendelt de beheerde configuratie — chflags schg op macOS, chattr +i op Linux, een icacls ACL op de directory op Windows.

Stap drie is het belangrijkst. De laptop bevat nooit een langdurig gateway-token: het refresh-token is 30 dagen geldig vanaf de laatste uitgifte, elke succesvolle uitvoering roteert het, en de authenticatiegegeven in de beheerde configuratie is vers opgehaald en afgestemd op de identiteit van die gebruiker.

Vereiste configuratie: GATEWAY_URL, CONTROL_PLANE_URL, TENANT_NAME. Optioneel: CODEX_GATEWAY_URL, CODEX_AUTH_MODE, CODEX_DEFAULT_MODEL, CODEX_SETTINGS_FILE. CODEX_AUTH_MODE="api-key" is de standaard; "chatgpt-subscription" zorgt ervoor dat de binary requires_openai_auth = true schrijft en het token verplaatst naar x-tfy-api-key. Machines zonder Codex vormen een schone no-op — de binary slaat ze over en sluit af.

De prioriteitsketens, en waarom Windows anders is

Op macOS en Linux wint het admin-bestand, dat bij elke opstart opnieuw wordt toegepast:

/etc/codex/managed_config.toml → ~/.codex/config.toml → CLI flags

model_provider = "truefoundry"
model = "gpt-5.2-codex"

[model_providers.truefoundry]
name     = "TrueFoundry Gateway"
base_url = "https://<your-truefoundry-gateway-url>"
wire_api = "responses"

[model_providers.truefoundry.http_headers]
Authorization = "Bearer <freshly-fetched-tfy-token>"

De model-sleutel op hoogste niveau wordt alleen geschreven wanneer CODEX_DEFAULT_MODEL is ingesteld; indien niet ingesteld, blijft de modelkeuze bij de ontwikkelaar terwijl de provider gehandhaafd blijft.

Op Windows veranderen het bestand, de volgorde en het schema allemaal.

C:\ProgramData\OpenAI\Codex\requirements.toml → ~/.codex/config.toml → CLI flags → C:\ProgramData\OpenAI\Codex\config.toml

Let op de laatste positie: Windows config.toml is de machine-standaard met de laagste prioriteit van de vier, dus het eigen bestand van een ontwikkelaar wint hiervan. requirements.toml wint van alles. Het provider-blok komt overeen met macOS; de model-pin niet:

# C:\ProgramData\OpenAI\Codex\requirements.toml
model_provider = "truefoundry"
# ... dezelfde [model_providers.truefoundry] en http_headers blokken ...

[models.new_thread]
model = "gpt-5.2-codex"

Het requirements-schema heeft geen model-sleutel op het hoogste niveau. CODEX_DEFAULT_MODEL komt in plaats daarvan onder [models.new_thread]. Als u het macOS-blok ongewijzigd naar Windows kopieert, doet de model-pin stilzwijgend niets.

Twee versienummers bepalen of dit allemaal echt werkt op Windows. v0.149.0 heeft managed_config.toml daar laten vervallen. v0.156.0 is het minimum voor handhaving — Codex respecteert model_provider in requirements.toml pas vanaf die build; oudere builds vallen terug op het config.toml met de laagste prioriteit, dat een ontwikkelaar vanuit zijn home-directory kan overschrijven. Controleer codex --version voordat u Windows als beheerd beschouwt. Windows Codex-beheer in de setup-binary is beschikbaar vanaf tfy-local-ai-setup v1.3.5.

Vergrendeling verandert het bestand in een beheersmaatregel:

Op macOS is /etc/codex/ root:wheel 755 en is het bestand root:wheel 644 plus schg — root zelf moet chflags noschg uitvoeren om het te bewerken.

De Windows ACL-waarschuwing verdient een eigen regel. C:\ProgramData\OpenAI\Codex\ is eigendom van Administrators met gestripte overerving: SYSTEM en Admins volledig, Users lezen; beide TOML-bestanden SYSTEM volledig, Admins lezen, Users lezen. De reden is hard — ProgramData stelt elke geauthenticeerde gebruiker in staat om mappen aan te maken, en Codex laadt elke configuratie die het daar vindt, in plaats van een door de gebruiker beschrijfbare te weigeren. Versoepel die ACL niet; een al te permissieve directory verandert een gehandhaafde configuratie stilzwijgend in een suggestie.

Web search governance

Codex bereikt het open web op twee manieren. Door de provider gehoste zoekopdrachten sturen de Responses API web_search-tool, inclusief op ondersteunde modellen op AWS Bedrock Mantle — snel, maar het gedrag varieert per provider en het is geen tool call die u beheert. MCP web search — Tavily of Exa achter de TrueFoundry MCP Gateway — wordt aanbevolen voor consistentie, omdat MCP-tools client-side draaien in het Codex-proces, ongeacht naar welk model de gateway routeert.

[mcp_servers.web-search]
url = "https://<gateway>/<tenant>/mcp/<mcp-server-name>/server"
http_headers = { Authorization = "Bearer TFY_API_KEY" }

Gebruik bearer_token_env_var = "TFY_API_KEY" in plaats van het token inline op te nemen. Om door de provider gehoste zoekopdrachten uit te schakelen, stelt u web_search = "disabled" in in ~/.codex/config.toml — dit schakelt alleen het door de provider gehoste pad uit; de MCP-server blijft werken totdat u het bijbehorende [mcp_servers.<name>]-blok verwijdert. Het registreren van zoeken als een MCP-server is ook wat dat tool-verkeer bestuurbaar maakt onder MCP gateway access control.

Audit en uitgaven

Omdat elke completion de gateway passeert, bestaat het auditspoor of de ontwikkelaar dat nu wil of niet — elke request in Request Traces met de opgeloste gebruiker, het geleverde model, tokens en latency.

Daarboven aggregeert het metrics-dashboard de hele fleet: uitgaven en volume per gebruiker, team en model.

Elke coding-client op de gateway belandt in dezelfde weergave — één kostenbeeld in plaats van vier, zoals in centralising cost control across AI coding IDEs.

Een uitgewerkt voorbeeld

Twee honderd engineers, macOS en Windows, ChatGPT Enterprise al aangeschaft. Ontwikkelaars behouden Codex; security krijgt attributie; finance krijgt een getal per team.

1. Maak de provider aan. Integrations → Providers → OpenAI, base URL https://chatgpt.com/backend-api/codex, API key-veld leeg — noteer dat in het runbook zodat de volgende beheerder het niet gaat "repareren".

2. Maak het Virtual Model aan. Slug gpt-5.2-codex — het echte model-ID, niet de fully qualified name. Eén ChatGPT-subscription target, plus op API-key gebaseerde targets voor failover.

3. Stel de MDM-configuratie in. GATEWAY_URL, CONTROL_PLANE_URL, TENANT_NAME, plus CODEX_AUTH_MODE="chatgpt-subscription" en CODEX_DEFAULT_MODEL="gpt-5.2-codex".

4. Push het script uurlijks, als root. Het installeert tfy-local-ai-setup v1.3.5, ververst het token van elke gebruiker, schrijft managed_config.toml op macOS en requirements.toml op Windows, en vergrendelt beide.

5. Koppel de Windows-rollout aan codex --version. Alles onder v0.156.0 is niet-gehandhaafd; rapporteer de versieverdeling van de fleet voordat u dekking claimt.

6. Verifieer. ls -lO voor schg, lsattr voor i, icacls voor eigenaar Administrators en Users:(RX). Open vervolgens Request Traces en bevestig dat de naam van een ontwikkelaar op de request staat, niet die van een service-account.

7. Sluit het web-search-pad af. Registreer Tavily of Exa achter de MCP Gateway en stel vervolgens web_search = "disabled" in.

De eerlijke beperking: deze stappen beheren de modelprovider, authenticatie en uitgaven. Ze bepalen niet welke MCP-servers een ontwikkelaar mag inschakelen.

Klaar om uw coding agents onder één handhavingspunt te brengen?

Routeer één Codex-installatie via een gateway en zie de eerste trace binnenkomen.

Start gratis

Valkuilen die het weten waard zijn

Het MDM-script beheert geen MCP-servers. Het beheert managed_config.toml, wat de modelprovider en authenticatie omvat. De handhaving door Codex van welke MCP-servers een ontwikkelaar mag inschakelen, bevindt zich in een afzonderlijk /etc/codex/requirements.toml op macOS en Linux, dat niet door tfy-local-ai-setup wordt geschreven. Implementeer dat naast het script — en vertel een auditor niet dat de MDM-setup de allowlisting van MCP omvat.

Twee MDM-scripts, één configuratiebestand, verschillende gepinde versies. De Codex-scripts pinnen tfy-local-ai-setup v1.3.5; de Claude Code-scripts pinnen v1.3.4. Beide beschrijven één binary die één opgeslagen configuratiebestand op dezelfde machine deelt, dus een fleet die beide uitvoert, zou elk uur een andere versie opnieuw installeren — en Windows Codex-ondersteuning bestaat pas vanaf v1.3.5. [VERIFIEER] de pin voordat u beide inschakelt.

Modelversieverschillen in de documentatie. De Codex-pagina kondigt GPT-5.3-Codex aan, terwijl elk configuratievoorbeeld, de slug-richtlijn en de MDM-standaard gpt-5.2-codex gebruiken. Pin expliciet in CODEX_DEFAULT_MODEL; [VERIFIEER] het huidige model-ID vóór de rollout.

Cursor kan niet op dezelfde manier worden gehandhaafd. De MDM-policies daarvan omvatten hooks, geen modellen: base URL, API-key en modellijst zijn niet via MDM afdwingbaar, dus een ontwikkelaar kan ze op elk moment terugdraaien. Copilot CLI heeft ook geen settings.json-pad voor BYOK. Codex en Claude Code zijn de twee die standhouden — Cursor security dicht de kloof.

Gerelateerde artikelen

• Claude Code Governance with an AI Gateway — hetzelfde probleem voor de andere grote coding agent
• Centralising Cost Control for AI Coding IDEs — één kostenoverzicht voor Codex, Cursor en Claude Code
• AI Coding Agent Pricing — wat coding agents werkelijk kosten per ontwikkelaar
• Cursor Security — waar handhaving aan de client-zijde stopt
• What Is an MCP Gateway — het beheren van de tool calls, niet alleen de completions

Conclusie

Het meeste advies over OpenAI Codex governance stopt bij "routeer het via een proxy." Dat is de makkelijke helft. De moeilijke helft bepaalt of de routing standhoudt in een echte fleet: een leeg API key-veld dat eruitziet als een fout maar het niet is, een verplicht wire-protocol, een slug die exact moet overeenkomen met een model-ID, een Windows-bestand met een eigen schema, een minimale versie waaronder de controle stilzwijgend niets doet, en een ACL die u niet mag versoepelen.

Geen van alle zijn het beleidsvragen. Het zijn configuratiefeiten, elk met een commando dat u kunt uitvoeren om het te controleren. Dat is het verschil tussen een governance-document en een beheerde fleet: iemand loopt naar een willekeurige laptop, voert ls -lO of icacls uit, en krijgt een ja of een nee.

Beheer uw coding agents op TrueFoundry

Gratis om te beginnen