OpenAI laat zien hoe je Codex veilig inzet: approvals, sandboxing en OpenTelemetry-audit logs
3 mins read

OpenAI laat zien hoe je Codex veilig inzet: approvals, sandboxing en OpenTelemetry-audit logs

Redactie0Tagged , , , , ,

OpenAI heeft een nieuwe inkijk gegeven in hoe het intern Codex (coding agents) veilig uitrolt. Het gaat niet om één ‘magic setting’, maar om een combinatie van sandboxing, goedkeuringsflows (approvals) en agent-native telemetry die in je bestaande security tooling past. In een tijd waarin agents steeds vaker code reviewen, commando’s draaien en met externe tools praten, wordt dit soort governance het verschil tussen een handige assistent en een oncontroleerbare automatiseringslaag.

1) Sandboxing + approvals: snelheid bij laag risico, rem bij hoog risico

In het artikel Running Codex safely at OpenAI beschrijft OpenAI een principe dat veel security teams zullen herkennen: laat routinehandelingen soepel gaan, maar forceer review zodra het risico stijgt (OpenAI, 8 mei 2026: https://openai.com/index/running-codex-safely/).

Concreet combineert OpenAI:

  • een sandbox als technische grens (waar mag Codex schrijven, mag het netwerk op, welke paden zijn beschermd?)
  • een approval policy die bepaalt wanneer Codex moet stoppen voor menselijke toestemming

In de Codex-documentatie wordt ook uitgelegd hoe configuratie-lagen werken (user config, project overrides, managed requirements) en hoe je sandbox- en approval-instellingen centraal kunt afdwingen (OpenAI Developers: https://developers.openai.com/codex/config-basic).

2) Waarom telemetry nu net zo belangrijk is als ‘toegang beperken’

Opvallend is de nadruk op agent-native audit trails. Klassieke endpoint- en netwerklogs vertellen meestal wat er gebeurde, maar niet altijd waarom. OpenAI stelt dat Codex events kan exporteren (o.a. prompts, tool approvals, tool execution results en netwerk allow/deny) via OpenTelemetry (OpenAI, 8 mei 2026: https://openai.com/index/running-codex-safely/).

OpenTelemetry zelf positioneert zich als vendor-agnostic framework om traces, metrics en logs te genereren en te exporteren richting je eigen backend (OpenTelemetry docs: https://opentelemetry.io/docs/what-is-opentelemetry/). Praktisch betekent dit: je kunt agent-gedrag samenbrengen met je bestaande SIEM/observability-stack, in plaats van een los ‘AI-dashboard’ erbij.

3) Link met OWASP: ‘excessive agency’ en onveilige output zijn bekende valkuilen

Dit soort maatregelen sluit aan bij de thema’s die OWASP al benoemt in de Top 10 voor LLM-applicaties, waaronder Prompt Injection, Insecure Output Handling en vooral Excessive Agency (OWASP GenAI Security Project: https://owasp.org/www-project-top-10-for-large-language-model-applications/).

Een coding agent die zonder frictie ‘alles mag’, kan — ook zonder kwade intentie — schade doen: secrets lekken, onbedoeld dependencies updaten, of commando’s uitvoeren die niet passen bij je change-management.

Wat betekent dit (en wat kun je morgen al doen)?

De kern van OpenAI’s boodschap: agents zijn productie-software met een security model, niet alleen een slimme autocomplete.

Drie snelle, praktische takeaways:

  1. Start met een default sandbox (bijv. workspace-write, beperkte netwerktoegang) en maak uitzonderingen expliciet.
  2. Maak approvals voorspelbaar: wat mag automatisch, wat vereist altijd een mens, en hoe voorkom je ‘approval fatigue’?
  3. Log agent-intent: stuur agent-events naar dezelfde plek waar je je incident response al doet.

Wie dit onderwerp wil verdiepen, lees ook op AI Feiten:

Als OpenTelemetry-export en approval policies straks ‘standaard’ worden in agent-platformen, verschuift het gesprek van “mag een agent code schrijven?” naar “hebben we bewijs, grenzen en terugkijkbaarheid als hij het doet?”.

Lees ook