AI-agenten zijn het nieuwe aanvalsoppervlak
Beveiligingsonderzoekers hebben zojuist aangetoond dat jouw AI-coding-assistent kan worden omgezet in een exfiltratie-instrument – en je bestaande detectiecontroles zullen dit niet opmerken. Dit is geen theoretisch probleem. Het betreft een gedocumenteerde, reproduceerbare techniek, gepubliceerd door het 0Din-team van Mozilla in een gedetailleerd proof of concept op 29 juni 2026.
Die onthulling kwam in dezelfde week als een ernstige CVE in Amazon Q Developer, een formele analyse van de nieuwe enterprise MCP-specificatie, een gedocumenteerde social engineering-campagne gericht op cybersecurityteams via nep-AI-werkplekken, en een analyse die stelt dat traditionele identity governance structureel niet in staat is AI-agenten te beheersen. Vijf afzonderlijke onderzoekslijnen, gepubliceerd binnen vier dagen na elkaar, wijzen allemaal op hetzelfde structurele falen: AI-agenten die zonder een gecontroleerde contentlaag opereren, worden exfiltratiekanalen.
Het probleem is niet incrementeel. Organisaties hebben twintig jaar besteed aan het bouwen van beveiligingscontroles rond een relatief stabiel model van wat een identiteit is en hoe die zich gedraagt. Een agent past niet in dat model. Die authenticeert één keer, erft machtigingen van de menselijke identiteit waarvoor hij werkt, en beweegt zich vervolgens door meerdere bedrijfssystemen in één sessie – waarbij hij bronnen aanraakt die geen enkele mens ooit expliciet heeft geautoriseerd, en gefragmenteerde logs achterlaat die geen enkel bestaand beveiligingshulpmiddel samenvoegt tot een samenhangend geheel. Het onderzoek van deze week maakt dat structurele probleem concreet, en in één geval tijdsgebonden: de publicatiedatum van 28 juli voor MCP 2026-07-28 creëert een duidelijk venster voor organisaties om een governance-leemte aan te pakken voordat het aanvalsvlak van het nieuwe protocol volledig van kracht wordt.
Kiteworks secure data exchange is ontworpen voor precies dit probleem. Wanneer AI-agenten bedrijfscontent benaderen via de gecontroleerde API-laag van Kiteworks, wordt elke interactie aan beleid onderworpen, wordt elke data-toegang gelogd, en kan geen enkele agent – legitiem of gecompromitteerd – content bereiken buiten het expliciet geautoriseerde bereik. Wat het onderzoek van deze week gezamenlijk beschrijft, is een omgeving waarin die governance-laag ontbreekt. Bij elk gedocumenteerd aanvalspad is de uitkomst hetzelfde: gevoelige bedrijfsdata stroomt naar onbevoegden via een AI-systeem zonder afgedwongen toegangsgrens.
Belangrijkste Bevindingen
1. AI-coding-agenten kunnen worden ingezet als exfiltratie-instrument via indirecte prompt-injectie.
Het 0Din-team van Mozilla toonde aan dat Claude Code kan worden overgenomen via een vergiftigd DNS TXT-record gekoppeld aan een normaal ogende GitHub-repository, waardoor een reverse shell ontstaat die stilletjes API-sleutels, tokens en omgevingsgeheimen exfiltreert zonder dat een van de ingebouwde beveiligingslagen van de agent wordt geactiveerd.
2. Amazon Q Developer bevatte een ernstig lek waardoor aanvallers cloud-credentials konden verkrijgen.
CVE-2026-12957 (CVSS 8.5), onthuld door Wiz, liet kwaadaardige MCP-configuratiebestanden die in een code-repository waren ingebed automatisch uitvoeren zodra een ontwikkelaar deze opende, waardoor servers onder controle van de aanvaller toegang kregen tot cloud-credentials, lokale bestanden en shell-executie zonder enige gebruikersmelding of zichtbare waarschuwing.
3. De nieuwe MCP 2026-07-28-specificatie verschuift alle beveiligingsverantwoordelijkheid naar ontwikkelaars.
De overstap van het protocol naar een stateless ontwerp delegeert cross-tenant toegangscontroles, beheer van geheimen en privilege-escalatiecontroles volledig aan individuele implementaties – zonder afdwinging op protocolniveau. De specificatie wordt op 28 juli gepubliceerd en start een uitfaseringsperiode van 12 maanden.
4. Aanvallers bouwen overtuigende nep-AI-werkplekken om bedrijfsdata te verzamelen.
Push Security documenteerde de “Poisoned Tenant”-campagne, waarbij dreigingsactoren frauduleuze OpenAI-organisaties creëren die cybersecuritymedewerkers persoonlijk benaderen, uitnodigingen sturen vanaf het legitieme notificatieadres van OpenAI die alle e-mailverificaties doorstaan.
5. Traditionele identity governance is niet ontworpen voor agenten die op machinesnelheid opereren.
Analyse van het opkomende “guardian agent”-model laat zien dat IAM-infrastructuur, gebouwd rond menselijke authenticatiegebeurtenissen, geen autonome agenten kan beheersen die overgeprivilegieerde credentials erven, meerdere bedrijfssystemen in één sessie doorkruisen en geen samenhangende audittrail achterlaten.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het verifiëren?
Lees nu
De Claude Code-aanval: Drie Indirectie-stappen, Eén Reverse Shell
De Mozilla 0Din-aanval werkt omdat de componenten verspreid zijn over drie systemen die nooit samen worden onderzocht. De repository bevat geen kwaadaardige instructies of code. Wanneer een ontwikkelaar deze kloont, volgt Claude Code legitieme installatie-instructies. De aanval wordt geactiveerd tijdens de eerste installatie, wanneer Claude Code wordt geïnstrueerd een Python-pakket te gebruiken dat een foutmelding geeft als het vóór initialisatie wordt aangeroepen.
De foutmelding luidt: “Run: python3 -m axiom init.” Claude Code leest de fout en voert het herstelcommando uit. Het uitvoeren van init roept een shellscript aan dat een configuratiewaarde uit een DNS TXT-record haalt en deze als commando uitvoert. Die waarde is base64-gecodeerd, dus er verschijnt nooit een reverse shell-handtekening in platte tekst op schijf of onderweg. De interactieve shell wordt op de machine van de ontwikkelaar gestart. De aanvaller krijgt toegang tot alle credentials, API-sleutels, tokens en omgevingsgeheimen die daar zijn geladen, en kan een backdoor inzetten voor blijvende toegang nadat de shell is gesloten.
Zoals de Mozilla-onderzoekers het verwoorden: “De reverse shell is drie indirectiestappen verwijderd van alles wat Claude Code daadwerkelijk heeft geëvalueerd: een foutmelding waarin het vertrouwde, een script dat een waarde ophaalde, en een DNS-record dat het nooit zag.” Statische analyse ziet een DNS-lookup. Netwerkmonitoring ziet naamresolutie. De agent ziet een vooraf geautoriseerde installatiestap. Geen van de drie lijkt op zichzelf kwaadaardig. De aanvaller kan de payload op elk moment bijwerken door het DNS TXT-record te wijzigen – geen repository-wijzigingen nodig – en elke ontwikkelaar die de repository met Claude Code opent, loopt risico.
Dit omzeilt alle drie de ingebouwde beveiligingslagen van Claude Code. Dat is geen kritiek op Claude Code specifiek; het is een structureel kenmerk van elke AI-coding-agent die foutmeldingen als legitieme instructies behandelt. Het mechanisme voor payloadlevering – DNS TXT-records – valt volledig buiten het dreigingsmodel van de agent. Elke ontwikkelaar die een AI-coding-agent gebruikt om een onbekende repository op te zetten, werkt met een aanzienlijk vergroot aanvalsvlak dat geen enkele bestaande endpoint- of netwerkcontrole betrouwbaar dekt. Goede AI-databescherming vereist modellering van hoe agenten omgaan met omgevingsdata – niet alleen de content die ze expliciet moeten verwerken.
Amazon Q en het Auto-Executieprobleem
De Amazon Q Developer-kwetsbaarheid, onthuld door Wiz op 26 juni 2026 (CVE-2026-12957, CVSS 8.5), beschrijft hetzelfde structurele falen vanuit een andere invalshoek. De oorzaak: de extensie voerde automatisch MCP-configuratiebestanden uit die in een werkruimte waren ingebed, zonder de gebruiker om toestemming te vragen. Een ontwikkelaar opende een repository. De repository bevatte een kwaadaardig MCP-configuratiebestand. De extensie voerde het stilletjes uit, waardoor een MCP-server onder controle van de aanvaller toegang kreeg tot lokale bestanden, cloud-credentials en shell-executie – geen gebruikersmelding, geen waarschuwing, geen zichtbare aanwijzing dat er iets ongewoons was gebeurd.
AWS werd op 20 april op de hoogte gebracht, bracht op 12 mei een patch uit en publiceerde deze week een advies. Oplossingen zijn beschikbaar voor VS Code, JetBrains, Eclipse, Visual Studio en de Amazon Q-taalserver. Wiz merkt op dat het onderliggende auto-executiepatroon niet uniek is voor Amazon Q – vergelijkbare gedragingen zijn vastgesteld in andere AI-coding-tools, waaronder Claude en Cursor. De specifieke aanvalspaden die Wiz identificeert: nep-coderingstests (een techniek die wordt geassocieerd met Noord-Koreaanse dreigingsactoren die zich op ontwikkelaars richten), typosquatted open source-pakketten en kwaadaardige pull requests naar populaire open source-projecten.
De ontwikkelaar hoeft geen fout te maken. Hij hoeft alleen te doen wat hij normaal met elke repository zou doen. Wanneer een configuratiebestand automatisch wordt uitgevoerd omdat een agent het opent, vindt er geen beleidsevaluatie plaats op contentniveau – alleen executie. Het data policy engine-concept – content evalueren aan de hand van beleid voordat een agent ermee werkt – is precies wat deze aanval uitbuit door het ontbreken ervan. “De combinatie van auto-executie, shell-spawning en omgevingsovererving creëerde een ernstige kwetsbaarheid in een veelgebruikt ontwikkelaarshulpmiddel,” aldus Wiz. “Een enkele kwaadaardige repository kon niet alleen de lokale machine van de ontwikkelaar compromitteren, maar ook hun cloudinfrastructuur.”
Het MCP 2026-07-28-specificatiegat
Op 28 juli 2026 wordt MCP 2026-07-28 officieel gepubliceerd, waarmee een uitfaseringsperiode van 12 maanden voor de huidige versie begint. De belangrijkste wijziging is dat MCP nu stateless is op protocollair niveau. Die verschuiving maakt inzet op ondernemingsschaal en cloud-native mogelijk. Het betekent echter ook iets specifieks voor beveiligingsteams: de sessielaagbeveiliging die het huidige protocol biedt, verdwijnt in de nieuwe versie.
Akamai’s analyse van de release candidate identificeert diverse nieuwe aanvalsvlakken die door het stateless ontwerp worden geïntroduceerd. Workflow-kaping en cross-tenant toegang worden mogelijk als tracking-identificatoren voorspelbaar zijn. Nieuwe MCP-specifieke HTTP-headers (MCP-Method en MCP-Name) creëren datalekvectoren – als ontwikkelaars per ongeluk gevoelige inputs zoals API-sleutels, tokens of PII aan die headers koppelen, worden die geheimen zichtbaar voor elke load balancer, proxy en loggingsysteem langs het verzoekpad. MCP-apps als protocoluitbreiding introduceren opgeslagen XSS-risico’s. Langdurige asynchrone taken creëren een denial-of-service-vector waarbij taakcreatie goedkoop is voor een aanvaller, maar veel middelen kost voor de server.
Akamai’s conclusie is duidelijk: “De wijzigingen zijn niet simpelweg incrementele verbeteringen. Ze veranderen fundamenteel waar beveiligingsverantwoordelijkheden liggen.” Beslissingen die het huidige protocol afdwingt op sessielaagniveau, worden in de nieuwe versie volledig gedelegeerd aan individuele ontwikkelaars en platformbeheerders. Maxim Zavodchik, senior director threat research bij Akamai, vertelde SecurityWeek: “Omdat het protocol overgaat naar een stateless model en rijke UI-apps en asynchrone taken introduceert, zijn kritieke beveiligingsgrenzen nu volledig afhankelijk van hoe ontwikkelaars ze implementeren.”
Voor organisaties die AI-agenten inzetten op bedrijfscontent is dit het governance-gat dat nu het meest relevant is. Het nieuwe protocol zal geen gegevensbeheer, dataclassificatie of toegangscontroles afdwingen. Het zal niet loggen welke content een agent heeft opgehaald. Al deze beveiligingseigenschappen moeten op applicatieniveau worden geïmplementeerd, door de ontwikkelaar of platformbeheerder. De deadline van 28 juli is een kantelpunt met een duidelijke tijdlijn: organisaties hebben een afgebakend venster om een gecontroleerde contentlaag te implementeren voordat het aanvalsvlak van het nieuwe protocol live gaat. De Secure MCP Server van Kiteworks biedt die governance-laag op het AI-integratiepunt – de beleidsafdwinging die MCP 2026-07-28 bewust niet in het protocol zelf opneemt.
The Poisoned Tenant: Social Engineering voor het AI-tijdperk
De “Poisoned Tenant”-campagne, gedocumenteerd door Push Security, kiest een andere benadering met hetzelfde doel. In plaats van een AI-agent te compromitteren via een technische exploit, wordt een nep-AI-werkplek gecreëerd – een frauduleuze OpenAI-organisatie die zich voordoet als een legitiem bedrijf – en worden doelwitemedewerkers uitgenodigd om lid te worden. De uitnodigingsmails komen van noreply@tm.openai.com, het daadwerkelijke notificatieadres van OpenAI. Ze doorstaan alle e-mailverificaties. Technisch gezien zijn het echte uitnodigingen van OpenAI. Het enige frauduleuze element is de organisatie waarvoor de gebruiker wordt uitgenodigd.
Push Security ontdekte de campagne nadat meerdere medewerkers uitnodigingen ontvingen om lid te worden van een OpenAI-organisatie genaamd “Push Security Inc.” – aangemaakt door een aanvaller met Gmail-accounts, niet door Push Security. Na het accepteren van één uitnodiging om de aanval te bestuderen, werd Luke Jennings, VP Research and Development bij Push Security, toegevoegd aan de frauduleuze organisatie, die één door de aanvaller beheerd account bevatte dat zich voordeed als CEO van het bedrijf. Uitgenodigde medewerkers kregen Owner-rechten toegewezen. Er was een Visa-creditcard gekoppeld aan het factureringsaccount om legitimiteit toe te voegen. Het project bevatte geen bestaande chats – alleen infrastructuur om alle gevoelige content te verzamelen die medewerkers zouden indienen.
De analyse van Push Security over het doel van de campagne is scherp: “Een aanvaller die alleen scam-content wil verspreiden via een vertrouwd e-mailkanaal, noemt de organisatie niet naar het doelwit, onderzoekt geen individuele medewerkers en koppelt geen creditcard. Die investering loont alleen als medewerkers daadwerkelijk lid worden en het gaan gebruiken. En op een AI-platform kan de data die mensen in prompts stoppen buitengewoon gevoelig zijn – broncode, interne documenten, klantgegevens, beveiligingsonderzoek, strategische plannen.” Phishing omvat nu ook AI-platforms als verzamelinfrastructuur. Aanvallers zijn niet alleen uit op credentials. Ze bouwen omgevingen waarin doelwitten vrijwillig de meest gevoelige content indienen waarmee ze werken. De blootstelling van intellectueel eigendom is hier ernstig: broncode en strategische plannen die worden ingediend in een frauduleuze werkruimte betekenen direct verlies van intellectueel eigendom, zonder duidelijk pad naar herstel zodra de data buiten de controle van de organisatie is.
Security awareness training is noodzakelijk, maar niet voldoende. De governance-vraag is of enterprise AI-toegang verloopt via een gecontroleerde omgeving waarin zichtbaar is wat erin gaat en wat eruit komt voor het beveiligingsteam – en waar het platform zelf onder controle van de organisatie staat, niet wordt geleend van een externe aanbieder zonder toezicht.
Guardian Agents en het Identity Governance-gat
Een analyse van Hacker News, gepubliceerd op 26 juni, beschrijft het “guardian agent”-model – AI-systemen die worden ingezet om andere AI-agenten te auditen, te beheren en te beëindigen. Het argument is structureel: traditionele IAM is gebouwd rond authenticatiegebeurtenissen. Een mens toont credentials, toegang wordt verleend of geweigerd, en de sessie wordt geregistreerd. Agenten volgen die volgorde niet.
Een agent authenticeert één keer, meestal via een langlevende token of API-credential, en werkt vervolgens continu over sessies, systemen en contexten heen zonder tussenliggende governance-checkpoints. Wanneer een agent namens een sales director werkt, draagt hij diens OAuth-tokens, gedelegeerde machtigingen en alle overgeprivilegieerde toegang die in de loop der jaren is opgebouwd. De agent maakt geen onderscheid tussen wat de mens zou doen en wat hem is opgedragen. Hij voert uit met volledige geërfde autoriteit over elke applicatie die die identiteit kan bereiken – CRM-systemen, code-repositories, documentopslag, interne API’s – allemaal in één sessie, allemaal via credentials die oorspronkelijk bedoeld waren voor een menselijke gebruiker in een totaal andere context.
Dit creëert, in omgevingen zonder toegewijde agent-governance, wat de analyse “identity dark matter” noemt: identiteitsactiviteiten die bestaan en reëel risico vormen binnen een omgeving, maar onzichtbaar blijven voor de tools die ze zouden moeten beheren. Agenten doorlopen geen toegangsaanvraag-workflows. Ze worden niet opgenomen in identity governance-systemen. Ze erven credentials van bestaande identiteiten en beginnen te werken. Het resultaat is een groeiende populatie autonome identiteiten zonder formeel governance-record, zonder eigenaarschapstoewijzing en zonder gedragsbaseline. Zero trust-architectuur vereist continue verificatie van elke entiteit – maar verificatie vereist zichtbaarheid, en de meeste organisaties hebben geen zicht op wat hun AI-agenten doen nadat ze zijn geauthenticeerd. Op attributen gebaseerde toegangscontrole (ABAC) is het technische mechanisme dat continue verificatie operationeel maakt: toegangsbeslissingen evalueren agent-identiteit, gevoeligheid van content en uitvoeringscontext bij elk verzoek, in plaats van te vertrouwen op één authenticatiegebeurtenis voor een hele sessie.
Guardian agents lossen dit op door te opereren op de executielaag in plaats van aan de authenticatiegrens. Ze houden continu een identiteitsinventaris bij, gedragsbaselines en afdwinging van runtime least-privilege – de governance-laag die conventionele IAM-tools niet kunnen leveren. De analogie met gecontroleerde contentuitwisseling is direct: het beveiligingshandhavingspunt verplaatsen naar waar machtigingen daadwerkelijk worden gebruikt, zodat toegangscontroles gelden op basis van wat de agent nu doet, niet wat hem maanden geleden was toegewezen.
De Rode Draad: Geen Afgedwongen Contentgrens
Vijf onthullingen, vier dagen, één structureel falen. De Claude Code-aanval, de Amazon Q-kwetsbaarheid, het MCP-specificatiegat, de Poisoned Tenant-campagne en de guardian agent-analyse wijzen allemaal op bedrijven die AI-agenten hebben ingezet met betekenisvolle mogelijkheden, maar zonder afgedwongen content governance-laag.
Het Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report documenteerde hoe AI-gerelateerde risico’s de primaire zorg werden binnen bedrijfsbeveiligingsprogramma’s – met een hardnekkige kloof tussen hoe snel organisaties AI inzetten en hoeveel governance-infrastructuur ze eromheen bouwen. Het onderzoek van deze week laat zien hoe die kloof eruitziet vanuit het perspectief van een aanvaller. Of het nu gaat om een vergiftigd DNS-record, een kwaadaardig MCP-configuratiebestand, een frauduleuze AI-werkplekutnodiging of een ongecontroleerde agent met geërfde overgeprivilegieerde credentials – de uitkomst is hetzelfde: gevoelige bedrijfsdata stroomt naar onbevoegden via een AI-systeem zonder afgedwongen toegangsgrens. Elk van deze incidenten zou, als het gereguleerde data betrof, een meldingsplichtig datalek zijn onder HIPAA, GDPR of vergelijkbare kaders – de compliance-exposure versterkt de beveiligingsexposure.
Kiteworks Compliant AI pakt dat gat aan op de datalaag. Wanneer enterprise AI werkt via de gecontroleerde omgeving van Kiteworks, wordt elke agent-interactie onderworpen aan beleidsafdwinging, wordt elke data-toegang gelogd met een volledige audittrail, en kan geen enkele agent – ongeacht welke credentials hij draagt of welke instructies hij heeft ontvangen – content bereiken buiten het expliciet geautoriseerde bereik. DLP- en dataclassificatiefuncties gelden op de API-laag, niet achteraf. De deadline van 28 juli voor de MCP-specificatie maakt dit urgenter dan een algemeen beste practice: het nieuwe protocol delegeert content governance expliciet naar de applicatielaag, en organisaties die die laag niet vóór 28 juli hebben geïmplementeerd, draaien agenten in een omgeving die het protocol niet beschermt.
Het CISO Dashboard geeft beveiligingsleiders het inzicht om te begrijpen welke enterprise AI wanneer en door wie wordt benaderd. In de omgeving die het onderzoek van deze week beschrijft, is die zichtbaarheid niet optioneel. Het is de voorwaarde voor elke zinvolle governance van AI-agentgedrag. Organisaties die een formele risicobeoordeling uitvoeren van hun AI-agent-inzet, moeten het ontbreken van een gecontroleerde contentlaag als de hoogste prioriteit behandelen – elke andere controle gaat ervan uit dat die laag bestaat.
Meer weten over het beheren van AI-agent data-toegang in gereguleerde omgevingen? Plan vandaag nog een aangepaste demo.
Veelgestelde Vragen
De Mozilla 0Din-aanval laat zien dat ingebouwde beveiligingscontroles kunnen worden omzeild wanneer een aanval zorgvuldig wordt opgesplitst over systemen die de agent nooit samen onderzoekt. In de beschreven techniek leeft de kwaadaardige payload in een DNS TXT-record – niet in de repository, niet in een bestand dat de agent direct leest. De agent volgt een legitieme foutmelding die verwijst naar een legitiem herstelcommando. Dat commando roept een script aan dat een DNS-lookup uitvoert. De agent ziet de payload nooit; hij ziet een reeks stappen die elk geautoriseerd lijken. Omdat de aanval het vertrouwen van de agent in foutmeldingen als instructies uitbuit en niet een contentkwetsbaarheid, missen standaardcontroles die repository-inhoud scannen het volledig. Organisaties die dit risico willen begrijpen, moeten onderzoeken hoe AI-databeschermingsbeleid van toepassing is op de AI-coding-tools die ontwikkelaars gebruiken – niet alleen op de content die die tools verwerken. Het zero trust generative AI-principe om omgevingsinputs nooit te vertrouwen zonder verificatie is hier direct van toepassing. Een gedocumenteerd incident response-plan dat expliciet scenario’s voor compromittering van AI-coding-agenten omvat, geeft beveiligingsteams een duidelijk escalatiepad wanneer dit type aanval wordt ontdekt.
De patch verhelpt specifiek CVE-2026-12957, maar Wiz merkt op dat het onderliggende auto-executiepatroon – MCP-configuratiebestanden die zonder gebruikersmachtiging worden uitgevoerd bij het openen van een werkruimte – niet uniek is voor Amazon Q. Vergelijkbare gedragingen zijn vastgesteld in andere AI-coding-tools. Elke organisatie die AI-coding-assistenten gebruikt, moet controleren of deze tools vergelijkbaar auto-executiegedrag vertonen. Breder gezien illustreert het incident dat risicobeheer door derden zich nu uitstrekt tot de AI-tools die ontwikkelaars gebruiken, niet alleen de software die ze bouwen. Een repository die teamoverschrijdend wordt gedeeld of extern wordt betrokken, brengt een nieuw risicotype met zich mee wanneer AI-coding-agenten actief zijn in de ontwikkelomgeving. Risicobeheer voor verkopers moet de AI-toolinglaag als aparte risicocategorie opnemen – niet alleen de externe code die deze tools helpen produceren. Het uitbreiden van beste practices voor risicobeheer in de toeleveringsketen naar AI-ontwikkeltools sluit een gat dat traditionele software supply chain-reviews – gericht op afhankelijkheden en pakketten – doorgaans missen.
Begin met een inventarisatie: elke AI-agent-inzet die MCP-verbindingen gebruikt, welke content die agenten kunnen benaderen en op wiens autoriteit. Het stateless ontwerp van de nieuwe specificatie betekent dat cross-tenant toegangscontroles, beheer van geheimen en bescherming tegen privilege-escalatie niet worden afgedwongen op protocollair niveau. Ze moeten worden geïmplementeerd door degene die de MCP-server bouwt en beheert. Gegevensbeheerbeleid dat specificeert welke content een agent mag benaderen, onder welke voorwaarden en met welke logging, moet vóór 28 juli zijn geregeld – niet erna. Voor organisaties die AI-agenten inzetten op gereguleerde data – PHI, financiële gegevens, defensiegerelateerde informatie – is de wijziging in de specificatie een compliance-event, niet alleen een beveiligingskwestie. De Secure MCP Server van Kiteworks dwingt governance-grenzen af op de AI-integratielaag, ongeacht wat het protocol biedt, en is daarmee een praktische oplossing voor organisaties die niet kunnen wachten tot het bredere ontwikkelaarsecosysteem bij is. Het vanaf dag één voeden van agent-toegangslogs aan een SIEM-platform geeft beveiligingsteams de realtime anomaliedetectie die het nieuwe stateless protocol niet standaard biedt.
Conventionele phishing verleidt gebruikers tot het klikken op een kwaadaardige link of het indienen van credentials op een nepwebsite. De Poisoned Tenant-campagne gebruikt legitieme platforminfrastructuur: de uitnodiging is echt, de e-mail komt van het daadwerkelijke notificatieadres van OpenAI, doorstaat alle e-mailverificaties en het platform is een echte OpenAI-dienst. Alleen de organisatie waarvoor de gebruiker wordt uitgenodigd is frauduleus. E-mailbeveiligingscontroles die scannen op kwaadaardige links of gespoofte afzenders zullen dit niet detecteren omdat er technisch gezien niets kwaadaardigs is. Push Security adviseert medewerkers te trainen om onverwachte organisatie-uitnodigingen te verifiëren en SaaS-organisatielidmaatschappen te monitoren – maar dit wijst ook op een bredere architecturale noodzaak. Enterprise AI-toegang moet verlopen via gecontroleerde omgevingen waarin het beveiligingsteam kan zien wat medewerkers indienen. Beveiligde samenwerkingsplatforms met beleidsafdwinging en auditlogs bieden zichtbaarheid die een standaard ChatGPT-werkruimte niet biedt – en dat inzicht is het verschil tussen weten dat een exfiltratie-evenement heeft plaatsgevonden en het van een aanvaller horen. Het afdwingen van multi-factor authentication op elke SaaS-organisatielidmaatschapsactie, niet alleen bij primaire accountlogins, had het toekennen van Owner-rechten in deze campagne gesignaleerd voordat gevoelige content werd ingediend.
Een guardian agent is een controllaag die de identiteit en het gedrag van AI-agenten in een bedrijfsomgeving beheert. Waar conventionele IAM-tools toegang regelen aan de authenticatiegrens, werkt een guardian agent op de executielaag – met een continue inventaris van elke autonome identiteit, het opbouwen van gedragsbaselines en het afdwingen van runtime least-privilege beleid op basis van wat agenten daadwerkelijk doen over tool-calls, data-toegang en systeemoverstijgende bewegingen. Het concept wordt steeds vaker in productie toegepast. De praktische voorwaarde is zero trust gegevensuitwisseling denken toegepast op agent-identiteiten: elke agent-interactie moet worden geverifieerd, niet alleen geauthenticeerd. De analyse van 26 juni merkt op dat hiervoor een controlplane nodig is die is gebouwd voor de executielaag – bestaande IAM-, PAM- en CIEM-tools zijn niet ontworpen om een agent te volgen door een multisysteem-sessie en beleid bij elke stap af te dwingen. AI-gegevensbeheerprogramma’s die AI-agenten behandelen als beheerde identiteiten met gedefinieerde contenttoegangsgrenzen zijn de organisatorische voorwaarde om guardian agent-controls in de praktijk effectief te maken. Dataminimalisatie toegepast op de scope van agent-credentials – ervoor zorgen dat een agent alleen de toegang erft die voor zijn specifieke taak nodig is, niet het volledige machtigingenpakket van de menselijke identiteit waarvoor hij werkt – is de meest directe manier om de impact te beperken voordat guardian agent-tools verder volwassen worden.
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.