CMMC 2.0 en AI Agents: Wat “Geautoriseerde Toegang” Betekent voor Workflows die CUI Aanraken

Defensie-aannemers zetten AI-agenten in voor het ontwikkelen van voorstellen, programmadocumentatie, supply chain management en technische dataworkflows. Veel van deze workflows raken gecontroleerde niet-geclassificeerde informatie. Daarmee vallen ze direct onder de reikwijdte van CMMC 2.0 – niet als toekomstige overweging, maar als een huidige nalevingsverplichting die derde beoordelaars nu al evalueren.

CMMC’s vereisten voor toegangscontrole, audittrail en encryptie bevatten geen uitzondering voor door machines aangestuurde systemen. Of nu een gescreende medewerker of een autonome AI-agent toegang heeft tot een CUI-document, de nalevingsverplichting is identiek: toegang moet geautoriseerd zijn, bepaald door rol en context, versleuteld met gevalideerde cryptografie, en vastgelegd in een operationele audittrail die is gekoppeld aan een menselijke autorisator. De meeste AI-inzet in de defensie-industrie zijn niet gebouwd om aan deze vereisten te voldoen.

Dit artikel legt uit wat CMMC 2.0 specifiek vereist voor AI-workflows die CUI verwerken, benoemt de nalevingsgaten die beoordelaars zullen vinden, en beschrijft beste practices voor het beheren van AI-agenttoegang tot CUI op een manier die verdedigbaar bewijs oplevert – geen verklaringen – wanneer de C3PAO langskomt.

Samenvatting voor het management

Belangrijkste idee: CMMC 2.0’s toegangscontrole, auditlogging en encryptiepraktijken gelden voor elk systeem dat CUI verwerkt, inclusief AI-agenten. Defensie-aannemers die AI inzetten op CUI-workflows zonder geauthenticeerde agentidentiteit, ABAC-beleidsafdwinging en operationele auditlogging, lopen nalevingsrisico’s op die niet achteraf kunnen worden hersteld zodra een beoordeling start.

Waarom dit belangrijk is: CMMC-certificering is een vereiste voor contractgeschiktheid – organisaties die niet slagen voor de beoordeling verliezen toegang tot DoD-contracten. Beoordelaars evalueren controles op het data access layer, niet op het modellayer. Een defensie-aannemer die geen delegatieketen kan aantonen die elke AI-agent CUI-interactie koppelt aan een menselijke autorisator, minimale toegangsafdwinging op operationeel niveau kan aantonen, en FIPS 140-3 gevalideerde encryptie over elk CUI-datapad kan laten zien, zal materiële bevindingen krijgen. De tijd om die gaten te dichten is vóórdat de C3PAO binnenkomt, niet tijdens de beoordeling.

Belangrijkste punten

1. CMMC 2.0 geldt zonder uitzondering voor AI-agenten die CUI verwerken. AC.1.001 vereist geautoriseerde toegang tot CUI, ongeacht of de gebruiker menselijk of geautomatiseerd is. CMMC maakt geen onderscheid tussen een gescreende medewerker en een AI-agent die een technisch datapakket verwerkt. De controles die menselijke CUI-toegang reguleren, gelden direct en volledig voor agenttoegang.
2. Beoordelaars evalueren controles op het datalayer, niet het modellayer. Een C3PAO zal niet vragen welk AI-model uw agenten gebruiken of hoe uw systeem-prompts zijn geconfigureerd. Ze vragen: welke CUI heeft de agent benaderd, onder welke autorisatie, met welke encryptie, en kunt u een audittrail tonen die de toegang koppelt aan een menselijke autorisator? Als het antwoord op een van deze vragen iets anders is dan een gedocumenteerd bewijspakket, zal de beoordeling bevindingen opleveren.
3. CUI-segregatievereisten gelden ook voor door AI beheerde mappenstructuren. CMMC’s toegangscontrolepraktijken vereisen dat CUI gescheiden is en alleen toegankelijk voor geautoriseerd personeel. Wanneer AI-agenten mappenhiërarchieën met CUI aanmaken, verplaatsen of herstructureren, moeten deze structuren dezelfde RBAC/ABAC-controles erven als handmatig ingerichte mappen. Door AI gegenereerde mappenstructuren die niet automatisch beleidscontroles erven, creëren segregatiegaten.
4. De delegatieketen verbindt AI-agentacties met menselijke verantwoordelijkheid. CMMC’s AC- en AU-praktijken vereisen dat toegang tot CUI herleidbaar is tot een geautoriseerd individu. Voor AI-agenten betekent dit dat het authenticatierecord de identiteit van de agent moet koppelen aan de specifieke mens die de workflow heeft gedelegeerd – niet alleen aan een serviceaccount. Zonder deze delegatieketen is de audittrail per definitie incompleet.
5. Runtime guardrails en systeem-prompts zijn geen CMMC-toegangscontroles. Netwerksandboxing, runtime policy engines en AI-veiligheidsfilters werken op het model- of executielaag. Ze zijn waardevolle beveiligingsmaatregelen, maar voldoen niet aan de CMMC-vereisten op dataniveau voor geautoriseerde toegang, auditlogging of encryptievalidatie. Een C3PAO accepteert ze niet als bewijs van AC.1.001- of AU.2.042-naleving.

