Alles wat je agent leest is aanvalsinput
Er is deze week één zin die alles samenvat wat er in agent-security gebeurde: alles wat je agent leest, is invoer die een aanvaller kan schrijven. Niet alleen chatberichten — ook code, logs, issue-titels, toolresultaten en bestandsnamen.
De casus die dat het scherpst laat zien komt van VirusTotal. Onderzoekers toonden prompt injection aan in de Code Insights-API: tekst verstopt in de te analyseren code stuurde de analyse zelf aan (exploiting.systems). Een beveiligingstool die kwaadaardige bestanden beoordeelt, laat zich sturen door het bestand dat hij beoordeelt. Als dát kan, dan kan het ook bij jouw agent die "alleen even een logbestand samenvat".
Filteren alleen werkt niet
De voor de hand liggende reactie — een filter dat verdachte instructies herkent — botst op zijn eigen foutmarge. Een deterministische aanpak tegen prompt injection blijkt in de praktijk veel legitiem werk te blokkeren; de auteur documenteerde de fout-positieven expliciet (vineetpant/customhouse).
Dat is geen argument tegen filtering, maar tegen filtering als enige laag. Een filter dat streng genoeg staat om injectie te stoppen, staat streng genoeg om je eigen securityrapport te weigeren. De verdediging die overblijft is architectonisch: beperkte rechten, geïsoleerde uitvoering, en expliciete toestemming voor risicovolle acties.
Fail closed in plaats van fail permissive
Precies dat principe zit in Runbook.v1, een specificatie voor beheerste MCP-workflows die bij onverwachte situaties stoppen in plaats van permissief door te gaan (CorpusIQ/runbook-spec). Toegestane tools en parameters staan vooraf vast; wat daarbuiten valt, valt dicht.
Voor een homelab is dat de bruikbaarste vertaling van "agent-security" die er deze week langskwam. Definieer per workflow welke tools mogen draaien met welke argumenten, en eis menselijke goedkeuring voor schrijven, verwijderen, netwerkbeheer en alles wat secrets aanraakt. Een agent die niet verder kan, is beter dan een agent die iets aannemelijks verzint en doorloopt.
Sandboxes lekken via gemak
GitHub verkleinde deze week de mounts van ~/.local in zijn agent-firewall tot alleen de daadwerkelijk benodigde paden, en houdt gevoelige sandboxstatus en sleutels buiten de agentcontainer (github/gh-aw-firewall#7530). Dat is een correctie op de meest gemaakte fout in zelfbouwopstellingen: een hele homedirectory of configuratiemap mounten omdat dat sneller werkt dan uitzoeken welke drie paden nodig zijn.
Dezelfde week liet GitHub zien hoe generatie zelf een injectiepad wordt: heredocs in automatisch gegenereerde workflow-YAML kunnen onbetrouwbare inhoud in een shellcontext laten belanden (github/gh-aw#53183). Laat agents daarom geen shellscripts samenstellen via vrije tekstinterpolatie. Gestructureerde argumenten, tijdelijke bestanden met vaste grenzen en validatie vóór uitvoering zijn saai en werken.
MCP-tokens zijn wachtwoorden
Een QuickBooks-MCP-server moest worden aangepast vanwege CSRF-risico's en onveilige tokenopslag (nexusct/quickbooks-online-mcp#1). Het patroon is bekend uit de webwereld en keert nu terug in de MCP-laag: OAuth-callbacks zonder bescherming tegen vervalste verzoeken, en tokens die belanden in bestanden die per ongeluk in een repository of logregel eindigen.
Behandel een MCP-token als een wachtwoord met schrijfrechten, want dat is het meestal ook. Buiten repositories en logs bewaren, rechten zo krap mogelijk zetten, en callbacks beschermen.
De dependency die je niet ziet
Tot slot een herinnering dat de aanvalsoppervlakte niet stopt bij je eigen code. Bij dear-agent bleken kwetsbare indirecte JavaScript-dependencies nog aanwezig, terwijl ze niet in het packagebestand stonden (vbonnet/dear-agent#1260). Een bijgewerkte top-level versie is geen bewijs dat het hele pad schoon is; de lockfile is de waarheid.
De checklist die overblijft
- Behandel alles wat een agent leest — code, documenten, logs, toolresultaten — als onbetrouwbare invoer, ook als het van een vertrouwde bron lijkt te komen.
- Vertrouw niet op filtering alleen. De filters die injectie stoppen, stoppen ook je eigen werk.
- Laat workflows dichtvallen bij twijfel: toegestane tools en parameters vooraf vastleggen, de rest weigeren.
- Mount concrete projectmappen, read-only waar het kan. Nooit een hele home- of configuratiemap "voor het gemak".
- Bewaar MCP-tokens buiten repositories en logs, met minimale rechten en beschermde OAuth-callbacks.
- Scan transitieve dependencies en controleer lockfiles, niet alleen de directe versienummers.
