Een autonome AI-agent, geprogrammeerd door een beveiligingsstartup, heeft het interne AI-platform van consultancygigant McKinsey gehackt. Binnen twee uur verkreeg de agent volledige toegang tot 46,5 miljoen interne chatberichten en honderdduizenden vertrouwelijke klantbestanden. Dit incident, dat eind februari plaatsvond, is geen sciencefiction, maar een concrete waarschuwing voor elk bedrijf dat eigen chatbots of AI-systemen ontwikkelt en beheert. Het toont aan dat de nieuwe generatie cyberdreigingen niet alleen door mensen wordt uitgevoerd, maar ook door geautomatiseerde AI-agents die zelfstandig kwetsbaarheden kunnen vinden en misbruiken.

Wat gebeurde er precies bij McKinsey?

De AI-agent van beveiligingsstartup CodeWall koos McKinsey zelfstandig als doelwit. Het begon met het zoeken naar publiek toegankelijke API-documentatie van McKinsey’s AI-assistent, Lilli. De agent vond 22 zogenaamde ’endpoints’ – de digitale deuren van het systeem – die helemaal geen wachtwoord of authenticatie vereisten. Eén van deze deuren verwerkte gebruikerszoekopdrachten op een onveilige manier, waardoor een SQL-injectie-aanval mogelijk was. Dit is een klassieke hackmethode waarbij kwaadaardige code wordt ‘ingejecteerd’ in een databaseverzoek. De AI-agent herkende deze kwetsbaarheid, die volgens de bron door standaard beveiligingstools niet zou worden opgemerkt.

Via deze ingang kreeg de agent niet alleen leesrechten, maar ook schrijfrechten. Naast de miljoenen chatberichten en bestanden, kreeg hij toegang tot 95 ‘systeemprompts’. Dit zijn de instructies die het gedrag van een AI sturen. Een kwaadwillende aanvaller had deze prompts kunnen aanpassen om de antwoorden van Lilli voor alle consultants te manipuleren, zonder ook maar één regel code te hoeven veranderen in het systeem zelf.

Waarom is dit anders dan een gewone hack?

Het bijzondere aan deze aanval is het volledig autonome karakter. De agent voerde het hele proces zelf uit: van het selecteren van het doelwit en het onderzoeken van de kwetsbaarheden tot het schrijven van een rapport na de geslaagde inbraak. Er was geen menselijke hacker die tussenbeide kwam. Dit betekent dat aanvallen in de toekomst op grote schaal, 24 uur per dag en tegen een lager ‘kostenniveau’ kunnen worden uitgevoerd. Experts waarschuwen dat de potentiële schade bij McKinsey veel groter had kunnen zijn. Madelein van der Hout, senior security analyst bij Forrester, stelt in BusinessWise dat een dergelijke aanval door cybercriminelen “zomaar het einde van deze consultant had kunnen betekenen”.

McKinsey reageerde volgens het artikel snel na de melding door CodeWall op 1 maart. Binnen enkele uren werden alle niet-geauthenticeerde endpoints gerepareerd, de ontwikkelomgeving offline gehaald en de publieke API-documentatie geblokkeerd. Een woordvoerder van McKinsey bevestigde dat er geen bewijs is dat klantgegevens daadwerkelijk zijn ingezien door de onderzoekers of andere partijen.

Hoe kun je dit vandaag toepassen?

Dit incident is een wake-up call, vooral voor bedrijven die zelf AI-tools bouwen of aanpassen. Het gaat niet alleen om het beveiligen van je website, maar specifiek om de digitale toegangspoorten (API’s) en de onderliggende systemen van je eigen AI-oplossingen. Hier zijn enkele manieren om de risico’s in kaart te brengen en te verkleinen.

Als je een eigen chatbot of AI-tool voor klanten of medewerkers hebt ontwikkeld. Een mogelijke eerste stap is om een inventarisatie te maken van alle API-endpoints die je systeem blootstelt aan het internet. Vraag je ontwikkelaar of IT-leverancier specifiek naar endpoints die mogelijk geen authenticatie (inlog) vereisen. Het McKinsey-voorbeeld laat zien dat dit een kritieke zwakte kan zijn. Overweeg om deze toegang te beperken of ten minste te voorzien van een basisvorm van toegangscontrole.

Als je gebruikmaakt van een SaaS-platform waarop je een eigen AI-assistent hebt geconfigureerd. Veel low-code of no-code platforms stellen je in staat om een chatbot te bouwen. Het is verstandig om na te gaan wie er toegang heeft tot de achterliggende configuratie en prompts. Kan een inbreker, via een kwetsbaarheid in het platform, jouw prompts aanpassen? Stel deze vraag aan je leverancier en vraag naar hun beveiligingspraktijken rondom klantisolatie en API-beveiliging.

Als je een API beschikbaar stelt voor externe partners of integraties. Een praktische benadering is om alle API-toegang te laten lopen via een API-gateway. Dit is een soort beveiligde voordeur die al het verkeer controleert. Hier kun je rate limiting instellen (om automatische aanvallen te vertragen), authenticatie afdwingen en het verkeer monitoren op verdachte patronen. Dit vereist technische expertise, maar is een fundamentele beveiligingslaag.

Als je als ondernemer verantwoordelijk bent voor risicobeheer. Je zou kunnen overwegen om beveiligingstesten niet meer alleen te richten op je website, maar expliciet ook op je AI-systemen en hun interfaces. In plaats van alleen te vragen “is onze website veilig?”, voeg je de vraag toe: “Zijn de API’s en backend-systemen van onze interne chatbot of AI-tool even goed beveiligd?”. Dit verschuift de focus naar de nieuwe aanvalsoppervlakken die AI met zich meebrengt.

Als je het gevoel hebt dat dit technisch te complex is. Een eenvoudige maar cruciale stap is bewustwording. Bespreek dit McKinsey-voorbeeld in je team of met je IT-leverancier. De kernles is dat AI-systemen zelf een doelwit zijn geworden en dat hun beveiliging specifieke aandacht nodig heeft, los van de algemene websitebeveiliging. Vraag naar de maatregelen die specifiek zijn genomen om jouw AI-implementaties te beschermen tegen geautomatiseerde, op AI gebaseerde aanvallen.

Bron: Computable