OpenAI breidt Codex uit naar Chrome — maar zet veiligheid centraal met sandboxing en approvals

Codex schuift op van “coding assistent” naar echte agent die dingen dóét. En juist daarom zet OpenAI de toon met een opvallend praktisch verhaal over governance: sandboxing, goedkeuringsflows en agent-native logging. Tegelijk melden media dat OpenAI Codex via een Chrome-extensie meer werk in de browser kan uitvoeren, zoals webapps testen en context verzamelen uit open tabs.

Die combinatie (meer autonomie + meer toegang tot je tools) maakt één vraag urgent: hoe voorkom je dat een agent ‘te veel’ kan, of iets doet dat je niet bedoelde?

1) Wat OpenAI bedoelt met “Codex veilig draaien”

In de post Running Codex safely at OpenAI beschrijft OpenAI hoe het intern Codex inzet met een duidelijke scheiding tussen laag-risico handelingen (zo frictieloos mogelijk) en hoog-risico handelingen (altijd expliciet stoppen voor review). De kern is een sandbox die bepaalt waar de agent kan schrijven, of netwerktoegang is toegestaan en welke paden beschermd blijven. Daarbovenop komt een approval policy die bepaalt wanneer Codex toestemming moet vragen.

2) Approvals, netwerkbeleid en auditlogs: agenten horen traceerbaar te zijn

OpenAI benadrukt ook dat “controle” niet genoeg is zonder zichtbaarheid. Daarom noemt het export van events via OpenTelemetry (denk aan prompts, approvals, tool-calls, netwerk-allow/deny) zodat securityteams kunnen reconstrueren wat er gebeurde én waarom. Dat sluit aan bij onze eerdere analyse op AI Feiten over veilig Codex inzetten met approvals, sandboxing en OpenTelemetry-audit logs.

3) De Chrome-extensie: Codex komt dichter bij “browser-werk”

Volgens Engadget heeft OpenAI een Chrome-extensie gelanceerd waarmee Codex browsergebaseerde taken kan uitvoeren, zoals webapps testen, context verzamelen uit tabbladen en parallel werken met Chrome DevTools. Dat klinkt klein, maar is strategisch groot: steeds meer werk (ook buiten development) vindt in de browser plaats.

4) Waarom dit nieuwswaardiger is dan “weer een plugin”

Browser-agents zijn het punt waar productiviteit en risico elkaar raken. We zagen iets vergelijkbaars toen Google Project Mariner stopzette: agenten die klikken, formulieren invullen en navigeren zijn krachtig, maar moeilijk te beveiligen en te voorspellen. Het OpenAI-verhaal laat zien waar de markt naartoe beweegt: agents worden normaal, maar alleen als ze in een control plane passen.

En er is nog een tweede reden: agenten verbruiken veel compute en tokens zodra ze gaan “rondkijken” en meerdere stappen proberen. Efficiëntie wordt dus net zo belangrijk als slimheid — zie ook ons recente stuk over goedkoper LLM-redeneren met minder tokens.

Wat betekent dit voor bedrijven en makers?

De praktische takeaway is dat je bij agents niet moet beginnen met “wat kan het model?”, maar met wat mag het systeem? Concreet:

• Werk met boundaries: sandboxing, beperkte netwerktoegang, en expliciete allowlists.
• Maak approvals een productfeature, niet een noodrem: laag risico automatisch, hoog risico altijd review.
• Log agent-intent: audit trails die prompts, acties en beslissingen koppelen (niet alleen proceslogs).

Het tempo van agent-integraties (ook buiten code) gaat omhoog. Wie nu al governance “meebouwt”, voorkomt later pijn — net zoals bij realtime multimodale systemen waar we eerder over schreven in onze marktupdate over spraak-AI.