De eerste golf van bezorgdheid over AI bij bedrijven was eenvoudig. Het waren simpelweg werknemers die gevoelige gegevens in openbare AI-tools plakten. Beveiligingsteams reageerden met gebruiksbeleid, domeinblokkeringen en regels ter voorkoming van gegevensverlies. Die reactie was destijds logisch.
Het past niet meer bij het probleem.
Shadow AI is verschoven van een probleem met datalekken naar een probleem met toegangscontrole. De dreiging gaat niet over wat werknemers in AI-tools typen. Het gaat erom welke AI-agenten binnen de organisatie actief zijn, met welke bedrijfssystemen ze zijn verbonden en welke acties ze wel of niet mogen ondernemen.
Van passieve tools naar actieve actoren
Werknemers en bedrijfseenheden bouwen AI-agenten in een tempo dat de meeste beveiligingsteams niet kunnen bijhouden. Aangepaste assistenten, codeeragenten, workflowautomatiseringen en agentische applicaties worden op verschillende afdelingen gemaakt, waarvan sommige op goedgekeurde platforms, maar veel via browserextensies, SaaS-native functies, ontwikkelaarstools, MCP-servers, eindpuntgebaseerde agenten en aangepaste scripts. Velen beginnen als snelle experimenten. Sommige raken binnen enkele dagen ingebed in kritische bedrijfsprocessen.
Het risicoprofiel van deze agenten is fundamenteel anders dan traditionele schaduw-IT. Een niet-goedgekeurde SaaS-applicatie is een bestemming voor gegevens. Een AI-agent is een actor die API’s kan aanroepen, opgeslagen inloggegevens kan gebruiken, records kan ophalen, configuraties kan wijzigen, stroomafwaartse workflows kan activeren en acties kan ondernemen in productiesystemen, vaak zonder dat een mens elke stap expliciet autoriseert.
Een werknemer die een klantrecord in een openbare AI-tool plakt, is een incident met gegevenslekken. Een aangepaste AI-agent die is verbonden met Salesforce, Snowflake, GitHub, Gong en Slack is een toegangscontrole-incident dat staat te gebeuren. Het kan gegevens vrijgeven, maar het kan ook lees-, schrijf- en verwijderacties op die gegevens uitvoeren. Het kan ook draaien op serviceaccounts met machtigingen die niemand heeft gecontroleerd en actief blijven zes maanden nadat de werknemer die het heeft gebouwd van functie is veranderd of het bedrijf heeft verlaten. Nieuw onderzoek van Token Security en de Cloud Security Alliance brengt precies in kaart hoe wijdverbreid deze blootstelling is geworden.
Waarom bestaande controles dit niet bereiken
De meeste beveiligingsmaatregelen voor ondernemingen zijn ontworpen voor menselijke identiteiten en deterministische werklasten. IAM-beleid, DLP-regels en netwerkmonitoring gaan uit van voorspelbaar gedrag en gedefinieerde toegangspaden. AI-agenten breken deze aannames.
Een agent die belast is met het oplossen van een mislukte implementatie kan logboeken lezen, controlesystemen opvragen, infrastructuurconfiguraties wijzigen, tickets openen, automatiseringspijplijnen activeren en technische teams op de hoogte stellen, allemaal op volgorde, allemaal met dezelfde overgenomen inloggegevens. Om te voorkomen dat workflows worden onderbroken, verlenen ontwikkelaars vooraf brede machtigingen. Deze machtigingen stapelen zich op. Agenten nemen bevoegdheden op makerniveau over, tijdelijke toegang wordt permanent en beveiligings- en identiteitsteams verliezen het zicht op wat die identiteiten feitelijk doen.
Het blokkeren van publieke AI-domeinen bereikt dit allemaal niet. Tegen de tijd dat een agent inloggegevens voor bedrijfssystemen heeft, is de grens al overschreden. Geautomatiseerd herstel van niet-menselijke identiteiten is waar die kloof wordt gedicht.
Hoe een echte schaduw-AI-inventaris eruit ziet
Om schaduw-AI te ontdekken, moet je kijken in de omgevingen waar agenten daadwerkelijk leven, zoals AI-platforms, SaaS-apps met ingebouwde automatisering, cloudaccounts, ontwikkelaarstools, eindpunten en identiteitsproviders. Hier zijn zes vragen om te bepalen of beveiligingsteams echte controle hebben.
- Waar worden agenten gemaakt of geïnstalleerd? Dit omvat voor de hand liggende AI-platforms, maar ook codeerassistenten, SaaS-native agentfuncties, lokale ontwikkelaarstools en interne applicaties die stilletjes AI-mogelijkheden hebben toegevoegd.
- Wie is eigenaar van elke agent en wie kan deze gebruiken? Zonder eigenaarschap is er geen verantwoordelijkheid. Een agent die is gebouwd voor een financieel team van drie personen en die door de hele organisatie wordt gedeeld, heeft een heel ander risicoprofiel dan een agent die zich richt op één enkele gebruiker.
- Met welke bronnen en services is de agent verbonden? Een agent kan op platformniveau onschadelijk lijken terwijl hij verbindingen heeft met gevoelige databases of productiesystemen via inloggegevens die informeel zijn toegekend en nooit zijn gecontroleerd.
- Welke identiteiten en geheimen gebruikt het? Agenten authenticeren via serviceaccounts, API-sleutels, OAuth-tokens, IAM-rollen in de cloud en langlevende geheimen. Elk referentietype brengt verschillende risico’s met zich mee.
- Wat is de bedoeling van de agent en wat heeft hij feitelijk gedaan? Configuratie alleen laat niet zien of een agent gegevens leest, records schrijft of toegang krijgt tot systemen buiten het beoogde bereik. Het begrijpen van de intentie en de gedragscontext is vereist om prioriteit te kunnen geven aan de respons.
- Is de agent nog actief? Uit de Agentic Pulse-gegevens van Token Security blijkt dat 65,4% van de agentic chatbots sinds de oprichting nooit is gebruikt, maar dat hun inloggegevens actief blijven. Slapende agenten met live toegang vormen een hardnekkige en ondergewaardeerde blootstelling.
De volwassenheidscurve om agent-AI-beveiliging te garanderen
De meeste organisaties staan nog aan het begin en hebben weinig tot geen agenteninventaris. De volgende stap is het verkrijgen van gedeeltelijke zichtbaarheid om te weten welke agenten bestaan, zelfs zonder de volledige context. Daarna hebben ze verrijking en context nodig om de intentie te begrijpen en het eigendom, de toegang en de inloggegevens van elke agent in kaart te brengen. De volgende stap is het toepassen van handhaving met geautomatiseerde controles die overmatige machtigingen herstellen, eigenaren van inactieve agenten op de hoogte stellen en nieuwe agenten markeren die verbinding maken met gevoelige systemen.
Het doel is niet om de adoptie van AI te blokkeren. Teams staan onder grote druk om deze tools te gebruiken, en veel van de productiviteitswinsten zijn legitiem. Als beveiliging een harde barrière wordt, verplaatst het gebruik zich verder ondergronds en ongezien. Het betere resultaat is een beheerde mogelijkheid om teams een pad te bieden om agenten in te zetten met geautomatiseerde controles die continu op de achtergrond draaien.
Dit vereist dat we AI-agenten op dezelfde manier behandelen als elke andere identiteit in de onderneming, met continue ontdekking, gedefinieerd eigendom, beperkte toegang en levenscyclusbeheer vanaf de creatie tot en met de buitengebruikstelling.
De vraag over schaduw-AI is veranderd. Het is niet langer de vraag: welke data stoppen medewerkers in AI? Het is nu: welke agenten zijn actief in onze omgeving en waar hebben we ze toegang toe gegeven? Dat zijn verschillende vragen. De tweede is degene die de blootstelling en het risico van een organisatie definieert. Als je nu die inventarisatie doorneemt, is het de moeite waard om te zien hoe anderen het benaderen.
