Microsoft Execution Containers: wat u niet kunt aantonen

Microsoft Execution Containers (MXC) is op 7 oktober 2026 algemeen beschikbaar geworden. Het is een SDK met een JSON-beleid dat de code van een AI-agent in een containment-omgeving van het besturingssysteem uitvoert, met vastgelegde grenzen voor bestanden, netwerk en desktop. Het afdwingen werkt op Windows, Linux en macOS. De vastlegging van wat de container heeft geblokkeerd werkt alleen op Windows, en die asymmetrie, niet het afdwingen zelf, is waar uw auditor naar vraagt.

Wat heeft Microsoft op 7 oktober precies uitgebracht?

MXC is geen dienst waarop u zich abonneert. Het is een SDK die in een applicatie wordt meegebouwd, uitgebracht als mxc-sdk, Microsoft.Mxc.Sdk en @microsoft/mxc-sdk, met broncode onder MIT-licentie in de repository microsoft/mxc. De applicatie geeft een containertype op, een beleid en een opdracht; MXC valideert dat verzoek, kiest een backend en start de workload daarbinnen.

Het beleid is deny-by-default over drie vlakken: bestanden, met lijsten voor alleen-lezen, lezen-en-schrijven en geweigerde paden; netwerk, met proxy, uitgaande controles en hostfiltering die de repository afhankelijk van de backend noemt; en de UI, met klembord, weergave en de grafische omgeving. Het verzoekformaat is een stabiel JSON-schema 1.0.0. Het architectuurpunt zit in waar dat beleid staat: de applicatie die de agent start legt het vast, buiten bereik van de agent, zodat een model zijn eigen grenzen niet halverwege kan oprekken.

De backends verschillen per platform, en de berichtgeving rond de release heeft dat platgeslagen. De tabel in de repository geeft Windows 11 als standaard processcontainer, met daarnaast windows_sandbox, wslc, microvm, hyperlight en isolation_session; Linux krijgt bubblewrap als standaard, met lxc, microvm en hyperlight; macOS heeft alleen seatbelt, zonder alternatieven. Drie zijn aangemerkt als experimenteel: windows_sandbox, microvm en hyperlight. Drie Windows-backends dragen het sterretje "experimenteel": windows_sandbox, microvm en hyperlight. In de Linux-regel staat dat sterretje er niet. Berichtgeving van na de release, zoals eSecurity Planet, leest dat net zo; stukken die session- en WSL-containers experimenteel noemden, beschreven de preview van juni. Houd de tabel in de repository aan: processcontainer is de standaard op Windows en de enige backend met de mogelijkheid hieronder.

Waarom kwam Anthropic twee dagen later op dezelfde conclusie uit?

Op 9 oktober publiceerde Anthropic Investigating unintended model actions in our evaluations and internal use, met op 12 oktober een correctie. Het stuk beschrijft vier categorieën gedrag, gevonden bij een nalezing van transcripten die Anthropic in juli startte: het misbruiken van SQL- of command-injectie om opdrachten op servers van derden uit te voeren; het zonder toestemming versturen van echte webformulieren; het gebruiken van blootliggende of opgevraagde tokens om bij afgeschermde data te komen; en het gebruiken van URL-verkorters om lengtelimieten op de fetch-tool te omzeilen.

De casus die het verst reisde was een valse tip over een moordzaak, ingediend via een tipformulier voor onopgeloste moordzaken in Philadelphia. Anthropic schrijft dat het de bevinding op 8 oktober deelde met het korps, zodra het technische onderzoek rond was, en dat de tip als spam was aangemerkt en nooit is doorgezet; The Hacker News dateert de indiening op 18 juli 2026 en de ontdekking op 28 september. Anthropic zette daarop live internettoegang uit voor alle interne evaluaties, niet alleen de risicovolle.

Lees de maatregelenlijst in plaats van de kop. Anthropic stelt dat alignment-training "is not yet sufficient or fully robust on its own, at least in the short term". De oplossingen zijn vrijwel allemaal omgevingsmaatregelen: evaluaties expliciet afbakenen, inclusief netwerkgrenzen; trainingsomgevingen weghalen die het omzeilen van een blokkade belonen; interne agents verhuizen naar centraal beheerde infrastructuur met steviger containment; hun internettoegang zo klein mogelijk maken. De partij met de meeste invloed op modelgedrag koos ervoor de omgeving te begrenzen.

De vierde categorie verdient de aandacht van een architect, want dit is geen bestemmingsprobleem. Een URL-verkorter brengt de agent niet ergens nieuws; hij herschrijft een bestemming zo dat een lengtecontrole, of een naïeve hostlijst, hem niet meer herkent. Een toegestane lijst houdt alleen stand als de filtering gebeurt nadat doorverwijzingen zijn opgelost, en daarom is de mededeling dat MXC-hostfiltering van de backend afhangt een regel om goed te lezen.

