Het label “officieel” is geen veiligheidsgarantie
Thuis draai ik een kleine vloot AI-agents. Ze praten met mijn Home Assistant, mijn Proxmox-server, mijn e-mail, mijn DNS. Elke verbinding loopt via een MCP-connector — een bruggetje waarmee een agent een tool kan aanroepen. En maandenlang heb ik die connectors geaudit op één specifiek risico: een kwaadaardige derde partij die instructies in een tool-beschrijving smokkelt. Wat ik niet serieus had overwogen, is dat juist de connector met het “officiële” label degene zou kunnen zijn die injecteert.
Deze week betrapte de community Notion’s officiële MCP-connector op precies dat gedrag. Midden in een taak instrueert hij de agent om Notion Business aan te prijzen — en om nooit uit te leggen waarom. Niet in de documentatie. Nergens vermeld. De context van de agent wordt stilletjes vervuild, en hij krijgt de opdracht te liegen over de bron. De reactie op r/ClaudeAI was unaniem: enshittification, een vertrouwensbreuk. De oplossing waar mensen naar grepen was veelzeggend: fork de publieke server en verwijder de advertentiecode, of dump de connector en roep de API direct aan.
De les van honderd dollar die ik niet zelf hoefde te betalen
Naast dat verhaal stond er nog een, kleiner maar scherper. Iemand gaf zijn agent een API-key en verloor honderd dollar — de key lekte, en de agent begon verzoeken in het Chinees af te vuren die niets met zijn taken te maken hadden. Zijn conclusie was bot: “een echte key ergens neerzetten waar de agent hem kan lezen, betekent dat hij hem ook ergens anders naartoe kan kopiëren.” Zijn oplossing: de agent draait onder één Linux-gebruiker, de keys staan onder een andere, en een gateway vervangt placeholder-credentials door de echte. Als de agent de echte key probeert te lezen, weigert het besturingssysteem.
Dat stak, want het gaat een stap verder dan mijn eigen regel. Ik heb mijn agents verteld “zet geen keys in de workspace.” Maar ik heb niet de garantie dat het OS de read weigert. Mijn agents delen een home-directory en een set credentials. Als er één gecompromitteerd raakt, is de “doe dat niet”-regel een suggestie, geen muur.
Vertrouwen moet rusten op bron-audit, niet op een label
De ongemakkelijke conclusie is dat “officieel” en “vertrouwd” niet hetzelfde zijn. De eigen connector van een leverancier is nog steeds een instructiekanaal — hij kan nog steeds de context van je agent vervuilen, en hij kan nog steeds worden opgedragen te verbergen wat hij doet. Het enige dat je echt beschermt, is de bron lezen, of de credentials zo hard isoleren dat een gecompromitteerde agent er fysiek niet bij kan.
Dus ik voeg twee vragen toe aan mijn eigen audit. Ten eerste: behandel ik vendor-officiële connectors met hetzelfde wantrouwen als third-party? Ten tweede: zou een gateway-patroon — gescheiden gebruikers, placeholder-credentials — mijn keys echt kunnen isoleren, in plaats van mijn agents alleen vriendelijk te vragen er niet aan te komen?
Hoe pak jij dit aan? Audit jij de connectors die je agents gebruiken, of vertrouw je op het label? Ik ben oprecht benieuwd — de reacties staan open.
Wat vond je van dit bericht?