Wat CMMC 2.0 vereist voor AI-systemen die CUI verwerken

CMMC 2.0 Level 2 is gebaseerd op NIST SP 800-171’s 110 beveiligingspraktijken verdeeld over 14 domeinen. Vier zijn het meest direct van toepassing wanneer AI-agenten CUI benaderen, verwerken of beheren: Access Control (AC), Audit and Accountability (AU), Identification and Authentication (IA), en System and Communications Protection (SC).

Toegangscontrole: AC.1.001 en AC.2.006

AC.1.001 vereist dat toegang tot CUI beperkt blijft tot geautoriseerde gebruikers, processen die namens geautoriseerde gebruikers handelen, en apparaten. “Processen die namens geautoriseerde gebruikers handelen” dekt expliciet AI-agenten – dit is geen grijs gebied. AC.2.006 vereist dat toegang beperkt blijft tot de soorten transacties en functies die geautoriseerde gebruikers mogen uitvoeren. Voor AI-agenten moet minimale noodzakelijke toegang worden afgedwongen op operationeel niveau: een agent die geautoriseerd is om een contractmap te lezen, mag niet automatisch alle bestanden downloaden, records verplaatsen of inhoud verwijderen. Elke handeling vereist een aparte beleidsbeoordeling.

Audit en verantwoording: AU.2.042

AU.2.042 vereist dat de activiteiten van individuele gebruikers – inclusief processen die namens hen handelen – worden gevolgd, vastgelegd en periodiek beoordeeld. Het auditrecord moet de geauthenticeerde identiteit van de agent vastleggen, de mens die de workflow heeft geautoriseerd, de specifieke CUI die is benaderd, de uitgevoerde handeling en het tijdstip. Een log die alleen toont dat een API-endpoint is aangeroepen, voldoet niet aan deze praktijk. Een log die toont welk CUI-document is benaderd, door welke agentidentiteit, onder welk beleid, geautoriseerd door welke mens, voldoet wél.

Identificatie en authenticatie: IA-praktijken

CMMC’s IA-praktijken vereisen dat gebruikers en processen uniek worden geïdentificeerd en geauthenticeerd voordat ze toegang krijgen tot CUI. AI-agenten die werken via gedeelde serviceaccounts of API-sleutels voldoen niet aan deze vereiste. Elke agent moet een unieke identiteitscredential hebben die is gekoppeld aan de specifieke workflow en de menselijke autorisator die deze heeft gedelegeerd. Wanneer meerdere agenten een identiteit delen, of wanneer het authenticatierecord de toegang niet kan herleiden tot een specifieke menselijke beslisser, kan niet aan de IA-praktijken worden voldaan.

Systeem- en communicatiebeveiliging: SC.3.177

SC.3.177 vereist dat CUI wordt versleuteld met FIPS-gevalideerde cryptografie bij overdracht over open netwerken en tijdens opslag. Voor AI-agenten betekent dit dat elk datapad dat de agent aanraakt – API-calls naar CUI-repositories, model inference-pijplijnen, tijdelijke bestandsopslag, outputkanalen – FIPS 140-3 gevalideerde cryptografische modules moet gebruiken. Standaard TLS– en AES-256-implementaties zonder bevestigde FIPS 140-3-validatie voldoen niet aan SC.3.177. Een beoordelaar die een AI-inzet beoordeelt, vraagt om validatiecertificaten van cryptografische modules, niet om leveranciersconfiguratiedocumentatie.

Waar AI-inzet tekortschiet ten opzichte van CMMC-vereisten

De standaardarchitectuur voor AI-agentinzet in de DIB – een agent verbonden met een documentrepository via API, beheerd door een serviceaccount en een systeem-prompt – faalt op meerdere punten tegelijk bij een CMMC-beoordeling. Dit zijn structurele mismatches tussen hoe de meeste AI-inzet is gebouwd en wat beoordelaars moeten verifiëren.

Geen delegatieketen betekent geen verantwoordelijke autorisator

