Een CISO loopt een bestuursvergadering binnen met slechts een half antwoord

Stel je een scenario voor dat zich de komende maanden in honderden ondernemingen zal afspelen. Een CISO loopt een bestuursvergadering binnen en zegt: “Onze OpenClaw-strategie is NemoClaw. NVIDIA’s OpenShell is onze policy engine. Cisco, CrowdStrike en Microsoft bouwen er allemaal op voort. We zijn gedekt.”

Het bestuur knikt. De presentatie ziet er indrukwekkend uit. De CISO heeft echt werk verricht—de runtime geëvalueerd, de juiste infrastructuurpartners geselecteerd, agents ingezet in een sandbox-omgeving met netwerkbeveiliging. Volgens elke redelijke maatstaf voor runtime-beveiliging is de architectuur solide.

Zes maanden later arriveert de CMMC-beoordelaar. De eerste vraag gaat niet over runtime-sandboxing. Het gaat niet over netwerkbeveiliging. Het gaat niet over welk model de agents gebruiken.

De vraag is: “Laat me zien welke CUI deze agent heeft benaderd, onder welke autorisatie, met welke encryptie, en toon de audittrail die deze toegang aan een menselijke autorisator koppelt.”

Dan ontdekt de CISO dat runtimebeleid en compliancebeleid verschillende zaken zijn. En tegen die tijd is het compliancegat al zes maanden aan het groeien door ongecontroleerde agentinteracties die niet achteraf kunnen worden geaudit. Het bewijs dat de beoordelaar nodig heeft, bestaat niet. Niet omdat de CISO nalatig was, maar omdat de architectuur zich op de verkeerde laag richtte.

Dit scenario is niet hypothetisch. Het is het voorspelbare gevolg van het verwarren van Jensen Huang’s claim over een “policy engine” met vereisten voor naleving van regelgeving. Het begrijpen van dit verschil is de belangrijkste governancebeslissing die een CISO of compliance officer in 2026 zal nemen.

Wat Huang Eigenlijk Zei—en Wat Het Werkelijk Betekent

Nauwkeurigheid is hier belangrijk. Tijdens de GTC 2026 keynote introduceerde Huang NVIDIA OpenShell als onderdeel van de NemoClaw-stack en zei dat deze technologieën kunnen dienen als “de policy engine van alle SaaS-bedrijven ter wereld.”

NVIDIA VP Kari Briski lichtte dit toe in een persbriefing voorafgaand aan de conferentie: “OpenShell biedt de ontbrekende infrastructuurlaag onder claws, zodat ze de toegang krijgen die ze nodig hebben om productief te zijn, terwijl beleidsgebaseerde beveiliging, netwerk- en privacybeveiliging worden afgedwongen.”

Deze uitspraken zijn nauwkeurige beschrijvingen van wat OpenShell doet. Het is een open-source runtime die agentuitvoering sandboxed, netwerkcontroles afdwingt, gegevensisolatie op runtime-niveau beheert en de infrastructuur biedt voor agents om binnen gedefinieerde grenzen te opereren. Dat is een waardevolle en noodzakelijke functionaliteit.

Maar “policy engine” heeft een specifieke betekenis in de compliancecontext die fundamenteel verschilt van NVIDIA’s gebruik. Wanneer een HIPAA-compliance officer “policy engine” hoort, denkt men aan: toegangscontrole op PHI, afdwingen van minimaal noodzakelijke toegang, encryptievalidatie en audittrails. Wanneer een CMMC-beoordelaar het hoort, denkt men aan: geautoriseerde toegang tot CUI met gedocumenteerde controles en bewijspakketten. Wanneer Huang het zegt, bedoelt hij: runtimebeveiliging voor hoe agents met SaaS-applicaties omgaan.

Beide betekenissen zijn legitiem. Het gevaar is ze te verwarren.

De Technische Architectuur van het Gat: Runtimebeleid vs. Gegevensbeheerbeleid

Het verschil tussen runtimebeleid en gegevensbeheerbeleid is niet semantisch. Het is architectonisch. Begrijpen waar elk beleid in de enterprisestack opereert, is essentieel voor het bouwen van een complete OpenClaw-strategie.

Runtimebeleid (het domein van OpenShell) werkt op de agentuitvoeringslaag. Het beantwoordt vragen als: Mag deze agent deze tool aanroepen? Mag deze agent dit netwerkpad benaderen? Draait deze agent in een juiste sandbox? Is de uitvoeringsomgeving geïsoleerd van het bredere systeem? Dit zijn infrastructuurniveaucontroles die bepalen wat de agent als computerproces mag doen.

