MXC zet beleidsgrenzen rond agents; Bitwarden verschuift distributie naar commerciële builds

Microsoft zet met Execution Containers (MXC) een expliciete beleidslaag rond agentworkloads: bestanden, netwerk en UI kunnen buiten de agent om worden begrensd. Tegelijk verschuift Bitwarden zijn distributie: de reguliere appstore- en directe builds krijgen een commerciële licentie, terwijl een GPLv3-variant op GitHub blijft bestaan.

Voor privacygevoelige chatinvoer is er Rampart, een kleine browserfilter die PII vóór verzending probeert te maskeren. De kernbeperking blijft dat zo’n filter een aanvullende barrière is, geen vervanging voor retentiebeleid of een veilige modelprovider.

MXC is GA: containmentbeleid los van de agent zelf

Microsoft heeft Microsoft Execution Containers algemeen beschikbaar gemaakt als policygedreven uitvoeringslaag voor onbetrouwbare code en agentworkloads. Een policy kan onder meer bepalen welke paden alleen leesbaar of beschrijfbaar zijn, welke netwerkverbindingen mogen, en of toegang tot desktop en UI is toegestaan. De bedoeling is dat model, plugin of gegenereerde code die grens niet zelf kan verruimen.

MXC kiest daarbij uit verschillende backends: process-containers op Windows, macOS en Linux; een aparte Windows-sessie voor zwaardere desktopisolatie; WSL-containers op Windows; en experimentele microVM’s op Windows en Linux. De processroute leunt volgens Microsoft op AppContainer, Seatbelt of Bubblewrap. Dat maakt het voor cross-platformagenten interessanter dan een Windows-specifieke sandbox, maar de isolatie-eigenschappen verschillen nadrukkelijk per backend.

Praktisch nuttig zijn de drie modi. Enforcement blokkeert ongeoorloofde toegang, Learning blokkeert én logt die poging, en Permissive laat haar tijdens policyontwikkeling nog door maar registreert wat de uiteindelijke policy zou weigeren. Gebruik die laatste modus niet als productiegrens: hij is er om benodigde rechten zichtbaar te maken, niet om een agent veilig te laten draaien.

De aankondiging noemt komende Entra-identiteit en Intune-beleid; dat zijn dus nog geen huidige garanties. Ook lost een file- en netwerkpolicy niet automatisch rechten in Jira, cloudaccounts of andere externe systemen op. Begin met een kleine werkmap, loopback/netwerk standaard dicht en test expliciet welke credentials, subprocessen en mountpunten bereikbaar blijven. Microsofts MXC-overzicht met backends en modi · HN-discussie

Bitwarden maakt commerciële builds de standaarddistributie

Bitwarden schrijft dat de volgende apps in appstores commercieel gelicentieerde builds worden; hetzelfde geldt volgens een verduidelijking voor directe downloads vanaf de eigen downloadpagina. Bestaande apps blijven volgens Bitwarden werken en er is geen directe actie vereist. De GPLv3 OSS-versie blijft op GitHub verschijnen, met de huidige functies in beide varianten.

De belangrijke nuance staat in dezelfde discussiedraad: Bitwarden zegt dat toekomstige componenten per geval onder een commerciële licentie kunnen vallen en dan alleen in die build bestaan. De broncode daarvan blijft volgens het bedrijf wel zichtbaar op GitHub, maar ‘bekijkbaar’ is iets anders dan GPL- of andere vrije softwarelicentie. Daarmee verandert vooral de zekerheid over de toekomstige featurepariteit, niet de huidige mogelijkheid om zelf te hosten.

Bitwarden stelt expliciet dat self-hosting en third-partyservers niet veranderen en dat de maatregel repackaging en doorverkoop moet raken. Dat is voor bestaande gebruikers geruststellend, maar geen langetermijnbelofte over welke nieuwe functies buiten de OSS-build vallen. In de HN-discussie draait de kritiek vooral om die open vraag; dat zijn individuele reacties, geen bewijs dat self-hosting nu verdwijnt.

