The 2025 security operations 

Deel I: Roadmap

1.1. Van het beveiligen van infrastructuur naar het besturen van intelligentie

De kern van cyberbeveiliging ondergaat in 2025 een fundamentele transformatie. De focus verschuift van het verdedigen van statische, definieerbare perimeters naar het beheersen van de risico’s die inherent zijn aan autonome, intelligente en diep onderling verbonden systemen. Organisaties worden geconfronteerd met een nieuwe, complexe uitdaging die wordt gevormd door de convergentie van drie krachtige factoren: de opkomst van geavanceerde, door AI aangedreven aanvalstechnieken; de adoptie van geautomatiseerde agent-georiënteerde architecturen zoals Agent-to-Agent (A2A) protocollen en Multi-Agent Control Panels (MCP); en een aanzienlijk verzwaard compliance-landschap, aangevoerd door regelgeving zoals de NIS2-richtlijn en de EU AI Act.¹

Deze convergentie creëert een omgeving waarin traditionele beveiligingsmodellen, gebaseerd op het detecteren van bekende signaturen en het bewaken van netwerkverkeer aan de rand, ontoereikend zijn. De dreigingen zijn niet langer alleen gericht op het compromitteren van systemen, maar op het manipuleren van de logica en het vertrouwen van de geautomatiseerde processen die de kern van de moderne onderneming vormen. Dit rapport presenteert geen lijst van geïsoleerde dreigingen, maar een geïntegreerde blauwdruk voor de transformatie van het Security Operations Center (SOC) en de onderliggende beveiligingsarchitectuur om deze nieuwe realiteit het hoofd te bieden. De strategie die hierin wordt uiteengezet, is gebaseerd op een proactieve, op identiteit gerichte en continu geverifieerde aanpak, essentieel voor overleving en veerkracht in het agentic tijdperk.⁴

1.2. Strategie

Om de organisatie succesvol door dit veranderende landschap te navigeren, moeten leiderschap en directie vier strategische imperatieven omarmen. Deze vormen de pijlers voor investeringen, beleid en operationele focus voor de komende jaren.

Imperatief 1: Omarm identiteit

De traditionele netwerkperimeter is vervaagd. De ware perimeter wordt nu gevormd door de identiteit van elke entiteit die toegang vraagt tot data of systemen, of dit nu een menselijke gebruiker, een IoT-apparaat, een microservice of een autonome AI-agent is. De explosieve groei van niet-menselijke identiteiten, met name binnen A2A- en MCP-frameworks, vereist een radicale verschuiving naar een Zero Trust-model. Dit model gaat uit van het principe “never trust, always verify” en dwingt af dat elke interactie, zonder uitzondering, expliciet wordt geauthenticeerd en geautoriseerd op basis van de minst benodigde privileges. Investeringen in geavanceerd Identity and Access Management (IAM) voor niet-menselijke identiteiten zijn niet langer optioneel, maar een fundamentele voorwaarde voor beveiliging.⁷

Imperatief 2: Investeer in AI-specifieke verdediging en monitoring

Standaard security-oplossingen zoals EDR en SIEM zijn grotendeels blind voor de nieuwe generatie AI-specifieke aanvallen. Dreigingen zoals datavergiftiging (data poisoning), modelontwijking (evasion attacks) en het stelen van modellen (model theft) opereren op een laag die voor deze tools onzichtbaar is. Effectieve verdediging vereist gespecialiseerde databronnen, zoals de logs van AI API’s en MCP-transacties, en nieuwe detectiemodellen die zijn getraind om afwijkend gedrag van AI-systemen zelf te herkennen. Het monitoren van de output en het gedrag van een model is even belangrijk geworden als het monitoren van netwerkverkeer.⁹

Imperatief 3: Operationaliseer AI governance

Voldoen aan de EU AI Act is geen papieren exercitie voor de juridische afdeling; het is een diepgaande technische en operationele uitdaging. De wet stelt strenge eisen aan de robuustheid, transparantie en traceerbaarheid van AI-systemen die als “hoog risico” worden geclassificeerd. Dit vertaalt zich direct naar technische controles die het SOC moet kunnen handhaven en auditen. Het vereist onveranderlijke (immutable) logging van alle beslissingen van het AI-systeem, een robuust risicomanagementproces voor de AI-levenscyclus en sterke cyberbeveiligings maatregelen om de integriteit van de modellen en data te waarborgen. AI governance moet worden geïntegreerd in de DevSecOps-pijplijn en de dagelijkse operaties van het SOC.¹²

Imperatief 4: Herdefinieer het SOC voor het agentic tijdperk

Het traditionele SOC, dat functioneert als een centrum voor het triageren van door mensen geanalyseerde alerts, is niet opgewassen tegen de snelheid en schaal van geautomatiseerde, AI-gedreven aanvallen. Het SOC van de toekomst moet zelf een agentic model omarmen. Het moet evolueren naar een orchestrator van geautomatiseerde detectie- en respons-agents, die opereren binnen een eigen, streng beveiligd Multi-Agent Control Panel. Deze transformatie stelt het SOC in staat om op machinesnelheid te reageren, menselijke analisten te focussen op proactieve threat hunting en strategische analyse, en de veerkracht van de organisatie significant te verhogen.⁴

1.3. 12-Maanden roadmap

De volgende roadmap biedt een gestructureerd plan om de organisatie binnen 12 maanden voor te bereiden op de uitdagingen van 2025. Het plan is opgedeeld in vier kwartalen, elk met een duidelijke focus.

Q1: Fundamentele Analyse & Governance

• Actie: Voer een gap-analyse uit van de huidige beveiligingsmaatregelen ten opzichte van de vereisten van de NIS2-richtlijn en de EU AI Act.
• Actie: Creëer een volledig inventaris van alle AI- en ML-systemen binnen de organisatie. Classificeer elk systeem op basis van het risiconiveau (minimaal, beperkt, hoog, onacceptabel) zoals gedefinieerd in de EU AI Act.
• Actie: Richt een formeel AI Governance Programma op, met vertegenwoordiging van Security, Legal, IT en de business, om beleid en controlemechanismen voor AI-gebruik te definiëren en te handhaven.¹⁶

Q2: Architectuur voor Zero Trus

• Actie: Start een pilotproject voor de implementatie van een Zero Trust-architectuur voor een kritieke A2A- of MCP-workflow. Focus op sterke, op certificaten gebaseerde identiteiten voor agents en microsegmentatie van de communicatiepaden.
• Actie: Implementeer en configureer een geavanceerde IAM-oplossing specifiek voor het beheer van de levenscyclus van niet-menselijke identiteiten, inclusief geautomatiseerde rotatie van credentials.

Q3: Verbetering van SOC-capaciteiten

• Actie: Integreer de logstromen van alle belangrijke AI-diensten (bv. Azure OpenAI, Google AI Platform) en interne MCP-platforms in het centrale SIEM-systeem. Zorg ervoor dat prompts, responses en metadata worden vastgelegd.
• Actie: Ontwikkel en test de eerste incident response playbooks voor AI-specifieke dreigingen, zoals datavergiftiging en API-misbruik door een malafide agent.