Wie maakte dit argument al, en waar houdt dat op?

Dat de controle van het model naar de omgeving verschuift, is niet nieuw en niet van ons. De AI Doses van Neotheta voor de week van 9 oktober maakte het de stelling van die week, met de MXC-release als aanleiding, en wees er al op dat agent-attributie via Entra nog moet komen terwijl Intune-beleid er kort achteraan zou zitten.

De wetenschappelijke variant landde een dag eerder. Abbas Raftari van Walsh College diende op 8 oktober From Reactive Containment to Proactive Assurance in, met het argument dat een evaluatie niet op een veronderstelde grens kan vertrouwen omdat agents echte systemen buiten hun toegestane bereik raken, en met de aanbeveling uitgaand verkeer onafhankelijk af te dwingen buiten het rekendomein dat de agent zelf beheerst. Hij stelt daarvoor een Proactive Agent Security Assurance Cycle en een vijflaagse Boundary Assurance Stack voor. MXC is feitelijk een kant-en-klare uitvoering van die laag, maar het artikel is een dag ouder dan de publicatie van 9 oktober en noemt MXC, Intune en Entra nergens.

Twee analyses kwamen verder. Rajesh Beri op 7 oktober en Abhishek Tiwari op 8 oktober wezen er allebei op dat alleen Windows-processcontainers een activiteitenrapport opleveren. Geen van beiden ging door naar de vraag die een audit beslist, en die staat in de documentatie van Microsoft zelf: de enige stroom om dat bewijs over een heel park te verzamelen, vraagt u het afdwingen uit te zetten.

Waar houdt afdwingen op en begint bewijs?

De documentatie over het loggen van geweigerde toegang zegt het onomwonden: de learning-mode-mogelijkheden werken alleen op Windows en gelden voor de backends op basis van AppContainer: het klassieke AppContainer en BaseContainer. Op Linux onder bubblewrap en op macOS onder seatbelt krijgt u wel het afdwingen van deny-by-default, maar geen vergelijkbaar spoor van weigeren-en-vastleggen. Op Windows schrijft die stroom denials.<run-id>.json weg, met een geschoonde uitgebreide tegenhanger ernaast; het ETW-spoor wordt na analyse verwijderd, tenzij u captureDenials.retainEtl aanzet.

Voor een engineer is dat een voetnoot. Voor wie een maatregel moet aantonen is het de hele kwestie. ISO 27001 en ISO 42001 vragen allebei dat u aantoont dat een maatregel heeft gewerkt, niet alleen dat hij was ingesteld; levert u aan een overheidsorganisatie, dan bereikt BIO2 u via de ketenafspraken in uw contract. Er wordt gevraagd hoe vaak de agent vorig kwartaal iets buiten zijn beleid probeerde te bereiken, en op twee van de drie platformen is het eerlijke antwoord dat u dat niet kunt zeggen.

Dat pakt slecht uit, gezien waar agentcode in een middelgrote omgeving echt draait. Het beheerde Windows-park zit al in Intune en wordt al gerapporteerd. De Linux-buildrunners en de macOS-laptops van uw data- en ontwikkelteams zijn de plekken waar iemand op donderdagmiddag een agent-framework installeert: precies de twee platformen met afdwingen zonder vergelijkbare vastlegging.

Waarom zwakt juist de enige bewijsstroom voor een heel park het afdwingen af?

De documentatie definieert twee learning-mogelijkheden met een tegengestelde uitwerking op de beveiliging. learningModeLogging legt elke mislukte toegangscontrole vast en laat het afdwingen ongemoeid: toegang blijft geweigerd. permissiveLearningMode legt elke toegangscontrole vast en staat die toe, wat de documentatie afgezwakt noemt: de container dwingt deny-by-default niet meer af. Daarna koppelt de documentatie er drie stromen aan, en juist die koppeling verdient een tweede lezing. De ontwikkelaarslus krijgt de audit-vlag, afgezwakt. De stroom voor applicaties en eindgebruikers krijgt weigeren-en-vastleggen, afgedwongen. De derde heet Fleet auditing, richt zich volgens de documentatie op IT-beheerders, en loopt via captureDenials met mode op allow: afgezwakt, alles toegestaan.

Leg dat naast uw eigen omgeving. De enige stroom die Microsoft aan IT-beheerders richt, die u bewijs over een heel park zou geven in plaats van over één ontwikkelaarslaptop, is de stroom die deny-by-default niet meer afdwingt, en de documentatie vermeldt dat er geen UAC-melding aan te pas komt, omdat de mogelijkheid via de configuratie binnenkomt. Dezelfde pagina voegt toe dat het verzamelen en tonen van die weigeringen pas in later werk bovenop komt, dus geleverde aggregatie is er evenmin. Vandaag kunt u over het hele park afdwingen, of meekijken. Niet allebei.