Voor teams met Bitwarden of Vaultwarden als exitstrategie is dit reden om de eigen afhankelijkheid tastbaar te maken: leg vast welke clientbuilds, browserextensies, mobiele apps en serverfeatures vereist zijn; test export en herstel; en volg nieuwe functies op licentie en protocolcompatibiliteit. Een onmiddellijke migratie volgt niet uit deze aankondiging, maar passief aannemen dat de builds permanent gelijk blijven evenmin. Bitwarden-forumbericht en verduidelijkingen · HN-discussie

Rampart filtert PII in de browser, maar claimt geen volledige privacy

Het Amerikaanse National Design Studio heeft Rampart open source gemaakt: een browsercomponent die vóór verzending chatinvoer op persoonsgegevens controleert. Een deterministische laag met regexes en validaties richt zich op gestructureerde gegevens zoals kaartnummers, e-mailadressen, telefoonnummers en ID’s; een MiniLM-model moet onder meer namen en adressen herkennen. Volgens het project is de volledige model- en tokenizerdownload 14,7 MB en draait de filtering lokaal via WebGPU.

Dat is een bruikbare architectuur voor applicaties die een extra lokale controle willen vóór een prompt naar een externe dienst gaat. Rampart noemt Nederlands naast zes andere talen en rapporteert 98,42% private-term recall op een eigen, afgeschermde set van 30.000 OpenPII-voorbeelden. Die score is echter een makersmeting op een specifieke dataset; hij zegt niet hoeveel echte Nederlandse bedrijfs- of zorgteksten door de mazen glippen.

Belangrijker: een PII-filter kan samenvoegbare, op zichzelf onschuldige details niet betrouwbaar als identificeerbaar verband herkennen. Ook 98,42% recall laat missers over. Zie dit daarom als defense in depth naast dataminimalisatie, toegangscontrole en een provider met passend retentiebeleid — niet als grond om gevoelige informatie voortaan zonder risico naar een chatbot te sturen. Rampart: ontwerp, benchmark en beperkingen · HN-discussie

Verder nog

• Nieuwe WebSockettest zet Node hoger dan verwacht: Daniel Lemire herhaalde zijn vergelijking van Node, Bun en Deno met een aangepaste methode en een in C geschreven client. Zijn samenvatting is dat Node in deze specifieke WebSocketproef sterk presteert en Deno minder. De discussie rond de post wijst er terecht op dat dit ook iets kan zeggen over μWebSockets.js en Node-compatibiliteit; zonder de volledige meetopzet is het geen algemene ranglijst voor runtimes. Lemires testmelding
• C-strtod heeft geen uniforme foutcheck buiten POSIX: een technische analyse laat zien dat standaard-C voor overflow afhankelijk is van math_errhandling, terwijl underflow niet altijd gemeld hoeft te worden. Voor ongeldige invoer moet je volgens de besproken standaardsemantiek endptr vergelijken met de oorspronkelijke pointer; alleen errno checken is niet portabel. POSIX legt strengere errno-regels op, maar ook daar kan ongeldige invoer per libc verschillen. Analyse met codevoorbeelden · Lobsters-discussie
• Vier theorem provers naast dezelfde priemgetallenbewijsopgave: een auteur formaliseerde Euclides’ bewijs in Lean, Isabelle/HOL, HOL4 en Agda. De vergelijking is nadrukkelijk persoonlijk en beperkt tot één bewijs, maar maakt een nuttige ontwerpkeuze zichtbaar: Lean en Isabelle bieden interactieve tussenstappen, terwijl Agda constructief blijft maar vrijwel geen automatisering heeft. De opgeslagen pagina is afgekapt; behandel dit als een inkijk in workflowverschillen, niet als volledige of neutrale toolselectiegids. Vergelijking · Lobsters-discussie