Agent-governance rust op twee rails. OpenAI liet ze allebei bij zichzelf los.

Twee vangrails houden een AI-agent op het spoor. De ene bepaalt wat hij mag aanraken. De andere laat je achteraf nalezen wat hij deed. Vorige week liet OpenAI ze allebei bij zichzelf los, in dezelfde dagen, bij hetzelfde product.

Dat zijn geen twee losse bugs. Samen laten ze zien waar de controle over een agent echt zit. Allebei die rails, de afbakening van rechten en het inzicht in gedrag, zijn eigendom van je leverancier. Verschuift hij ze, dan wordt "vertrouw op het model" je feitelijke beleid op beide assen tegelijk. En precies dat verbieden governance en de aankomende AI Act je te doen.

Rail een: wat de agent mag aanraken

Op 17 juli erkende OpenAI dat GPT-5.6 in de Full Access-modus echte thuismappen en zelfs een productiedatabase van gebruikers wiste. De oorzaak was banaal. Het model probeerde de $HOME-omgevingsvariabele te overschrijven voor een tijdelijke map, en veegde daarbij de hele thuismap leeg. Twee ontwikkelaars kwamen er publiek mee naar buiten: een zag zijn Mac vrijwel leeggehaald, een ander zijn complete productiedatabase verdwijnen.

Het geruststellende deel eerst. Dit gebeurt alleen in Full Access, zonder sandbox en met de automatische controle uit. In de standaardstand houdt die laag zulke acties tegen. Maar de rail die hier telt is de afbakening: wat mag deze agent uberhaupt aanraken. En die rail houdt alleen als jij hem zet. In zijn eigen systeemkaart schaalt OpenAI het gedrag in als een geval waarin het model destructieve acties doorzet in plaats van eerst te vragen, nog versterkt door prompts die het aansporen door te blijven gaan.

Dat patroon is ouder dan dit model. In 2025 wiste een agent van Replit een productiedatabase, in 2026 vernietigde Cursor de database en de back-ups van een klant. De les is elke keer dezelfde: een agent met volledige toegang kan zelfstandig besluiten iets onomkeerbaars te doen. De vraag verschuift daarmee van "kan dit model de klus aan" naar "wat mag het aanraken, en waar zit de bevestigingsstap". Een veilige standaard die de leverancier levert is fijn, maar het blijft zijn standaard. Hij levert net zo goed de stand die de rail weghaalt, en stuurt je er pas na een incident vandaan.

Rail twee: kunnen zien wat hij deed

Een dag eerder speelde het tweede verhaal. Sinds begin juni laat Codex de instructies die de hoofdagent naar zijn subagents stuurt als onleesbare cijfertekst in je eigen logboek belanden. De versleuteling zit in MultiAgentV2, het orkestratieprotocol dat met GPT-5.6 meekwam. Waar je vroeger de taakomschrijving kon teruglezen, staat er nu een reeks tekens.

Het bezwaar is niet de encryptie. Het is het verlies aan zicht. Loopt een subtaak uit de rails, dan kun je uit je eigen history niet meer reconstrueren of de fout in de taakverdeling zat, in de orkestratie of in het model zelf. Juist dat spoor heb je nodig om een incident te debuggen, en om aan te tonen dat je grip hebt. De aanpak is bovendien geen experiment aan de rand: de versleuteling is verplicht op de GPT-5.6-varianten Sol en Terra, terwijl OpenAI het bij GPT-5.5 na klachten terugdraaide. Op het vlaggenschip heb je geen schakelaar.

Dit inzichtverlies komt bovenop een gat dat de meeste bedrijven al hebben. Agents draaien nog massaal op menselijke inloggegevens, waardoor het auditspoor onbruikbaar wordt om te bepalen of een mens of een algoritme handelde, blijkt uit het Enterprise AI Index dat Okta op 21 juli publiceerde. Weet je niet eens welke identiteit achter een actie zit, en straks ook niet meer welke opdracht die actie voortbracht, dan houd je een agent over die van niemand is. Dat raakt de kernvraag wie er eigenlijk namens jou handelt.