Q4: Automatisering & validatie

• Actie: Implementeer de eerste geautomatiseerde responsacties (SOAR) via een beveiligd intern SOC MCP. Voorbeelden zijn het automatisch isoleren van een host na detectie van AI-gegenereerde malware of het blokkeren van een API-sleutel na verdacht gebruik.
• Actie: Voer een red team-oefening uit die specifiek gericht is op het simuleren van aanvallen op de AI-infrastructuur, inclusief adversarial ML-technieken en pogingen om A2A-communicatie te compromitteren. Gebruik de resultaten om de detectie- en responsstrategieën verder aan te scherpen.

Deel II: Het dreigingslandschap van 2025

2.1. Inleiding van het dreigingslandschap

Artificiële intelligentie is een technologie met een duaal karakter: het biedt ongekende mogelijkheden voor verdedigers om dreigingen te detecteren en te neutraliseren, maar het bewapent tegelijkertijd aanvallers met krachtige nieuwe tools om aanvallen te schalen, te personaliseren en te verhullen. Het dreigingslandschap van 2025 wordt gekenmerkt door deze dualiteit. Om effectief te kunnen verdedigen, is een gestructureerd begrip van de methoden van de tegenstander essentieel.

Hiervoor zijn gestandaardiseerde raamwerken onmisbaar. Het MITRE ATT&CK®-framework biedt een uitgebreide kennisbank van tactieken, technieken en procedures (TTP’s) die door aanvallers worden gebruikt tegen traditionele IT-infrastructuren.¹⁷ Echter, met de opkomst van AI-systemen als primair doelwit, is ATT&CK alleen niet meer voldoende. Het MITRE ATLAS™-framework is specifiek ontwikkeld om de unieke aanvalsvectoren tegen AI- en machine learning-systemen te catalogiseren.⁹ Een holistische verdedigingsstrategie vereist een geïntegreerde visie die beide raamwerken combineert, omdat moderne aanvalsketens vaak TTP’s uit beide domeinen omvatten.²⁰

Table 1: Cyber threat intelligence

https://docs.google.com/spreadsheets/d/e/2PACX-1vSId8q9Kxb2-ms30F8oUmOppvMlEV2UbAO8-jcGeDfItKZsxUgqM3jBrIIlsE5JS2PjBOOzUyQeQDKO/pubhtml?gid=0&single=true

Tabel 2: Aanvalsmatrix (2025)

De volgende matrix biedt een gestructureerd overzicht van de 26 geïdentificeerde geavanceerde aanvalstypes. Deze tabel dient als het centrale referentiedocument voor de rest van dit rapport en verbindt elke aanval met zijn operationele kenmerken, detectievereisten en potentiële bedrijfsimpact.

https://docs.google.com/spreadsheets/d/e/2PACX-1vSId8q9Kxb2-ms30F8oUmOppvMlEV2UbAO8-jcGeDfItKZsxUgqM3jBrIIlsE5JS2PjBOOzUyQeQDKO/pubhtml?gid=1758752997&single=true

2.2. Adversarial Machine Learning (AML)

Adversarial Machine Learning (AML) vertegenwoordigt een klasse van aanvallen die specifiek gericht is op de inherente kwetsbaarheden van machine learning-algoritmes. In tegenstelling tot traditionele cyberaanvallen die softwarefouten exploiteren, misbruiken AML-technieken de wiskundige fundamenten van het model zelf. Deze aanvallen omzeilen vaak traditionele beveiligingsmaatregelen omdat de inputs niet “malicious” zijn in de klassieke zin; ze bevatten geen malware of exploit-code, maar zijn subtiel gemanipuleerd om het model te misleiden.¹¹ De MITRE ATLAS-matrix is het essentiële raamwerk om deze dreigingen te begrijpen en te categoriseren.⁹

De drie belangrijkste categorieën van AML-aanvallen zijn:

1. Evasion Attacks (Ontwijking): Dit is de meest voorkomende vorm van AML. De aanvaller creëert een “adversarial example” door een kleine, voor mensen vaak onzichtbare, verstoring toe te voegen aan een legitieme input. Deze verstoring is zorgvuldig berekend om het model te dwingen een incorrecte classificatie te maken. Een bekend voorbeeld is het veranderen van enkele pixels in een afbeelding van een stopbord, waardoor een autonoom voertuig het als een snelheidslimietbord interpreteert. Binnen de ATLAS-matrix valt dit onder de tactiek ML Attack Staging (AML.TA0012) en de techniek Craft Adversarial Data (AML.T0043).²⁴
2. Poisoning Attacks (Vergiftiging): Deze aanvallen vinden plaats tijdens de trainingsfase van een model. De aanvaller injecteert een kleine hoeveelheid kwaadaardige data in de trainingsset. Deze “vergiftigde” data kan het model trainen om specifieke, incorrecte beslissingen te nemen wanneer het een bepaalde trigger ziet, of het kan de algehele prestatie van het model degraderen. Dit is een supply chain-aanval op het AI-model zelf en wordt gecategoriseerd onder ML Attack Staging (AML.TA0012) en de techniek Poison Training Data (AML.T0033).²⁴
3. Model Inversion/Extraction Attacks (Modelinversie/extractie): Bij deze aanvallen probeert de tegenstander gevoelige informatie over de trainingsdata of de architectuur van het model zelf te achterhalen. Door de API van het model herhaaldelijk met specifieke queries te bevragen en de outputs te analyseren, kan een aanvaller proberen de trainingsdata te reconstrueren (inversion) of een functioneel equivalente kopie van het model te trainen (extraction). Dit valt onder de ATLAS-tactiek Exfiltration (AML.TA0013) en de technieken Infer Training Data (AML.T0045) en Extract ML Model (AML.T0038).²⁴

De verdediging tegen AML vereist een fundamenteel andere aanpak. Het gaat niet om het blokkeren van bekende slechte inputs, maar om het bouwen van robuustere modellen (bv. via adversarial training) en het monitoren van het gedrag en de prestaties van het model in productie om onverwachte degradatie of afwijkende beslissingspatronen te detecteren.

2.3. LLM Supply chain en data

De levenscyclus van een Large Language Model (LLM) is complex en biedt meerdere toegangspunten voor data Poisoning aanvallen. Deze aanvallen zijn bijzonder verraderlijk omdat de compromittering plaatsvindt vóórdat het model in productie wordt genomen, waardoor de kwetsbaarheid diep in de logica van het model is ingebed.²⁷ De aanvalsvector is niet een netwerkpakket of een malafide executable, maar de data die het model vormt.

De belangrijkste fasen en bijbehorende risico’s zijn:

