Windows-functie voorkomt dat OpenClaw willekeurige bestanden kan verwijderen

Microsoft komt met een functie voor Windows om de toegang tot bestanden en mappen van AI-agents te beperken. Daardoor kunnen die niet langer willekeurige bestanden verwijderen. Microsoft Execution Containers, MXC, komt later dit jaar uit.

MXC kan het proces of de sessie isoleren, maar ook een kleine VM starten om de AI-agent werk te laten doen, zegt Microsoft. Daardoor kunnen gebruikers, maar ook bedrijven, afdwingen dat AI-agents alleen tot bepaalde mappen toegang hebben en niet tot de rest. MXC moet een sandbox voor AI-agents gaan worden, zo redeneert Microsoft.

Het bedrijf kondigde dat aan op de eigen ontwikkelaarsconferentie Build. Onder meer OpenClaw, de populairste toepassing om AI-agents te bouwen, ondersteunt in een previewversie MXC. De functie zelf is nu ook te testen en moet later dit jaar in Windows komen.

MXC op OpenClaw voor Windows
MXC op OpenClaw voor Windows

Door Arnoud Wokke

Redacteur Tweakers

02-06-2026 • 20:36

32

Reacties (32)

Sorteer op:

Weergave:

Ik blijf het absurd vinden dat mensen een AI agent vertrouwen met volledige toegang tot hun PC, laat staan hun hele digitale leven. Als je ook maar een beetje weet hoe een LLM werkt dan snap je dat er weinig is dat gevaarlijker is dan dat.

Dat het verleidelijk is snap ik, lijkt mij ook wel handig om een 'echte' digitale assistent te hebben, maar zolang prompt injection een ding is en de onderliggende technologie gebaseerd is op het voorspellen van een volgend woord met behulp van ruis ga ik me er niet aan wagen.. Ik zie met Claude Code al vaak genoeg dat auto mode dingen doorlaat die echt wel flinke schade kunnen aanrichten, en die draai ik dan nog veilig afgeschermd van de rest.
Kun je daarvan voorbeelden noemen? Ik gebruik Claude Code een jaar op macOS zonder beperkingen (behalve dat macOS zelf wat beperkingen oplegt aan alle app). Misschien is het onverstandig; maar ik zie het nooit misgaan?

[Reactie gewijzigd door kamerplant op 2 juni 2026 21:07]

Ik gebruik Claude vooral als troubleshooter, want programmeren kan ik (gelukkig) nog altijd beter dan een ruisgenerator (alleen niet altijd sneller, maar liever goed dan snel..). Wat ik vooral merk is dat hij er vaak voor kiest om hele databases leeg te gooien en opnieuw te importeren, caches leeg te gooien, of in code dingen te omzeilen als debug stap.
Maar als we het verder trekken naar praktisch gebruik buiten development; als ik 'm vraag om mee te kijken waarom een Linux update niet wil installeren of waarom mijn Mac Mini traag is, of bijv. een foutmelding probeer uit te laten zoeken, dan stelt hij nogal snel dingen voor die toch vrij impactvol zijn (configs aanpassen e.d.). Allemaal prima, maar dat zijn wel dingen waar ik toch echt wel de controle over wil houden.
Mensen die zo'n chatbot volledige toegang tot alles geven spelen gewoon keihard met vuur. Ik moet er niet aan denken dat zo'n tool als OpenClaw mails gaat sturen vanuit mijn naam of mijn volledige inbox leeggooit omdat er ergens in een mailtje een prompt verstopt zat..
Ja eens, dan snap ik je!

Dan blijft staan: Als je aan een normaal project aan het werkt bent, dan gaan Claude Code écht niet ineens je mailbox leeggooien ofzo (tenzij prompt injection). Anyway, ook al doe ik het zelf: ik zou nooit iemand aanraden om de dangerously-skip-permissions flag gebruiken hoor :D . In het begin moest je Claude echt continue toestemming geven - toen is dit een ingeslopen manier van werken geworden :P
Als je aan een normaal project aan het werkt bent, dan gaan Claude Code écht niet ineens je mailbox leeggooien ofzo
Dat zeg je wel, maar hier was toevallig recent een mooi voorbeeld van.

tl;dr: een doodnormale testing library voor kotlin en java had een log regeltje toegevoegd die aan AI agents vertelde om het project weg te gooien.

Je mailbox leeggooien is wel een beetje vergezocht inderdaad, maar stel je hebt een veelgebruikte cli om je mails te beheren oid, is er dus best een kans dat claude zo'n command gaat proberen uit te voeren.