Gegevensbeheerbeleid (het compliance-domein) werkt op de gegevenstoegangslaag. Het beantwoordt vragen als: Mag deze agent dit specifieke bestand benaderen? Onder welke autorisatie—en wie is de menselijke autorisator? Zijn de gegevens versleuteld met gevalideerde cryptografie? Wordt elke toegang gelogd in een manipulatiebestendig record? Kan dit auditrecord worden gekoppeld aan een specifieke vereiste uit regelgeving? Dit zijn controles op gegevensniveau die bepalen welke informatie de agent mag benaderen en leveren het bewijs dat compliance vereist. Zonder deze laag hebben ondernemingen geen basis voor data security posture management nu AI-agents zich snel verspreiden.

De Kiteworks 2026 Forecast documenteert hoe ver ondernemingen verwijderd zijn van het voldoen aan vereisten voor gegevensbeheer voor AI. Slechts 43% heeft een gecentraliseerde AI Data Gateway. Negentien procent heeft losse point solutions zonder samenhangend beleid. Zeven procent heeft helemaal geen AI-controles.

OpenShell pakt geen van deze tekortkomingen op gegevenslaag aan. Het is daar ook niet voor ontworpen. Het is ontworpen om agent-runtimes veilig te maken—een totaal ander probleem.

Wat Elk Belangrijk Regelgevend Kader Werkelijk Vereist—en Waar OpenShell Tekortschiet

Regelgeving reguleert geen agents. Ze reguleren data. Dat onderscheid vormt de basis van het compliancegat.

HIPAA vereist dat onder de wet vallende entiteiten toegangscontrole op beschermde gezondheidsinformatie implementeren (§164.312(a)(1)), minimaal noodzakelijke toegang afdwingen (§164.502(b)), auditlogs van PHI-toegang bijhouden (§164.312(b)), en encryptie toepassen op elektronische PHI (§164.312(a)(2)(iv)). Stel een zorginstelling voor waar een AI-agent patiëntendossiers ophaalt om ontslagbrieven te genereren. Die agent valt onder elk van deze vereisten. De sandbox van OpenShell dwingt geen minimaal noodzakelijke toegang op bestandsniveau af—het kan niet voorkomen dat de agent dossiers van patiënten buiten het huidige zorgproces benadert. Het produceert geen PHI-specifieke logs die tonen welke dossiers voor welke patiënt zijn ingezien. Het past geen FIPS 140-3 gevalideerde encryptie toe op data in rust. Wanneer de OCR-onderzoeker om bewijs van toegangscontrole op de PHI-interacties van de agent vraagt, is runtimebeveiliging geen afdoend antwoord.

CMMC vereist geautoriseerde toegang tot Controlled Unclassified Information met gedocumenteerde toegangscontroles (AC.1.001, AC.2.006), auditlogging van CUI-toegang (AU.2.042), en gevalideerde encryptie (SC.3.177). Een defensie-aannemer die AI-agents gebruikt om technische datapakketten te verwerken, moet aantonen dat elke agentinteractie met CUI is geautoriseerd door een specifiek individu, gelogd op operationeel niveau en versleuteld met gevalideerde cryptografie. De netwerkbeveiliging van OpenShell sluit niet aan bij deze specifieke praktijkvereisten. Een CMMC-compliancebeoordelaar wil delegatieketens zien die agentacties aan menselijke autorisatoren koppelen—iets wat alleen een gegevensbeheerlaag kan bieden.

PCI DSS 4.0 vereist beperkte toegang tot kaarthoudergegevens op need-to-know-basis (Vereiste 7), encryptie van kaarthoudergegevens (Vereiste 4), en logging van alle toegang (Vereiste 10). Een OpenClaw-agent die betalingsgegevens verwerkt in een NemoClaw-runtime valt nog steeds onder al deze vereisten, ongeacht hoe goed de runtime is gesandboxed. De QSA zal de runtime niet beoordelen. De QSA beoordeelt of toegang tot kaarthoudergegevens beperkt, versleuteld en gelogd is volgens de PCI DSS-vereisten.

SOX Sectie 404 vereist IT-general controls over financiële data, inclusief identity & access management, change management en audittrails. Een agent die toegang heeft tot financiële rapportagedata—kwartaalcijfers ophaalt, rekeningen afstemt, rapporten genereert—moet onder dezelfde ITGC-controles werken als een menselijke medewerker. Die controles moeten aantoonbaar zijn voor auditors, met bewijs dat op verzoek kan worden geleverd.

In alle gevallen richt de regelgeving zich op de gegevenslaag, niet op de runtime-laag. OpenShell maakt de runtime veiliger. Het maakt de data access niet compliant.

Het Microsoft-Bewijs: Zelfs NVIDIA’s Partners Zien het Verschil