• Pre-training Fase: LLM’s worden getraind op enorme datasets die van het internet zijn geschraapt. Aanvallers kunnen deze fase vergiftigen door op grote schaal malafide of bevooroordeelde content te publiceren op fora, blogs of in code repositories, in de hoop dat deze wordt opgenomen in de volgende trainingsset van een groot model.
• Fine-tuning Fase: Organisaties specialiseren vaak een basis-LLM voor een specifieke taak door het te fine-tunen op een kleinere, domeinspecifieke dataset. Deze dataset, hoewel kleiner, is een primair doelwit. Een aanvaller die erin slaagt om zelfs een klein aantal vergiftigde voorbeelden in deze set te injecteren, kan een “backdoor” creëren. Deze backdoor kan worden geactiveerd door een specifieke trigger-zin, waardoor het model een vooraf bepaalde, kwaadaardige actie uitvoert.²⁹
• Retrieval-Augmented Generation (RAG) Fase: Veel moderne LLM-applicaties gebruiken RAG, waarbij het model informatie ophaalt uit een externe kennisdatabase (vaak een vector database) om zijn antwoorden te onderbouwen. Als een aanvaller deze database kan compromitteren en vergiftigde documenten kan injecteren, zal het LLM deze onbetrouwbare informatie presenteren als een feitelijk, onderbouwd antwoord.

Een bijkomend risico is de “memory persistence” van agentic systemen. In tegenstelling tot stateless applicaties, onthouden deze agenten informatie over interacties heen. Een aanvaller kan een agent geleidelijk “vergiftigen” met misleidende informatie via meerdere, schijnbaar onschuldige interacties. Deze informatie wordt opgeslagen in het geheugen van de agent en kan zijn beslissingen in de toekomst subtiel beïnvloeden, een vorm van “low-and-slow” manipulatie die extreem moeilijk te detecteren is.²⁸

2.4. Convergentie van dreigingen

De analyse van het dreigingslandschap onthult twee fundamentele verschuivingen die de strategie voor cyberverdediging bepalen.

Ten eerste vervagen de grenzen tussen de traditionele en de AI-specifieke aanvalskaders. Een geavanceerde aanvalsketen is zelden beperkt tot alleen TTP’s uit MITRE ATT&CK of alleen uit MITRE ATLAS. In plaats daarvan zien we een hybride aanpak. Een aanval kan beginnen met een klassieke ATT&CK-techniek, zoals Phishing (T1566), om initiële toegang te verkrijgen. De payload die via deze phishing-e-mail wordt afgeleverd, is echter geen traditionele malware, maar een zorgvuldig geconstrueerd “adversarial example” (ATLAS-techniek AML.T0043). Dit voorbeeld is ontworpen om een AI-gebaseerd e-mailfilter of een andere interne beveiligingscontrole te omzeilen. Eenmaal binnen kan de aanvaller overgaan tot het vergiftigen van een productiemodel (ATLAS-techniek AML.T0033) om bedrijfsprocessen te saboteren. Een SOC dat zijn monitoring en threat modeling beperkt tot slechts één van deze raamwerken, zal de volledige context en het uiteindelijke doel van de aanval missen. Een geïntegreerde verdediging die detectiesignalen uit beide domeinen correleert, is daarom noodzakelijk.

Ten tweede transformeert de opkomst van A2A- en MCP-architecturen de aard van de aanvalsdoelen. Deze systemen, ontworpen voor automatisering en schaalbaarheid, introduceren een nieuw, uiterst waardevol doelwit: de orchestratielaag zelf.¹ Waar aanvallers zich traditioneel richtten op het compromitteren van een gebruiker of een server, verschuift de focus nu naar het compromitteren van de identiteit of de logica van een autonome agent. Het compromitteren van een enkele, hoog-geprivilegieerde agent of het MCP stelt een aanvaller in staat om kwaadaardige acties op machinesnelheid en -schaal te orkestreren, waarbij menselijke controlemechanismen volledig worden omzeild. Wanneer een aanvaller een malafide taak kan injecteren in een MCP, zal het panel deze taak plichtsgetrouw uitvoeren met de legitieme credentials van zijn ondergeschikte agents.⁴ Dit is een geavanceerde vorm van “Living off the Land”, die niet op het niveau van het besturingssysteem, maar op de logische orchestratielaag opereert. Dit verheft “API Abuse” van een tactische techniek tot een strategisch einddoel en maakt de beveiliging van de A2A/MCP-infrastructuur zelf tot een nieuwe, kritieke controlepijler.

Deel III: Zero Trust voor menselijke en machine-identiteiten

3.1. Fundamentele principes van Zero Trust 2025

De traditionele beveiligingsfilosofie, gebaseerd op een versterkte perimeter waarbinnen systemen en gebruikers impliciet worden vertrouwd, is obsoleet. De realiteit van cloud-computing, mobiel werken en nu ook autonome AI-agenten dwingt tot de adoptie van een Zero Trust-architectuur. Dit model is gebaseerd op een aantal fundamentele principes die de basis vormen voor een veerkrachtige en moderne verdediging.⁵

• Never Trust, Always Verify: Dit is het kernprincipe. Geen enkele gebruiker, apparaat, applicatie of agent wordt standaard vertrouwd, ongeacht zijn locatie (binnen of buiten het “oude” netwerk). Elke toegangsverzoek moet expliciet worden geverifieerd met behulp van alle beschikbare signalen, zoals identiteit, apparaatstatus, locatie en de gevoeligheid van de data.
• Assume Breach: De architectuur wordt ontworpen met de aanname dat een aanvaller al binnen het netwerk aanwezig is. Dit verlegt de focus van uitsluitend preventie aan de perimeter naar detectie en respons binnenin het netwerk. Het doel is om de laterale beweging van een aanvaller te beperken en de impact van een eventuele inbreuk (de “blast radius”) te minimaliseren.
• Least Privilege Access: Gebruikers en systemen krijgen alleen de minimaal benodigde rechten en toegang om hun specifieke taak uit te voeren. Dit principe wordt dynamisch en just-in-time toegepast, waarbij rechten alleen worden verleend voor de duur van een specifieke sessie of taak.

Deze principes evolueren van een netwerk-centrische toepassing (microsegmentatie) naar een identiteit-centrisch model. De identiteit – van mens, machine of AI-agent – is de nieuwe controlelaag. Een centrale, uniforme beleidsengine (Policy Enforcement Point) evalueert continu elke toegangsverzoek tegenover het gedefinieerde beleid, waardoor een dynamische en contextbewuste beveiliging ontstaat.⁶

3.2. Het beveiligen van het agentic ecosysteem: A2A en MCP architecturen

De principes van Zero Trust zijn direct en noodzakelijk toepasbaar op de opkomende architecturen voor AI-agenten. Deze systemen introduceren een nieuwe klasse van niet-menselijke identiteiten die op hoge snelheid en met grote autonomie opereren, waardoor traditionele, handmatige beveiligingscontroles onwerkbaar worden.

A2A Protocol Security

Het Agent-to-Agent (A2A) protocol standaardiseert de communicatie tussen autonome agents en bestaat uit drie hoofdfasen: Discovery, Authenticatie en Communicatie.³² Elke fase introduceert specifieke risico’s die met Zero Trust-controles moeten worden gemitigeerd.

• Discovery: Een client-agent ontdekt de capaciteiten en het endpoint van een remote-agent via een openbaar “Agent Card” (een JSON-bestand).