Ik zie net dat ze helaas issues uit hebben gezet op hun repo, en het originele issue kan ik zo niet terugvinden, maar deze maakt het ook wel duidelijk: https://web.archive.org/web/20260531164640/https://github.com/jqwik-team/jqwik/issues/710
(tenzij prompt injection)
Tja zolang promt injection zo simpel is als ergens wat tekst neerzetten, moet je er toch echt van uit gaan dat alle externe text die jij in je agent stopt een prompt injection kan bevatten
Dan blijft staan: Als je aan een normaal project aan het werkt bent, dan gaan Claude Code écht niet ineens je mailbox leeggooien ofzo (tenzij prompt injection).
Niet met opzet, maar een foutje is snel gemaakt. "rm -rf $home/$project" ... en dan blijkt $project niet te bestaan en wordt je hele homedir getrashed.
Ik had overlaatst iets gelijkaardig met CoPilot.
Ik was aan het troubleshooten waarom de Wazuh agent niet wou starten.
Copilot wou mij systemd unit files laten aanpassen om timeouts aan te passen en zelfs de ExecStart commando's aanpassen.
Ik controleerde zelf verder en er bleek gewoon nog een lock file aanwezig te zijn van een gefaalde startup.
Maar aan zoiets simpels had CoPilot niet gedacht.

Zowel met ChatGPT en met CoPilot (die ook GPT gebruikt overigens) merk ik dat ze ook altijd direct 5 stappen tegelijk willen uitvoeren om iets te troubleshooten i.p.v. eerst simpele dingen te testen en dan dieper te gaan onderzoeken.
Er zijn genoeg mensen die graag een Cortana (die van Halo) of een EDI (Mass Effect) naast zich hebben zitten. ;)
ik ben het tegelijk helemaal met je eens en helemaal met je on eens.

windows het OS heeft volledige toegang tot je bestanden en ook dat is niets meer of minder dan een zut-computercode die uiteindelijk functies aan aanroepen om dingen op het systeem te doen waaronder het formateren van disks.

wat maakt nou dat je windows daarmee kunt vertrouwen en andere software niet, hoevaak zijn er uiteindelijk bugs geweest in de verschillende OS'en die corrupte data veroorzaakten.

dat gezegd hebbende hebben we bij de verschillende AI-modellen behoorlijke hallucinaties gezien die zomaar dingen kunnen gaan doen die totaal niet de bedoeling zijn.

je moet er dus een bepaald evenwicht in zien te vinden ik zou dan ook eerder kiezen voor het genereren van een bash-script die de taak gaat uitvoeren dmv ai om dan eerst een handmatige check te doen of het script wel klopt om het dan handdmatig uit te voeren dan dat ik AI daatwerkelijk systeem-toegang geef

een andere oplossing zou kunnen zijn om AI alleen toegang te geven tot een version-controlled copy van je data-set denk aan een soort personal cloud waarin je met ai werkt als daily driver terwijl je de data ook gewoon nog lokaal op een backup nas hebt en misschien nog in een remote backup cloud off-site.


kortom er zijn echt wel manieren om data-safe met een AI-agent om te gaan zonder deze direct toegang te geven tot de nukes.
Ik denk dat er wel een wezenlijk verschil is tussen een OS als Windows dat vooral passief z'n werk doet terwijl jij bezig bent, en een chatbot die actief acties gaat uitvoeren op dat OS. Ja dataverlies kan altijd optreden, maar die kans is significant groter wanneer er automatisch dingen worden gedaan met die data.

Verder een heel leuk idee en het zou inderdaad heel mooi zijn om een volledige VCS op je OS te hebben. Je zou bijvoorbeeld de harness die je gebruikt kunnen instellen om een nieuwe ZFS snapshot van je data te maken voor iedere actie (die dan weer de vorige versie als parent heeft) zonder al te veel overhead. Maar niet heel realistisch scenario voor 99.99% van de mensen die domweg het commando op de OpenClaw website uitvoeren om aan de slag te gaan?
Ooh gelijk ook die steek onder water! Waarom?
Bizar genoeg zie ik het defensieve gedrag wel bij meer mensen die fan zijn van AI. En het doet me ook wel wat denken aan de flamewars tussen windows gebruikers en linux gebruikers.
Je moet een AI gewoon geen admin-rechten geven, dan ben je er al dunkt mij.

