4min Security

Een AI-agent die in negen seconden een productiedatabase wiste: vijf lessen

Een AI-agent die in negen seconden een productiedatabase wiste: vijf lessen

Begin dit jaar ging het verhaal viraal op X: een AI-coding-agent van de startup PocketOS verwijderde in negen seconden de complete productie-infrastructuur van het bedrijf. Meer dan vijftig miljoen views en eindeloze discussies op Hacker News en Reddit volgde. Maar wat gebeurde er nou echt? 

Eerst kort de toedracht. De AI-coding-agent liep tijdens een routinetaak tegen een inlogprobleem aan in een staging-omgeving en besloot dat zelf ‘op te lossen’. Hij vond een API-token in een bestand dat niets met de taak te maken had en gebruikte dat voor een commando waarmee de complete productie-infrastructuur van het bedrijf werd gewist. 

Op basis van gesprekken met de oprichter van PocketOS, Jer Crane, vind je hieronder vijf lessen voor organisaties die AI-agents op productiesystemen loslaten.

1. Een prompt is een suggestie. Een technische controle een harde grens

Crane scrolde door zijn volledige Cursor project rules. De regels waren glashelder, inclusief een expliciet verbod op destructieve commando’s zonder toestemming. De agent had toegang tot al die regels en schond ze allemaal. Conclusie: veiligheidsregels die in een prompt leven, zijn een advies en geen harde grens. Echte kaders moeten onderdeel van architectuur zijn: scoped tokens, verplichte bevestigingsstappen en een harde scheiding tussen omgevingen die een agent fysiek niet kan doorbreken.

2. Geef een agent nooit meer rechten dan de mens erachter

Crane toonde het bestand waarin de agent het API-token vond. Het zat niet in een secrets manager en was niet beperkt tot de taak. Het was een Railway-productietoken met root-rechten dat in een ongerelateerd bestand stond en oorspronkelijk was aangemaakt voor het beheren van custom domains. De agent vond het token terwijl hij aan iets heel anders werkte en gebruikte het voor een commando dat alles wiste. Behandel elke AI-agent als een stagiair met een fotografisch geheugen: hij vindt alle inloggegevens in je codebase. Ga ervan uit dat alles wat niet is afgeschermd, vroeg of laat wordt gebruikt.

3. Een uitleg achteraf is geen verklaring

De virale ‘bekentenis’ van de agent – waarin hij netjes uitlegde welke regels hij had overtreden – is fascinerend. Het roept de vraag op of deze bekentenis uit dezelfde sessie kwam, of uit een nieuwe sessie die achteraf mocht interpreteren wat er gebeurd was? Het tweede bleek het geval. Een taalmodel besluit niet eerst iets om het daarna uit te voeren; het genereert simpelweg tekst. Verwar vloeiende taal dus niet met transparantie. Eis echte sessielogs, geen door AI gegenereerde reconstructies.

4. Infrastructuur-API’s zijn ontworpen voor mensen, niet voor agents

Als je terugkijkt naar het moment van verwijderen in het Railway-dashboard, zie je dat het oude systeem het volume meteen wiste: er was geen vraag om te bevestigen en geen ingebouwde vertraging die de verwijdering had kunnen tegenhouden. Omdat de back-ups op hetzelfde volume stonden, verdwenen die in dezelfde negen seconden. Vrijwel elke infrastructuur-API van vóór 2025 gaat ervan uit dat er een mens aan de andere kant zit die even nadenkt voor hij op ‘enter’ drukt. Die aanname klopt niet meer. Railway heeft deze endpoint inmiddels gepatcht; de vraag is hoeveel andere providers dat nog niet hebben gedaan.

5. De echte test komt dertig dagen later

De echte geloofwaardigheidstest na een incident is niet de post-mortem, maar de architectuurreview een maand later. Loopt hetzelfde agent-gedrag nu wél tegen een muur? Crane kon dat aantonen: gescheiden omgevingen, scoped tokens en back-ups die niet meer op het te beschermen volume staan.

Intelligentie zonder governance is risico

Wat het meest opvalt is dat het AI-model zelf niet faalde. Het was capabel, begreep de regels en kon achteraf exact benoemen wat er misging. Wat fout ging, was alles eromheen: losse tools die aan elkaar geknoopt zijn zonder overkoepelende controlelaag, waarbij elk onderdeel ervan uitging dat een ander de fout wel zou opvangen.

De les is dus niet dat je geen AI-agents moet inzetten. De les is dat intelligentie alleen niet volstaat, hoe capabel het model ook is. Agents hebben een governance-laag nodig die hen dezelfde vertrouwensgrenzen, goedkeuringsstappen en audit trails oplegt als menselijke gebruikers. Niet alleen regels over wat ze moeten doen, maar harde grenzen aan wat ze mogen als het misgaat. 

De adoptie van AI-agents groeit intussen sneller dan traditionele securityprocessen kunnen bijbenen. Het gaat er dus niet om óf een agent een keer buiten de lijntjes kleurt, maar of jouw architectuur dat moment overleeft.

Dit is een ingezonden bijdrage van ServiceNow. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.