• Dreiging: Agent Card Poisoning. Een aanvaller kan de metadata in een Agent Card manipuleren om een client-agent te misleiden, bijvoorbeeld door een malafide skill te adverteren of door middel van prompt injection in de beschrijving.³⁴
• Zero Trust Controle: Strikte validatie en sanitization van alle metadata die uit een Agent Card wordt gelezen. De bron van de Agent Card moet cryptografisch worden geverifieerd.
• Authenticatie: De client-agent authenticeert zich bij de remote-agent, doorgaans via standaarden als OAuth 2.0 of OpenID Connect.³⁵

• Dreiging: Agent Impersonation. Een malafide agent doet zich voor als een legitieme agent door gestolen credentials (bv. een OAuth-token) te gebruiken.³³
• Zero Trust Controle: Implementeer sterke, op Public Key Infrastructure (PKI) gebaseerde identiteiten voor elke agent. Gebruik van workload-bound, kortlevende certificaten in plaats van langdurig geldige tokens of API-sleutels. Dit zorgt ervoor dat de identiteit van de agent onlosmakelijk verbonden is met de workload zelf en niet eenvoudig kan worden gestolen.⁷
• Communicatie: De agents wisselen taken en data uit via HTTPS en JSON-RPC.³⁶

• Dreiging: Task Replay en Man-in-the-Middle. Een aanvaller kan een legitiem taakverzoek onderscheppen en opnieuw afspelen, of de communicatie afluisteren en manipuleren.³⁷
• Zero Trust Controle: Dwing wederzijdse TLS (mTLS) af voor alle A2A-communicatie. Dit zorgt ervoor dat niet alleen de client de server verifieert, maar ook de server de identiteit van de client cryptografisch valideert. Elke transactie moet een unieke, niet-herbruikbare nonce bevatten om replay-aanvallen te voorkomen.

MCP Architectuur Security

Een Multi-Agent Control Panel (MCP) fungeert als de centrale orchestrator voor een vloot van AI-agenten. Het beheert de intelligente routering van taken, de integratie met externe tools en API’s, het governance-beleid en het statusbeheer (geheugen) van de agents.¹ Hoewel krachtig, vormt het MCP ook een gecentraliseerd punt van falen en een uiterst waardevol doelwit voor aanvallers.

• Dreiging: Malicious Plugin Registration. Een aanvaller registreert een kwaadaardige tool of plugin bij het MCP. Wanneer een agent deze tool aanroept, wordt de malafide code uitgevoerd met de rechten van de agent.
• Dreiging: Policy Bypass. Een aanvaller vindt een kwetsbaarheid in de governance-engine van het MCP om de toegangscontroles te omzeilen en een agent ongeautoriseerde acties te laten uitvoeren.
• Dreiging: State/Memory Manipulation. Een aanvaller manipuleert de opgeslagen staat of het geheugen van een agent via het MCP, waardoor de toekomstige beslissingen van de agent worden beïnvloed.

Zero Trust Controles voor MCP:

• Fine-Grained Access Control: Implementeer Attribute-Based Access Control (ABAC) in plaats van Role-Based Access Control (RBAC). Dit stelt het MCP in staat om toegangsbeslissingen te nemen op basis van een rijke context (bv. “Agent A mag tool B alleen aanroepen tijdens kantooruren voor taak C”), wat het principe van least privilege veel strikter afdwingt.¹
• Execution Sandboxing: Voer elke tool-aanroep of plugin-executie uit in een geïsoleerde, tijdelijke sandbox-omgeving (bv. een container). Dit beperkt de impact van een eventueel gecompromitteerde tool en voorkomt dat deze het onderliggende systeem of andere agents kan beïnvloeden.³⁸
• Immutable Audit Logs: Zorg ervoor dat elke beslissing die door het MCP wordt genomen – elke taakroutering, elke tool-aanroep, elke beleidsevaluatie – wordt vastgelegd in een onveranderlijk (immutable) auditlog. Dit is cruciaal voor forensische analyse en het detecteren van afwijkend gedrag.¹⁰

3.3. Architecturale imperatieven

De analyse van deze nieuwe architecturen leidt tot twee strategische conclusies die de toekomstige richting van beveiligingsoperaties en -investeringen bepalen.

Ten eerste is er een duidelijke convergentie zichtbaar tussen de architectuur van een Multi-Agent Control Panel en die van een traditioneel SOAR-platform (Security Orchestration, Automation, and Response). Een MCP, zoals beschreven voor het aansturen van business-agents, routeert taken naar gespecialiseerde agents op basis van de intentie van het verzoek.⁴ Een SOAR-platform doet conceptueel hetzelfde: het routeert alerts naar geautomatiseerde playbooks op basis van het type alert. Dit betekent dat een modern SOC niet alleen moet leren hoe het zich moet verdedigen tegen kwaadaardige MCP’s, maar ook zijn eigen veilige, interne MCP moet bouwen om een nieuwe generatie van AI-gedreven verdedigings-agents te orkestreren. Een security-incident wordt dan een “taak” die door het SOC-MCP wordt ontvangen en gerouteerd naar gespecialiseerde security-agents voor threat intelligence-verrijking, log-analyse of containment-acties. De principes voor het beveiligen van een business-MCP zijn dus direct van toepassing op het bouwen van een veerkrachtig, geautomatiseerd SOC van de volgende generatie.

Ten tweede wordt een robuuste Public Key Infrastructure (PKI) een fundamentele, kritieke controle voor het beveiligen van AI. De opkomst van kortlevende, autonome agenten maakt traditioneel beheer van credentials, zoals statische API-sleutels, onhoudbaar en onveilig.⁴⁰ Een Zero Trust-model in een dergelijke dynamische omgeving kan alleen worden gerealiseerd als elke agent een sterke, unieke en kortlevende identiteit heeft. Een moderne, geautomatiseerde PKI, die in staat is om op aanvraag workload-bound certificaten uit te geven (zoals via het SPIFFE/SPIRE-model), is de enige schaalbare oplossing.⁷ Deze certificaten dienen niet alleen voor de authenticatie van elke A2A-transactie, maar maken ook de oprichting van versleutelde mTLS-kanalen mogelijk, wat vertrouwelijkheid en integriteit garandeert. Investeringen in een moderne PKI zijn daarom geen optionele verbetering meer, maar een absolute voorwaarde voor de veilige inzet van agentic AI-systemen.

Deel IV: Het proactieve SOC

4.1. Geavanceerde Detectie-Engineering

De verschuiving naar AI-gedreven en agentic aanvallen vereist een parallelle evolutie in de detectiestrategieën van het SOC. Detectie gebaseerd op bekende, statische signaturen verliest aan effectiviteit tegen polymorfe malware en subtiele, gedragsmatige aanvallen. De focus moet verschuiven naar het detecteren van afwijkingen van een normale baseline (anomaliedetectie) en het herkennen van patronen die wijzen op kwaadaardige TTP’s (gedragsanalyse).⁴¹ Dit is alleen mogelijk door de juiste databronnen te verzamelen en te analyseren.

