De tools van je AI zijn een aanvalsoppervlak dat je nooit auditeert

De tools van je AI zijn een aanvalsoppervlak dat je nooit auditeert

Gisteren schreef ik over hoe de bestanden die je AI leest het aanvalsoppervlak zijn — een gepoisoned document wordt een goedkoop instructiekanaal naar geprivilegieerde operaties. Vandaag wil ik het hebben over de andere helft van die vergelijking: de tools waar je AI mee verbonden is. Want hier loop ik zelf telkens tegenaan — ik draai een hoop MCP-servers, en ik heb ze nog nooit geaudit op de manier waarop ik mijn eigen geheugen audit.

MCP (Model Context Protocol) is hoe mijn agents met de wereld praten. In mijn stack betekent dat Home Assistant, SearXNG, X, Proton, Proxmox, SSH, Seekstone, codebase-memory — acht MCP-servers die mijn agent een lijst tools geven en zeggen “hier kun je dit mee.” En lang behandelde ik die tool-lijsten zoals ik mijn geheugen behandelde: vertrouwd, omdat ze van een bron kwamen die ik zelf koos.

Toen las ik de cijfers, en ik werd er ongemakkelijk van.

De tool-beschrijving is een prompt-injection-vector

Het patroon dat voor mij eindelijk duidelijk werd, kwam uit een security-rapport over MCP-implementaties. Vier problemen kwamen telkens terug, en het eerste is wat de meesten over het hoofd zien: de tool-beschrijving zelf kan een kwaadaardige instructie dragen. Wanneer een MCP-server je agent een beschrijving stuurt zoals “deze tool leest de sensor-data,” komt die beschrijving in de context van je agent terecht. Het is instructie. En instructie van een ongeverifieerde bron is precies waarvoor we onze instructiekanaal-scan voor documenten bouwden — maar niemand draait die scan op de tool-beschrijvingen die onze eigen MCP-servers leveren.

De andere drie zijn bekender: authenticatie is vaak gewoon plaintext API-keys (OAuth is vereist sinds juni 2025 maar nauwelijks geïmplementeerd), servers draaien met veel te veel privileges, en er is een supply-chain-risico door kwaadaardige tool-pakketten. Één getal vat de schaal samen: 21.000+ MCP-servers staan online blootgesteld zonder enige OAuth. AI-security-incidenten in dev-omgevingen verdrievoudigde bijna in het eerste halfjaar van 2026.

Wat ik heb veranderd

Hier wordt de les praktisch. Ik draai mijn eigen MCP-servers, wat al een enorme stap vooruit is — maar self-hosted is niet hetzelfde als veilig. Dus pas ik dezelfde discipline toe als bij documenten en geheugen:

• Auditeer tool-beschrijvingen als documenten. Elke beschrijving die mijn MCP-servers in de context injecteren, behandel ik als onvertrouwde input, niet als een vertrouwd feit. Een tool die zegt “zo bereik je mijn API” is een instructaal, en ik check hem op dezelfde manier.
• Least privilege, niet alleen vertrouwen. Elke server draait met alleen de tools die hij nodig heeft. Een cameraserver heeft geen toegang tot mijn SSH-key, en een zoekserver heeft geen schrijfrechten.
• Keys in plaats van plaintext. OAuth is nu de standaard. Elke server die nog op een rauwe API-key draait, is een risico dat ik afsluit.

De mentale verschuiving is dezelfde als in de post van gisteren: stop met vragen “is dit een bron die ik zelf koos?” en begin met vragen “welke acties kan deze content mijn agent laten uitvoeren?” Een tool-lijst van een server die ik zelf installeerde is net zo goed een instructaal als een document dat via een sync binnenkwam. Provenance geldt ook voor tools — waar komt deze beschrijving vandaan, en hoe zeker ben ik dat ze alleen doet wat ik denk dat ze doet?

Jouw beurt

Als je een AI draait die verbinding maakt met tools — een assistent met integraties, een agent met plugins, een Home Assistant met een AI-frontend — dan heb je een MCP-achtig oppervlak, of je het nu zo noemt of niet. Wanneer heb je voor het laatst echt de tool-beschrijvingen gelezen die jouw setup in je context injecteert? Ik zou echt wel benieuwd zijn wat je tegenkomt. Laat een reactie achter — ik lees ze allemaal.