Ik ben trouwens ook zeer benieuwd of MS hun eigen AI heeeel toevallig wel system-rechten gunt of ook onder het mxc stramien laat vallen.
Je moet een AI gewoon geen admin-rechten geven, dan ben je er al dunkt mij.
Nee, dan ben je er niet, want met de gewone user rechten (van de ingelogde user) heeft de AI volledig toegang tot al jouw eigen bestanden (lezen, schrijven, verwijderen en rechten aanpassen).
Maar... Dat is juist waarom men een OpenClaw gebruiken toch? Ik kan mij goed voorstellen dat je systeembestanden wil afschermen, maar userdata aan kunnen raken is juist wat het hele doel van dat spul is.
Aan kunnen raken wel (d.w.z. lezen), maar absoluut geen bestanden wijzigen of verwijderen. Daar heeft MS nu juist de Microsoft Execution Container (MXC) voor ontwikkeld om te zorgen dat de AI app/agent alleen leesrechten krijgt en verder geen schade kan aanrichten op je PC.
Nou zelfs lezen kan gevaarlijk zijn. Denk aan een prompt injection attack om wachtwoorden uit te lezen en te versturen naar een endpoint.
Aan kunnen raken wel (d.w.z. lezen), maar absoluut geen bestanden wijzigen of verwijderen. Daar heeft MS nu juist de Microsoft Execution Container (MXC) voor ontwikkeld om te zorgen dat de AI app/agent alleen leesrechten krijgt en verder geen schade kan aanrichten op je PC.
Het ligt natuurlijk erg aan de usecase, zoals @Triblade_8472 al stelt. Ik heb ook botjes die juist wel mijn data mogen veranderen, inclusief het wijzigen of verwijderen van bestanden. Ik gebruik OpenClaw niet maar het lijkt me een bot die juist wel schrijfrechten nodig heeft om echt goed te functioneren.

De aanpak van MS lijkt veel op mijn eigen aanpak. Botjes draaien in containers en krijgen bij voorkeur indirect toegang tot mijn data. Programmeerbotjes zijn het makkelijkste, die krijgen hun data van mijn centrale git server. Daarmee mogen ze doen wat ze willen maar alle veranderingen worden vastgelegd in git. Als het me niet bevalt draai ik de commits terug. Bij de wat gevoeligere projecten mag de bot niet direct naar de master-git schrijven maar sturen ze mijn pull-requests.

Het is gewoon noodzakelijk, ik heb al teveel mis zien gaan. Van botjes die mijn hele schijf proberen te wissen ("rm -rf $oeps"), pogingen om te hacken ("oh, ik heb geen rechten, laat ik kijken of ik tóch root kan krijgen door te zoeken naar wachtwoordbestanden of ssh-keys") tot het compleet verbouwen van mijn systeem ("Hey, je hebt geen rpm. apt-get install rpm. Hey, je hebt de libc rpm nog niet, laat ik die installeren .") tot het aanpassen van mijn compiler ipv van de progameerbug op te lossen.

Het is prachtig hoe handig die botjes soms om beperkingen heen werken, maar af en toe ook eng. Ik heb inmiddels expliciete instructies dat work-arounds niet zijn toegestaan. Als het niet netjes kan dan moeten ze maar een bugreport inschieten zodat ik er naar kan kijken.

[Reactie gewijzigd door CAPSLOCK2000 op 3 juni 2026 11:44]

Heb je zeker die post gemist van afgelopen week dat een AI via een omweg (user lid van docker groep) toch sudo had gedaan.
Dat is toch gewoon geweten. Docker draait vaak gewoon met sudo rechten, because reasons en daarom moet je altijd opletten met het draaien van onbekende containers. Docker heeft zelfs een lange tijd een introductie filmpje gehad in hun "Getting started"-tutorial waar ze dat mooi aantoonde.
Geen admin / sudo rechten is de basis, maar je zal (zoals MXC beoogt) ook isolatie van het file system moeten hebben (data die niet gelezen kan worden kan ook niet gelekt worden, om maar wat te noemen). Daarnaast wil je strikte controle over netwerk verkeer; als er vanuit de sandbox alsnog (al dan niet op basis van host level ssh keys) verkeer naar buiten toe mogelijk is, kan er van alles binnengehaald worden waar je geen controle over hebt.