De sterkste bevestiging van het verschil tussen runtime- en databeheer komt van NVIDIA’s eigen partners. Microsoft Security kondigde aan samen te werken met NVIDIA aan adversarial learning via Nemotron en OpenShell, waarbij Alexander Stojanovic, VP van Microsoft Security’s NEXT AI-team, rapporteerde over “160x verbetering in het vinden en beperken van AI-gebaseerde aanvallen.” Dat is een belangrijke vooruitgang in runtime threat detection—het identificeren wanneer agents worden gemanipuleerd, gecompromitteerd of misbruikt.

Tegelijkertijd publiceerde de securityblog van Microsoft uitgebreide richtlijnen voor het veilig draaien van OpenClaw waarin werd aanbevolen dit te behandelen als “untrusted code execution met persistente credentials” en het alleen te implementeren in volledig geïsoleerde omgevingen met toegewijde, niet-geprivilegieerde credentials. De richtlijn waarschuwde expliciet dat lokaal draaiende agents de volledige privilege set van hun hostmachine erven, dat persistente geheugen betekent dat gecompromitteerde data sessie-overstijgend toegankelijk blijft, en dat traditionele beveiligingstools moeite hebben agentgedrag te detecteren.

Deze twee standpunten zijn niet tegenstrijdig. Ze zijn complementair—en ze tonen precies de gelaagde architectuur die deze analyse beschrijft. Microsoft investeert in runtime adversarial protection via OpenShell (Laag 2) en erkent tegelijk dat runtimebescherming alleen het data access-risico (Laag 3) niet oplost. Microsoft’s 160x verbetering in het detecteren van AI-aanvallen betekent dat gecompromitteerde agents sneller worden gevonden. Het betekent niet dat de data die deze agents benaderden, beheerd, versleuteld of auditeerbaar was met een chronologische documentatie die een compliance-auditor tevredenstelt.

Als Microsoft—NVIDIA’s eigen beveiligingspartner—dit onderscheid in haar officiële richtlijnen aanhoudt, zouden enterprise-CISO’s dat ook moeten doen in hun architectuurkeuzes.

Het Cisco en CrowdStrike-ecosysteem: Uitstekend op Laag 1 en 2, Stil op Laag 3

Het ecosysteem dat zich rond NemoClaw vormt, onderstreept de complementaire positionering. Cisco’s AI Defense beveiligt agentuitvoering en was een van de eerste enterprisebeveiligingsoplossingen geïntegreerd in de NemoClaw-stack. CrowdStrike’s Secure-by-Design AI Blueprint integreert threat detection direct in agentinzet-workflows. LangChain-integratie maakt lokale agentontwikkeling mogelijk met governance hooks op runtime-niveau.

Dit zijn stuk voor stuk waardevolle beveiligingsmogelijkheden. En ze werken allemaal op runtime- en infrastructuurniveau. Geen ervan dwingt ABAC-beleid af op individuele bestandsbewerkingen—ze kunnen niet onderscheiden tussen een agent die een map leest en een agent die de inhoud downloadt. Geen ervan levert compliance-bewijspakketten die aansluiten bij HIPAA, CMMC, PCI-naleving of SOX-controlevereisten. Geen ervan bewaart de delegatieketen van agentactie naar menselijke autorisator, wat de bewijslast is waar compliancebeoordelaars om vragen. Geen ervan past FIPS 140-3 gevalideerde encryptie toe op door agents benaderde data in rust.

CrowdStrike publiceerde een uitgebreide analyse van OpenClaw-beveiligingsrisico’s en bracht een enterprise-brede zoek- en verwijdercontentpack uit via Falcon for IT. Hun focus lag op detectie en reactie—het identificeren waar OpenClaw is ingezet op beheerde endpoints, het begrijpen van de blootstelling en het herstellen van risico’s. Dat is Laag 2-werk, en belangrijk werk. Maar Laag 3—het beheren van welke data deze agents benaderen, onder welke compliancecontroles, met welk auditeerbaar bewijs—blijft onopgelost door elke partner in het NVIDIA-ecosysteem. Het ecosysteem beveiligt de agent. Niemand in het ecosysteem beveiligt de data die de agent aanraakt.

Hoe Kiteworks Compliant AI de Compliance-laag Invult die OpenShell Openlaat

Kiteworks Compliant AI werkt op Laag 3 van de enterprise OpenClaw-architectuur—de AI-gegevensbeheer- en regulatory compliance-laag. Het onderschept elke AI-agentinteractie met gevoelige bedrijfsdata, verifieert identiteit, dwingt ABAC-beleid af, past FIPS 140-3 gevalideerde encryptie toe en legt manipulatiebestendige logs vast voordat er toegang tot data is. Het zit tussen AI-agents en de gereguleerde data die ze nodig hebben, en beheert toegang onafhankelijk van het model, de runtime en het agentframework.

