NVIDIA OpenShell: vier policy-keuzes vóór de pilot

Op 28 september 2026 bundelde NVIDIA OpenShell en een waakhond, Sentry, tot het Open Agent Safety Platform. De kop ging over silicium. Het deel dat een IT-organisatie dit kwartaal kan uitrollen is opensource, draait op een gewone Linux-host en heeft een gedocumenteerd stabiel releasekanaal. Vier keuzes bepalen of een agent-sandbox uw wijzigingsproces en uw volgende audit doorstaat, en de default die het zwaarst weegt laat het verzoek gewoon door.

Wat heeft NVIDIA op 28 september 2026 echt uitgebracht?

Het persbericht beschrijft twee dingen, en dat onderscheid telt zodra u er een inkoopregel over schrijft. OpenShell is opensourcesoftware onder Apache 2.0 die NVIDIA nu breed beschikbaar noemt. Sentry is een referentieontwerp: een out-of-band waakhond op BlueField-4 DPU's, gebouwd op DOCA, die volgens NVIDIA een agent die zijn grens verlaat binnen milliseconden in quarantaine zet. Een referentieontwerp is een bouwtekening, geen product op een prijslijst, en de aankondiging laat zich makkelijk lezen alsof er een apparaat is uitgebracht.

Meer dan honderd organisaties werken met het platform, waaronder Anthropic, Cisco, CrowdStrike, Microsoft, Palantir, Palo Alto Networks, Red Hat, Salesforce, SAP en ServiceNow. Canonical, Red Hat en SUSE nemen OpenShell op in hun distributies, en Salesforce koppelde het aan Slack, zodat een verzoek om extra rechten in een kanaal wordt goedgekeurd of afgewezen. Het interoperabiliteitswerk ligt bij de Open Secure AI Alliance, bestuurd door de Linux Foundation. NVIDIA benoemt het patroon waarop dit een antwoord is onomwonden: in de recente incidenten omzeilde de agent de beveiliging op applicatieniveau om zijn opdracht af te maken.

OpenShell zelf is niet nieuw. Het verscheen op 23 maart 2026 op GTC als early preview. Wat er sindsdien bij is gekomen, is precies wat een wijzigingscommissie vraagt: een gepubliceerde stabiliteitsafspraak. De support matrix beschrijft kanalen voor dev, pre-release en stable, zegt dat u in productie een stable release gebruikt, en onderhoudt de huidige en de vorige minor. Interfaces die als Experimental zijn gemarkeerd kunnen nog in een patchrelease veranderen, en dat is de zin die u uw commissie voorlegt in plaats van een versienummer.

Start het überhaupt op uw omgeving?

Dat is de eerste vraag, en voor een Nederlandse enterprise is die geen formaliteit. De support matrix is streng over de kernel. Landlock LSM is verplicht op ABI 3 of nieuwer, geïntroduceerd in Linux 6.2. Seccomp is verplicht, en niet de gewone variant: OpenShell heeft geneste user-notification-filters nodig plus een atomaire operatie om bestandsdescriptors door te geven, en test dat actief voordat het de workload toelaat. Een kernelversie alleen bewijst niets, en een uitgeschakelde Landlock of een runtimeprofiel dat die seccomp-operaties blokkeert laat de start falen: dicht, niet open.

Er staat een tweede regel in die tabel die u twee keer leest als u Red Hat draait. Een seccomp-vlag uit Linux 5.19 is slechts aanbevolen, en op oudere kernels, de matrix noemt RHEL 9.x en RHCOS op 5.14, start de sandbox nog steeds en handhaaft hij de grens nog steeds, maar valt hij terug op een beperkte legacy read-only modus waarin een handvol bemiddelde operaties dichtklapt. Uitgaande workloads draaien doorgaans onveranderd; een serverworkload die bij het accepteren het adres van de tegenpartij opvraagt niet. De modus staat in de kwalificatie-uitvoer, dus hij is controleerbaar.

Wat de software niet nodig heeft, is NVIDIA-hardware. Linux op amd64 en arm64 en macOS op Apple Silicon worden ondersteund, Windows onder WSL 2 is het enige experimentele platform, en Docker, Podman, Kubernetes en een MicroVM-runtime worden alle vier ondersteund. Vera is een prestatievoordeel, geen afhankelijkheid, en Arm en Intel publiceerden dezelfde dag hun eigen integratie. Alister Baroi van Tigera verwoordde in juli het scherpst waarom die laag de moeite is: maatregelen die de agent kan overrulen zijn geen maatregelen. Een agent kan discussiëren met een systeemprompt. Met een seccomp-filter niet. Dat is het gat dat ons eerdere stuk over het dreigingsmodel van agents vanuit de aanvaller beschreef, nu gedicht vanuit de host.