Zero trust is er niet voor niets en agents is wel de laatste "gebruikerscategorie" waar je een uitzondering voor zou moeten maken.
Hot take, maar ik denk dat MS één van de eerste bedrijven is dat vermoed dat AGI nog heel ver weg is en al zeker niet economisch interessant. Dat leid ik toch af uit de stappen die ze terugzetten en het minder integreren van AI in hun producten. Waarmee ik niet wil zeggen dat AI en met name LLM een flop zijn of niet beter zullen worden, maar dat de stappen voorlopig niet meer zo spectaculair zullen zijn of meer gestuurd, o.a. door safeguards zoals Microsoft nu ontwikkeld.
Dat durf ik nog niet zo te stellen, MS wil eerder zelf in de arena stappen en minder afhankelijk worden van bv OpenAI. Microsoft unveils new AI models lessen reliance on OpenAI, lower costs
MXC is een leuk lapmiddel, maar eigenlijk wil je natuurlijk compleet van traditionele bestanden zoals wij ze nu kennen af en in plaats daarvoor een bestandssysteem dat versiebeheer ingebouwd heeft en waarbij de organisatie van bestanden los staat van waar ze zich bevinden. Dat we 45 jaar na het uitkomen van MS-DOS nog steeds een C-schijf gebruiken is natuurlijk heel raar.
Kan je wat verder toelichten wat je bedoelt?

Wanneer je zegt, versiebeheer onafhankelijk van bestandslocatie, bedoel je een soortvan git voor je gehele OS? Als ik je goed begrijp, lijkt mij dat onpraktisch en een overtreffende trap van reguliere backups, waar (om tal van redenen) al niet voldoende gebruik van wordt gemaakt door de gemiddelde consument.

En hoe relateert dat tot de C-schijf?
Als je een document of foto maakt, kan dat bestand nog steeds net als nu ergens op je SSD opgeslagen worden, maar ik plaats van in een FAT of NTFS tabel dit bestand te koppelen aan een locatie zou het op een andere manier gestructureerd kunnen worden. Je document en foto zouden bijvoorbeeld dmv tags die de inhoud of het doel beschrijven gelabeld kunnen worden om het later terug te vinden. Je kunt dan met een zoekopdracht bijvoorbeeld je volledige administratie kunnen vinden en kopiëren, of enkel de brieven die je naar de Belastingdienst hebt gestuurd, waar dan ook foto's bij komen die je hebt gemaakt van ontvangen correspondentie.

Wat ik met de C-schijf bedoel is dat je nu zelf moet bepalen in welke map je iets opslaat, maar deze structuur wordt ook gedeeld met systeem bestanden, applicaties, etc. Als (niet-Tweaker) gebruiker wil je die losse systeembestanden niet eens zien. Praktisch gezien heb je namelijk helemaal niks aan C:\Windows, C:\Program Files, etc, maar je krijgt het toch elke keer te zien als je even dat spreadsheetje opzoekt met daarin je WK-pool.

En ja, systeembestanden en applicaties moeten ook ergens opgeslagen staan, maar ook dat zou ergens rond kunnen zweven zolang het maar van de juiste tags is voorzien zodat je besturingssysteem weet welke applicaties beschikbaar zijn.

Mbt versiecontrole; Git slaat dit nu in je normale bestandssysteem op naast het bestand dat je aan het bewerken bent. Een AI-agent kan dit dus ook simpelweg weer verwijderen of aanpassen. MXC zorgt misschien wel dat zulke bestanden niet meer te benaderen zijn voor AI-agents, maar zodra die een script schrijven dat daarna in de user context draait kan het er nog steeds bij. Als versiecontrole een basisvoorziening is van het bestandssysteem dan worden wijzigingen (voor de AI-agent én gebruiker) op de achtergrond geregistreerd zonder manier om dit aan te passen. Er moet dan wel een regel zijn dat er bijvoorbeeld per bestand maximaal zoveel wijzigingen worden bijgehouden ivm benodigde schijfruimte, en dat je niet door een bestand snel 10 keer te editen de hele historie wist (het zou bijvoorbeeld hooguit één wijziging per dag op moeten slaan) zodat je altijd een paar dagen de tijd hebt om nog een backup terug te halen (wat ook een onderdeel van het bestandssysteem kan zijn ipv een handmatige actie).

Laatste puntje is dat, door bestanden los te koppelen van een exacte locatie, het ook veel makkelijker wordt om ze te syncen tussen verschillende computers en dat backups onderdeel van het hele proces kunnen zijn ipv een handmatige kopieeractie of een los te configureren app die het voor je regelt.

[Reactie gewijzigd door Skit3000 op 3 juni 2026 09:54]

Dank voor de verdere toelichting!

