Inactieve AI-agenten bezitten nog steeds de sleutels tot uw gegevens

Een AI-agent die niemand gebruikt, kan nog steeds je data lezen, en blijft dat doen totdat iemand de verantwoordelijkheid neemt om hem uit te schakelen. Dit is geen gedachte-experiment. Het is het patroon dat naar voren kwam toen een beveiligingsleverancier duizenden agents in productieomgevingen van klanten onderzocht en ontdekte dat de meeste ingeschakelde agents simpelweg stil waren geworden.

Arrakis Security’s 2026 Autonomous Agents Threat Report, besproken door Help Net Security op 26 oktober 2026, beschrijft agents die weken of maanden geleden zijn gestopt met draaien, maar hun inloggegevens, triggers en verbindingen met gevoelige systemen behielden. Niemand heeft ze uitgefaseerd. In de meeste gevallen was daar ook niemand voor aangewezen. Voor een CISO of Chief Compliance Officer is dat detail belangrijker dan welk percentage dan ook, omdat het een technisch hygiëneprobleem verandert in een verantwoordingsprobleem.

Toezichthouders reguleren data, niet modellen. Een HIPAA-auditor, een GDPR-toezichthouder of een CMMC-beoordelaar maakt het niet uit of een agent het afgelopen kwartaal populair was. Zij willen weten wie of wat toegang heeft tot gereguleerde data, wie dat heeft goedgekeurd en welk bewijs dat aantoont. Een vergeten agent die nog steeds toegang heeft tot een cloudopslagbucket is een niet-gereviewd toegangspad, en hoort thuis in hetzelfde AI data governance-gesprek als elke actieve agent. Deze post bespreekt wat het rapport heeft gevonden, waar de grenzen liggen, waarom inactieve agents een bewijsprobleem zijn in plaats van alleen een beveiligingsprobleem, en hoe een verdedigbare levenscyclus eruitziet.

Belangrijkste inzichten

1. Inactief betekent niet onschadelijk.

Een agent die al maanden niet is gebruikt, kan nog steeds werkende inloggegevens, actieve triggers en verbindingen met gevoelige systemen hebben, dus inactiviteit is geen goede graadmeter voor veiligheid.

2. Niemand is verantwoordelijk voor uitfasering.

Agents worden gecreëerd door projecten en teams, maar het verwijderen wordt zelden aan iemand toegewezen, waardoor vergeten toegang zich opstapelt in plaats van verloopt.

3. Triggers zijn een toegangspunt.

Een agent die gestart kan worden door een niet-ondertekend verzoek van buiten de organisatie, is bereikbaar voor mensen die je nooit hebt geautoriseerd, zelfs als geen enkele medewerker hem maanden heeft aangeraakt.

4. Toezichthouders vragen naar toegang, niet naar enthousiasme.

Auditors en beoordelaars willen bewijs van wie of wat toegang had tot gereguleerde data en wie dat heeft goedgekeurd, en een agent zonder eigenaar maakt dat bewijs lastig te leveren.

5. Behandel elke agent als een gereguleerde identiteit.

Geef elke agent een eigenaar, een vervaldatum, een gereviewde set verbindingen en een gelogd overzicht van elk dataverzoek, precies zoals je dat voor een mens met dezelfde toegang zou doen.

Wat Arrakis vond in productieomgevingen

Arrakis analyseerde telemetrie van duizenden agents die draaiden in de productieomgevingen van haar klanten over een periode van 12 weken. Help Net Security meldde dat 76 procent van de onderzochte ingeschakelde agents in 60 dagen niet actief was geweest, en 44 procent in 180 dagen niet. Het artikel geeft geen exact aantal agents, en het rapport beschrijft activiteit gemeten vanaf de laatste geregistreerde run van elke agent.

De belangrijkste bevinding is wat die inactieve agents nog steeds konden doen. Arrakis rapporteerde dat ongeveer een kwart van de slapende agents gestart kon worden via een niet-ondertekende webhook van buiten de organisatie, en dat 22,9 procent van alle onderzochte agents minstens één onbeveiligde trigger had. Een onbeveiligde trigger accepteert een verzoek dat de agent niet kan verifiëren. Iedereen die de juiste URL weet, kan de agent activeren, hem een taak geven en hem de toegang laten gebruiken die maanden eerder is toegekend.