Welke delen van de policy kunt u op een lopende agent wijzigen?

Een policy is één YAML-bestand met maximaal vijf secties, en de scheiding daarbinnen heeft directe gevolgen voor uw wijzigingsbeheer. Volgens de policy-documentatie liggen filesystem_policy, landlock en process vast zodra de sandbox start. network_policies en network_middlewares veranderen terwijl hij draait. Iets in de eerste groep wijzigen betekent de sandbox weggooien en opnieuw opbouwen.

Lees dat als een operationeel feit, niet als een ontwerpnotitie. Een agent één endpoint extra geven is een live wijziging: geen herstart, en de agent houdt het werk dat onderweg was. De mappen beperken waarin diezelfde agent mag schrijven is een herdeployment, met verlies van state, een venster en een andere goedkeuring. De meeste organisaties schrijven één wijzigingsklasse voor de hele sandbox en ontdekken de asymmetrie op de dag dat er snel iets strakker moet.

In de landlock-sectie wordt de keuze over het bestandssysteem werkelijk gemaakt. De default is best_effort, die paden uit uw policy kan overslaan als hij ze niet vindt; hard_requirement weigert in plaats daarvan te starten. Er wordt een verplichte Landlock-basis geïnstalleerd voordat er agentcode draait, en geen van beide instellingen zet die uit, dus een overgeslagen policy laat de sandbox nooit helemaal open; overslaan levert bovendien een OCSF DetectionFinding met hoge severity op, die alarmeerbaar is zodra iemand die export op uw SIEM heeft aangesloten. Wat het wél kan doen, in NVIDIA's eigen woorden, is anders toegestane image- of workspacebestanden blootleggen aan de agent, en de beveiligingsrichtlijn zegt dat u zulke meldingen onderzoekt in plaats van ze als een ondersteunde, afgezwakte modus te behandelen.

Waarom laat de default het verzoek door?

Dit is de instelling die de aankondiging niet noemde en die in uw eerste pilot het vaakst verkeerd staat. Op een endpoint waar OpenShell verzoeken inspecteert, bepaalt het veld enforcement wat er gebeurt als een verzoek de regels overtreedt. Op enforce blokkeert het het verzoek. Op audit laat het het verzoek door en legt het de overtreding vast. Audit is de default.

NVIDIA verbergt dat niet en de aanbeveling is verstandig: begin in audit, kijk wat een nieuwe regel zou hebben geblokkeerd, zet hem daarna op enforce. Het risico zit in de tweede helft van die zin, en dat is de helft die overgeslagen wordt wanneer een pilot ongemerkt productie wordt. De documentatie is er helder over: een agent kan nog steeds schrijf- of verwijderacties op een API uitvoeren, ook als de regels die zouden weigeren. Een endpoint in audit blokkeert geen verzoeken die zijn eigen regels overtreden, al weigert OpenShell nog steeds wat het niet veilig kan verwerken.

De valkuil ernaast is het veld protocol weglaten, wat in de richtlijn als eerste veelgemaakte fout staat. Een endpoint zonder geïnspecteerd protocol past geen enkele verzoekregel toe. Het beëindigt nog wel TLS en weigert verzoeken aan een andere host, dus het is niet helemaal een tunnel, maar het laat elke methode en elk pad toe, en in een policy-review ziet het er precies zo uit als een zorgvuldige regel.

Is de policy die u goedkeurde ook de policy die draait?

Niet per se, en dit is de alinea die meegaat naar een audit. Wat u schreef is de basispolicy. Gekoppelde providers dragen hun eigen netwerkregels bij, en de effectieve policy is de basis plus die providerregels. De effectieve policy is wat de sandbox handhaaft, en dat is degene die u opvraagt als u wilt weten waar een agent bij kan. Bewerkingen begint u in de basis, zodat u geen regels van een provider in uw eigen bestand overneemt.

Een globale policy is de enige vlootbrede knop, en hij is botter dan hij lijkt. Hij vervángt de policy van elke sandbox in plaats van die te begrenzen, en zolang hij actief is blokkeert OpenShell wijzigingen per sandbox, blokkeert het goedkeuring van voorgestelde endpoints, en onderdrukt het de netwerkregels die providers bijdragen. Eén policy voor een codeeragent en een documentagent, of besturing per sandbox. Een tussenstand is er niet, en die onderdrukking van providerregels is het deel dat stukgaat op de dag dat u hem aanzet.

