Microsoft noemt 7 manieren waarop je AI-agenten gehackt kunnen worden. Eén daarvan gebeurt nu al in de praktijk.

Op Microsoft Build 2026 heeft het security research-team zijn bestaande AI-agent dreigingstaxonomie uitgebreid met zeven nieuwe categorieën die weerspiegelen wat aanvallers doen — en wat verdedigers missen — in ingezette agentische systemen. De naamgeving doet ertoe: “AI-agents zijn risicovol” is een houding; zeven specifieke, afzonderlijke aanvalsvectoren met bijbehorende mitigaties vormen een operationeel raamwerk.

Agentic Supply Chain Compromise. In tegenstelling tot traditionele supply chain-aanvallen die afhankelijk zijn van kwaadaardige code, werkt deze vector via natuurlijke taal. Het gedrag van een agent kan worden beïnvloed door vijandige inhoud in prompts, opgehaalde documenten of instructies van upstream agents — zonder enige code-injectie.

Goal Hijacking. Een aanvaller voegt instructies toe die lijken te passen bij de legitieme taak van de agent, terwijl het uiteindelijke doel ongemerkt wordt omgeleid. Vooral gevaarlijk in meerstaps agentische workflows waarbij de agent zelfstandig oordeelt.

Inter-Agent Trust Escalation. In multi-agent architecturen kan een gecompromitteerde agent een valse identiteit of verhoogde rechten claimen bij een orkestrerende agent. De orkestrator, zonder cryptografische verificatie, accepteert de claim en verleent toegang die niet zou mogen.

Computer Use Agent Visual Attack. Agents die via grafische interfaces werken, kunnen worden gemanipuleerd door vijandige inhoud die op het scherm wordt weergegeven — verborgen instructies in documenten, webpagina’s of UI-elementen die het gedrag van de agent via het visuele kanaal omleiden.

Session Context Contamination. Een aanvaller introduceert data die het redeneren van de agent in volgende stappen beïnvloedt, zonder dat veiligheidsmaatregelen bij een individuele beslissing worden geactiveerd. De besmetting stapelt zich op gedurende een sessie, waardoor een gecompromitteerde uitkomst ontstaat uit op zichzelf onschuldige input.

MCP/Plugin Abuse. De categorie waaronder het Asana-incident valt. Het Model Context Protocol creëert een gestructureerd kanaal waarlangs agents met externe tools en databronnen communiceren. Kwetsbaarheden in dat kanaal — logische fouten, verkeerd ingestelde rechten of kwaadaardige tools — kunnen data blootstellen die de agent niet mag bereiken, exfiltratie mogelijk maken of toegang verschaffen over organisatorische grenzen heen.

Capability/Architecture Disclosure. Een agent die interne implementatiedetails onthult — systeem prompt-inhoud, toolmogelijkheden, beschikbare integraties — biedt de verkenning die nodig is om gerichtere aanvallen te ontwerpen.

5 Belangrijkste Inzichten

1. MCP/Plugin Abuse is nu al een productierisico, geen theoretisch probleem.

De MCP-serverdatalek bij Asana in 2025 stelde ongeveer 1.000 organisaties bloot toen een logische fout tenantgrenzen overschreed — taakdata, projectmetadata, opmerkingen en geüploade bestanden waren zichtbaar tussen organisaties. Microsoft heeft deze categorie nu formeel benoemd in zijn bijgewerkte AI-agent dreigingstaxonomie. De Kiteworks Secure MCP Server pakt dit aan door beleid af te dwingen op het protocollaire niveau voordat data de agent bereikt — de governance-laag waarvan het Asana-incident aantoonde dat die noodzakelijk is.

2. Microsofts Build 2026-reactie biedt handhavingsinfrastructuur, niet alleen beleidsadvies.

De Execution Container, Agent Control Specifications en ASSERT-toolset creëren een runtime governance-laag die securityteams kunnen inzetten tegen specifieke dreigingsscenario’s. De Execution Container dwingt expliciete grenzen af tijdens runtime, in plaats van te vertrouwen op zelfbeperking door agents. Agent Control Specifications zijn draagbare, controleerbare beleidsdefinities die onafhankelijk van de agent kunnen worden geversioneerd. ASSERT operationaliseert alle zeven faalmodi via adversariële testopstellingen. Dit is nu een engineeringdiscipline — met benoemde vectoren en gepubliceerde tegenmaatregelen.

3. De zeven faalmodi bieden red teams een concrete checklist.

