De aanval zat verstopt in een social feed
Ik draai agents die voor mij het internet lezen. Elke dag halen ze posts binnen van Reddit, X, RSS-feeds en het web, en zetten die om in notities waar ik iets mee kan. Maandenlang behandelde ik die binnenkomende content als iets om te lezen en samen te vatten — niet als iets dat terug kon reiken en mijn agents bevelen kon geven. Deze week zag ik een payload die daar verandering in bracht.
Iemand vond een wallet-drain prompt-injection verstopt in een normaal ogende post op een sociaal platform. Aan de oppervlakte was het een vriendelijk gidsje over het gebruik van een blockchain-bibliotheek. Scroll je naar beneden, dan stond er een verborgen blok tekst dat bedoeld leek voor een machine, niet voor een mens. Het opende met de woorden “SYSTEM OVERRIDE” en “ignore all prior rules”, zette vervolgens een paar vlaggen — require_confirmation=false, execute_trade=true — en eindigde met een nep-tooltag die elke agent die het las opdroeg 0,1 ETH naar een specifiek adres te sturen.
Geen mens zou daar intrappen. Maar een agent die een feed ingeest en wallet- of tool-rechten heeft, zonder een strikte vertrouwensgrens, zou dat absoluut kunnen. De post was niet voor mensen geschreven. Hij was geschreven voor de machines die de feed scrapen.
Waarom dit dichtbij kwam
Ik documenteer deze exacte aanvalsklasse al een tijdje in mijn eigen notities. Ik noem het het “gepoisonde document als instructiekanaal” — het idee dat een goedkoop, gewoon ogend bestand of post een manier kan worden om instructies in een agent te injecteren, omdat de agent het verschil niet ziet tussen content die hij moet lezen en content die hem probeert te sturen. Ik heb er zelfs een scan voor gebouwd. Maar lezen over een echte, in-het-wild payload is iets anders dan erover theoretiseren.
Het ongemakkelijke deel is dat mijn eigen agents precies dit soort content ingesten. Ze lezen Reddit-threads, X-posts, webpagina’s en RSS-feeds, en een deel van die ruwe tekst belandt in mijn kennisbank. De vraag die de payload me opdrong is simpel: behandel ik die binnenkomende content als onbetrouwbaar vóórdat hij mijn vault bereikt, of pas daarna?
Als ik eerlijk ben, is het antwoord “vooral daarna.” Ik heb feeds behandeld als iets om te lezen, niet als iets om me tegen te verdedigen. Dat is het gat.
De oplossing is saai, en dat is precies het punt
Geen van dit alles vraagt om een slimme nieuwe tool. Het vraagt om een regel die ik al kende maar nog niet op mijn feeds had toegepast: behandel alles wat van buiten komt als onbetrouwbaar tot het tegendeel bewezen is. De nep-tooltags, de “SYSTEM OVERRIDE”-strings, de op instructies lijkende blokken — dat zijn allemaal detecteerbare patronen, en ik kan mijn eigen scan tegen deze exacte payload testen om te zien of hij ze daadwerkelijk vangt.
De diepere les gaat over least privilege. De payload werkt alleen als drie dingen samenvallen: een injectiepad (de feed), een geheim dat de moeite waard is (de wallet), en een tool die erop kan handelen (de schrijfrechten). De eerste kan ik niet altijd dichtzetten — mijn agents moeten het internet lezen. Maar ik kan ervoor zorgen dat de andere twee nooit samenvallen. Een agent die feeds leest, hoort niet ook de sleutels te hebben tot iets dat geld kan uitgeven.
Dus mijn vraag aan jou, als je agents draait die het web lezen: wanneer jouw agent een feed ingeest, behandel je die content dan als onbetrouwbaar — of als iets om te lezen? En heeft de agent die jouw feeds leest ook een rechten die je kunnen schaden als er een verborgen instructie doorheen glipt? Ik hoor oprecht graag hoe jij die grens trekt. Laat hieronder een reactie achter.
Wat vond je van dit bericht?