Wanneer een CMMC-beoordelaar een CUI-toegangsgebeurtenis bekijkt en vraagt wie deze heeft geautoriseerd, moet het antwoord een specifiek genoemde persoon met gedocumenteerde bevoegdheid zijn. Een serviceaccount geeft een systeemnaam als antwoord. Een API-sleutel geeft een token. Zonder een delegatieketen die de actie van de agent koppelt aan de mens die de workflow heeft geautoriseerd, heeft de toegangsgebeurtenis geen verantwoordelijke autorisator – een directe bevinding tegen AC.1.001 en AU.2.042. Cruciaal: dit kan niet achteraf worden gerepareerd. De delegatieketen moet op het moment van toegang worden vastgelegd, anders bestaat deze niet in het auditrecord.

Operationele toegangsafbakening ontbreekt architectonisch

De meeste AI-inzet geeft agenten brede repository-credentials en vertrouwt op systeem-prompts om te beperken wat de agent daadwerkelijk doet. CMMC-beoordelaars evalueren wat de agent technisch gezien mocht doen, niet wat hem werd opgedragen te doen. Als een serviceaccount toegang geeft tot 10.000 CUI-documenten en de taak van de agent er drie nodig had, had de agent ongeautoriseerde toegang tot 9.997 documenten vanuit het minimale noodzakelijke standpunt van AC.2.006 – ongeacht of hij ze heeft opgehaald.

Door AI aangemaakte mappenstructuren dragen geen geërfde controles

AI-agenten creëren steeds vaker mappenstructuren voor voorstel-documenten, programmadocumenten en technische datapakketten. CMMC vereist dat deze mappen automatisch CUI-toegangscontroles erven. In de meeste inzet krijgen door AI aangemaakte mappenhiërarchieën pas RBAC- of ABAC-beleid als een mens ze achteraf inricht. Elk document dat in een niet-gereguleerde, door AI aangemaakte map wordt geplaatst, is een CUI-segregatiebevinding.

Beste practices voor CMMC-conforme AI-agenttoegang tot CUI

1. Stel agent-specifieke identiteitscredentials in die gekoppeld zijn aan menselijke autorisatoren

Elke AI-agent die CUI benadert, moet worden voorzien van een unieke identiteitscredential op workflow-niveau – geen gedeelde serviceaccount. Die credential moet in het authenticatierecord worden gekoppeld aan de specifieke persoon die de workflow heeft geautoriseerd. De delegatieketen – menselijke autorisator naar agentidentiteit naar CUI-toegangsgebeurtenis – moet worden vastgelegd in elk auditlogboek. Gedeelde credentials voldoen niet aan de IA-vereisten van CMMC, ongeacht scoping op applicatieniveau.

2. Dwing operationele ABAC af voor elk CUI-dataverzoek

Implementeer op attributen gebaseerde toegangscontrole die elk CUI-verzoek evalueert op basis van het geauthenticeerde profiel van de agent, de CUI-classificatie van de data, de workflowcontext en de specifieke handeling. Een agent die geautoriseerd is om een voorstelmap te lezen, mag niet alle bestanden downloaden, inhoud verplaatsen of aangrenzende CUI-categorieën benaderen. Deze beoordeling per handeling is het mechanisme dat voldoet aan AC.2.006’s minimale noodzakelijke vereiste.

3. Zorg dat door AI beheerde mappenstructuren automatisch CUI-controles erven

Elke mappenhiërarchie die door een AI-agent wordt aangemaakt of aangepast en CUI bevat, moet bij creatie RBAC- en ABAC-controles erven – niet via latere handmatige inrichting. De governance-laag die CUI-segregatie afdwingt, moet in de mapcreatie zelf zijn ingebed. Mappen zonder geërfde controles zijn segregatiebevindingen, ongeacht wie of wat ze heeft aangemaakt.

4. Leg operationele, manipulatiebestendige auditlogs vast voor alle agent-CUI-toegang

Elke AI-agent CUI-interactie moet op operationeel niveau worden gelogd: agentidentiteit, menselijke autorisator, specifiek document of map benaderd, type handeling, uitkomst van beleidsbeoordeling en tijdstip. De log moet manipulatiebestendig zijn en exporteerbaar voor C3PAO-bewijsevaluatie en SIEM-integratie. API-logs op sessieniveau voldoen niet aan AU.2.042 – en dit is een van de eerste bewijsverzoeken die beoordelaars doen.

5. Valideer FIPS 140-3-encryptie over elk CUI-datapad

Controleer elk punt waarop CUI wordt verzonden of opgeslagen in AI-agentworkflows – API-calls, modelhosting, vector databases, tijdelijke agentopslag, uitvoerbestanden – en bevestig FIPS 140-3 gevalideerde cryptografische modulecertificering voor elk. SC.3.177 vereist gevalideerde cryptografie, niet alleen sterke algoritmen. Een organisatie die AES-256 gebruikt maar geen FIPS 140-3 modulevalidatiecertificaat kan overleggen, heeft een bevinding, ongeacht de encryptiekracht.

