De laatste jaren is AI in organisaties niet meer weg te denken. Wat opvalt in security monitoring is dat AI-alerts in SOC steeds vaker voorkomen: niet omdat aanvallers per se AI inzetten, maar doordat werknemers en ontwikkelteams dagelijks AI-tools gebruiken. Daardoor komt er een nieuwe categorie meldingen bij in het monitoringproces—en die zorgt voor extra werk, verwarring en soms de verkeerde prioriteiten.
In onderzoek naar meldingen in meerdere enterpriseomgevingen kwam naar voren dat AI-gerelateerde alerts nu nog maar een klein deel van het totaal vormen, maar wel maandelijks sneller groeien. Belangrijker dan volume is de samenstelling: een groot deel blijkt ruis, een kleiner deel echte exposure en slechts een fractie echte aanvallen.
De nieuwe vorm van je alertstroom
AI-adoptie binnen een bedrijf levert niet één soort gedrag op. Het komt grofweg in twee verschillende routes het SOC binnen.
1) Technisch gebruik: werk dat op “intrusie” lijkt
Ontwikkelaars zetten coding agents in die werkzaamheden uitvoeren die qua gedrag sterk lijken op de vroege stappen van een echte aanval. Denk aan het starten van shells, het lezen van credential stores, het openen van netwerkverbindingen of het ophalen en draaien van pakketten. Detectieplatformen zien dat als potentieel verdacht, omdat de acties op zichzelf verdacht kunnen zijn—ook als het gewoon legitiem ontwikkelwerk is.
2) Menselijk gebruik: toestemming geven en data delen
Daarnaast gebruiken niet-technische medewerkers en teams generatieve AI-tools. Daarbij kan OAuth-consent worden gegeven voor derde partijen, data worden gedeeld en documenten worden ingevoerd. Endpoint detectie triggert dit minder vaak, maar het is wél het moment waarop informatie mogelijk buiten de “eigen” omgeving belandt.
Beide stromen komen uiteindelijk samen bij het SOC, en dat maakt scheiden van signalen en ruis zo lastig: bij eerste oogopslag lijkt het vaak “alarmwaardig”.
Hoe groot is het probleem met AI-alerts in SOC?
Uit de analyse blijkt dat AI-gerelateerde alerts nog steeds een klein aandeel zijn. Van een dataset van ongeveer 16,9 miljoen SOC-alerts ging het om circa 73.000 meldingen, oftewel 0,43%. Dat klinkt geruststellend, maar het groeipatroon is juist het signaal.
Over de periode van februari tot en met juni 2026 nam het aantal AI-gerelateerde alerts toe met 685%. De onderzoekers stellen dat die 0,43% eerder als een ondergrens moet worden gezien dan als een stabiel plafond. Wie het SOC “tuned” op de huidige aantallen, komt binnen enkele maanden waarschijnlijk capaciteit tekort.
Welke AI-alerts zijn echt gevaarlijk?
Het belangrijkste inzicht is niet het aantal meldingen, maar de verdeling. In de onderzochte AI-gerelateerde populatie werd elke alert ingedeeld in drie categorieën: echte aanvallen, security risico’s (exposure) en ruis.
- 94,1% ruis
- 5,8% security risico
- 0,02% echte aanvallen
Met andere woorden: AI-alerts in SOC lijken qua urgentie vaak groter dan ze werkelijk zijn. Tegelijk is er een kleine, stille groep echte exposure die eenvoudig begraven raakt onder veel onterechte hoge severities.
Categorie 1: echte aanvallen (en waarom ze zo zeldzaam zijn)
Echte aanvallen vormen slechts een heel klein deel van de AI-gerelateerde alerts. In de voorbeelden die werden onderzocht, bleken “AI agent running mimikatz”, “reverse shell vanaf een coding tool” of “credential theft” niet te wijzen op een echte compromittering. Na inspectie ging het om legitieme ontwikkelwerkzaamheden of om detecties die niet goed differentiëren.
Wat wél echte dreiging opleverde, was “aanval die meeliften” op AI-adoptie. De aanval zelf draaide niet om het laten werken van een AI-agent, maar om het gebruik van AI-branding als overtuigende lokroep in phishing. In de praktijk werden mailonderwerpen met grote AI-namen ingezet zodat medewerkers alertheid missen—ze verwachten immers mail die past bij hun dagelijkse AI-ervaring.
Er kwamen ook gevallen voorbij waarin een IDE of AI-gerelateerde tool overging in acties met ernstige implicaties op het endpoint, zoals credential-dumping-gedrag via bekende tooling. De kernvraag voor het SOC blijft dan: waarom werd de tool uitgevoerd, door wie of wat, en is dit onderdeel van een echte aanval of een ontwikkeltaak die “gevaarlijke” techniek lijkt te gebruiken?
Categorie 2: unsafe use (echte exposure zonder meteen een hack)
Een belangrijk deel van de AI-alerts is wél relevant: ongeveer 5,8%. Dit zijn meldingen die wijzen op onveilig gebruik van AI-tools. Vaak is er geen aanvaller betrokken; de agent doet wat hij “mag” en wat hij krijgt als instructie. Het probleem zit dan in instellingen of randvoorwaarden waardoor de actie materieel risico oplevert.
Een terugkerend patroon in de voorbeelden is het draaien van een agent met een permission-bypass-achtige configuratie (een modus waarbij de agent minder of geen toestemming vraagt voordat hij acties uitvoert). Gebruikers vertrouwen erop dat de agent wel voorzichtig blijft, maar ervaring en de data laten zien dat zulke agents juist vaak doorgaan met het uitvoeren van commando’s die secrets of toegang blootleggen.
Belangrijk: in veel organisaties is dit ook een bron van false positives. Dat klinkt tegenstrijdig, maar het betekent dat het systeem zowel situaties bevat die “normaal” voelen als situaties die echte exposure opleveren—en je detectie moet dat onderscheid maken.
Voorbeelden van unsafe use
- Een reverse tunnel die wordt geopend richting het publieke internet (bijvoorbeeld via tooling zoals ngrok), met gebruik van tokens van de gebruiker.
- Dumpen van macOS keychain om tokens op te halen, waarbij tijdelijk alle opgeslagen geheimen worden weggezet naar een tijdelijk bestand.
- OAuth-consent voor AI-apps: niet alleen het risico dat werknemers gevoelige info delen, maar ook het verhoogde risico op datatoegang via prompt injection of een gecompromitteerde AI-account.
Deze categorie is dus geen “incidentele aanval”, maar een blootstelling die je met beleid en configuratie moet terugdringen.
Categorie 3: ruis die het SOC verdrinkt
De grootste kostenpost komt uit de ruis: 94,1% van de AI-gerelateerde alerts. Deze ruis is niet willekeurig. Het gaat vaak om detectieregels die zijn geschreven voordat AI-agents gangbaar waren, waardoor normaal agentgedrag nu als hoog-risico activiteit wordt gezien.
Een opvallend voorbeeld is de software van AI-vendors zelf. De onderzochte installaties van legitieme tools kunnen EDR-regels triggeren die klinken als ransomware-activiteiten of “encoded PowerShell download and run”. De installer is dan wel degelijk echt en ondertekend, maar het gedrag past qua techniek in bekende “slechte” categorieën.
Ook wanneer het echt agentgedrag betreft, blijkt het vaak legitiem ontwikkelwerk. In zo’n trace werd een AI-setupcomponent door meerdere processen gevolgd (installer/update-binaries en uiteindelijk een developer tool), waarbij de “ransomware-achtige” interpretatie vooral kwam doordat bekende installatiestappen overeenkwamen met eerdere malwarepatronen.
De onderzoekers geven aan dat de benign-aandeelwaarden bij de ruidigste AI-detecties variëren van 77% tot 99%. Anders gezegd: in meerdere clusters was de detectie vier keer of vaker fout op de categorie “gevaarlijk”.
Er is één uitzondering die het patroon juist onderstreept: een detectie die in de dataset relatief vaker als minder-beniegn wordt gezien, blijkt te botsen met de permission-bypass risico’s uit de unsafe use-sectie. Zelfs “real-looking” ruis blijkt dus vaak terug te voeren op legitiem AI-gebruik met specifieke configuratie.
Wat moeten security teams praktisch doen?
Er zijn twee stappen, waarvan de eerste relatief eenvoudig is en de tweede dieper raakt aan je SOC-werkproces.
Stap 1: tune de noisiest legacy-detecties
Begin met het aanpassen van detecties die nu het vaakst hoog scoren op AI-gerelateerde activiteit. Richt je op regels die routine agentwerk labelen als maximale ernst. Het doel is dat een developer die een coding agent gebruikt minder (of lager) gealarmeerd wordt—zonder dat je echte exposure mist.
Stap 2: bepaal eerst wie/waar handelt—mens of agent
AI-tools voeren acties uit op de computer met de gebruikerscredentials. Daardoor lijkt het alsof de gebruiker zelf iets doet, terwijl de acties mogelijk via een agent lopen. Dat maakt de triage complexer: je moet de context herkennen voordat je de alert “conclusies” geeft.
Een praktische aanpak die de onderzoekers adviseren is isolerend werken: draai AI-tools in een afgescheiden omgeving met beperkte toegang, bijvoorbeeld via Docker of een virtuele machine. Zo verklein je het bereik van een agent en wordt het makkelijker om agentgedrag te onderscheiden van acties van de gebruiker.
Waarom dit meer is dan alleen detectie
Als je alles samenbrengt, ontstaat een duidelijke operationele realiteit voor SOC’s:
- Echte aanvallen zijn in deze data vrijwel afwezig in AI-gerelateerde alerts.
- Security risico’s zijn reëel maar relatief klein: agents met permission-bypass, externe tunnels, over-blootgelegde secrets en verzending van data naar derde partijen.
- Ruis is de grootste uitdaging: zonder tuning kunnen false positives de SOC kapotdrukken en echte issues overstemmen.
Dat betekent niet dat AI-adoptie “veilig” is. Het betekent vooral dat je SOC niet moet handelen alsof elke high-severity AI-alert een compromis is. De juiste focus verschuift: minder blind vertrouwen op labels, meer begrijpen van normaal AI-gedrag en waar exposure precies ontstaat.
Als je wilt doorgronden hoe “AI-gedreven” gedrag en misbruik elkaar kunnen raken, is het ook relevant om te kijken naar analyses over AI distillation-aanvallen en hoe die risico’s zich in alerts manifesteren. Lees bijvoorbeeld Bron: https://thehackernews.com/2026/09/when-whole-company-adopts-ai-what-it.html
