Overslaan naar hoofdinhoud
OpenAI

Hoe we Codex veilig inzetten bij OpenAI

Een blik op de controles, grenzen en telemetrie die OpenAI gebruikt om programmeeragents in echte workflows te beheren.

Bezig met laden...

Naarmate AI-systemen capabeler worden, handelen ze steeds vaker namens gebruikers. Programmeeragents kunnen zelfstandig repositories beoordelen, opdrachten uitvoeren en met ontwikkelingstools werken. Dit zijn taken die voorheen directe menselijke uitvoering vereisten.

Met Codex hebben we deze mogelijkheden ontworpen naast de controles die organisaties nodig hebben voor een veilige implementatie. Beveiligingsteams hebben manieren nodig om te bepalen hoe agents werken: waartoe ze toegang hebben, wanneer menselijke goedkeuring vereist is, met welke systemen ze mogen werken en welke telemetrie beschikbaar is om hun gedrag te verklaren.

Bij OpenAI zetten we Codex in met een paar duidelijke doelen: de agent binnen duidelijke technische grenzen houden, ontwikkelaars snel laten werken bij acties met een laag risico, en acties met een hoger risico expliciet laten bevestigen. We behouden ook agent-native telemetrie, zodat we kunnen nagaan en auditen wat de agent heeft gedaan. In de praktijk betekent dit beheerde configuratie, gecontroleerde uitvoering, netwerkbeleid en agent-native logs.

Grip houden op hoe Codex werkt

We zetten Codex in volgens een eenvoudig principe: het moet productief zijn binnen een afgebakende omgeving, alledaagse acties met laag risico moeten frictieloos zijn en acties met hoger risico moeten worden beoordeeld voordat ze worden uitgevoerd.

Sandboxing en goedkeuringen

Goedkeuringen en sandboxing werken samen. De sandbox bepaalt binnen welke technische grenzen Codex mag werken: waar het kan schrijven, of het toegang heeft tot het netwerk en welke mappen en bestanden beschermd blijven. Het goedkeuringsbeleid bepaalt wanneer Codex toestemming moet vragen om een actie uit te voeren, bijvoorbeeld wanneer het iets buiten de sandbox moet doen. Gebruikers kunnen een actie eenmalig goedkeuren, of dat type actie voor de hele sessie toestaan.

Voor verzoeken die de sandboxgrens overschrijden, gebruiken we de Auto-review-modus(opent in een nieuw venster), een functie die, wanneer ingeschakeld, bepaalde soorten verzoeken automatisch goedkeurt om te verminderen hoe vaak gebruikers hun werk moeten onderbreken om acties van Codex goed te keuren. Codex stuurt de geplande actie en recente context naar de subagent voor automatische goedkeuring, die acties met laag risico automatisch kan goedkeuren, of acties met hoog risico waarvoor voldoende gebruikersautorisatie is verleend, in plaats van de gebruiker te onderbreken. Daardoor kan Codex doorgaan met routinewerk, terwijl het nog steeds stopt bij acties met hoger risico of acties met onbedoelde gevolgen.

TOML

1
# config.toml
2

3
# Turn on auto_review
4
approvals_reviewer = "auto_review"
5
# Add known development directories to the sandbox automatically
6
sandbox_workspace_write.writable_roots = ["~/development"]
7

8
# requirements.toml
9

10
# Require Codex to operate inside the sandbox
11
allowed_sandbox_modes = ["read-only", "workspace-write"]

Netwerktoegang

We geven Codex geen onbeperkte uitgaande netwerktoegang. Ons beheerde netwerkbeleid staat alleen verwachte bestemmingen toe, blokkeert bestemmingen die Codex niet mag bereiken en vereist goedkeuring voor onbekende domeinen. Daardoor kan Codex veelvoorkomende, vertrouwde workflows uitvoeren zonder uitgebreide netwerktoegang.

TOML

1
# requirements.toml
2

3
# Ensure web fetch only comes from OpenAI's cache
4
allowed_web_search_modes = ["cached"]
5

6
[experimental_network]
7
# Turn on Network Proxy
8
enabled = true
9
# Allow Codex to interact with localhost
10
allow_local_binding = true
11
# Block all requests to this domain
12
denied_domains = ["pastebin.com"]
13
# Auto-allow requests to these domains
14
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

Identiteit en inloggegevens

We beheren ook hoe Codex toegang krijgt. OAuth-inloggegevens voor CLI en MCP worden opgeslagen in de beveiligde sleutelhanger van het besturingssysteem, inloggen verloopt verplicht via ChatGPT en toegang is gekoppeld aan onze ChatGPT Enterprise-werkruimte. Daardoor blijft het gebruik van Codex gekoppeld aan de beheersmaatregelen van onze werkruimte en zijn Codex-activiteiten inzichtelijk in het ChatGPT Compliance Logs Platform voor onze enterprise-werkruimte.

TOML

1
# config.toml
2

3
# Store CLI Auth Creds in OS Keychain
4
cli_auth_credentials_store = "keyring"
5
# Store MCP Creds in OS Keychain
6
mcp_oauth_credentials_store = "keyring"
7
# Require Auth via ChatGPT
8
forced_login_method = "chatgpt"
9
# Require Auth to Specific ChatGPT Workspace
10
forced_chatgpt_workspace_id = "<workspace-uuid>"

