AI coding agents worden een security-product: OpenAI zet in op sandboxing, approvals en audit-logs

In de afgelopen maanden zijn coding agents van ‘slimme autocomplete’ doorgeschoven naar systemen die zelf repositories kunnen lezen, commando’s uitvoeren en met developer tools praten. OpenAI beschrijft nu concreet hoe het Codex intern veilig inzet met sandboxing, approvals en agent-native audit trails (bron: OpenAI over Running Codex safely). Dat klinkt technisch, maar de implicatie is groter: wie agents in productie brengt, bouwt óók een nieuw security-product.

1) Sandboxing + approvals: productiviteit binnen harde grenzen

Volgens OpenAI moet laag-risico werk soepel gaan, maar alles wat buiten de afgesproken boundary valt, moet expliciet stoppen voor review. Die boundary is deels technisch (waar mag de agent schrijven, welke paden zijn beschermd, mag er netwerkverkeer uit) en deels procedureel (wanneer is menselijke approval vereist). OpenAI noemt daarnaast een Auto-review mode die in bepaalde gevallen ‘laag risico’ requests automatisch kan goedkeuren om de flow niet te breken (bron: Running Codex safely).

Voor teams die al experimenteren is dit herkenbaar: het echte risico zit vaak niet in “de agent schrijft code”, maar in wat hij daarna mag doen. Een nuttig achtergrondstuk op AI Feiten is: zo draait Codex met sandboxing en approvals.

2) Geen open internet: network policy als standaard voor agents

OpenAI schrijft dat Codex niet met open-ended outbound access draait: bekende, ‘expected’ destinations kunnen door, onbekende domeinen vragen om approval of worden geblokt. Dat past bij de bredere trend dat agent-platforms meer op policy engines gaan lijken dan op chat-interfaces.

Die governance-kant zie je ook terug in regelgeving en toezicht. Organisaties merken nu al dat “AI in de keten” vragen oproept over controleerbaarheid en verantwoordelijkheid — een thema dat terugkomt in discussies rond NIST-achtige kaders en toezicht-initiatieven (zie ook: NIST/CAISI en frontier AI-testakkoorden).

3) Telemetry die ‘waarom’ kan beantwoorden: OpenTelemetry + agent logs

Klassieke securitylogs vertellen je meestal wat er gebeurde (proces gestart, bestand aangepast), maar zelden waarom. OpenAI stelt daarom agent-native events beschikbaar, en noemt expliciet export via OpenTelemetry: prompts, approval-beslissingen, tool-activiteiten, MCP-gebruik en network allow/deny events (bron: Running Codex safely).

Dat is niet alleen handig bij incident response; het maakt ook beleid iteratief: je ziet welke tools gebruikt worden, waar policy te strikt is, en waar de agent “omwegen” zoekt. Dit sluit aan bij hoe OWASP risico’s rond agents framed — denk aan prompt injection en ‘excessive agency’ (bron: OWASP LLM Top 10).

4) Meer cyber-capability? Dan ook sterkere toegang en account security

Tegelijk schuift OpenAI richting getrapte toegang voor security workflows. Met Trusted Access for Cyber krijgen geverifieerde defenders minder onnodige refusals voor defensieve taken, terwijl misbruik (credential theft, stealth, persistence) geblokt blijft (bron: OpenAI over Trusted Access for Cyber). In dezelfde week werd ook duidelijk dat OpenAI de lat hoger legt op capability-classificatie (bron: GPT‑5.5 Instant System Card).

Op AI Feiten vind je hierover meer context: GPT‑5.5‑Cyber en Trusted Access uitgelegd.

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

De belangrijkste les: agent-adoptie is governance. Wil je coding agents veilig uitrollen, denk dan in lagen:

• Boundary: sandboxing en duidelijke “outside sandbox = review” regels.
• Policy: default-deny netwerk, allowlists voor bekende workflows.
• Identiteit: sterke authenticatie (liefst phishing-resistent) en rol-gebaseerde toegang.
• Bewijs: agent-native logs die naar je SIEM kunnen.

Wie dit goed neerzet, kan agents sneller in de praktijk brengen zonder dat security achteraf de rem erop moet zetten. En dat is precies waarom enterprise AI steeds vaker draait om ‘delivery’ en control planes, niet alleen om modelvergelijkingen (zie ook: enterprise AI draait om delivery).