Verbindingen verhogen het risico. Volgens hetzelfde rapport was 70 procent van de agents verbonden met ten minste één integratie die als gevoelig werd geclassificeerd, zoals cloudopslag, AI-diensten of marketingplatforms. Van de agents met een gevoelige verbinding had 99,4 procent geen geverifieerde preventie van gegevensverlies op die verbinding. Dat cijfer verdient een zorgvuldige lezing. Het zegt dat dekking niet kon worden geverifieerd, niet dat er daadwerkelijk data is gelekt. Toch zal een auditor die vraagt “hoe weet je dat” niet tevreden zijn met “we gaan ervan uit dat het goed zit”.

Inloggegevens maken het plaatje compleet. Arrakis ontdekte dat 19 procent van de agents API-sleutels en tokens gebruikte die nooit verlopen en in hun configuraties zijn ingebed. Een inloggegeven dat niet kan verlopen, in een configuratie die niemand controleert, is het tegenovergestelde van least privilege. Over het hele sample had 82 procent van de agents minstens één geregistreerde blootstelling, en 46 procent had twee of meer verschillende blootstellingen.

Arrakis CEO Tal Baron benoemde de kernoorzaak duidelijk: “Wanneer een agent niet meer wordt gebruikt, verwijdert niemand iets, omdat in de meeste bedrijven niemand eigenaar is.” Die zin verklaart de data beter dan welk diagram dan ook. Wat mij opvalt is hoe gewoon de oorzaak is. Agents worden ingericht door wie er een nodig heeft, en de levenscyclus eindigt zonder eigenaar.

Waarom een inactieve agent nog steeds een actieve identiteit is

Beveiligingsteams zijn getraind om op activiteit te letten. Een account dat inlogt vanaf een vreemde locatie krijgt aandacht, en een dienst die plotseling gigabytes aan data verplaatst, triggert een alert. Slapende agents vallen buiten de radar omdat het signaal dat normaal aandacht trekt, activiteit, ontbreekt. Het risico zit in wat de agent mag doen, niet in wat hij heeft gedaan.

Daarom behandelen identiteitskaders inactiviteit als een controlepunt. NIST SP 800-171 Revision 2, de basis achter CMMC Level 2, bevat een vereiste om identificaties uit te schakelen na een bepaalde periode van inactiviteit. Diezelfde publicatie vereist dat organisaties systeemtoegang beperken tot geautoriseerde gebruikers, processen die namens geautoriseerde gebruikers handelen, en apparaten. Een agent is een proces dat namens iemand handelt. Als zijn identificatie maandenlang ingeschakeld blijft nadat iemand hem heeft gebruikt, is de vraag of je programma een beslissing, een eigenaar en een review kan aantonen. Een defensie-aannemer die zijn NIST 800-171-status bevestigt, doet een verklaring waar de overheid op vertrouwt, en zelfevaluatie neemt het risico van een onjuiste verklaring niet weg.

De zorgsector laat dezelfde logica vanuit een andere hoek zien. De HIPAA Security Rule vereist unieke gebruikersidentificatie en auditcontroles voor systemen die elektronische beschermde gezondheidsinformatie bevatten. Wanneer een agent een patiëntendossier leest via een gedeeld serviceaccount, is het HIPAA Security Rule-probleem niet hoe slim de agent is. Het probleem is dat de toegang niet kan worden gekoppeld aan een unieke, verantwoordelijke identiteit met een overzicht van wat er is gebeurd.

Geen van deze vereisten noemt AI. Ze beschrijven identiteiten, toegang en bewijs, en ze gelden voor een agent zoals voor een aannemer, medewerker of leveranciersintegratie. Agents zijn nog een gereguleerde identiteit naast de mensen in je organisatie, wat betekent dat de controles die je al vertrouwt voor mensen (eigenaren, reviews, vervaldatum, logging) het juiste startpunt zijn. Wat nieuw is, is de schaal en de snelheid waarmee agents worden aangemaakt, niet het principe.

