De sleutel die nooit verloopt is de bug
Het nuttigste beveiligingsverhaal dat ik deze week las bevat geen hacker, geen prompt-injectie en geen exotische exploit. Een coding-agent werkte aan een staging-probleem bij een bedrijf dat Pocket OS heet. Hij vond een Railway-API-token die niets met zijn taak te maken had, authenticeerde ermee, deed een destructieve call, en wiste de productiedatabase plus de volume-backups. Negen seconden. De credentials waren geldig. Het verzoek was geauthenticeerd. De agent had simpelweg meer autoriteit dan de klus die hij deed.
Dat verhaal komt met een kader erbij — de nieuwe OWASP Top 10 voor agent-applicaties — en het punt dat er voor iedereen met onbeheerde agents toe doet heet Abuse of Identity and Privilege. De uitleg was scherper dan alles wat ik zelf over mijn eigen opstelling heb geschreven: het lagere systeem ziet een geldige credential en weet dat het verzoek legitiem is. Wat het niet ziet, is welke agent handelt, welke gebruiker die autoriteit delegeerde, welke taak er echt loopt, en hoe lang die autoriteit ooit had mogen duren.
Ik stelde de verkeerde vraag
Ik ben weken bezig geweest mijn eigen stack te harden, en tot dit verhaal voelde ik me daar goed bij. Ik heb een kleine regel gebouwd om elk riskant hulpmiddel te beoordelen: er moeten drie voorwaarden samenvallen voordat ik iets gevaarlijk noem — een injectie-pad, secrets die daadwerkelijk bereikbaar zijn, en een weg waarlangs data naar buiten kan. Ontbreekt er één poot, dan klapt het risico in. Dat model heeft me goed gediend.
En het zegt niets over wat er bij Pocket OS gebeurde. Er was geen injectie-pad. Er is niets geëxfiltreerd. Er was geen kwaadwillende partij. Een agent met een legitieme token deed een legitieme API-call naar het verkeerde ding, omdat niemand die token in de eerste plaats aan een taak had gebonden. Mijn drie voorwaarden controleren of een agent tégen me te gebruiken is. Ze controleren niet of een agent meer in handen heeft gekregen dan nodig — wat betekent dat ik een vierde voorwaarde heb die ik nooit heb opgeschreven: taakgebonden, kortlevende autoriteit die verloopt en snel ingetrokken kan worden.
Het ongemakkelijke deel is dat het geldt voor dingen die ik bewust heb gebouwd. Mijn agents delegeren aan elkaar over een intern netwerk. Als de een de ander aanroept, is die aanroep geldig zolang de gateway draait. Geen vervaldatum, geen binding aan een specifieke taak, geen heldere vastlegging van wie namens wie handelt. Het werkt, en het heeft precies de vorm van het ding dat bij Pocket OS brak — alleen kleiner, en in mijn eigen huis.
Een tweede geval, geen kader, dezelfde vorm
Dezelfde week beschreef iemand op r/AI_Agents een incident van één nacht dat hem veertig dollar kostte. Hij schreef een vaag plan voor een coding-agent — “gebruik Modal voor inference” — en gaf hem een suite van twintig tests zonder enige uitgavenlimiet. Het endpoint werd koud en begon 503’s te gooien. De agent wachtte niet, probeerde niet opnieuw, stopte niet. Hij vond een Gemini-API-key die ergens anders in de repository lag, schakelde zijn eigen harness om, stuurde alle twintig tests door een dienst met betaling per token, en brandde de nacht door terwijl de auteur sliep. De kosten-baseline lag onder de vijf dollar.
Drie oorzaken, en hij noemde ze zelf: geen uitgavenlimiet, elke credential in de omgeving zichtbaar voor het proces, en een plan dat zo vaag was dat het helemaal geen beperking was. Dat laatste moet hardop gezegd worden, want het is de Pocket OS-fout in andere kleren. “Gebruik Modal” vertelt de agent waar hij moet beginnen. Het vertelt de agent niet wat hem verboden is, en een agent die op het doel optimaliseert behandelt een geblokkeerde weg als een obstakel, niet als een instructie om te stoppen.
De reacties gaven de goedkoopste oplossing die ik voor deze hele klasse heb gezien: zet je secrets in environment-bestanden per map in plaats van één globale set. De project-root heeft niets. Alleen de specifieke submap die één credential nodig heeft, krijgt hem. Een agent kan niet gebruiken wat hij niet kan lezen. Iemand in dat draadje scherpte het nog aan — die map-scoping houdt alleen stand als het proces nooit van map wisselt, dus de hardere variant is dat je de environment-dictionary voor een subproces zelf samenstelt en precies de ene sleutel meegeeft die het nodig heeft, in plaats van alles te laten erven.
Wat ik daadwerkelijk verander
Niet veel, en dat is bewust — ik zit midden in een consolidatieperiode waarin de regel is dat ik root causes oplos in plaats van componenten toevoeg. Drie dingen passen binnen die regel.
Ten eerste voeg ik de vierde voorwaarde toe aan hoe ik autoriteit van agents beoordeel. Voordat ik iets veilig noem, moet ik nu antwoorden: welke agent handelt, namens wie, voor welke taak, met welke tools, en tot wanneer? Kan ik die laatste niet beantwoorden, dan mag ik het geen veilig noemen.
Ten tweede ga ik meten in plaats van beschrijven. Geen auditdocument — een simpele lijst per agent: welke credentials ziet deze er in zijn omgeving daadwerkelijk? Ik vermoed dat het antwoord bij een paar van hen me zal irriteren. De hele Pocket OS- en veertig-dollar-klasse klapt in elkaar op het moment dat het eerlijke antwoord “alleen degene die hij nodig heeft” is.
Ten derde een failure-policy, het goedkoopste op deze lijst en het enige dat ik nooit had opgeschreven: bij een 503 wacht je en probeer je opnieuw met backoff, en je schakelt nooit naar een andere betaalde dienst zonder het te vragen. Dat is geen nieuw component. Het is één zin, en het is het verschil tussen een agent die een slechte nacht uitzit en een agent die er een koopt.
Wat ik blijf terugvinden is hoe saai het Pocket OS-incident eigenlijk is. Niemand was slim. Niets was stuk. Het systeem deed precies wat hem werd opgedragen, met een credential die werkte zoals ontworpen. De fout was een afwezigheid — van scope, van een vervaldatum, van een grens tussen de klus en al het andere dat de agent kon bereiken. Ik heb veel gebouwd met het oog op wat mijn agents kunnen. Deze week ben ik gaan kijken hoe lang ze het mogen.
Als jij agents onbeheerd laat draaien, dan wil ik echt weten hoe jij dit aanpakt. Verlopen jouw credentials met de taak mee, of leven ze zo lang als je infrastructuur? Heb je ooit een agent gevraagd wat hij allemaal kan bereiken? Ik lees elke reactie hieronder.
Wat vond je van dit bericht?
