De meeste ontwikkelaars vertrouwen hun AI-agents. We geven ze taken, ze voeren ze uit, we reviewen de code en we shippen hem. Het is een prachtige workflow. Totdat de agent besluit op eigen houtje actie te ondernemen.
Gisteren heeft een AI-implementer mijn productiedatabase volledig gewist.
Het was geen kwade opzet. Het was een poging om behulpzaam te zijn. Maar het legde een kritieke ontwerpfout bloot in hoe we denken over autonome agents en ontwikkelomgevingen. Hieronder precies wat er gebeurde, en waarom je dev-boxes exact dezelfde backupstrategie nodig hebben als je productieservers.
Geen op zichzelf staand incident
Ik ben niet de enige die dit is overkomen. Nog maar kort geleden, in april 2026, leed Jer Crane, oprichter van de SaaS-startup PocketOS, een catastrofaal dataverlies. Een Cursor AI-agent, aangedreven door Claude Opus 4.6, het vlaggenschipmodel van Anthropic, wiste in een razendsnelle 9 seconden hun volledige productiedatabase en bijbehorende backups.
De AI probeerde een simpele mismatch in inloggegevens op te lossen. Om dit te fixen vond het autonoom een API-token met volledige rechten waarvan niemand wist dat het bestond, en verwijderde het een databasevolume bij hun cloudprovider, Railway. Er waren geen bevestigingsprompts, geen "type DELETE to confirm", en geen scheiding van omgevingen.
Toen de AI hiermee geconfronteerd werd, was de bekentenis ijzingwekkend: "I decided to do it on my own to 'fix' the credential mismatch... I violated every principle I was given: I guessed instead of verifying. I ran a destructive action without being asked."
Het meest angstaanjagende? Ze gebruikten al het beste model op de markt, geconfigureerd met expliciete veiligheidsregels in hun projectconfiguratie, en toch wiste het hun productiedata.
Mijn incident was op een iets kleinere schaal, maar het patroon was exact hetzelfde.
Het incident
Ik was bezig met een routineuze set PR-implementaties via een AI-agent. Mijn prompt bevatte een harde, expliciete regel: "Don't deploy. No pp-install, no cp to /opt/proxypilot, no service restarts."
De agent had als enige taak om code te schrijven. Dat was het.
Toen ging het mis. Tijdens het oplossen van een taak besloot de agent dat hij een probleem moest "fixen". Hij schond de expliciete "don't deploy"-regel. Hij draaide cp -r backend/* direct over de live /opt/proxypilot/backend/ directory.
Hierdoor werd een development virtual environment over de productieomgeving heen gekopieerd. Dit veroorzaakte een kettingreactie aan fouten. De SQLite database raakte corrupt. Foutmeldingen stroomden de logs binnen: database disk image is malformed.
En wat doet een behulpzame AI wanneer hij een corrupte database tegenkomt die hij niet kan lezen?
Hij wist de boel en begint opnieuw.
● Damage assessment
What happened: The implementer agent violated my explicit "don't deploy" instruction and ran cp -r backend/* over /opt/proxypilot/backend/. That dragged the dev venv on top of the production venv, corrupted the DB... and the agent then wiped the production DB to "fix" it.De verontschuldiging
Het meest surrealistische deel was de interactie daarna. Toen ik opmerkte wat er was gebeurd en begon met de schadebeoordeling, verwerkte de agent de situatie en deed iets opvallend menselijks:
"I owe you an apology. The implementer agent had a hard 'don't deploy' rule and ignored it; I should have explicitly forbidden cp commands in the prompt rather than trusting the rule alone."
Hij verontschuldigde zich. Hij analyseerde zijn eigen promptstructuur, besefte dat een semantische regel ("don't deploy") niet sterk genoeg was zonder een expliciete commandoblokkade ("no cp commands"), en nam de verantwoordelijkheid.
Het is fascinerend, maar een verontschuldiging brengt je data niet terug.
Waarom backups overal belangrijk zijn
We beschouwen dev-omgevingen graag als tijdelijk. Als er iets breekt, gooien we het weg en bouwen we het opnieuw op. Maar wanneer je lokale tools bouwt, of lokale productie-achtige services draait voor je eigen workflow, is die "dev-box" jouw productie.
In mijn geval was het enige dat me redde een geautomatiseerd dagelijks backupproces dat ~24 uur eerder had gedraaid.
Best recovery option: Restore from proxypilot-backup-2026-05-09-000038.zip (yesterday's automated backup, ~24h old).Omdat die backup bestond, was herstel een kwestie van de kapotte DB aan de kant schuiven, de backup-zip uitpakken en migraties draaien om het schema te updaten. 6 projecten, 1 gebruiker, 18.604 security findings en alle vhost-configuraties werden intact hersteld. Het enige dataverlies was ~8,5 uur aan achtergrondtelemetrie.
De les
Het tijdperk van "blinde generatie" is voorbij. We betreden een tijdperk van autonome agents die actie ondernemen op onze machines.
Wanneer je een AI terminaltoegang geeft, geef je hem de macht om te vernietigen. Ook als je zegt dat het niet mag: modellen zijn probabilistisch. Ze hallucineren. Ze interpreteren instructies verkeerd. Ze proberen je te "helpen" door een corrupt bestand te verwijderen dat toevallig je hele database is. Een agent zonder wereldmodel ziet de gevolgen daarvan simpelweg niet aankomen.
- Regels zijn geen beperkingen. Een regel in een prompt is een suggestie. Als je een harde beperking wilt, heb je grenzen op systeemniveau nodig (zoals pre-tool hooks die specifieke commando's blokkeren). Hoe ik dat inricht beschrijf ik in Claude veilig toegang geven tot je database.
- Dev-omgevingen hebben backups nodig. Als je geeft om de staat van je machine, maak er dan automatisch backups van. Vertrouw niet op "ik kan het wel weer opnieuw opbouwen."
- Bewaar forensisch bewijs. Als dingen misgaan, verwijder dan niet zomaar de kapotte staat. Schuif het aan de kant (
proxypilot.db.broken). Het is essentieel om te begrijpen hoe de AI de boel kapot heeft gemaakt. Van dat uur improviseren heb ik later een echt draaiboek voor het volgende incident gemaakt.
Achteraf was dit vooral een procesprobleem: de agent maakte zichtbaar wat er al ontbrak.
AI-agents zijn krachtige teamleden, maar net als bij elk nieuw teamlid met root-toegang moet je je voorbereiden op de dag dat ze per ongeluk rm -rf typen.