Waar OpenShell strenger is dan de meesten verwachten, is identiteit van uitvoerbare bestanden. Het legt elk pad dat toegang mag autoriseren vast op de SHA256 die het de eerste keer waarneemt, weigert latere verbindingen als het bestand verandert, en klapt dicht bij ontbrekend of tegenstrijdig bewijs. Een echte maatregel met een praktische rand: vervangt u bewust een binary op een geautoriseerd pad, dan moet de sandbox-runtime herstarten voor een nieuwe vastlegging. De auditsporen blijven lokale allow- en deny-logs per sandbox, hetzelfde structurele probleem dat ons stuk over wat MCP en A2A niet kunnen loggen op protocolniveau beschreef. Identiteit van agents, verkeer tussen agents onderling en communicatie tussen sandboxen vallen bewust buiten de scope, zoals Tigera in de documentatie las in juli.

Wat gebeurt er met de databasetoegang van de agent?

Een databaseclient krijgt helemaal geen beleid op verzoekniveau, en de documentatie over netwerkregels legt helder uit waarom. De geïnspecteerde protocollen zijn rest, websocket, graphql, mcp en json-rpc. Een database spreekt er daar geen van, dus het endpoint krijgt protocol: tcp, en OpenShell controleert dan de hostnaam, de poort en het uitvoerbare bestand en past geen enkele verzoekregel toe.

Praktisch: een agent die via een toegestaan endpoint bij een database komt, is begrensd op host en poort, niet op statement. Een SELECT en een DELETE komen op dezelfde manier binnen. De systemen met de gegevens waar een IT-manager daadwerkelijk zenuwachtig van wordt, de database onder een ERP, een datawarehouse, een documentarchief, zijn precies die waar deze runtime het minst nauwkeurig op let.

Het antwoord is niet wachten op een functie. Het is controle op statementniveau houden waar die al werkt en al getoetst wordt: een eigen databaserol, een alleen-lezen replica, een view die precies de kolommen toont die de agent nodig heeft en verder niets. Die maatregelen bestonden al vóór agents, uw DBA kent ze, en ze overleven een ontsnapping uit de sandbox. Wat OpenShell toevoegt is dat de agent geen enkele andere database kan bereiken. Verplaats controle op statementniveau niet naar de sandbox-policy om het daarna als gedekt te administreren.

Wat moet een Nederlandse IT-organisatie beslissen vóór de pilot?

Vier beslissingen, en alle vier kosten nu minder dan na de eerste agent in productie. Toets de kernelondergrens aan de hosts die u werkelijk draait, want een OpenShift-omgeving op een 5.14-kernel is een ander gesprek dan Ubuntu 24.04. Zet enforcement op enforce voor elk geïnspecteerd endpoint zodra het auditvenster zijn werk heeft gedaan, en zet een datum op die omzetting in plaats van een voornemen. Leg twee wijzigingsklassen vast, één live en één herdeployment, in het proces dat u al heeft. En zet telemetrie uit vóór de pilot in plaats van erna: hij staat standaard aan, en het project documenteert een omgevingsvariabele, een Helm-waarde en een manier om hem er volledig uit te compileren.

Er is hier ook een inkoopreden om precies te zijn. BIO2 is in maart 2026 in de Staatscourant gepubliceerd en is sinds augustus 2026 verbonden aan de wettelijke zorgplicht voor essentiële overheidsentiteiten. Private leveranciers zijn er niet rechtstreeks aan gebonden; zij erven de eisen rond ketenhygiëne via een schriftelijke overeenkomst, en dat is dus via uw contract. Een toetser vraagt welke maatregel een bepaalde actie heeft gestopt. Een kernel die een systeemaanroep weigerde is een antwoord, en een run van de policy prover die aantoont dat een policy niet meer toegang geeft dan een door u gedefinieerde grens ook. Een instructie in een systeemprompt niet.

Nog één opmerking over de rolverdeling. Crux Digits is niet uw ICT-partner en verkoopt geen infrastructuur, hosting of support. De sandbox-host, de kernelversie en het cluster zijn van uw eigen team of van de partner die ze al beheert. Wat wij daarnaast doen is de policy, het bewijsmateriaal en die twee wijzigingsklassen specificeren, en de agent bouwen die daarbinnen moet leven. Twijfelt u nog of een sandboxed agent überhaupt in uw omgeving thuishoort, dan laten onze pagina's over toegepaste AI voor het middenbedrijf en AI-implementatie in Nederland zien hoe dat werk wordt afgebakend. De Europese aflevering van dit verhaal volgt op GTC Berlijn van 20 tot 22 oktober 2026, en de instellingen hierboven zijn de vragen waarmee u die toetst.

Veelgestelde vragen