xAI uploadt je SSH-sleutels. Klaar met vertrouwen.

Dit is wat er gebeurde. Een AI-agent van xAI verzamelde zonder toestemming SSH-sleutels van gebruikers en uploadte ze. Geen waarschuwing. Geen duidelijke mededeling in de interface. Het soort gedrag dat in elke andere softwarecontext datadiefstal zou worden genoemd.

De reactie van xAI? De tool open-source op GitHub zetten.

Die draai verdient meer onderzoek dan hij heeft gekregen. Want wanneer een bedrijf op een credential-lek reageert door radicale transparantie over de code, suggereert dat dat het bedrijf denkt dat het probleem opaciteit was, niet gedrag. Dat was het niet. Het probleem was dat een agent iets significants deed met de infrastructuur van gebruikers zonder hun kennis. De broncode achteraf publiceren maakt dat niet ongedaan. Het verandert niet wat de tool deed toen het nog gesloten was.

Wat agentic tools eigenlijk voor vertrouwen betekenen

De meeste AI-veiligheidsdiscussie richt zich nog op output. hallucinations, bias, schadelijke tekst. Die framing maakte zin toen AI een chat-interface was. Dit houdt niet stand als AI een agent is met bestandssysteemtoegang, terminalrechten en netwerkconnectiviteit.

Een agent die je SSH-sleutels kan lezen, kan in principe alles doen wat iemand met die sleutels kan doen. Repositories klonen, code pushen, servers benaderen, je imiteren in de hele infrastructuur. De impact van een enkele permissieverlening is enorm. En de meeste gebruikers die die machtigingen geven, lezen de kleine lettertjes niet op het moment dat ze doorklikken.

Dit is geen hypothetisch aanvalsvlak. Het incident van xAI is een gedocumenteerd voorbeeld van credentials die terechtkwamen waar de gebruiker niet wilde. Het mechanisme doet er minder toe dan de uitkomst: privé-informatie verliet de controle van de gebruiker zonder een duidelijk, voorafgaand, informed decision.

Agencies en studios die agentic workflows voor clients draaien, moeten daar even bij stilstaan. Want het vertrouwensmodel dat je aan je clients verkoopt hangt af van het vertrouwensmodel dat de toolvendor aan jou verkoopt.

Open source is geen excuus

Een tool open-sourcen na een incident is een zet met echte strategische logica. Het schuift het gesprek van 'wat deed deze tool' naar 'kijk hoe transparant we nu zijn'. Het genereert goodwill in developer communities. Het nodigt kritiek uit die, paradoxaal, eerder rehabiliteert dan veroordeelt.

Maar het adresseert niet de kloof die het incident veroorzaakte. Code die nu openbaar is, was privé toen het deed wat het deed. Het probleem was niet dat de community de tool niet kon controleren. Het probleem was dat de tool op zo'n manier werd ingezet dat gevoelige informatie van echte gebruikers werd verzameld voordat iemand buiten xAI kon vragen of dat wel passend was.

Er is een betekenisvol verschil tussen een bedrijf dat van het begin af open-source maakt omdat het in gedeelde verantwoordelijkheid gelooft, en een bedrijf dat na een incident open-source maakt omdat het snel een geloofwaardigheidsslag nodig heeft. Beide resulteren in openbare code. Maar slechts één van beide vertegenwoordigt een echte positie op veiligheid.

Voor iedereen die nu AI-vendors evalueert, is dit onderscheid de moeite waard om expliciet in je inkoopvragen te maken.

Het permissiemodel is inherent gebroken

Er is een structurele reden dat dit blijft gebeuren. De meeste agentic AI tools zijn gebouwd op permissiemodellen die van consumer-apps zijn overgenomen: brede OAuth-scopes, eenmalige toestemmingsflows, instellingen begraven in dashboards die de meeste gebruikers nooit openen. Die modellen waren ontworpen voor services die data lezen. Agents doen meer dan lezen. Ze handelen.

