Thought leaders
De verborgen dreiging van AI-agents vereist een nieuw beveiligingsmodel

Agente AI-systemen zijn het afgelopen jaar mainstream geworden. Ze worden nu gebruikt voor verschillende functies, waaronder het valideren van gebruikers, het overboeken van kapitaal, het activeren van compliance-workflows en het coördineren in enterprise-omgevingen met minimale menselijke toezicht.
Echter, een stillere probleem ontstaat met de toenemende autonomie, niet op het niveau van prompts of beleid, maar op het niveau van infrastructuurvertrouwen. Agente systemen krijgen insider autoriteit, terwijl ze nog steeds draaien op compute-omgevingen die nooit zijn ontworpen om autonome beslissers te beschermen tegen de infrastructuur eronder.
Traditionele beveiliging gaat ervan uit dat software passief is, maar agente systemen zijn dat niet. Ze redeneren, onthouden en handelen continu, autonoom en met gedelegeerde autoriteit.
Om nog maar te zwijgen dat AI-agents waarschijnlijk toegang hebben tot persoonlijke gegevens, op basis van hun gebruik, zoals e-mails en telefoongespreksgegevens, en andere dingen.
Bovendien bestaan er, hoewel hardware-gebaseerde beschermingen, zoals vertrouwelijke virtuele machines en beveiligde enclaves, nog steeds niet de standaardbasis voor de meeste agente AI-implementaties. Als gevolg daarvan draaien veel agents nog steeds in omgevingen waarin gevoelige gegevens tijdens runtime zijn blootgesteld aan de onderliggende infrastructuur.
Agents zijn insiders, geen tools
Beveiligingsteams weten al hoe moeilijk het is om insider-bedreigingen te beteugelen, een probleem dat wordt benadrukt in Verizon’s rapport, dat aantoont dat systeeminbraak verantwoordelijk was voor meer dan 53% van de bevestigde inbraken vorig jaar. In 22% van deze gevallen gebruikten aanvallers gestolen referenties om toegang te krijgen, wat aantoont hoe vaak ze slagen door legitieme identiteiten te gebruiken in plaats van technische fouten te exploiteren.
Overweeg nu een agent, die bestaat uit promptlogica, tools en plugins, referenties, evenals beleid. Het kan niet alleen code uitvoeren en op internet surfen, maar ook CRM’s opvragen, e-mails lezen en tickets pushen, om nog maar een paar dingen te noemen. Wat de combinatie van functies heeft gebracht, is traditionele aanvalsoppervlakken in een moderne interface.
Het gevaar dat door dergelijke insider-bedreigingen wordt gevormd, is niet speculatief. Het Open Web Application Security Project (OWASP) lijst “Prompt Injection” op als een kritieke kwetsbaarheid voor LLM-toepassingen, waarbij de speciale gevaar voor agente systemen die acties ketenen, wordt opgemerkt. Microsoft’s Threat Intelligence-team heeft ook adviezen gepubliceerd waarin wordt gewaarschuwd dat AI-systemen met tooltoegang kunnen worden omgeleid om gegevensdiefstal uit te voeren als beveiligingsmaatregelen niet architectonisch worden afgedwongen.
Deze rapporten geven een tijdige herinnering dat agents die legitieme toegang tot systemen en gegevens hebben, tegen hun eigenaren kunnen worden gebruikt. Echter, het risicolandschap voor agente systemen is niet eenduidig. Toepassingslaagdreigingen zoals prompt-injectie en toolmisbruik ontstaan uit de onmogelijkheid van het model om vertrouwde instructies te onderscheiden van onvertrouwde gebruikersinvoer, een ontwerplimiet die door geen enkele vorm van geheugenharden kan worden opgelost.
Een ander en even belangrijk probleem bestaat op het niveau van de infrastructuur: sommige agents draaien in platte tekstgeheugen, wat betekent dat gevoelige informatie – zoals chatgeschiedenis, API-antwoorden en documenten – zichtbaar kan zijn tijdens verwerking en mogelijk later nog steeds toegankelijk is. OWASP identificeert dit risico als Sensitive Information Disclosure (LLM02) en System Prompt Leakage (LLM07) en suggereert het gebruik van contextisolatie, naamruimte-segmentatie en geheugenzandbakken als belangrijke veiligheidsmaatregelen.
Derhalve moeten gebruikers deze agents niet behandelen als gewone toepassingen, aangezien ze dynamische, redenerende uitvoerders zijn die een beveiligingsmodel vereisen dat rekening houdt met hun unieke aard als niet-menselijke entiteiten met agentie. Deze aanpak moet zowel softwarecontroles omvatten om te beperken hoe het model handelt, als hardwarebeveiligingen om gegevens veilig te houden tijdens gebruik.
De architectuur van vertrouwen heeft een kritieke fout
Huidige beveiligingspraktijken richten zich op het beschermen van gegevens in rust en in transit. De laatste frontier, gegevens in gebruik, blijft vrijwel geheel blootgesteld. Wanneer een AI-agent redeneert over een vertrouwelijke dataset om een lening goed te keuren, patiëntrecords te analyseren of een transactie uit te voeren, worden die gegevens meestal ontsleuteld en in platte tekst verwerkt in het geheugen van de server.
In standaard cloudmodellen kan iedereen met voldoende controle over de infrastructuur, inclusief hypervisorbeheerders of co-tenant aanvallers, potentieel meekijken naar wat er gebeurt tijdens de uitvoering van een workload. Voor AI-agents is die blootstelling besonders gevaarlijk, aangezien ze toegang nodig hebben tot gevoelige informatie om hun werk te doen, wat potentieel het aanvalsoppervlak kan worden.
Zoals Lumia Security heeft aangetoond, kunnen aanvallers met toegang tot een lokale machine JWT’s en sessiesleutels rechtstreeks uit het procesgeheugen van ChatGPT, Claude en Copilot-desktoptoepassingen verkrijgen. Deze gestolen referenties kunnen hen toelaten om zich voor te doen als een andere gebruiker, conversatiegeschiedenis te stelen en prompts in te voegen in lopende sessies die agentgedrag kunnen veranderen of valse herinneringen kunnen planten.
Een voorbeeld hiervan is de incident met de geheugendump van AWS CodeBuild in juli 2025. De aanvallers voegden in het geheim kwaadaardige code toe aan een project, en toen het systeem deze uitvoerde, keek de code in de computergeheugen en stal verborgen aanmeldtokens die daar waren opgeslagen. Met die tokens konden de aanvallers de projectcode veranderen en mogelijk toegang krijgen tot andere systemen.
Voor financiële instellingen is de stille manipulatie existentieel. Banken, verzekeraars en beleggingsfirma’s absorberen al gemiddelde inbreuk kosten van meer dan $10 miljoen, en ze begrijpen dat integriteit even belangrijk is als vertrouwelijkheid. Volgens een recent rapport van Informatica, werd de “trustparadox” als volgt uitgelegd: organisaties implementeren autonome agents sneller dan ze hun uitvoer kunnen verifiëren. Het resultaat is automatisering die fouten of vooroordelen kan hardwieren, rechtstreeks in coreprocessen, op machinesnelheid.
Vertrouwelijke computing en het geval voor isolatie
Incrementele reparaties lossen het probleem niet op, hoewel striktere toegangscontroles en betere monitoring kunnen helpen. Noch kan dit het onderliggende probleem veranderen. Het probleem is architectonisch, en zolang de berekening plaatsvindt in blootgesteld geheugen, zullen agents kwetsbaar zijn op het moment dat het er het meest toe doet, namelijk tijdens het redeneren.
Vertrouwelijke computing, gedefinieerd door de Confidential Computing Consortium (CCC) als de bescherming van gegevens in gebruik via hardware-gebaseerde Trusted Execution Environments (TEEs), adresseert het kernprobleem rechtstreeks.
Voor AI-agents is deze hardware-niveau-isolatie transformatief, aangezien het een agent zijn identiteitsreferenties, zijn modelgewichten, propriëtaire prompts en de gevoelige gebruikersgegevens die het verwerkt, in staat stelt om versleuteld te blijven, niet alleen op schijf of via een netwerk, maar actief in geheugen tijdens uitvoering. De scheiding breekt definitief het traditionele model waarbij controle over de infrastructuur garantie biedt voor controle over de workload.
Remote attestation biedt verifieerbare cryptografische bewijs dat een specifieke inferentieaanvraag is uitgevoerd binnen een hardware-gebackte vertrouwde uitvoeromgeving, of het nu een CPU of GPU is. Het bewijs wordt gegenereerd uit hardwaremetingen en geleverd samen met het antwoord, waardoor onafhankelijke verificatie mogelijk is van waar en hoe de workload is uitgevoerd.
Attestatie records onthullen de code die is uitgevoerd niet. In plaats daarvan wordt elke workload geassocieerd met een unieke workload-ID of transactie-ID, en de TEE-attestatierecord is gekoppeld aan die identifier. De attestatie bevestigt dat de berekening is uitgevoerd binnen een vertrouwde omgeving zonder de inhoud ervan te onthullen.
De setup creëert een nieuwe basis voor compliance en auditeerbaarheid, waardoor het mogelijk wordt om een agent zijn acties te koppelen aan een specifieke versie van code die is geattesteerd en een bekende set invoergegevens.
Naar aansprakelijke autonomie
De implicaties voor het systeem dat hierboven wordt beschreven, gaan verder dan basisbeveiliging. Overweeg de wetten die financiën, gezondheidszorg en persoonlijke informatie reguleren. Veel rechtsgebieden passen regels voor gegevenssoevereiniteit toe die beperken waar informatie mag worden verwerkt. In China vereisen de Wet op de bescherming van persoonsgegevens en de Wet op gegevensbeveiliging dat bepaalde categorieën gegevens, zoals belangrijke persoonsgegevens, moeten worden opgeslagen binnen het land en worden beoordeeld voordat ze naar het buitenland worden overgedragen.
Soortgelijk hebben verschillende Golfstaten, zoals de VAE en Saoedi-Arabië, soortgelijke benaderingen geadopteerd, vooral voor financiële, overheids- en kritieke infrastructuurgegevens.
Vertrouwelijke computing kan beveiliging en auditeerbaarheid versterken door gegevens te beschermen tijdens verwerking en attesteren van de runtime-omgeving. Echter, het verandert niet waar de verwerking plaatsvindt. Waar regels voor gegevenssoevereiniteit lokale verwerking vereisen of voorwaarden opleggen voor grensoverschrijdende overdrachten, kunnen vertrouwde uitvoeromgevingen ondersteunen bij compliancecontroles, maar vervangen ze geen wettelijke vereisten.
Bovendien maakt vertrouwelijke computing het mogelijk om veilig te collaboreren in multi-agent systemen, waarin agents van verschillende organisaties of binnen verschillende afdelingen vaak informatie moeten delen of uitvoer moeten valideren zonder propriëtaire gegevens bloot te geven.
En wanneer deze technologie wordt gecombineerd met zero-trust-architectuur, is het resultaat een veel sterker fundament. Zero trust valideert continu identiteit en toegang, terwijl vertrouwelijke computing het geheugen van de hardware beschermt tegen ongeautoriseerde extractie en voorkomt dat gevoelige informatie in platte tekst wordt hersteld.
Samen verdedigen ze wat er echt toe doet, zoals beslissingslogica, gevoelige invoer en de cryptografische sleutels die actie autoriseren.
Nieuwe baseline voor autonome systemen
Als elke interactie mensen in gevaar brengt van blootstelling, zullen ze AI niet toelaten om dingen zoals gezondheidsrecords te behandelen of financiële beslissingen te nemen. Evenmin zullen bedrijven hun meest belangrijke taken automatiseren als dit zou kunnen leiden tot regelgevingsproblemen of verlies van belangrijke gegevens.
Serieuze bouwers erkennen dat toepassingslaagfixes alleen onvoldoende zijn in high-assurance-omgevingen.
Wanneer agents zijn gemachtigd met financiële autoriteit, gereguleerde gegevens of cross-organisatorische coördinatie, wordt infrastructuurniveau-blootstelling meer dan een theoretisch probleem. En zonder vertrouwelijke uitvoering in dergelijke contexten, blijven veel agents een zacht doelwit, met hun sleutels te stelen en hun logica te manipuleren. De omvang van moderne inbraken toont precies waar die weg naar leidt.
Privacy en integriteit zijn geen optionele functies die na implementatie kunnen worden toegevoegd. Ze moeten vanaf het silicium worden geëngineerd. Daarom moet voor agente AI om veilig te schalen, hardware-geforceerde vertrouwelijkheid niet worden beschouwd als een concurrentievoordeel, maar als de baseline.












