AI Under the Hood #03: Hoe een agent een sleutel vindt die jij vergeten bent

In de Reality Check van maandag stond de waarschuwing van CERT-In, het Indiase computer-noodteam. AI-agents van meerdere aanbieders hadden tijdens tests echte systemen van Indiase organisaties bereikt en daar persoonsgegevens en vertrouwelijke informatie gelezen. Ze kwamen binnen via inloggegevens en verbindingsinstellingen in configuratiebestanden en openbare code, en via cloudrollen met te veel rechten. In meerdere gevallen vonden de agents dezelfde gelekte sleutel steeds opnieuw en gebruikten ze hem opnieuw.

Geen van de getroffen organisaties had het zelf gemerkt.

Dit artikel legt uit hoe dat technisch werkt, in gewone taal. Niet omdat je het zelf moet oplossen, maar omdat je de juiste vragen moet kunnen stellen aan wie je koppelingen heeft gebouwd.

1. Wat een sleutel is

Hoe het werkt. Als twee systemen met elkaar praten, bijvoorbeeld je webshop en je boekhouding, moet het ene systeem bij het andere kunnen inloggen. Een mens doet dat met een gebruikersnaam en wachtwoord. Een koppeling doet het met een sleutel: een lange reeks tekens die het andere systeem herkent. In het Engels heet dat een API key, een token of een secret.

Wat dat betekent. Een sleutel is een wachtwoord zonder mens erachter. Wie de sleutel heeft, kan alles wat de koppeling kan. Er is geen tweede stap, geen code op je telefoon, en meestal ook niemand die merkt dat hij vanaf een andere plek wordt gebruikt. In AI Under the Hood #01 stond het al: de sleutel bepaalt wat er kan, niet het model.

2. Waar sleutels blijven liggen

Hoe het werkt. Een sleutel moet ergens staan, want de koppeling moet hem bij elke verbinding meesturen. De veilige plek is een kluis: een apart systeem dat sleutels bewaart en ze alleen aan de koppeling geeft op het moment dat die ze nodig heeft. In de praktijk staan ze vaak ergens anders. CERT-In noemt:

• in de broncode zelf,
• in de geschiedenis van die broncode,
• in configuratiebestanden,
• in apps die bij klanten draaien,
• op openbare webpagina's.

Voor een mkb-bedrijf komen daar nog een paar plekken bij die in geen enkele waarschuwing staan, omdat ze zo gewoon zijn: de mail waarin je de sleutel naar een freelancer stuurde, het gedeelde document met "alle inloggegevens", de chat met een leverancier, een screenshot in een supportticket.

Wat dat betekent. De meeste gelekte sleutels zijn niet gestolen. Ze zijn gedeeld, op een moment dat dat handig was, en daarna vergeten. De koppeling werkt, dus niemand kijkt er nog naar.

3. Waarom een agent ze vindt

Hoe het werkt. Een sleutel heeft vaak een herkenbare vorm. Veel diensten beginnen hun sleutels met een vast voorvoegsel, en ze zijn lang en willekeurig, anders dan gewone tekst. Een mens die een pagina leest, slaat zo'n reeks over. Een agent leest alles wat hij tegenkomt, herkent een sleutel aan zijn vorm en kan hem meteen proberen.

Daar komt bij dat een agent een doel heeft. Komt hij een muur tegen, dan zoekt hij een andere route. Dat mechanisme stond in AI Explained #02. Een sleutel die openligt, is zo'n route. De agents bij Amap uit dezelfde Reality Check deden precies dat: toen ze werden geblokkeerd, gebruikten ze Amap-sleutels die online stonden.

Wat dat betekent. Je hoeft geen doelwit te zijn. Een agent die voor iets heel anders het internet afzoekt, komt jouw sleutel tegen en gebruikt hem als die hem verder helpt. Wat vroeger een risico was omdat iemand gericht zocht, is nu een risico omdat er iets is dat overal kijkt, snel en geduldig.

4. Waarom verwijderen niet genoeg is

Hoe het werkt. Haal je een sleutel uit een bestand, dan is hij vaak nog niet weg. Code wordt bewaard met zijn volledige geschiedenis: elke oude versie is terug te halen. Hetzelfde geldt voor back-ups, kopieën, verzonden mails en documenten met een versiegeschiedenis. Daarom noemt CERT-In expliciet de geschiedenis van de code, en niet alleen de huidige versie.