Bronnen

Een effectieve detectiestrategie voor het landschap van 2025 is afhankelijk van de integratie van zowel traditionele als nieuwe, AI-specifieke logbronnen:

• Cloud Provider Audit Logs: Dit blijft de fundamentele bron voor het detecteren van ongeautoriseerde wijzigingen in de infrastructuur, IAM-manipulatie en verdacht API-gebruik. Diensten zoals Google Cloud Audit Logs en Azure Diagnostics zijn essentieel voor het monitoren van de controlelaag van de cloud-omgeving.⁴⁴
• AI Service Logs: Dit is een relatief nieuwe, maar cruciale categorie. Logs van diensten zoals Azure OpenAI (RequestResponseLog) bieden directe zichtbaarheid in de interacties met LLM’s. Ze bevatten de prompts, de gegenereerde responses, token-gebruik en de uitkomsten van content-filtering. Deze logs zijn de primaire bron voor het detecteren van prompt injection, data-exfiltratie via LLM’s en misbruik van de AI-dienst.⁴⁷
• A2A/MCP Logs: Dit is een nieuwe, verplichte logbron die vaak nog niet standaard bestaat. Organisaties moeten afdwingen dat hun interne A2A- en MCP-frameworks gedetailleerde, gestructureerde auditlogs produceren van elke belangrijke gebeurtenis. Dit omvat agent-registraties, taakverzoeken, tool-aanroepen met parameters, en de uiteindelijke respons van de agent. Zonder deze logs is het onmogelijk om de acties van autonome agenten te traceren en te beveiligen.³⁹
• Endpoint- en Netwerkdata (EDR/NDR): Traditionele bronnen blijven relevant voor het correleren van activiteit op de hogere, logische lagen (zoals een A2A-aanroep) met concrete gebeurtenissen op hosts en in het netwerk (zoals het starten van een proces of het openen van een netwerkverbinding).

Tabel 3: SOC detectie & mitigatie matrix

Het beproefde incident response-levenscyclusmodel van NIST – Preparation, Detection & Analysis, Containment, Eradication & Recovery, en Post-Incident Activity – blijft relevant, maar de invulling van elke fase moet worden aangepast aan de specifieke kenmerken van AI-incidenten.⁵³

• Preparation: Deze fase wordt uitgebreid met nieuwe elementen. Naast traditionele assets moeten organisaties een inventaris bijhouden van al hun AI-modellen, de datasets waarop ze zijn getraind (data provenance), en de tools waartoe ze toegang hebben. Er moeten vooraf goedgekeurde “kill switches” worden ontwikkeld om autonome agenten onmiddellijk te kunnen deactiveren in geval van een incident.⁵⁶
• Detection & Analysis: De analysefase wordt complexer. Analisten moeten kunnen differentiëren tussen een traditionele compromittering (bv. de server waarop het model draait is gehackt) en een modelgedragscompromittering (bv. het model zelf is vergiftigd en produceert kwaadaardige output). Dit vereist nieuwe vaardigheden en diagnostische tools.
• Containment, Eradication & Recovery: De acties in deze fase veranderen drastisch.

• Containment: Kan inhouden dat een gecompromitteerde agent wordt geïsoleerd, zijn credentials onmiddellijk worden ingetrokken, of dat het verkeer wordt omgeleid naar een “schoon” back-up model.
• Eradication: Is niet langer het verwijderen van malware, maar kan betekenen dat een model moet worden teruggerold naar een eerdere, niet-vergiftigde versie, of dat de corrupte data uit een RAG-database moet worden gezuiverd.
• Recovery: Betekent vaak het initiëren van een volledige hertrainingscyclus van het model met een opgeschoonde dataset.

https://docs.google.com/spreadsheets/d/e/2PACX-1vSId8q9Kxb2-ms30F8oUmOppvMlEV2UbAO8-jcGeDfItKZsxUgqM3jBrIIlsE5JS2PjBOOzUyQeQDKO/pubhtml?gid=137605728&single=true

Gedetailleerde IR Playbooks (Top 5 Dreigingen)

1. Cloud Account Takeover (ATO) via API Abuse: Stappen omvatten het identificeren van de gecompromitteerde credential, het analyseren van cloud audit logs (bv. CloudTrail, Azure Audit) op laterale beweging en ongebruikelijke API-aanroepen, het onmiddellijk roteren van alle getroffen secrets, en het implementeren van strengere IP-whitelisting voor de API.
2. AI-Powered Phishing & BEC 3.0: Triageproces omvat analyse van e-mailheaders en -content met tools die specifiek getraind zijn om AI-gegenereerde tekst te herkennen. Respons omvat een organisatiebrede wachtwoordreset en een gerichte bewustwordingscampagne over de nieuwe generatie phishing.
3. Adversarial ML Evasion Attack: Detectie begint met een alert over een plotselinge daling in de prestaties van een specifiek model (bv. een fraudedetectiesysteem mist plotseling veel meer gevallen). Analyse richt zich op het correleren van deze daling met specifieke inputpatronen. Containment is het tijdelijk blokkeren van de bron van de verdachte inputs. Eradicatie vereist dat het model wordt hertraind met technieken als “defensive distillation” om het robuuster te maken tegen de waargenomen aanval.
4. LLM Data Poisoning: Dit is een complex, multi-team playbook. Na detectie (vaak door onverwacht, bevooroordeeld of kwaadaardig gedrag van het model) moet het MLOps-team worden ingeschakeld. Samen met het security-team wordt de vergiftigde data in de trainings- of RAG-set geïdentificeerd. Het model wordt offline gehaald (containment). De data wordt opgeschoond en een volledige hertrainings- en validatiecyclus wordt gestart (eradication & recovery). Post-incident analyse focust op het versterken van de data-inname- en validatiepijplijn.
5. Ransomware-as-a-Service (RaaS) 2.0: Dit playbook bouwt voort op standaard ransomware-respons (isoleren, back-ups herstellen, etc.), maar voegt specifieke stappen toe voor het analyseren van EDR- en NDR-data op tekenen van AI-gestuurde laterale beweging, die veel sneller en onvoorspelbaarder kan zijn dan menselijke aanvallers.

4.3. Het evoluerende SOC

De operationele realiteit van het verdedigen tegen deze dreigingen leidt tot twee onvermijdelijke conclusies over de evolutie van het SOC.

Ten eerste, logbronnen worden een productvereiste. Voor het effectief monitoren van A2A- en MCP-systemen volstaan standaard OS- of netwerklogs niet. De interacties – de intentie van een taak, de gebruikte parameters, de uitkomst – zijn applicatie-laag gebeurtenissen die alleen door het framework zelf kunnen worden gelogd.¹ Dit betekent dat het SOC niet langer passief logdata kan consumeren; het moet proactief logging-specificaties definiëren en deze als een niet-onderhandelbare eis opleggen aan de ontwikkelteams die agentic applicaties bouwen. De beveiligingseisen van het SOC worden zo een drijvende kracht achter de architectuur en features van interne applicaties. De SOC-analist moet kunnen zien welke agent welke tool heeft aangeroepen met welke data, en dat kan alleen als de ontwikkelaar die log-hook heeft ingebouwd.⁵¹