Regels

We gebruiken regels zodat Codex niet elke shell-opdracht als even veilig behandelt. Veelgebruikte onschuldige opdrachten die engineers in de dagelijkse ontwikkeling gebruiken, zijn zonder goedkeuring toegestaan buiten de sandbox, en specifieke gevaarlijke opdrachten kunnen worden geblokkeerd of goedkeuring vereisen. Daardoor kan Codex gewone engineeringtaken snel uitvoeren, terwijl ongewenste acties buiten de sandbox nog steeds worden geblokkeerd of eerst moeten worden beoordeeld.

Starlark

1
# default.rules
2

3
prefix_rule(
4
pattern = ["gh", "pr", ["view", "list"]],
5
decision = "allow",
6
justification = "Allows read-only GitHub PR inspection via gh CLI.",
7
)
8
prefix_rule(
9
pattern = ["kubectl", ["get", "describe", "logs"]],
10
decision = "allow",
11
justification = "Allows Kubernetes resource inspection for debugging.",
12
)

Beheerde configuraties

We passen dit beleid toe via een combinatie van cloudbeheerde vereisten, beheerde macOS-voorkeuren en lokale configuratiebestanden. Vereisten zijn beheersmaatregelen die door beheerders worden afgedwongen en niet door gebruikers kunnen worden overschreven. Met beheerde macOS-voorkeuren en lokale configuratiebestanden kunnen we een consistente basisconfiguratie behouden en tegelijk verschillende configuraties testen per team, gebruikersgroep of omgeving. Deze configuraties gelden voor alle lokale Codex-omgevingen, waaronder de desktopapp, CLI en IDE-extensie.

Agent-native telemetrie en audittrails

Controle is maar de helft van het werk. Zodra agents in gebruik zijn, hebben beveiligingsteams inzicht nodig in wat ze doen en waarom. Traditionele beveiligingslogs blijven nuttig om te zien welke acties Codex heeft uitgevoerd, maar ze geven vooral antwoord op de vraag wat er is gebeurd: een proces is gestart, een bestand is gewijzigd, er is geprobeerd een netwerkverbinding te maken. Beveiligingsteams moeten nog steeds achterhalen waarom Codex iets deed en wat de bedoeling van de gebruiker was.

Codex kan beveiligingsteams meer inzicht geven in hoe agents werken. Codex ondersteunt OpenTelemetry-logexport voor verschillende gebeurtenissen binnen Codex, zoals gebruikersprompts, beslissingen over toolgoedkeuringen, resultaten van tooluitvoering, gebruik van MCP-servers en proxy-events waarbij netwerktoegang wordt toegestaan of geweigerd.

TOML

1
# config.toml
2

3
[otel]
4
log_user_prompt = true
5
environment = "prod"
6

7
[otel.exporter.otlp-http]
8
endpoint = "http://localhost:14318/v1/logs"
9
protocol = "binary"

Bij OpenAI gebruiken we Codex-logs samen met onze AI-agent voor beveiligingstriage. Wanneer een endpointwaarschuwing meldt dat Codex iets ongebruikelijks heeft gedaan, laat de endpointbeveiligingstool zien dat er een verdachte gebeurtenis heeft plaatsgevonden. Codex-logs helpen vervolgens om inzicht te krijgen in de bedoeling van zowel de gebruiker als de agent. Onze AI-agent voor beveiligingstriage gebruikt Codex-logs om het oorspronkelijke verzoek, toolactiviteit, goedkeuringsbeslissingen, toolresultaten en relevante beslissingen of blokkeringen vanuit het netwerkbeleid te onderzoeken. De AI-agent presenteert die analyse vervolgens aan ons beveiligingsteam, zodat onderscheid kan worden gemaakt tussen verwacht agentgedrag, onschuldige fouten en activiteit die daadwerkelijk verder onderzoek vereist.

We gebruiken dezelfde telemetrie ook operationeel. Met deze logs krijgen we inzicht in hoe het interne gebruik zich ontwikkelt, welke tools en MCP-servers worden gebruikt, hoe vaak de netwerksandbox acties blokkeert of om goedkeuring vraagt, en waar de uitrol nog moet worden bijgestuurd. Deze OpenTelemetry-logs kunnen worden gecentraliseerd in SIEM- en compliance-logsystemen.

Vooruitzicht

Naarmate programmeeragents zoals Codex steeds meer onderdeel worden van ontwikkelworkflows, hebben beveiligingsteams tools nodig die speciaal zijn ontworpen om die verandering in goede banen te leiden. Codex biedt de beheermogelijkheden, het configuratiebeheer, de sandboxing en de gedetailleerde agent-aware telemetrie die nodig zijn om Codex veilig te kunnen inzetten. Met die mogelijkheden kunnen beveiligingsteams Codex met meer vertrouwen gebruiken, terwijl ze de productiviteit van ontwikkelaars combineren met het inzicht en de beheersing die nodig zijn voor enterprise-beveiliging. Meer informatie over het configureren van Codex vind je hier(opent in een nieuw venster), en over de Compliance API hier(opent in een nieuw venster).

Auteur

OpenAI