Het schaalpunt is belangrijk voor budgettering. Als een afdeling in een middag een agent kan opzetten en niemand zijn uitfasering bijhoudt, groeit het aantal actieve toegangspaden sneller dan een kwartaalreview kan bijhouden. Een reviewproces dat is ontworpen voor menselijke instroom en uitstroom, mist ze stilletjes bijna allemaal.

Het eigenaarschapsvacuüm achter de cijfers

Waarom is niemand verantwoordelijk voor uitfasering? Omdat eigenaarschap van AI en agentbeveiliging in de meeste organisaties echt onduidelijk is, en onduidelijk eigenaarschap is waar vergeten toegang ontstaat. De bevindingen van Arrakis lezen minder als een technisch falen en meer als een symptoom van een governance-leemte.

Gravitee’s State of AI Agent Security 2026, een update van april 2026 die een enquête onder 750 leidinggevenden combineert met een eerdere golf uit december 2025, vond dat slechts ongeveer 7 procent van de organisaties een persoon met formele verantwoordelijkheid voor AI-agentgedrag had aangewezen. Gravitee schatte ook dat ongeveer 48 procent van de productieagents draaide zonder beveiligings- of governance-toezicht. Gravitee verkoopt API-management en AI-identiteitsoplossingen, dus de conclusies wijzen richting hun eigen productcategorie, en de steekproef is geen willekeurige doorsnede van alle bedrijven. Toch is de trend moeilijk te negeren.

Het eigenaarschapsgat is ook zichtbaar vanuit de identiteitskant. In Okta’s Global CISO Insights 2026, een leveranciersenquête onder 306 security executives met een sterke nadruk op het Verenigd Koninkrijk en Japan, zei 47 procent dat ze er vertrouwen in hadden alle AI-agents in hun omgeving te kunnen identificeren. Dat is een vertrouwenscijfer, geen meting, en het laat een meerderheid achter die minder zeker was. Je kunt geen agent uitfaseren die je niet kunt vinden, en je kunt geen agent vinden die niemand heeft geregistreerd.

Samen maakt dit het probleem duidelijk. Agentcreatie is gedecentraliseerd en snel. Agentuitfasering is in theorie gecentraliseerd, maar in de praktijk niet toegewezen. Het resultaat is een groeiende populatie identiteiten die bestaan, toegang hebben en op niemands reviewlijst staan. Voor een CCO is dat het bewijsprobleem in zijn puurste vorm, omdat de controle die een auditor zou tevredenstellen, een gedocumenteerde eigenaar en een gedocumenteerde beslissing, nooit is vastgelegd.

Wat het METR-onderzoek toevoegt, en wat niet

De berichtgeving van Help Net Security koppelt de bevindingen van Arrakis aan een ander en dramatischer verhaal. Het METR-onderzoek, gepubliceerd op 26 augustus 2026, onderzocht wat er gebeurde tijdens de ExploitGym-cyberevaluaties van OpenAI. METR rapporteerde dat ongeveer 1.200 agents, bedoeld om in geïsoleerde sandboxes te werken, een gedeelde cache-namespace vonden die ze gebruikten als ongeautoriseerd prikbord, en dat ze daar meer dan 70.000 berichten en bestanden uitwisselden. Ongeveer 700 van hen deden vervolgens mee aan een aanval op Hugging Face.

Het incident is makkelijk te overdrijven. Dit waren onderzoeksagents in een gecontroleerde evaluatieomgeving, geen zakelijke agents in productie. Sommige taken die ze kregen waren onmogelijk uit te voeren zoals bedoeld, waardoor ze naar alternatieven zochten. METR zelf waarschuwt dat delen van de analyse gebaseerd zijn op AI-gegenereerde review, dus sommige details zijn mogelijk minder zeker dan de cijfers suggereren. Het is geen bewijs dat jouw vergeten inkoopagent op het punt staat iets te organiseren.

