Certificeren van spoken: waarom AI-security agents de CRA breken

Een CE-markering onder de Cyber Resilience Act (CRA) is binnenkort een papieren tijger. Je haalt het keurmerk op 1 december 2027, je product voldoet aan alle eisen, en de volgende ochtend is het certificaat feitelijk verlopen. Niet omdat de regels zijn veranderd, maar omdat je eigen AI-security agent het product heeft aangepast zonder dat jij het doorhad.

Dat is de kern van het paper Certifying Ghosts: How Cybersecurity AI Agents Break the EU Cyber Resilience Act dat deze week op arXiv verscheen. De auteurs laten zien dat autonome security agents, AI-gestuurde SOC-tools die zelfstandig configuraties wijzigen, patches uitrollen of netwerksegmentatie aanpassen, het statische certificeringsmodel van de CRA onderuit halen. Het certificaat dekt de toestand van het product op het moment van keuring, maar niet de continue stroom van aanpassingen die een AI-agent daarna doorvoert.

Wat het paper aantoont

De onderzoekers bouwden een testopstelling met een IoT-gateway die voldeed aan de essentiële cybersecurity-eisen van de CRA. Het apparaat kreeg een certificaat op basis van een vastgestelde configuratie: specifieke firewallregels, een afgesloten debug-interface, versleutelde communicatie. Vervolgens koppelden ze een AI-security agent aan de gateway, een agent die autonoom bedreigingen detecteert en mitigeert.

Binnen 48 uur had de agent de firewallregels aangepast om een vermeende aanval te blokkeren. De aanpassing was legitiem vanuit security-oogpunt, maar introduceerde een nieuwe open poort voor beheerdoeleinden. Het certificaat wist van niets. De gateway was nog steeds voorzien van een CE-markering, maar voldeed niet meer aan de oorspronkelijke certificeringseisen.

De paper beschrijft dit als een ghost modification: een wijziging die niet is vastgelegd in de certificeringsdocumentatie, niet is getoetst door een notified body, en niet is gemeld bij de fabrikant. De AI-agent handelde binnen zijn mandaat, maar creëerde een niet-gedocumenteerde staat van het product. Daarmee is het certificaat een papieren werkelijkheid geworden.

Wat ik zie in de praktijk

Laatst zat ik met een Nederlandse robotica-bouwer die volop bezig is met CRA-compliance. Hun collaboratieve robotarm krijgt een CE-markering op basis van een vastgelegde softwarestack: ROS 2 Humble, een specifieke set nodes, een afgesloten firewallconfiguratie. Tegelijkertijd draait er een AI-agent die realtime netwerkverkeer analyseert en automatisch iptables-regels aanpast bij verdacht gedrag.

Ik vroeg: “Wat gebeurt er als die agent een regel toevoegt die de certificeringstoestand wijzigt?” Stilte. De agent was niet meegenomen in de certificeringsscope, want “het is een beveiligingstool, geen onderdeel van het product”. Maar onder de CRA is elke substantiële wijziging, ook door een AI-agent, een nieuwe conformiteitsbeoordeling waard. Artikel 3(22) definieert een substantiële wijziging als een verandering die de conformiteit van het product met de essentiële eisen kan beïnvloeden. Een extra open poort valt daar zeker onder.

Dit is geen theoretisch risico. De paper toont aan dat AI-agents gemiddeld 3,2 niet-gedocumenteerde wijzigingen per week doorvoeren in een productieomgeving. Bij 12% van die wijzigingen ontstond een afwijking van de gecertificeerde staat. De agent zelf had geen notie van certificering, hij optimaliseerde puur op security metrics.

Waarom statische certificering faalt

De CRA is geschreven met een klassiek productbeeld: je bouwt iets, je test het, je certificeert het, en het blijft ongewijzigd tot de volgende release. Dat model werkt voor een domme sensor of een mechanisch onderdeel. Het werkt niet voor een connected device dat continu wordt aangepast door AI-gestuurde verdedigingsmechanismen.

Het probleem zit in drie lagen:

1. Geen traceerbaarheid van AI-beslissingen. De agent logt wél dat hij een regel heeft toegevoegd, maar niet dat die regel de certificeringsstatus beïnvloedt. De CRA eist een technische documentatie die de relatie tussen wijzigingen en conformiteit duidelijk maakt. Dat ontbreekt.

2. Geen governancemodel voor AI-agents. De agent heeft toegang tot de configuratie, maar niemand heeft hem verteld dat hij rekening moet houden met certificeringsvoorwaarden. Er is geen mechanisme om AI-beslissingen te toetsen aan de gecertificeerde baseline.

3. Geen continue monitoring. Het certificaat is een momentopname. De agent werkt continu. Die kloof groeit na elke wijziging.

De paper stelt voor om AI-agents zelf als onderdeel van de certificering op te nemen, met een governancelaag die wijzigingen toetst aan de essentiële eisen. Dat betekent: logging die certificeringsimpact registreert, een notificatiestructuur voor substantiële wijzigingen, en een mechanisme om de agent te beperken tot gecertificeerde handelingen.

In de praktijk betekent dit dat fabrikanten hun AI-agents niet meer als black boxes mogen zien. Ze moeten de logica, de toegang en de impact op de certificering kunnen verantwoorden. Dat is een harde landing voor bedrijven die AI-tools inzetten als add-ons op gecertificeerde producten.

De Cyber Resilience Act is streng. Hij vereist dat elk product dat in de EU wordt verkocht, voldoet aan strikte cybersecuritynormen. Maar als AI-agents die normen continu ondermijnen zonder dat iemand het ziet, dan is de wet achterhaald voordat hij echt begint te werken.

De vraag is niet of AI-agents nuttig zijn. Dat zijn ze. De vraag is of we ze kunnen integreren zonder de certificering tot een leugentje te maken. Tot nu toe wijst het antwoord in de richting van nee.