De dmv tags, hoe zouden die worden toegewezen in jouw beeld? Wanneer dat afhankelijk van de gebruiker zou zijn vrees ik dat je (juist voor de doelgroep die we hier suggereren te helpen) je er niet zover op vooruit gaat. Te veel voorbeelden gezien waarbij mensen simpelweg alles op een hoop gooien en dan zich afvragen waarom ze niets terug kunnen vinden, die doelgroep lijkt me nou niet bepaald waarschijnlijk om tags handmatig in te stellen, laat staan überhaupt te definiëren.

Ik geef je volstrekt gelijk dat merendeel van het file system niet relevant is voor de gemiddelde leek. Documenten (en laten we niet beginnen over de programma's die Documents als hun default voor install gebruiken...) en Downloads is wat de meeste nodig hebben. Dat achter een 'dev only' escalatie gooien, danwel de aanpak van MacOS, ligt voor de hand.

Wat betreft version control, ik kan me inderdaad voorstellen dat iets in die richting flinke meerwaarde heeft, al vrees ik dat het een hypothetical blijft in de praktijk. Je benoemt terecht de balans tussen version control, opslag, etc. Zie daar dan ook een uitdaging in wat 'voldoende' version VC betekent voor de gemiddelde gebruiker. Ik vrees dat daar nogal een spreiding in zit en er zelfs een risico bestaat dat iedereen gaat aannemen dat 'je toch wel die versie van 10 keer geleden kan terugpakken' totdat dat dan weer fout gaat.

Ontken niet dat het huidige file managing system inderdaad wat agrarisch is, maar een nieuwe balans daarin vinden is voor mij een klus te groot, dàt probleem laat ik aan de andere tweakers over ;)

[Reactie gewijzigd door Floriancitt op 3 juni 2026 11:21]

Tags bij afbeeldingen zijn misschien enkel de locatie en moment van opname. Dat clustert in ieder geval foto's van vakanties en dagjes uit bij elkaar. Verder kan je natuurlijk met beeldherkenning ook al wat extra informatie uit een foto halen.

Qua versiebeheer zouden mensen inderdaad gemakzuchtiger kunnen worden, maar opzich hoeft dat geen kwaad te kunnen als de regel is "de laatste bewerking op een dag wordt 10 dagen bewaard" in samenwerking met "er wordt elke week een externe backup gemaakt". Het kost natuurlijk beide wel schijfruimte, maar als je veel bestanden aan het bewerken bent kan je OS natuurlijk gewoon een melding geven dat je ruimte te kort komt ipv stilletjes oude revisies wissen.

De backup zelf zou tussen al je apparaten gedeeld kunnen worden, of (gecodeerd) op de server van een externe aanbieder (of op een apparaat van bijvoorbeeld een familielid, wederom gecodeerd).

Als je applicaties download zou de standaard moeten zijn dat deze gewoon direct geïnstalleerd worden (hoe dat er dan ook uit ziet) zonder dat je ooit het installatiebestand ziet.

Maar het is inderdaad niet iets wat zo maar gaat veranderen. Zeker als apps steeds meer verdwijnen tbv AI die ze just in time genereert voor de toepassing die je op dat moment nodig hebt, denk ik dat bestandsopslag ook meer en meer gaat verdwijnen van je eigen apparaten naar de cloud (of wellicht/hopelijk een NAS in je eigen meterkast zodat je er nog enigszins controle op hebt).
'Daardoor kunnen die niet langer willekeurige bestanden verwijderen.'

Maar wat als die 'bewaakte' bestanden niet zo willekeurig blijken zijn, en deze bestanden precies zijn waarmee Microsoft op de gebruiker's PC filesystem, die bestanden in kaart brengt en integreert in Microsoft-authored AI modellen ? Dan word het een AI model diversifactie-politieman/agent.

Ook word het weer een concurrentie verhaal, net zoals het aloude FAT patent waarop MSDOS en later ook Windows was gebouwd, later vervangen door NTFS. Allemaal technieken om data de structureren en data-integriteit te bewaken. Merk op dat het oorsponkelijke google business model was 'structuring the worlds data'.

Geef mij maar een OS waarbij alle componenten die data structuur- en integriteit garanderen volledig onder mijn eigen controle zijn, inclusief of er wel of geen backups gemaakt worden, en hoe die data via netwerk of attachable storage naar een andere plek worden verplaatst, inclusief onder welke voorwaarden en welke garanties dat gebeurt

[Reactie gewijzigd door cmpxchg op 3 juni 2026 06:49]

Wel eens gebruikt, maar toch echt in een geïsoleerde omgeving, kun je zelf aangeven tot hoe ver ie mag gaan.

Maar blijf toch liever zelf controle houden en dit als hulp gebruiken

Op dit item kan niet meer gereageerd worden.