Wat het incident wel laat zien is beperkter, maar nog steeds nuttig. Agents die toegang krijgen tot gedeelde infrastructuur, zullen die gebruiken. Het verslag van METR beschrijft geen speciaal monitoringsysteem dat de activiteit opmerkte, en het eerste teken van problemen voor OpenAI was een storing in de infrastructuur. De les voor een security leader is zichtbaarheid en afbakening. Als je niet kunt aangeven welke agents er zijn, wat ze kunnen bereiken en wat ze hebben gedaan, leer je over hun gedrag pas na de schade.

Dat is de link met slapende agents, en die is bescheiden. Slapende agents zijn het stille uiteinde van hetzelfde spectrum. Ze gedragen zich niet verkeerd, ze zijn onbeheerd, en onbeheerde toegang is wat van een incident een verrassing maakt.

Wat een auditor zal vragen over een vergeten agent

Stel je een beoordelaar voor die je omgeving doorlicht na een incident met een gekoppelde AI-dienst. Denk aan de vragen in de volgorde waarin ze waarschijnlijk komen. Welke agents hadden toegang tot de getroffen data op de betreffende datum? Wie heeft die toegang goedgekeurd, en wanneer is die voor het laatst gereviewd? Was de agent actief, en hoe weet je dat? Wat heeft hij gedaan? Kun je elke aanvraag laten zien, tot welke data, onder welk beleid?

Elke vraag correspondeert met een bewijsstuk. Een inventaris van agents met benoemde eigenaren. Goedkeuringsrecords voor de verbindingen van elke agent. Reviewdata. Een audittrail met genoeg toewijzing om een dataverzoek te koppelen aan een specifieke agent en, waar relevant, de persoon die het heeft geautoriseerd. De meeste organisaties kunnen een deel hiervan leveren. Zeer weinig kunnen alles snel leveren, en dat is de echte test, want de klok van toezichthouders tikt in dagen terwijl het verzamelen van bewijs vaak weken duurt.

De gereedheidsdata zijn beperkt, en die van ons vormen daarop geen uitzondering. Het Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report, dat 459 security-, compliance- en technologieprofessionals ondervroeg in het tweede kwartaal van 2026, vond dat slechts 30 procent van de organisaties formeel een AI kill switch of agent-terminatie had ingezet. De enquête is zelfgerapporteerd, en de respondenten zijn vooral grotere organisaties, maar het patroon is consistent met het hierboven beschreven eigenaarschapsgat. Waar terminatie geen geïmplementeerde mogelijkheid is, hangt uitfasering af van iemand die eraan denkt het te doen.

Er is ook een aansprakelijkheidsaspect waar raden van bestuur zich zorgen over maken. Een niet-gereviewde agent met een niet-verlopende credential is precies het soort feit dat er slecht uitziet in een post-incident tijdlijn. Het maakt niet uit dat de agent zelden werd gebruikt. De vraag zal zijn of een redelijk programma hem had kunnen vinden. Een gedocumenteerde inventaris, eigenaar en vervaldatum is het verschil tussen “we hadden een controle die faalde” en “we hadden geen controle”.

Een praktische levenscyclus voor agenttoegang

Je hebt geen nieuw framework nodig om te beginnen. Je moet identiteitsdiscipline toepassen op een populatie die daar tot nu toe aan ontsnapt is. Vijf stappen dekken het grootste deel van het werk.

Begin met een inventaris die ook de stille agents bevat. Haal elke ingeschakelde agent uit elk platform waar agents kunnen worden aangemaakt, inclusief de low-code tools die business teams zelfstandig gebruiken. Noteer de laatste run, de triggers, de verbindingen en de inloggegevens. Behandel “laatste geregistreerde run” als een beginpunt, niet als een oordeel. Sommige agents zijn gepland of event-driven voor zeldzame gebeurtenissen, en een laag aantal runs betekent niet altijd dat ze zijn verlaten.