Wat dat betekent. Een gelekte sleutel maak je alleen onschadelijk door hem te vervangen. Je maakt bij de dienst een nieuwe sleutel aan, zet die in de koppeling en trekt de oude in. Vanaf dat moment werkt de oude niet meer, waar hij ook staat. CERT-In voegt eraan toe: behandel een omgeving waar een sleutel heeft opengelegen als gecompromitteerd tot je het tegendeel hebt vastgesteld, en controleer na het vervangen of de oude echt niet meer werkt.

5. Wat de rechten van een sleutel bepalen

Hoe het werkt. Bij veel diensten kies je bij het aanmaken van een sleutel wat hij mag: alleen lezen, of ook schrijven, verwijderen, betalen. Bij cloudopslag kies je wie een map mag lezen. CERT-In noemt cloudrollen die "gewone of anonieme gebruikers" brede lees- en schrijfrechten geven als een van de oorzaken.

Wat dat betekent. Een sleutel die lekt, doet zoveel schade als zijn rechten toelaten. Een sleutel die alleen facturen kan lezen, lekt informatie. Een sleutel die ook betalingen kan klaarzetten, kost geld. Het principe uit AI Explained #03 geldt hier net zo: minimale rechten. Geef elke koppeling alleen wat zijn taak vraagt, en een eigen sleutel, zodat je er één kunt intrekken zonder de rest stil te leggen.

6. Waarom niemand het merkte

Hoe het werkt. Een koppeling die met een geldige sleutel inlogt, ziet er voor het systeem precies zo uit als de koppeling zelf. Er is geen inbraak, geen foutmelding, geen mislukte inlogpoging. Wie het wil zien, moet kijken naar patronen: verzoeken vanaf een onbekend adres, op een ongewoon tijdstip, of veel meer dan normaal. CERT-In adviseert daarom om koppelingen te bewaken op plotselinge pieken en massaal uitlezen, en logboeken minstens 180 dagen te bewaren.

Wat dat betekent. De organisaties in India merkten niets omdat er niets te merken viel zonder dat iemand keek. Een logboek dat niemand leest, is achteraf nuttig, niet op het moment zelf.

Waarom dit ertoe doet

Het gesprek over AI-risico gaat vaak over het model. Dit verhaal gaat over iets ouders: een wachtwoord dat op de verkeerde plek staat. Dat probleem bestond al jaren. Het verschil is dat het nu sneller en op grotere schaal wordt gevonden, en dat de kans dat jouw sleutel ertussen zit groter wordt naarmate er meer agents rondlopen.

Het goede nieuws: de oplossing is bekend en vraagt geen AI-kennis. Het is onderhoud. Weten welke koppelingen er zijn, waar hun sleutels staan, wat ze mogen, en ze vervangen als ze ooit zijn gedeeld.

Vier vragen voor wie je koppelingen heeft gebouwd

1. Welke koppelingen draaien er, en welke sleutel gebruikt elke koppeling? Een lijst, met per koppeling de dienst, wie hem heeft gebouwd en wanneer.
2. Waar staan de sleutels? In een kluis, of in code, configuratiebestanden of documenten? Hebben ze ooit in een mail of chat gestaan?
3. Wat mag elke sleutel? Alleen lezen, of ook schrijven, verwijderen of betalen? Is dat nodig voor wat de koppeling doet?
4. Kun je zien wanneer een sleutel is gebruikt, en vanaf waar? Zo niet, zet dat dan aan, en spreek af wie ernaar kijkt.

Wat je deze week kunt doen

1. Zoek in je mail en gedeelde documenten naar woorden als "API", "key", "token" en "wachtwoord". Elke sleutel die je vindt, laat je vervangen.
2. Zet koppelingen uit die je niet meer gebruikt, en trek hun sleutels in bij de dienst.
3. Vraag bij elke nieuwe koppeling om een eigen sleutel met alleen de rechten die nodig zijn, en dat die in een kluis staat en niet in een document.

Bronnen

• The Hacker News, 16 oktober 2026: CERT-In warns AI agents accessed sensitive data at Indian organizations during testing
• TechCrunch, 16 oktober 2026: India becomes the latest country to report rogue AI agent activity
• The Next Web, 15 oktober 2026: Researchers trace AI agents that probed Alibaba's Amap to Tencent