Eerder deze maand sprak ik op de Gartner Security & Risk Management Summit over een blinde vlek waar de meeste beveiligingsprogramma’s nog steeds geen rekening mee houden: hoe aanvallers AI-beveiligingsprogramma’s omzeilen door verouderde infrastructuur te gebruiken om AI-agenten te kapen.
De adoptie van AI gaat sneller dan beveiligingsprogramma’s kunnen verklaren. Ongeveer 71% van de organisaties gebruikt AI-agents in hun bedrijfsapplicaties, en 31% heeft deze al naar productieworkflows overgezet.
Om deze reden besteden organisaties terecht middelen aan het beveiligen van AI-workloads tegen modelvergiftiging, snelle injectie, datalekken en andere opkomende bedreigingen. Toch mist deze focus alles onder de AI-laag. Omdat een niet-gepatchte server, een verkeerd geconfigureerde Active Directory-machtiging of een in de cache opgeslagen inloggegevens op de machine van een ontwikkelaar blootstellingen zijn die aanvallers een directe route geven naar alles waar uw AI-agenten van afhankelijk zijn: kennisbanken, cloudopslag, Lambda-functies, SaaS-integraties en de inloggegevens waarmee ze verbonden zijn.
Dit betekent dat bedreigingsactoren uw AI niet echt frontaal hoeven aan te vallen – ze hoeven alleen maar te bereiken waar het verbinding mee maakt. In dit artikel leg ik uit hoe de oude infrastructuur het aanvalspad wordt naar AI-agentomgevingen en wat beveiligingsteams kunnen doen om die paden te blokkeren.
AI-agenten gebruiken wat ze erven
Ondanks hun nieuwigheid en kracht functioneren AI-agenten in sommige opzichten net als andere middelen in uw omgeving. Ze authenticeren via bestaande identiteitsproviders, slaan gegevens op in bestaande cloudbuckets, voeren taken uit via bestaande Lambda-functies en nemen machtigingen over van bestaande IAM-rollen. Elk van deze afhankelijkheden draagt de veiligheidsschuld met zich mee die de organisatie had voordat de AI-implementatie begon.
Bovendien doen de meeste organisaties dit onbedoeld samenstelling die schuld. Volgens Infosecurity Magazine verleent 70% van de organisaties hun AI-systemen meer bevoorrechte toegang dan een mens in dezelfde rol. Het is niet verrassend dat hieraan een pijnlijk prijskaartje hangt. Organisaties met overbevoorrechte AI rapporteerden een incidentpercentage van 76%, vergeleken met slechts 17% voor degenen die de minste bevoegdheden afdwingen.
Al deze verbindingen – identiteitsproviders, cloudbuckets, Lambda-functies, IAM-rollen – lopen via de infrastructuur die uw teams al jaren beheren: Active Directory, cloud-IAM, serviceaccounts, opgeslagen inloggegevens. Toch was niets ervan ontworpen met AI-agents in gedachten, en het grootste deel ervan werd al lang voordat de eerste agent in productie ging, ingericht. Het resultaat is dat een aanvaller die via een van deze lagen zijn weg vindt, de AI niet hoeft aan te raken. De eigen machtigingen van de agent doen het werk voor hen.
Hoe een CVE uit 2025 een AI-agent kaapt in 2026
Het onderstaande diagram toont een typische AI-agentarchitectuur voor ondernemingen. Een klantensuccesteam gebruikt een door AI aangedreven co-piloot – gehost op AWS Bedrock – om klantgegevens op te vragen die vanuit Salesforce naar een S3-bucket zijn geëxporteerd. De Co-Pilot voert taken uit via Lambda-functies en kan worden geïntegreerd met bedrijfsapplicaties. John, een ontwikkelaar, bouwt en onderhoudt de agent. Gebruikers in de hele organisatie hebben er dagelijks mee te maken.
Dit is wat er gebeurt als een aanvaller binnenkomt. Het volgende diagram toont een aanvalspad dat mijn team heeft gemodelleerd in een echte bedrijfsomgeving. Geen van deze blootstellingen is exotisch; ze bestaan momenteel, in een of andere combinatie, in de meeste bedrijfsnetwerken. Wat ze gevaarlijk maakt, is de manier waarop ze verbinding maken. Hier ziet u hoe de aanval zich stap voor stap ontwikkelde.
- Fase 1: Een S3-bucket wordt een cruciaal bezit. Om de CSM-co-piloot te voeden, exporteerde het team Salesforce-gegevens naar een S3-bucket. Die export maakte van de bucket een waardevol doelwit met gevoelige klantgegevens. Meerdere gebruikers binnen het AWS-account kregen te brede leestoegang tot productie-S3-buckets – waaronder John, de co-piloot-ontwikkelaar, die nooit toegang nodig had tot productiegegevens. Op zichzelf is dit een eenvoudige verkeerde configuratie van de machtigingen.
- Fase 2: Een ongepatchte server aan de rand. Op een extern gerichte server wordt Apache Tomcat uitgevoerd. Die server is blootgesteld aan CVE-2025-24813 – een fout bij het uitvoeren van externe code die in maart 2025 werd onthuld en diezelfde maand werd toegevoegd aan CISA’s Known Exploited Vulnerabilities-catalogus. Het is nooit gepatcht. Omdat de server zich in de bedrijfsomgeving bevindt en is gekoppeld aan Active Directory, kan een aanvaller die misbruik maakt van het beveiligingslek in de cache opgeslagen inloggegevens uit het servergeheugen dumpen en een AD-gebruikersaccount in gevaar brengen. Op zichzelf is dit een bekende kwetsbaarheid op één server: ernstig, maar niet kritisch.
- Fase 3: Verkeerde configuratie van Active Directory maakt laterale verplaatsing mogelijk. Dat gecompromitteerde AD-account kan misbruik maken van een verkeerde configuratie van een op bronnen gebaseerde beperkte delegatie om zich voor te doen als John en toegang te krijgen tot zijn werkstation. John gebruikt AWS CLI om de cloudbronnen van de co-piloot te beheren, en achter de schermen slaat CLI AWS-toegangssleutels op zijn machine op. De aanvaller verzamelt deze sleutels. Op zichzelf is dit een probleem met AD-machtigingen – een van de duizenden die in de meeste omgevingen voorkomt.
- Verbind nu de drie fasen. De aanvaller maakt misbruik van CVE-2025-24813 aan de rand, dumpt inloggegevens, beweegt zich lateraal door AD naar het werkstation van John, verzamelt zijn AWS-toegangssleutels en leest elk record in de productie-S3-bucket – dezelfde bucket die de kennisbank van de co-piloot voedt. De Co-Pilot-agent is nu gecompromitteerd. De aanvaller bepaalt wat hij leest, wat hij vertrouwt en wat hij teruggeeft aan gebruikers. Geen enkel deel van de AI-stack werd rechtstreeks aangevallen. Drie bescheiden bevindingen – een cloudsleutel met te veel privileges, een niet-gepatchte webserver, een verkeerde AD-configuratie – werden een kritiek aanvalspad.
Wat eraan te doen
Het aanvalspad dat ik zojuist heb beschreven, doorkruist vier lagen: netwerk, identiteit, cloud en AI. De meeste beveiligingsprogramma’s beoordelen elk van deze lagen afzonderlijk, en de risico’s in elk daarvan zijn mogelijk al bekend. Een EASM-tool markeert de Tomcat-server. Een AD-beveiligingstool vangt de verkeerde configuratie van de delegatie op. Een CSPM-tool pikt de overbevoorrechte S3-toegang op. Ieder rapporteert een matige bevinding die mogelijk niet kan worden verholpen vanwege een lagere prioriteit, maar in combinatie een kritiek probleem kan worden: een Tomcat-kwetsbaarheid aan de rand loopt via AD naar de cloudreferenties van een ontwikkelaar en eindigt bij de kennisbank van een AI-agent.
Het sluiten van deze paden begint met een benadering van blootstellingsbeheer die de afhankelijkheden van AI-agenten (kennisbanken, opslagbuckets, Lambda-functies, enz.) zelf als kritische activa behandelt. Van daaruit moet je achteruit in kaart brengen: welke identiteitsrelaties, machtigingen en infrastructuur zijn verbonden met die assets, en welke van die verbindingen dragen exploiteerbare risico’s met zich mee in de context van jouw omgeving? Wanneer je het volledige pad in kaart brengt, ontstaan er knelpunten: plaatsen waar één enkele oplossing meerdere routes naar je AI-middelen blokkeert.
Als uw platform voor blootstellingsbeheer dat volledige pad kan traceren (van de oudere server via de AD- en cloudinfrastructuur tot de kennisbank van een AI-agent) kunt u de blootstelling herstellen voordat een aanvaller deze ketent. Als dit niet lukt, zal geen enkele hoeveelheid vangrails op de AI-laag deze sluiten.
De onderste regel
De adoptie van AI-agenten versnelt op elke bedrijfsafdeling. En elke nieuwe agent die u implementeert, maakt verbinding met de infrastructuur die al beschikbaar is. Dat betekent dat het aanvalsoppervlak bij elke inzet toeneemt.
De vraag voor beveiligingsleiders is niet of uw AI-laag beschermd is. Het gaat erom of de omgeving waarin deze agenten opereren (inclusief uw traditionele infrastructuur) aanvallers de weg biedt om ze te kapen.
Omdat aanvallers geen nieuwe technieken nodig hebben om AI-agenten in gevaar te brengen. Ze hebben alleen de oude nodig – en een omgeving waarin ze het oude kunnen gebruiken om het nieuwe te exploiteren.
Opmerking: Dit artikel is zorgvuldig geschreven en bijgedragen voor ons publiek door Zur Ulianitzky, SVP Product- en Beveiligingsonderzoek, XM Cyber.