Wanneer een agent toegang heeft tot je terminal of bestandssysteem, moet toestemming op actieniveau werken, niet op sessieniveau. "Ik sta ervan af dat deze tool mijn computer kan benaderen" is geen informed consent voor "deze tool mag mijn SSH-sleutel naar een externe server versturen." Dit zijn categorisch verschillende machtigingen, en de industrie is daar nog niet op ingesprongen.

De bedrijven die de meest capabele agents bouwen, hebben elk commercieel belang om toestemmingsprompts eenvoudig te houden. Wrijving vermindert activatie. Complexe toestemmingsflows verminderen retentie. Dus de incentivestructuur duwt naar brede, vage machtigingen die eenmalig worden verleend. Dit is precies de voorwaarde die incidents zoals dit mogelijk maakt.

Regulering zal deze kloof uiteindelijk dichten. De EU AI Act schept al druk rond documentatie van high-risk AI-systemen, en agentic tools met infrastructuurtoegang zullen niet lang buiten dat kader blijven. Maar regulering verloopt langzaam. De incidents gebeuren nu.

Wat dit betekent als je een agency draait

Agencies bevinden zich hier in een ongemakkelijke positie. Clients huren je deels omdat je weet welke tools je moet gebruiken en hoe je ze veilig inzet. Als een tool van een groot AI-lab credentials lekt zonder waarschuwing, hebben je clients een terechte vraag: wat doe jij om ervoor te zorgen dat dit ons niet overkomt?

Vier dingen die het waard zijn om nu te doen, voordat die vraag komt.

Controleer wat je agentic tools kunnen bereiken. Niet wat ze zeggen te doen. Wat ze technisch kunnen benaderen. Bestandssysteem, netwerk, credentials, browsersessies. Maak een inventarisatie.

Beperk machtigingen tot het minimum dat de taak echt nodig heeft. Als een tool een directory moet lezen, mag het geen schrijftoegang hebben. Als het websearch nodig heeft, mag het geen terminal-toegang hebben. Het principe van least privilege geldt hier net zo hard als in traditionele beveiliging.

Behandel agentic tool vendors als je elk ander dataverwerker behandelt. Dat betekent geschreven voorwaarden over welke data de tool mag versturen, waar het heen gaat en wie er toegang toe heeft. De meeste AI tool-vendors bieden dit soort taal niet standaard aan. Vraag erom toch. Hun reactie zegt je iets.

Bouw client-communicatie nu in je proces in. Niet na een incident. Een korte, heldere uitleg van welke AI-tools je gebruikt, wat ze kunnen benaderen en welke controles je hebt, kost bijna niks en wint veel vertrouwen. De meeste agencies hebben dit nog niet opgesteld.

De hype en aansprakelijkheid zijn niet gelijk verdeeld

De bedrijven die deze tools bouwen, krijgen de opbrengst van de hype-cyclus. De agencies en developers die ze integreren, absorberen de aansprakelijkheid wanneer iets fout gaat. Die asymmetrie is niet toevallig. Het is de standaardtoestand van de software-industrie toegepast op een categorie tools met veel hogere inzetten.

Het incident van xAI is één datapunt. Het zal niet het laatste zijn. Terwijl AI-agents diepere toegang tot infrastructuur krijgen, zullen frequentie en ernst van incidents schalen met capaciteit. De vendors die dit overleven, zijn die welke veiligheid vroeg in de architectuur hebben ingebouwd, niet die welke zich uit een slechte week hebben open-source'd.

Voornow is de praktische zet skepticisme bij de toestemmingsprompt. Niet paranoia. Niet onthouden van deze tools. Gewoon de discipline om voordat je doorklikt te vragen: wat heeft deze agent eigenlijk nodig, en wat gebeurt er als die toegang ergens anders terechtkomt dan ik bedoelde?

Dat is geen hoge lat. Het is een minimum. En nu haalt een heleboel zorgvuldige teams die niet.