Hoe Kiteworks CMMC-conforme AI-agentgovernance mogelijk maakt

AI-agenttoegang tot CUI beheren op het niveau dat CMMC-beoordelaars vereisen, vraagt om een andere architectuur dan de meeste defensie-aannemers nu inzetten. Serviceaccounts, API-sleutels en systeem-prompts richten zich op de applicatielaag. CMMC beoordeelt het datalayer. Het Kiteworks Private Data Network – FedRAMP Moderate Authorized en ondersteunt bijna 90% van de CMMC 2.0 Level 2-vereisten – biedt defensie-aannemers een governance-laag die elke AI-agentinteractie met CUI onderschept voordat deze plaatsvindt, waarbij de identiteitsverificatie, toegangsbeleid, encryptie en audittrail worden afgedwongen die CMMC-beoordelaars zullen evalueren.

Agentidentiteit en delegatieketen voor AC.1.001 en AU.2.042

Kiteworks authenticeert elke AI-agent voordat CUI-toegang plaatsvindt en koppelt die authenticatie aan de mens die de workflow heeft gedelegeerd. De volledige delegatieketen – autorisatoridentiteit, agentidentiteit, operationele context en beleidsuitkomst – wordt vastgelegd in elk auditlogboek. Wanneer een C3PAO vraagt wie deze CUI-toegang heeft geautoriseerd en wat de agent mocht doen, is het antwoord een compleet, getimestamped, manipulatiebestendig record, geen reconstructie uit applicatielogs.

Operationele ABAC voor AC.2.006 minimale noodzakelijke afdwinging

Kiteworks’ Data Policy Engine evalueert elk AI-agent CUI-verzoek aan de hand van een multidimensionaal beleid: het geauthenticeerde profiel van de agent, de CUI-classificatie van de gevraagde data, de workflowcontext en de specifieke handeling. Een agent die geautoriseerd is om voorstel-documenten in een specifieke map te lezen, kan niet alle bestanden downloaden, aangrenzende CUI-categorieën benaderen of handelingen buiten zijn bevoegdheid uitvoeren. Minimale noodzakelijke toegang wordt afgedwongen op operationeel niveau – de vereiste die AC.2.006 oplegt en die de meeste AI-inzet momenteel niet kan aantonen.

Gereguleerde mapbewerkingen voor CUI-segregatie

Kiteworks Compliant AI’s Governed Folder Operations Assist stelt AI-agenten in staat om CUI-mappenhiërarchieën aan te maken, hernoemen, verplaatsen en organiseren met natuurlijke taalopdrachten, waarbij elke handeling wordt afgedwongen door de Data Policy Engine. Door AI-agenten aangemaakte mappenstructuren erven automatisch RBAC- en ABAC-controles, waarmee CMMC’s CUI-segregatievereisten vanaf het moment van creatie worden nageleefd. Handmatige inrichting is niet nodig en geen door AI aangemaakte map bestaat buiten de governance-grens.

FIPS 140-3-encryptie en manipulatiebestendige audittrail voor SC.3.177 en AU.2.042

Alle CUI die via Kiteworks wordt benaderd, is beschermd met FIPS 140-3 Level 1 gevalideerde encryptie tijdens overdracht en opslag, waarmee SC.3.177 wordt nageleefd met gevalideerde modulecertificering die direct aan beoordelaars kan worden getoond. Elke agent-CUI-interactie wordt vastgelegd in een manipulatiebestendige, operationele log die kan worden geïntegreerd in de SIEM van de organisatie. Wanneer de C3PAO een bewijspakket voor AU.2.042 opvraagt, is het antwoord een exporteerbaar rapport – geen forensische reconstructie uit infrastructuurlogs die nooit waren ontworpen om vast te leggen wat CMMC vereist.

Voor defensie-aannemers die AI willen inzetten met operationele snelheid zonder CMMC-bevindingen op te lopen, biedt Kiteworks de governance-infrastructuur die elke AI-agentinteractie met CUI standaard assessor-ready maakt. Lees meer over de CMMC-nalevingsmogelijkheden van Kiteworks of vraag een demo aan om te zien hoe Kiteworks AI-agenttoegang tot CUI in uw omgeving beheert.

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 bestaat geen “–dangerously-skip-permissions” voor uw data
• Blog Post
  Toezichthouders zijn klaar met vragen of u een AI-beleid heeft. Ze willen bewijs dat het werkt.