Ten tweede, incident response wordt MLOps. De respons op een aanval als datavergiftiging of modelontwijking is geen traditionele SecOps-activiteit. Het vereist een diepe, operationele samenwerking tussen het SOC, datawetenschappers en ML-engineers.⁵⁸ De “eradicatie”-stap is niet het verwijderen van een virus, maar het hertrainen van een neuraal netwerk. De “recovery”-stap is het veilig uitrollen van dit nieuwe model via een MLOps-pijplijn. Dit dwingt de fusie van SecOps- en MLOps-teams, -processen en -tooling. Een incident met een AI-model kan niet worden opgelost zonder de expertise van degenen die het model hebben gebouwd en onderhouden, wat leidt tot de creatie van geïntegreerde, cross-functionele responsteams.²⁵

Deel V: Governance, Risk, and Compliance (GRC)

5.1. Vertaling van regelgevende mandaten naar technische controles

Een robuuste beveiligingsstrategie moet niet alleen technisch effectief zijn, maar ook aantoonbaar voldoen aan de geldende wettelijke en regelgevende kaders. Voor organisaties die in Europa opereren, zijn de GDPR, de NIS2-richtlijn en de EU AI Act de belangrijkste pijlers. Dit gedeelte vertaalt de juridische vereisten van deze regelgeving naar concrete, implementeerbare technische en procedurele controles.

• GDPR (General Data Protection Regulation): De focus ligt op Artikel 32 (Beveiliging van de verwerking), Artikel 33 (Melding van een inbreuk in verband met persoonsgegevens aan de toezichthoudende autoriteit) en Artikel 34 (Mededeling van een inbreuk in verband met persoonsgegevens aan de betrokkene). Aanvallen zoals Cloud ATO, RaaS 2.0 en datavergiftiging (indien persoonsgegevens worden gebruikt voor training) vormen per definitie een datalek onder de GDPR. De strikte meldplicht van 72 uur na kennisname vereist een zeer efficiënt detectie- en analyseproces.⁵⁹ Controles zoals sterke encryptie, toegangsbeheer en regelmatige tests zijn directe vereisten uit Artikel 32.
• NIS2-richtlijn: Artikel 21 legt een brede zorgplicht op aan essentiële en belangrijke entiteiten om passende en evenredige technische, operationele en organisatorische maatregelen te nemen om de risico’s voor de beveiliging van netwerk- en informatiesystemen te beheersen. De richtlijnen van ENISA concretiseren dit. Belangrijke domeinen zijn incidentbehandeling, beveiliging van de toeleveringsketen (supply chain), en toegangsbeheer.² Dit vertaalt zich naar de noodzaak van gedocumenteerde IR-plannen, het uitvoeren van security assessments van leveranciers (ook van data en AI-modellen), en het implementeren van multi-factor authenticatie (MFA) voor alle toegang, met name voor geprivilegieerde accounts.⁶⁴
• EU AI Act: Deze wetgeving introduceert specifieke, dwingende eisen voor AI-systemen die als “hoog risico” zijn geclassificeerd. De belangrijkste technische vereisten zijn te vinden in Artikel 15 (Nauwkeurigheid, robuustheid en cyberbeveiliging) en Artikel 12 (Logboekregistratie). Artikel 15 vereist dat AI-systemen veerkrachtig zijn tegen pogingen om hun gedrag te veranderen, inclusief AML-aanvallen. Artikel 12 mandateert de automatische en onveranderlijke registratie van gebeurtenissen (“logs”) gedurende de levensduur van het AI-systeem, om traceerbaarheid van de werking en beslissingen te garanderen. Dit maakt gedetailleerde AI-logging een wettelijke verplichting.³

Tabel 3: Compliance mapping

Deze tabel biedt een directe en auditeerbare koppeling tussen de voorgestelde beveiligingscontroles in dit rapport en de specifieke artikelen uit de relevante regelgeving. Het stelt compliance-teams in staat om de technische strategie te valideren en helpt de CISO om due diligence aan te tonen.

5.2. Risicoregister

Een gestructureerd risicobeheerproces is essentieel om de inspanningen en middelen te richten op de meest significante dreigingen. Het volgende register biedt een raamwerk voor het scoren en prioriteren van de geïdentificeerde aanvallen.

Tabel 4: Hoog-Niveau Risicoregister

5.3. De Toekomst van GRC

De integratie van AI en de nieuwe regelgevingskaders forceren een fundamentele herijking van de GRC-functie.

Ten eerste wordt “Compliance by Design” voor AI een technische realiteit. De vereisten van de EU AI Act voor logboekregistratie, robuustheid en traceerbaarheid zijn geen zaken die na de implementatie kunnen worden gecontroleerd en afgevinkt.³ Ze moeten vanaf de eerste dag worden ingebouwd in de architectuur van het AI-systeem en de MLOps-pijplijn. De eis voor automatische, onveranderlijke logging (Artikel 12) betekent dat de logica voor het vastleggen van data-afkomst, modelversie, input en de resulterende beslissing deel moet uitmaken van de kernapplicatie.⁶⁷ Dit maakt het security-architectuurteam en het DevSecOps-team direct verantwoordelijk voor compliance-uitkomsten. De vereisten van de compliance-afdeling moeten worden vertaald naar concrete technische specificaties voor ontwikkelaars in de ontwerpfase. Het achteraf proberen toe te voegen van deze functionaliteit is technisch complex, kostbaar en vaak onmogelijk. Compliance is hiermee definitief “naar links verschoven” in de ontwikkeling levenscyclus.

Ten tweede breidt het risico in de toeleveringsketen zich uit naar data en modellen. De NIS2-richtlijn legt een sterke nadruk op de beveiliging van de ICT-toeleveringsketen.⁶³ Voor AI-systemen omvat deze keten veel meer dan alleen softwareleveranciers. De “leveranciers” zijn nu ook open-source modellen van platforms zoals Hugging Face, vooraf getrainde modelgewichten, en datasets die worden aangekocht bij databrokers. Elk van deze componenten kan een vector zijn voor een aanval, zoals datavergiftiging.²⁷ Het doorlichten van deze nieuwe categorie “leveranciers” is een kritieke, en vaak nog onvervulde, GRC-uitdaging. GRC-processen moeten worden uitgebreid om due diligence uit te voeren op data- en model leveranciers, met dezelfde nauwgezetheid als bij traditionele softwareleveranciers. Dit omvat het controleren van de herkomst (provenance), de documentatie, de methodologie voor dataverzameling en eventuele bekende kwetsbaarheden of vooroordelen in de modellen en datasets.

Dreigingsprofielen Cyberaanvallen in het AI-tijdperk

1. Dreigingsprofiel: AI-Powered Phishing (A25-01)