Agentic Supply Chain Compromise, Goal Hijacking, Inter-Agent Trust Escalation, Computer Use Agent Visual Attack, Session Context Contamination, MCP/Plugin Abuse en Capability/Architecture Disclosure zijn nu gedocumenteerde aanvalsvlakken die specifieke testdekking vereisen. Microsoft raadt aan om agent supply chains te inventariseren, agentidentiteit cryptografisch te verifiëren in plaats van op basis van bewering, en alle zeven vectoren toe te voegen aan red-team dekkingsmatrices.

4. Traditionele IAM- en DLP-controles dekken agentisch gedrag niet.

AI-agents werken asynchroon, schakelen tools aan elkaar en handelen namens gebruikers op manieren die bestaande perimeter- en identiteitscontroles niet kunnen beheersen. DLP-tools inspecteren bekende kanalen; agents roepen externe API’s aan en verwerken inhoud uit bronnen buiten die kanalen. Een speciale AI content governance-laag — die afdwingt welke gevoelige inhoud agents mogen ophalen, verwerken en verzenden — is vereist.

5. Gereguleerde sectoren lopen extra risico.

AI-agents die CUI, PHI of ITAR-gecontroleerde data benaderen via verkeerd ingestelde MCP-integraties veroorzaken zowel een beveiligingsincident als een compliance-overtreding. CMMC, HIPAA en GDPR pauzeren niet omdat de actor een AI-agent was — toegang moet worden geautoriseerd, gelogd en beveiligd onder dezelfde kaders die menselijke toegang tot gereguleerde inhoud regelen.

MCP/Plugin Abuse: Van Taxonomie naar Productiedatalek

Asana lanceerde MCP-serverintegratie met LLM-mogelijkheden op 1 mei 2025. Een logische fout in de implementatie stelde gebruikers van de ene organisatie in staat data van een andere Asana-omgeving te zien — taakniveau-informatie, projectmetadata, teamdetails, opmerkingen, discussies en geüploade bestanden. De blootstelling werd begrensd door de toegangsrechten van elke gebruiker, maar het ging om cross-tenant datatoegang vanuit een AI-integratie die organisaties volledig vertrouwden.

Asana ontdekte de fout in juni 2025, ongeveer een maand nadat de MCP-functie live ging. Ongeveer 1.000 klanten werden getroffen. De les is niet dat MCP inherent onveilig is — het protocol is een communicatielaag. De les is dat het protocol een governance-laag erbovenop vereist: expliciet beleid dat bepaalt wat elke agent mag benaderen, onder welke voorwaarden en met welke reikwijdte. Zonder die laag erft de MCP-integratie de rechten van de onderliggende dienst — wat in multi-tenant SaaS-omgevingen precies het soort cross-organisatorische blootstelling oplevert dat Asana meemaakte.

Microsoft heeft deze faalcategorie nu formeel benoemd en naast zes andere vectoren geplaatst in een taxonomie die securityteams moeten gebruiken om hun AI red-team programma’s te structureren. De AI data governance-fouten in MCP-inzet zijn geen exotische randgevallen. Ze zijn het voorspelbare gevolg van krachtige integraties zonder voldoende beleidsafdwinging tussen tenants.

Microsofts Runtime Reactie: Execution Container, ASSERT en Agent Control Specifications

Drie Build 2026-componenten vormen samen het meest complete, enterprise-grade AI-agent beveiligingsraamwerk dat een grote leverancier heeft gepubliceerd.

De Microsoft Execution Container dwingt expliciete grenzen af tijdens runtime, in plaats van te vertrouwen op zelfbeperking door agents. Agentoutput, plugincalls en toolaanroepen worden behandeld als niet-vertrouwde uitvoeringspaden die beleidsbeoordeling vereisen voordat ze doorgaan — het beveiligingsmodel verschuift van “configureer de agent correct en hoop” naar “dwing grenzen af op het uitvoeringsniveau, ongeacht het gedrag van de agent.”

Agent Control Specifications zijn draagbare beleidsdefinities die beschrijven wat een agent mag doen, welke tools hij mag aanroepen en welke externe endpoints hij mag bereiken. Specificaties staan los van de agentimplementatie — controleerbaar, versieerbaar en aanpasbaar zonder de agent zelf te wijzigen. Dit behandelt agent governance als een configuratiebeheerprobleem in plaats van een embedded-codeprobleem.

ASSERT (Adversarial Stress and Security Evaluation for Resilient Thinking) operationaliseert de zeven faalmodi via adversariële testopstellingen waarmee securityteams ingezette agents kunnen testen op specifieke kwetsbaarheden voordat aanvallers die vinden.

Waarom Traditionele Beveiligingsmaatregelen Tekortschieten