De architectuur implementeert vier niet-onderhandelbare vereisten voor compliant AI-data access. Geauthenticeerde agentidentiteit verifieert elke agent vóór datatoegang en koppelt de agent aan de menselijke autorisator die de workflow heeft gedelegeerd. ABAC-beleidsafdwinging evalueert elk datarequest tegen multidimensionaal beleid: agentprofiel, dataclassificatie, requestcontext en specifieke bewerking. FIPS 140-3 gevalideerde encryptie beschermt alle door agents benaderde data met cryptografische modules die voldoen aan federale en bedrijfs-auditvereisten. En manipulatiebestendige audittrails leggen elke interactie vast—wie, wat, wanneer en waarom—en voeren deze direct door naar enterprise SIEM-systemen.

De Kiteworks Secure MCP Server beheert interactieve AI-assistenten (Claude, Copilot) via het Model Context Protocol met OAuth 2.0-authenticatie. De AI Data Gateway beheert programmatische RAG-pijplijnen en geautomatiseerde workflows. Drie speciaal ontwikkelde Governed Assists breiden compliance uit naar de meest voorkomende gereguleerde dataoperaties—bestandsbeheer, mapbewerkingen en formuliercreatie—elk identiteitsgeverifieerd, ABAC-geëvalueerd, FIPS 140-3 versleuteld en manipulatiebestendig gelogd. Beide integratiepatronen dwingen hetzelfde beheer af: Kiteworks Compliant AI-beleid geldt consequent, ongeacht de integratiemethode.

Dit is niet competitief met OpenShell. Het is de laag die OpenShell nodig heeft om het complianceplaatje compleet te maken. NemoClaw maakt agents veiliger in gebruik. Kiteworks Compliant AI zorgt ervoor dat de data die ze benaderen beheerd en auditeerbaar is, zodat ondernemingen datacompliance kunnen aantonen binnen elk gereguleerd kader.

Wat CISO’s en Compliance Officers Moeten Doen Voor Hun Volgende AI Governance Review

Ten eerste, audit uw huidige AI-governancearchitectuur aan de hand van het drielaags model. Koppel elke controle die u heeft aan de juiste laag (compute, runtime of data). Identificeer op welke laag de meeste gaten zitten. Voor 57% van de organisaties volgens de Kiteworks 2026 Forecast zal dat Laag 3 zijn.

Ten tweede, informeer uw bestuur over het verschil tussen runtimebeleid en compliancebeleid voordat zij “policy engine” horen en denken dat het probleem is opgelost. Gebruik de Kubernetes-analogie: netwerkbeleid voldoet niet aan de eisen van uw auditor, en runtime-sandboxing ook niet. Dit is vooral belangrijk voor organisaties die onder DORA en NIS 2 vallen, waar ICT-risicobeheer nu expliciet wordt uitgebreid naar AI-systemen.

Ten derde, koppel uw specifieke regelgevende verplichtingen (HIPAA, CMMC, PCI DSS, SOX) aan AI-agentinteracties. Documenteer welke vereisten van toepassing zijn op agentdatatoegang en controleer of uw huidige controles deze afdekken. De meeste organisaties zullen aanzienlijke gaten ontdekken. Een formele risicobeoordeling van AI-agentdatatoegang wordt steeds meer een wettelijke verwachting, niet alleen een beste practice.

Ten vierde, implementeer gecentraliseerd AI-gegevensbeheer voordat u agentinzet uitbreidt. Organisaties die governance-infrastructuur vooraf opzetten, voorkomen dure aanpassingen achteraf. Elke week zonder governance op gegevenslaag is een week van ongecontroleerde interacties die niet achteraf kunnen worden geaudit.

Ten vijfde, positioneer compliance governance als de AI-versneller in interne discussies. De organisaties die AI het snelst inzetten, zijn degenen die het snelst door de AI-databeschermingsreview komen. Geautomatiseerd, ingebouwd beheer vervangt de handmatige compliancebarrière die AI-projecten in elke gereguleerde onderneming blokkeert.

De complianceklok tikt. De high-risk-bepalingen van de EU AI-wet zijn volledig afdwingbaar vanaf augustus 2026. Gartner voorspelt dat meer dan 50% van de grote ondernemingen tegen het einde van het jaar verplichte AI-compliance-audits zal ondergaan. De tijd om Laag 3 te bouwen is vóórdat de auditor arriveert, niet erna.

Wilt u meer weten over hoe Kiteworks kan helpen? Plan vandaag nog een aangepaste demo.

Aanvullende bronnen

• Blog Post
  Zero‑Trust Strategieën voor Betaalbare AI-privacybescherming
• Blog Post
  Hoe 77% van de organisaties faalt op AI-gegevensbeveiliging
• eBook
  AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met gegevensbeveiliging 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.