Waar AI-phishing tekst gebruikt om te misleiden, gaat de volgende aanval nog een stap verder door onze zintuigen te manipuleren met behulp van AI-gegenereerde video en audio.

2. Dreigingsprofiel: Deepfake Social Engineering (A25-11)

De vorige aanvallen richten zich op het manipuleren van mensen, maar wat als aanvallers de AI-systemen zelf kunnen corrumperen voordat ze überhaupt worden gebruikt?

3. Dreigingsprofiel: Data Poisoning (A25-14)

De kern van de nieuwe dreigingen.

Deze dreigingsprofielen tonen een fundamentele verschuiving in het cyberlandschap. Moderne AI-aanvallen zijn niet langer alleen gericht op het binnendringen van systemen, maar focussen zich op het manipuleren van de logica en het vertrouwen van zowel geautomatiseerde processen als de mensen die ze gebruiken. Dit vormt de kern van de uitdaging voor de cyberbeveiliging in het AI-tijdperk.

Geciteerd werk

1. MCP for AI Agents: Enabling Modular, Scalable Agentic Systems | Unleash.so, geopend op september 24, 2025, https://www.unleash.so/post/model-control-plane-mcp-for-ai-agents-enabling-modular-scalable-agentic-systems
2. EU: ENISA Guidelines on Compliance with NIS 2 Directive Published | Privacy Matters, geopend op september 24, 2025, https://privacymatters.dlapiper.com/2025/08/eu-enisa-guidelines-on-compliance-with-nis-2-directive-published/
3. AI Act | Shaping Europe’s digital future – European Union, geopend op september 24, 2025, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
4. Designing Multi-Agent Intelligence – Microsoft for Developers, geopend op september 24, 2025, https://developer.microsoft.com/blog/designing-multi-agent-intelligence
5. What Is Zero Trust Architecture? Key Elements and Use Cases – Palo Alto Networks, geopend op september 24, 2025, https://www.paloaltonetworks.com/cyberpedia/what-is-a-zero-trust-architecture
6. Strengthening AI agent security with identity management – Accenture, geopend op september 24, 2025, https://www.accenture.com/us-en/blogs/security/strengthening-ai-agent-security-identity-management
7. Zero Trust for Agentic AI Security | Keyfactor, geopend op september 24, 2025, https://www.keyfactor.com/solutions/secure-ai-agents/
8. Zero Trust Strategy & Architecture | Microsoft Security, geopend op september 24, 2025, https://www.microsoft.com/en-us/security/business/zero-trust
9. mitre atlas – PointGuard AI, geopend op september 24, 2025, https://www.pointguardai.com/glossary/mitre-atlas
10. MCP vs MoCoP: Why your AI security is screwed if you only have one, geopend op september 24, 2025, https://www.sumologic.com/blog/mcp-vs-mcp2
11. What Are Adversarial AI Attacks on Machine Learning? – Palo Alto Networks, geopend op september 24, 2025, https://www.paloaltonetworks.com/cyberpedia/what-are-adversarial-attacks-on-AI-Machine-Learning
12. What to Know About the EU AI Code of Practice | Schellman, geopend op september 24, 2025, https://www.schellman.com/blog/ai-services/the-eu-ai-code-of-practice
13. EU AI Act – Credo AI, geopend op september 24, 2025, https://www.credo.ai/eu-ai-act
14. EU AI Act: Implications for Log Management Systems and … – Logdy, geopend op september 24, 2025, https://logdy.dev/blog/post/eu-ai-act-implications-for-log-management-systems-and-compliance
15. Implementing Multi-Agent Systems Using MCP: A Guide for AI Architects | Blog – Codiste, geopend op september 24, 2025, https://www.codiste.com/multi-agent-ai-systems-mcp-implementation
16. LLM Security Frameworks: A CISO’s Guide to ISO, NIST & Emerging AI Regulation – Hacken, geopend op september 24, 2025, https://hacken.io/discover/llm-security-frameworks/
17. MITRE ATT&CK®, geopend op september 24, 2025, https://attack.mitre.org/
18. Quick Guide to the MITRE ATT&CK Framework for Security… – Abnormal AI, geopend op september 24, 2025, https://abnormal.ai/blog/mitre-attck-framework
19. Why MITRE ATLAS is a Game-Changer for Adversarial Machine Learning | by Rohit Ranjan | Sep, 2025 | Medium – Cubed, geopend op september 24, 2025, https://blog.cubed.run/why-mitre-atlas-is-a-game-changer-for-adversarial-machine-learning-a5d2c707f417
20. MITRE ATT&CK AI Classification in ThreatConnect, geopend op september 24, 2025, https://knowledge.threatconnect.com/docs/mitre-attack-ai-classification-in-threatconnect
21. Rule-ATT&CK Mapper (RAM): Mapping SIEM Rules to TTPs Using LLMs – arXiv, geopend op september 24, 2025, https://arxiv.org/html/2502.02337v1
22. What is the MITRE ATT&CK framework? – eSentire, geopend op september 24, 2025, https://www.esentire.com/cybersecurity-fundamentals-defined/glossary/what-is-the-mitre-att-ck-framework
23. MITRE ATLAS™, geopend op september 24, 2025, https://atlas.mitre.org/
24. Understanding the MITRE ATLAS Matrix: How Attackers Target AI Systems – Medium, geopend op september 24, 2025, https://medium.com/bluetuple-ai/understanding-the-mitre-atlas-matrix-how-attackers-target-ai-systems-ecb75399819f
25. Adversarial Machine Learning: Defense Strategies – neptune.ai, geopend op september 24, 2025, https://neptune.ai/blog/adversarial-machine-learning-defense-strategies
26. FRAME : Comprehensive Risk Assessment Framework for Adversarial Machine Learning Threats – arXiv, geopend op september 24, 2025, https://arxiv.org/html/2508.17405v1
27. Multi-Faceted Studies on Data Poisoning can Advance LLM Development – arXiv, geopend op september 24, 2025, https://arxiv.org/html/2502.14182v1
28. Securing Agentic AI: A Comprehensive Threat Model and Mitigation Framework for Generative AI Agents – arXiv, geopend op september 24, 2025, https://arxiv.org/pdf/2504.19956
29. Learning to Poison Large Language Models for Downstream Manipulation – arXiv, geopend op september 24, 2025, https://arxiv.org/html/2402.13459v3
30. A Linear Approach to Data Poisoning – arXiv, geopend op september 24, 2025, https://arxiv.org/pdf/2505.15175
31. Keeping an Eye on LLM Unlearning: The Hidden Risk and Remedy – arXiv, geopend op september 24, 2025, https://arxiv.org/pdf/2506.00359
32. What is A2A protocol (Agent2Agent)? – IBM, geopend op september 24, 2025, https://www.ibm.com/think/topics/agent2agent-protocol
33. Practical Examples on How MCP and A2A Protocols Defend Against AI Agent Security Threats – Non-Human Identity Management Group, geopend op september 24, 2025, https://nhimg.org/community/agentic-ai-and-nhis/practical-examples-on-how-mcp-and-a2a-protocols-defend-against-ai-agent-security-threats/
34. Safeguarding AI Agents: An In-Depth Look at A2A Protocol Risks and Mitigations – LIVEcommunity, geopend op september 24, 2025, https://live.paloaltonetworks.com/t5/community-blogs/safeguarding-ai-agents-an-in-depth-look-at-a2a-protocol-risks/ba-p/1235996
35. How to enhance Agent2Agent (A2A) security | Red Hat Developer, geopend op september 24, 2025, https://developers.redhat.com/articles/2025/08/19/how-enhance-agent2agent-security
36. Getting Started with Agent2Agent (A2A) Protocol: A Purchasing Concierge and Remote Seller Agent Interactions on Cloud Run and Agent Engine | Google Codelabs, geopend op september 24, 2025, https://codelabs.developers.google.com/intro-a2a-purchasing-concierge
37. Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms in Multi-Agent Systems – arXiv, geopend op september 24, 2025, https://arxiv.org/html/2505.12490v3
38. rinadelph/Agent-MCP: Agent-MCP is a framework for creating multi-agent systems that enables coordinated, efficient AI collaboration through the Model Context Protocol (MCP). The system is designed for developers building AI applications that benefit from multiple specialized agents working in parallel on different aspects of a project. – GitHub, geopend op september 24, 2025, https://github.com/rinadelph/Agent-MCP
39. Non-Human AI Security: A Comprehensive Guide to Managing Non-Human Identities and Secrets Management – Flowgrammer, geopend op september 24, 2025, https://flowgrammer.ca/non-human-ai-security-guide/
40. Prompts as Code & Embedded Keys | The Hunt for LLM-Enabled Malware | SentinelOne, geopend op september 24, 2025, https://www.sentinelone.com/labs/prompts-as-code-embedded-keys-the-hunt-for-llm-enabled-malware/
41. Splunk SIEM: Key Features, Limitations and Alternatives – Exabeam, geopend op september 24, 2025, https://www.exabeam.com/explainers/splunk/splunk-siem-key-features-limitations-and-alternatives/
42. What Is Anomaly Detection? Examples, Techniques & Solutions – Splunk, geopend op september 24, 2025, https://www.splunk.com/en_us/blog/learn/anomaly-detection.html
43. Detecting Anomalies using Machine Learning on Splunk – SideChannel – Tempest, geopend op september 24, 2025, https://www.sidechannel.blog/en/detecting-anomalies-using-machine-learning-on-splunk/
44. Cloud Audit Logs overview – Google Cloud, geopend op september 24, 2025, https://cloud.google.com/logging/docs/audit
45. Detect suspicious activity in GCP using audit logs – Sysdig, geopend op september 24, 2025, https://www.sysdig.com/blog/suspicious-activity-gcp-audit-logs
46. Artificial authentication: Understanding and observing Azure OpenAI abuse – Red Canary, geopend op september 24, 2025, https://redcanary.com/blog/threat-detection/azure-openai-abuse/
47. How Can I check error log with Azure Open Ai services – Microsoft Learn, geopend op september 24, 2025, https://learn.microsoft.com/en-us/answers/questions/2103257/how-can-i-check-error-log-with-azure-open-ai-servi
48. Implement Advanced Monitoring for Azure OpenAI Through a Gateway – Microsoft Learn, geopend op september 24, 2025, https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/azure-openai-gateway-monitoring
49. Azure OpenAI Integration – Elastic, geopend op september 24, 2025, https://www.elastic.co/docs/reference/integrations/azure_openai
50. Enable Diagnostic Logs for OpenAI Service Instances – Trend Micro, geopend op september 24, 2025, https://www.trendmicro.com/cloudoneconformity/knowledge-base/azure/AIServices/enable-diagnostic-logs.html
51. A2A Protocol Configuration Best Practices | Expert Guide – BytePlus, geopend op september 24, 2025, https://www.byteplus.com/en/topic/551220
52. Best practices for deploying multi-agent AI systems with distributed execution? – Reddit, geopend op september 24, 2025, https://www.reddit.com/r/AI_Agents/comments/1mhi8xp/best_practices_for_deploying_multiagent_ai/
53. NIST Incident Response Guide: Lifecycle, Best Practices & Recovery – AuditBoard, geopend op september 24, 2025, https://auditboard.com/blog/nist-incident-response
54. NIST Incident Response: 4-Step Life Cycle, Templates and Tips – Cynet, geopend op september 24, 2025, https://www.cynet.com/incident-response/nist-incident-response/
55. Incident Response Plan: Frameworks and Steps – CrowdStrike, geopend op september 24, 2025, https://www.crowdstrike.com/en-us/cybersecurity-101/incident-response/incident-response-steps/
56. NIST Releases Control Overlays for Securing AI Systems Concept Paper August 14, 2025, geopend op september 24, 2025, https://csrc.nist.gov/News/2025/control-overlays-for-securing-ai-systems
57. Incident Response in a AI Hybrid World – AFCEA International, geopend op september 24, 2025, https://events.afcea.org/Augusta24/Custom/Handout/Speaker0_Session10919_1.pdf
58. Incident response for AI&ML Threats – Playbooks, geopend op september 24, 2025, https://playbooks.flexibleir.com/playbook-incident-response-for-aiml-threats/
59. Art. 33 GDPR – Notification of a personal data breach to the supervisory authority, geopend op september 24, 2025, https://gdpr-info.eu/art-33-gdpr/
60. Art. 34 GDPR – Communication of a personal data breach to the data subject – General Data Protection Regulation (GDPR), geopend op september 24, 2025, https://gdpr-info.eu/art-34-gdpr/
61. Personal data breaches: a guide | ICO – Information Commissioner’s Office, geopend op september 24, 2025, https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/
62. What is GDPR, the EU’s new data protection law?, geopend op september 24, 2025, https://gdpr.eu/what-is-gdpr/
63. Decoding the NIS2 Directive: Practical guidelines from the EU Agency for Cybersecurity on NIS2 risk management and skills – CMS LawNow, geopend op september 24, 2025, https://cms-lawnow.com/en/ealerts/2025/08/decoding-the-nis2-directive-practical-guidelines-from-the-eu-agency-for-cybersecurity-on-nis2-risk-management-and-skills
64. Understanding NIS2 MFA Requirements With ENISA Guidance – Rublon, geopend op september 24, 2025, https://rublon.com/blog/nis2-mfa-requirements-enisa-guidance/
65. NIS2 Implementing Regulation: Essential Compliance Strategies For 2025, geopend op september 24, 2025, https://www.blazeinfosec.com/post/nis2-implementing-regulation/
66. NIS2 Technical Implementation Guidance | ENISA, geopend op september 24, 2025, https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
67. Article 19: Automatically Generated Logs | EU Artificial Intelligence Act, geopend op september 24, 2025, https://artificialintelligenceact.eu/article/19/
68. Good practices for supply chain cybersecurity – ENISA, geopend op september 24, 2025, https://www.enisa.europa.eu/sites/default/files/publications/Good%20Practices%20for%20Supply%20Chain%20Cybersecurity.pdf