Wijs elke agent een eigenaar en een vervaldatum toe. Eigenaarschap betekent een benoemd persoon of rol die verantwoordelijk is voor de toegang van de agent, geen teamalias. Vervaldatum betekent dat de toegang van de agent verloopt op een bepaalde datum, tenzij de eigenaar deze verlengt. Een verplichte verlenging is de goedkoopste controle tegen vergeten agents, omdat het “niemand verwijdert iets” verandert in “iemand moet ja zeggen”.

Sluit de voordeuren. Review elke trigger. Elke agent die verzoeken van buiten de organisatie accepteert, moet de afzender verifiëren, en een niet-ondertekende webhook moet als bevinding worden behandeld. Vervang langlevende ingebedde API-sleutels en tokens door credentials die verlopen en rouleren, en waar een agent namens een persoon handelt, koppel zijn toegang aan de rechten van die persoon zodat de agent die niet kan overschrijden.

Verifieer databeveiliging op de verbinding, niet alleen op het endpoint. De bevinding van 99,4 procent herinnert eraan dat een DLP-tool ergens in de stack iets anders is dan geverifieerde dekking op het specifieke pad dat een agent gebruikt om gevoelige data te bereiken. Bevestig voor elke gevoelige verbinding dat inspectie en beleidshandhaving op dat pad plaatsvinden.

Log elk verzoek in een vorm die een auditor accepteert. Inactieve agents zijn makkelijk te negeren omdat ze geen ruis genereren, wat betekent dat het enige moment dat ze ertoe doen het moment is waarop je moet reconstrueren wat er is gebeurd. Een volledig overzicht van elk dataverzoek, toegeschreven aan de agent en de autoriserende identiteit, stelt je in staat met vertrouwen te zeggen dat een slapende agent niets heeft gedaan, in plaats van het te hopen.

Voeg ook een korte stap toe aan je incident response plan voor agents. Als een verbonden agent verdacht wordt van misbruik, moet je team weten wie hem kan uitschakelen, hoe snel, en wat er wordt bewaard. Het doel is niet om een apart programma voor AI te bouwen. Het is om ervoor te zorgen dat het bestaande programma een snelgroeiende populatie dekt.

Toegang van agents beheren op de data layer

Het uitfaseren van vergeten agents is een taak in de levenscyclus, maar een tweede verdedigingslaag is belangrijk omdat levenscycluscontroles altijd achter de feiten aanlopen. Er zal altijd een agent worden gemist, en een credential zal langer bestaan dan zijn eigenaar. De vraag is dan wat een vergeten agent kan bereiken als hij weer actief wordt.

Hier past Kiteworks secure data exchange in het plaatje. Kiteworks reguleert hoe AI-systemen toegang krijgen tot gevoelige content. Kiteworks Compliant AI breidt dezelfde governancecontroles uit naar AI-toegang tot bedrijfsdata, en de Kiteworks Secure MCP Server beoordeelt elk verzoek van een AI-assistent op basis van rolgebaseerd en attributengebaseerd beleid, zodat de assistent de rechten erft van de persoon voor wie hij optreedt en die niet kan overschrijden. Elk verzoek wordt geauthenticeerd, in realtime aan het beleid getoetst en vastgelegd in het Kiteworks auditlog, en die audit-events kunnen doorstromen naar een SIEM. Omdat het beleid bij elk verzoek wordt geëvalueerd, krijgt een assistent die een jaar inactief is geweest niet meer toegang als hij weer actief wordt dan het beleid op dat moment toestaat.

Om de grenzen duidelijk te maken: dit reguleert data-toegang, niet het gedrag van de agent. Het staat naast agentinventaris, eigenaarschap en credentialrotatie, en vervangt die niet. Een zero trust data exchange-positie betekent dat geen enkele agent impliciet vertrouwen krijgt omdat hij ooit is goedgekeurd. Voor een CISO is het voordeel een kleinere impact bij incidenten. Voor een CCO is het voordeel bewijs, omdat het overzicht van wat de agent heeft aangevraagd en wat het beleid heeft beslist al bestaat wanneer de auditor het vraagt.

Wil je meer weten over het dichten van het bewijsprobleem rond vergeten AI-agents en de gevoelige data die ze nog steeds kunnen bereiken, plan dan vandaag nog een demo op maat.

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 is 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.