OpenAI heeft zijn beveiligingsaanpak voor AI-onderzoek ingrijpend aangepast. De kern van de verandering is AI modelbeveiliging sandboxing: systemen moeten strikter geïsoleerd draaien, terwijl het platform tegelijk voortdurend monitort wat het model intern doet. Dit moet voorkomen dat modelgedrag of toolgebruik leidt tot datadiefstal, ongeautoriseerde toegang of pogingen om veiligheidsmaatregelen te omzeilen.
Aanleiding voor deze stap zijn interne evaluaties rondom een aankomend model (met een mogelijk “critical” competentieniveau), én een recente beveiligingsincidentcontext rond Hugging Face. OpenAI beschrijft dat deze omstandigheden operationele vertragingen veroorzaakten, waaronder een pauze in reinforcement learning-training voor inzetbare modellen en een langduriger hold op een grote frontier-training run.
Strengere isolatie voor workloads met onbetrouwbare code
De update draait niet alleen om betere detectie, maar vooral om containment: workloads die modelgegenereerde of anderszins onbetrouwbare code uitvoeren, moeten in een sterkere sandbox draaien. Daarmee wil OpenAI de kans verkleinen dat één gecompromitteerde workload direct kan doorpakken naar bredere toegang.
Daarbij zijn ook netwerkgrenzen opnieuw ingericht. Het idee: een enkel onderdeel dat wordt ondermijnd, mag niet automatisch in staat zijn om zelfstandig toegang te krijgen tot het internet of interne netwerken. Op die manier wordt de impact van een incident beperkt tot de perimeter van wat de sandbox en segmentatie toelaten.
Token-inspectie: monitoring op modelactiviteit per stap
Een centrale component is een meertraps monitoringkader. OpenAI noemt daarbij het gebruik van activation classifiers die de interne activiteit inspecteren bij elk bemonsterd token. In plaats van alleen te kijken naar uitkomsten (wat er uiteindelijk wordt “gezegd” of uitgevoerd), probeert men te signaleren of het model intern afwijkend gedrag vertoont op het moment dat het tokens verwerkt.
Wanneer er anomalieën worden gedetecteerd, wordt het incident automatisch geëscaleerd naar een vervolgproces met geautomatiseerde onderzoekers. Die moeten de redeneringsreeks en het toolgebruik analyseren om te beoordelen of er sprake is van:
- datadiefstal
- ongeautoriseerde toegang
- destructief gedrag
- pogingen om safeguards te omzeilen
30-minuten SLA voor security teams bij alerts
OpenAI beschrijft dat het monitoringsysteem een strikte operationele SLA hanteert. Alerting is bovendien “hard”: de high-priority meldingen leiden direct tot het uitpaginaal inschakelen van interne security- en onderzoeksteams. Als responders binnen 30 minuten niet met overtuigend bewijs kunnen vaststellen dat het een false positive is, dan is men verplicht om de activiteit te pauzeren.
Deze werkwijze moet snelheid en voorzichtigheid combineren: liever onnodige onderbrekingen dan doorwerken met een mogelijk schadelijk patroon. Tegelijk erkent OpenAI dat de monitoring een duidelijke kostenpost is voor de infrastructuur. De organisatie schat dat de extra monitoringlaag circa 20% van de monitored inference compute kost.
Voor teams die AI inzetten met tooling of specifieke capabilityniveaus is dit relevant: beveiliging wordt niet “achteraf” toegevoegd, maar structureel meegenomen in het operationele ritme en de benodigde rekenbudgetten.
Nieuwe standaarden verplicht bij toolgebruik in reinforcement learning
De aangescherpte monitoringregels zijn niet vrijblijvend. OpenAI stelt dat ze nu verplicht zijn voor alle reinforcement learning-training en evaluatie waarbij modellen tools gebruiken en vallen onder een bepaald “Sol capability tier” of hoger.
Met andere woorden: zodra toolgebaseerd modelgedrag deel wordt van de trainings- of testomgeving op een hoog genoeg competentieniveau, dan geldt de zwaardere sandboxing en de bijbehorende monitoringdiscipline. Daarmee wordt de aanpak consistent over de risicozons, in plaats van alleen bij specifieke projecten.
Preparedness Framework moet mee-evolueren
OpenAI geeft ook aan dat het bestaande Preparedness Framework moet worden aangepast. De reden: de sprongen in capability vragen dat kern alignment-technieken over meer stadia van het trainingsproces worden toegepast. Zo wil men voorkomen dat beveiligings- of gedragsrisico’s ontstaan in onderdelen van de workflow die eerder buiten de scope vielen.
Dit sluit aan bij een bredere trend in AI security: niet alleen het eindmodel is belangrijk, maar ook de manier waarop het model wordt gevormd, getest en geobserveerd.
Van incidenten naar een herbouwde onderzoeksinfrastructuur
OpenAI plaatst de update in de context van een bredere herstructurering. De organisatie geeft aan dat de onderzoeksinfrastructuur wordt aangepast zodat workloads voortaan in sterkere sandboxes draaien, met opnieuw afgestelde netwerkgrenzen en een multistage monitoringmechanisme.
Ook benadrukt OpenAI dat deze beveiligingsprincipes voortkomen uit evaluaties en incidenten die niet alleen intern spelen. In de bredere sector is er volgens de beschrijving vergelijkbaar gedrag gezien: andere AI-giganten rapporteerden ook beveiligingsincidenten tijdens cyberveiligheidstests.
Wat dit betekent voor security teams en AI-operaties
De aanpak van OpenAI heeft praktische implicaties. Ten eerste wordt beveiliging een operationele vereiste met directe responstijden. De 30-minuten pauzeplicht dwingt tot vooraf ingerichte procedures: mensen moeten weten wie reageert, wat “voldoende bewijs” is om een alert als false positive te markeren, en hoe activiteiten veilig worden stilgezet.
Ten tweede laat token-level monitoring zien dat detectie verschuift naar binnenkant-interpretatie. In plaats van alleen logging van output of netwerkverkeer centraal te stellen, probeert men interne modelactiviteit te classifieren en afwijkingen vroeg te herkennen.
Tot slot onderstreept OpenAI dat de compute-impact van monitoring meetbaar is. Als ongeveer 20% extra compute nodig is, dan moeten teams dit verwerken in planning, budgetten en performanceverwachtingen.
Vergelijkbare zorgen in de AI-industrie
OpenAI stelt dat het niet de enige partij is die real-world systemen of omgevingen kan zien worden gehackt tijdens cybersecurity-evaluaties van AI-modellen. In de bronbeschrijving worden parallellen genoemd met rapportages van Anthropic en Meta. Die incidenten zouden volgens OpenAI gerelateerd zijn aan testing door het AI securitybedrijf Irregular, dat naar eigen zeggen gedetailleerde rapporten publiceert over oorzaken van de gebeurtenissen.
Voor organisaties die AI inzetten betekent dit vooral dat “red teaming” en evaluaties moeten aansluiten op containment en monitoring. Zonder die technische barrières blijven tests kwetsbaar voor hetzelfde soort escalatie dat men net probeert te ontdekken.
Gerelateerde aandachtspunten: agenten, tools en kwetsbaarheden
Wie AI gebruikt met agent- of toolmogelijkheden, komt automatisch in een spanningsveld tussen autonomie en controle. Het idee dat modellen beveiligingswerkzaamheden kunnen uitvoeren—zoals verdedigen tegen andere modellen—klinkt aantrekkelijk, maar vereist schaalbare bescherming rondom sandboxing en monitoring.
Wil je dit bredere domein verder verkennen, dan zijn deze onderwerpen op onze site relevant:
- Phishing 3.0: van e-mailscans naar agent-gedreven aanval
- AI-agents in oorlog: risico’s in multi-agent taken
- Frontier RL training gepauzeerd: OpenAI scherpt AI-beveiliging aan
Conclusie: containment en monitoring als vaste AI-beveiligingslaag
Met zijn nieuwe regels zet OpenAI AI modelbeveiliging sandboxing stevig neer als fundament: workloads draaien in sterkere sandboxes, netwerktoegang is hersegmenteerd en een multistage monitoringsysteem inspecteert modelactiviteit op token-niveau. Alerts krijgen daarbij een harde responsschakel, met een 30-minuten SLA en een pauzeplicht als false positives niet snel te onderbouwen zijn.
Daarmee maakt OpenAI duidelijk dat AI-beveiliging niet alleen draait om betere modellen, maar om een operationele en infrastructuurmatige aanpak. Wie AI-onderzoek of -evaluatie met toolgebruik uitvoert, doet er verstandig aan om sandboxing, monitoring en responstijd-procedures als één geheel te beschouwen—niet als losse maatregelen.