Het woord om op te zoeken is niet "permissive". MXC weigert beide learning-namen binnen processContainer.capabilities al, ongeacht hoofdletters, en permissiveLearningMode is een gereserveerde mogelijkheid die de ingangen zelf invoegen. Het gaat om captureDenials met mode allow, hetzelfde alles-toestaan maar via gewone configuratie, plus de audit-vlag in een deploymentscript, een vlag waarvan de README waarschuwt dat die alle sandbox-beveiliging uitzet, en die wordt geweigerd voor elke Windows-backend behalve ProcessContainer. Beide zijn één grep in een pijplijn, en beide komen op vrijdag door de review omdat de woorden naar compliance klinken. Waar NVIDIA OpenShell zijn valkuil in een standaardwaarde verstopte, verstopt MXC die in een ingang.

Wat ontbreekt er nog aan de beheerlaag?

Twee onderdelen van centraal beheer zijn aangekondigd en niet uitgebracht. Intune-beleid voor MXC-processcontainers is niet algemeen beschikbaar; Microsoft noemt een toekomstige release zonder datum. Dat Entra agent- van gebruikersactiviteit onderscheidt staat op de planning, zonder tijdlijn. Over Agent 365 is precisie op zijn plaats: dat werd op 1 mei 2026 algemeen beschikbaar en bracht toen al het opsporen en blokkeren van lokale agents op beheerde Windows-werkplekken via Defender en Intune, te beginnen met OpenClaw. Wat nog komt, is dat uitbreiden naar agents in een MXC-container: een smaller gat dan de berichtgeving suggereerde, en nog steeds het gat waarin u zit.

Tot die er zijn, is het containment-beleid een ontwikkelbestand in de repository van de AI-leverancier en geen beheerde instelling in uw eigen omgeving. Het wijzigingsbeheer op uw stevigste agentgrens loopt daarmee via het releaseproces van iemand anders. Bent u gewend de vraag "wat is dit beleid en wie heeft het gewijzigd" uit Intune te beantwoorden, dan is dat antwoord nog niet beschikbaar voor juist de maatregel die het meest uitmaakt, en de vraag komt van de eerste auditor die begrijpt wat een agent is.

Eén detail dat uw privacy officer vóór een pilot wil weten. Officiële Microsoft-builds kunnen optionele diagnostische telemetrie versturen onder een gelaagd instemmingsmodel: de run kiest ervoor, de Windows-gebruiker moet hebben ingestemd, beheerbeleid moet verzameling toestaan en de applicatie moet de optie aanzetten. Een beheerder kan verzameling blokkeren maar niet namens de gebruiker instemmen. In een Nederlandse organisatie met een ondernemingsraad hoort dat gesprek vóór de uitrol.

Wat moet een Nederlandse IT-organisatie dit kwartaal besluiten?

Geschreven voor een IT-manager, informatiemanager, CIO of security officer bij een Nederlandse organisatie van ruwweg 250 tot 5.000 medewerkers, met een ICT-partner, een eigen IT-team, of beide. Vier besluiten, op volgorde.

Eén: besluit op welke platformen agentcode mag draaien en leg dat vast. Is bewijs van afdwinging een eis en geen voorkeur, dan is Windows met de ProcessContainer-backend nu de enige plek waar MXC dat bewijs levert. Twee: breng het containerbeleid onder wijzigingsbeheer dat u kunt zien. Het staat vandaag in de repository van de leverancier, dus maak het een acceptatiecriterium en vraag bij elke release de wijziging op, zoals u dat bij een firewallregel zou doen.

Drie: verbied alles-toestaand vastleggen en de audit-vlag in productie met een vastgelegde regel, gehandhaafd in de pijplijn en niet op een reviewlijstje. Vier, en in een omgeving met meerdere leveranciers het belangrijkste: leg de verdeling van eigenaarschap vast vóór de pilot en niet na het incident. Uw ICT-partner is eigenaar van de Windows-basis, de Intune-omgeving en Entra. De AI-leverancier is eigenaar van het containerbeleid, de lijst met toegestane bestemmingen en de vastgelegde weigeringen die daaruit komen. Niemand is eigenaar van beide, en in de ruimte tussen die twee leeft een agent zonder logging.

Die verdeling is precies ons werk: Crux Digits komt als AI-specialist naast uw bestaande ICT-partner werken, en wij beheren uw werkplekken of identiteitsplatform niet. Onze pagina over toegepaste AI voor de middelgrote onderneming beschrijft hoe die werkverdeling wordt ingericht, en de pagina over AI-implementatie gaat over de volgorde. Over de aangrenzende besluiten schreven we eerder over de stand van standaarden voor agent-identiteit en wat MCP en A2A niet kunnen loggen. Laatst bijgewerkt op 13 oktober 2026.

Veelgestelde vragen