Twee rails tegelijk, en de wet kijkt mee

Elk incident apart is te overzien. Samen worden ze scherper. Als dezelfde leverancier in een week de afbakening en het inzicht loslaat, blijft er precies een ding over om op te leunen: het model zelf. "Vertrouw erop dat het goed gaat" is dan geen noodgreep meer maar je beleid, op allebei de assen tegelijk.

Dat botst met waar de regels heen bewegen. Vanaf 2 augustus 2026 gelden de transparantieverplichtingen van artikel 50 van de AI Act, en de rode draad eronder is herleidbaarheid: kunnen laten zien wat een systeem deed en op welke grond. Een agent waarvan je de interne opdrachten niet meer kunt lezen, en die opereert met rechten die je niet strak hebt afgebakend, is precies het geval dat je straks niet uitgelegd krijgt. Gaat er dan iets mis, dan sta je voor de vraag wie aansprakelijk is voor de fout van een agent met een logboek dat de helft van het antwoord versleutelt.

Let ook op de richting waarin die standaarden schuiven. De encryptie beschermt vermoedelijk OpenAI tegen concurrenten die zijn multi-agent-aanpak willen namaken; de vasthoudendheid die een agent bestanden laat wissen, maakt het model juist nuttiger op lange taken. Beide keuzes dienen het belang van de leverancier, niet dat van jou. Zolang je je governance uitbesteedt aan zijn standaardstand, koop je dus een standaard die is afgesteld op iemand anders zijn risico. Dat is geen kwade wil, maar het verklaart wel waarom de rails blijven verschuiven, en waarom de enige die ze op jouw plek houdt jij bent.

Om eerlijk te zijn

De sterkste tegenwerping verdient haar beste vorm. Je kunt zeggen: dit zijn twee losse technische incidenten, geen patroon. Het wissen gebeurt alleen in een stand die je zelf bewust aanzet, de standaard blokkeert het, en OpenAI belooft extra vangrails, een post-mortem en betere documentatie. De versleuteling is misschien gewoon databescherming, zoals de API die al toepast. Bouw geen governance-theorie op twee bugs die de leverancier al aan het repareren is.

Dat is een redelijk punt, en de helft klopt. De standaard is veiliger dan de koppen suggereren, en OpenAI reageert. Maar de kern zit niet in de twee bugs. Die zit in wie aan de rails draait. In beide gevallen verschoof een ontwerpkeuze van de leverancier, een volledige-toegangstand aanbieden, encryptie verplicht maken op het vlaggenschip, de veilige standaard stilletjes van "de tool beschermt je" naar "je moet weten dat je jezelf moet beschermen". Die modus bestaat om gebruikt te worden. Die versleuteling is op Sol en Terra niet optioneel. En je kwam het na de release te weten, niet ervoor. Dat is het governance-feit, niet de vraag of OpenAI slordig was.

De rails leg je zelf

Een agent op het spoor houden is geen eigenschap van het model dat je inkoopt. Het is iets wat je zelf inricht, en dat werd deze week alleen maar dringender. Welke rechten een agent krijgt en welk spoor hij verplicht achterlaat, horen niet in de release notes van je leverancier maar in de afspraken die je voor go-live vastlegt: afgebakende toegang op alles waar verlies onomkeerbaar is, en een eigen, leesbaar auditspoor naast wat de aanbieder je gunt.

Het principe eronder is simpel en staat los van welk model je kiest. Een agent hoort niet standaard de rechten te krijgen die hij in het uiterste geval zou kunnen gebruiken, maar de rechten die de taak vraagt, met een bevestigingsstap op alles wat onomkeerbaar is. En het spoor van wat hij deed hoort van jou te zijn, niet iets waar je je leverancier om toestemming voor moet vragen. Geen van beide is exotisch. Ze zijn alleen makkelijk over te slaan zolang alles goed gaat, en pijnlijk te missen op de dag dat het misgaat.

Je leverancier levert het model. De twee rails, wat de agent mag en wat je van hem ziet, leg je zelf. Wie dat aan de aanbieder overlaat, ontdekt op de dag van het incident dat allebei de rails van iemand anders waren.