Een gebruiker die inlogt op een SaaS-platform voert inloggegevens in, doorloopt multi-factor authentication en werkt binnen een gedefinieerde sessie. Audit logs registreren welke bestanden werden benaderd. Een AI-agent doet geen van deze dingen op een overzichtelijke manier. Hij werkt asynchroon, voert honderden toolaanroepen uit zonder menselijke tussenkomst bij elke stap. Hij koppelt verzoeken aan elkaar, haalt data op bij de ene bron om een query bij een andere te informeren. Hij handelt namens een gebruiker wiens sessie mogelijk uren eerder is beëindigd.

Zero-trust architectuur biedt het juiste conceptuele kader — nooit vertrouwen, altijd verifiëren — maar de verificatiemechanismen die voor menselijke actoren zijn gebouwd, sluiten niet goed aan op asynchrone agents die continue autorisatie nodig hebben over meerstaps toolchains. Microsofts Execution Container en Agent Control Specifications richten zich op de uitvoeringslaag. De datalaag — die bepaalt welke gevoelige inhoud de agent mag ophalen, verwerken en verzenden — vereist een speciaal content governance-raamwerk dat verder gaat dan alleen runtime-containment.

De Compliance-inzet in Gereguleerde Sectoren

De zeven faalmodi die Microsoft benoemt, zijn niet alleen beveiligingsdreigingen — het zijn potentiële compliance-overtredingen onder kaders die bepalen hoe specifieke categorieën gevoelige inhoud moeten worden behandeld.

Voor defensie-aannemers onder CMMC 2.0 geldt: een AI-agent die CUI uit een projectmanagementsysteem haalt en via een MCP-integratie naar een externe tool stuurt zonder juiste controles, veroorzaakt een CMMC compliance-incident. Hetzelfde geldt voor HIPAA: PHI die via de context van een AI-agent stroomt, valt onder toegangscontrole– en auditvereisten, ongeacht of de actor mens of AI is. GDPR voegt dataminimalisatie toe: een agent die meer data ophaalt dan nodig voor de taak, kan de minimisatievereiste van de GDPR schenden puur door zijn werkwijze.

Ondernemingen in gereguleerde sectoren kunnen AI-agent governance niet als een apart programma behandelen naast bestaande complianceverplichtingen. Ze moeten dezelfde dataclassificatie, toegangscontroles, audit logging en transmissiebeveiliging die menselijke toegang tot gereguleerde inhoud regelen, uitbreiden naar AI-agent toegang.

Een Zero-Trust Content Governance-laag Bouwen voor AI-Agents

De Kiteworks Secure MCP Server omhult AI-agent toegang tot door Kiteworks beheerde inhoud met een beleidsafdwingingspunt. In plaats van agents direct toegang te geven tot alle beschikbare inhoud, beoordeelt de Secure MCP Server elk verzoek aan de hand van expliciet toegangsbeleid voordat data naar de agent stroomt — afdwinging op protocolniveau, niet op agentimplementatieniveau.

De Kiteworks AI Data Gateway breidt dit uit naar enterprise AI-workflows in het algemeen en biedt een gecontroleerd kanaal voor AI-queries op gevoelige contentrepositories met classificatiebewuste toegangsregels. CUI, PHI en andere gereguleerde inhoud is alleen toegankelijk voor AI-agents die expliciet geautoriseerd zijn om deze te verwerken. Elke interactie wordt vastgelegd in een fraudebestendige audit log die direct naar SIEM stroomt — de documentatie waar CMMC-beoordelaars, HIPAA-auditors en GDPR-toezichthouders naar zoeken bij het onderzoeken van AI-toegang tot gevoelige inhoud.

Het Kiteworks Private Data Network breidt deze governance uit over e-mail, bestandsoverdracht, MFT, SFTP, webformulieren en API’s onder één beleidsengine en één geconsolideerde audit log. Microsoft heeft de dreigingen benoemd en de tools voor handhaving op uitvoeringsniveau geleverd. De resterende vraag voor elke onderneming is of de content governance-laag volwassen genoeg is om het risico aan te kunnen.

Wil je meer weten over het beschermen van je gevoelige inhoud tegen gecompromitteerde AI-agents? Plan vandaag nog een persoonlijke demo.

Aanvullende Bronnen

• Blog Post
  Zero‑Trust strategieën voor betaalbare AI-privacybescherming
• Blog Post
  Hoe 77% van de organisaties faalt in AI-databeveiliging
• eBook
  AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met databeveiliging in 2025
• Blog Post
  Er bestaat geen “–dangerously-skip-permissions” voor jouw data
• Blog Post
  Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.