Microsoft løftede på Build 2026 sløret for Microsoft Execution Containers, MXC. VentureBeat beskriver det som et OS‑niveau, policy‑drevet lag i Windows og WSL. Pointen er let at mærke, hvis man har prøvet at sætte agenter i produktion: klare grænser, stærk identitet og audit, så man tør give agenter rigtige opgaver uden panik i supporten.
Hurtig tjekliste for CTO, CISO og AI‑ops
- Planlæg en 6‑ugers pilot med to isolationsniveauer (process‑isolation og micro‑VM) og mål kold/varm start, CPU/RAM, I/O‑latens og værktøjslatens pr. niveau.
- Bind agenter til Entra‑identiteter og test token‑levetid, rotation og re‑auth i lange kørsler.
- Etabler central logging med felter: policy_id, agent_id, initiator, timestamp, action, result, error_code, correlation_id.
- Indfør human‑in‑the‑loop ved højrisko‑handlinger, fx skrivning til delte drev eller eksterne API‑kald.
- Skriv runbooks for policy‑blokering, skift af isolation og hurtig rollback, og kør en bordøvelse.
- Afklar med leverandører: SLA ved agentfejl, ansvarsgrænser og placering af logs.
Det er vores korte version. Resten folder konsekvenserne ud og peger på faldgruber, vi selv har set i drift.
Hvad MXC er teknisk
MXC leveres som SDK og policy‑model indlejret i Windows og Windows Subsystem for Linux, ifølge VentureBeat og Microsofts Build‑materiale. Man deklarerer, hvad en agent må, og kernel håndhæver grænserne ved kørsel. Det omfatter adskillelse fra desktop, udklipsholder, UI og inputenheder, så en agent ikke rører brugerens session uden tilladelse.
MXC tilbyder et sammensætligt sandbox‑spektrum, der spænder fra let process‑isolation (som GitHub Copilot CLI allerede benytter) til micro‑VMs, Linux‑containere og i den tunge ende hele cloud‑instanser på Windows 365, jf. VentureBeat. For enterprise betyder det, at man kan matche isolationsniveau til risiko og behov, på OS‑laget.
Hvem er med på vognen
VentureBeat skriver, at OpenAI og Nvidia er on board. Det er VentureBeats rapportering; vi har ikke set separate statements fra Microsoft, OpenAI eller Nvidia. Hvis involveringen holder, kan det pege mod samspil mellem model‑ og hardware‑økosystem, optimeringer i værktøjskæder og kortere vej for agentrammer på Windows. Brug det som signal, ikke som kontrakt. Spørg ind, før I binder jer.
Sikkerhedsvinklen der flytter noget
Agenter udvider angrebsfladen. De læser filer, skriver kode, kalder værktøjer, går på nettet. Når handlinger styres via prompts og værktøjskald, smuldrer mange hegnspæle fra klassiske apps. OS‑niveau kontrol giver derfor mening. Kernel‑håndhævede grænser og UI/clipboard‑separation er mere robuste end at gemme sig bag en API‑gateway til én tjeneste.
Fleksibilitet i isolation er praktisk. Nogle opgaver kræver lav latens og lokal disk, andre kræver fuld kapsling. Vi havde en dansk kunde, hvor en build‑pipeline røg i hegnet, fordi en agent fik adgang til en forældet delt mappe. Den slags er netop, hvad stramme MXC‑policies kan stoppe.
Konsekvenser for implementering
At vælge en sandkasse er ikke et klik i et GUI. CI/CD skal bygge, signere og deploye agentpakker med de rette MXC‑policies og binde dem til identiteter. I skal styre images, eventuelt særskilte WSL‑distroer, og udvide tests til at dække hvert isolationsniveau, I bruger. Logging og audit skal ind i samme pipeline, ellers får I hegn uden sporbarhed.
Ydelse er et kompromis. Process‑isolation er letvægts, micro‑VMs og cloud er tungere. Der er ingen offentlige tal i de materialer, vi har set. Mål derfor selv pr. profil: 1) kold/varm starttid, 2) CPU‑ og RAM‑overhead over 1/5/15 minutters belastning, 3) I/O‑latens på lokale og netværksdrev, 4) throughput under peak (jobs/minut), 5) værktøjslatens for eksterne kald, 6) fejlrate ved isolationsskift.
Testdesign og målinger
Lav en enkel testmatrix med rækker for process‑isolation, container, micro‑VM og cloud‑instance, og kolonner for ovenstående metrikker. Kør mindst 30 gentagelser per metrik for kold/varm start, og to belastningsprofiler: burst (kort, høj intensitet) og steady (15 minutter jævn last). Log miljøvariabler, image‑versioner og policy‑hash for reproducerbarhed.
Hold testdata små og deterministiske i første omgang (fx 100 ens jobs), og indfør derefter variation i inputstørrelse. Sammenlign også fejlopførsel: hvordan ser genopretningen ud, hvis et værktøj kaster netværksfejl i micro‑VM kontra process‑isolation.
Identitet, audit og governance
VentureBeat beskriver, at MXC binder hver agent til stærk identitet, lokalt eller via Entra, så handlinger kan tilskrives, revideres og styres. Det kræver, at jeres IdP‑opsætning følger med: provisioning‑flows, token‑levetider, nøgle‑rotation og nød‑deaktivering af kompromitterede konti, også uden for kontortid.
Log skemaet bør være eksplicit og ensartet: policy_id, policy_version, agent_id, run_id, initiator, timestamp, action, target, result, error_code, correlation_id, isolation_level. Uden det bliver revision og root cause‑analyse gisninger.
Drift og support i virkeligheden
Runbooks skal opdateres. Incident‑respons skal dække nye hændelser: policy‑blokeringer, UI‑adskillelse der stopper et flow, identitetsbinding der fejler under lange kørsler. Overvågning skal have hooks ind i MXC‑laget, ellers ser I kun symptomer i applikationen. Rollback bliver mere kompleks, fordi et policy‑skift kan ramme flere teams på én gang.
Vi havde en kunde, hvor en simpel agent, der sorterede PDF‑bilag, standsede en hel fakturabatch, fordi udklipsholder var blokeret i et baggrundsscript. Med eksplicit UI/clipboard‑separation vil det enten være forventet og testet, eller forbudt. Begge dele slår tilfældigheder.
Begrænsninger og åbne spørgsmål
Der mangler offentlige performance‑data. Kompatibilitet for tredjepartsagenter, som ikke er Microsoft‑first, er ubeskrevet i kilderne. Multi‑tenant i Windows 365 og ejerskab af logs dér er uklart. Vi afventer dokumentation og planlægger selv at teste tidligt.
Vi savner også præcise detaljer om governance‑API’et: hvor fint kan man styre ressourcer, netværk og systemkald. VentureBeat beskriver principperne, og Microsoft nævner integration i Windows/WSL. Granulariteten må måles, når SDK’et lander.
Sikkerhedsmodeller i praksis
Let isolation i Copilot‑CLI‑stil er allerede i brug, som VentureBeat påpeger. AWS’ AgentCore Gateway og MCP‑tilgangen adresserer identitet og værktøjsadgang i netværkslaget, stærkt til autentifikation og server‑side sporing, men de rører ikke hostens UI eller filsystem direkte.
MXC’s styrke er host‑niveau kontrol. Den oplagte svaghed er mulig platformsbinding. Containers og micro‑VMs lyder fleksible, men værdien afhænger af, hvor nemt det er at køre samme agent med samme politik på tværs af Windows‑laptop, WSL og Windows 365. Et spektrum er kun stærkt, hvis skift mellem niveauer er trivielle i drift.
Tredjepartsafhængigheder
For eksisterende agentrammer bliver der sandsynligvis brug for hooks til policy‑deklaration, identitetsbinding og event‑logging. Indtil SDK‑dokumentation er offentlig, markér dette som åbne punkter i jeres arkitektur: hvor i jeres agent‑framework injiceres MXC‑policy, hvordan propagere agent_id/policy_id til logs, og hvordan håndteres fallback, hvis et isolationsskift fejler.
Kommercielle og licensmæssige implikationer
Når MXC er indlejret i Windows som SDK/policy, opstår et valg: standardisere agentdrift på Windows for at få kernel‑beskyttelse og stærk identitet, eller bevare en mere platformagnostisk strategi. Det er et forhandlingspunkt. Hvis partnere senere tilbyder glattere integrationer på Windows, kan incitamentet tippe.
Vendor lock‑in er en reel risiko. Få på skrift, hvordan logs kan eksporteres, hvordan policies versionstyres uafhængigt af OS‑opgraderinger, og hvad der loves af bagudkompatibilitet. Ellers kan man ende fastlåst.
Compliance uden illusioner
MXC kan hjælpe med sporbarhed, ansvar og audit. Det støtter krav i fx GDPR, og EU‑lovgivning om AI er på vej til at skærpe dokumentation og styring. Det ændrer ikke behovet for dataminimering, slettepolitikker og klare roller. MXC gør det lettere at håndhæve og dokumentere, ikke at springe compliance over.
Hvad man bør gøre nu
En prioriteret liste, der kan eksekveres på 4–8 uger. Start småt i et isoleret miljø, og vent med brede udrulninger til I har målinger.
- Definér en pilot med to isolationsniveauer og mål kold/varm start, overhead og latens pr. niveau.
- Bind agenter til Entra‑identiteter og test token‑fornyelse og nøgle‑rotation under lange kørsler.
- Log struktureret med policy_id, agent_id, initiator, timestamp, action, result, error_code og korrelations‑ID til applikationslogs.
- Indfør human‑in‑the‑loop for højrisko‑handlinger og dokumentér godkendelsesflow.
- Udarbejd runbooks for policy‑blokering, isolationsskift og rollback, og gennemfør en bordøvelse med cross‑team deltagelse.
- Afklar SLA’er, ansvarsgrænser og log‑placering med leverandører.
Snillds vinkel fra marken
Vi har set små agentflows udløse supportkald, når de rammer lokale filer og ældre UI’er. MXC’s UI/clipboard‑separation kan dæmpe det, hvis testcases og skærmoptagelser følger med. Ellers flytter problemet bare.
Vores nuværende tilbud er en kort, fokuseret 2‑trins workshop. Trin 1: kortlæg målprocesser og risiko, vælg 2–3 konkrete policies. Trin 2: design en MXC‑pilot. En simpel policy‑skabelon, vi starter med, ligner: resources: read[“C:\\agents\\workspace”], write[“C:\\agents\\out”]; network: allow[api.intra.local:443], deny[*]; ui: deny_all; clipboard: deny; identity: entra_service_principal. Ikke køn, men klar at teste på mandag.
Bordøvelse i praksis
Scenarie: En agent forsøger at uploade en CSV til en ekstern API. Policy blokerer udgående trafik. Forventede hændelser i loggen: action=net_connect, target=https://api.external.com, result=denied, error_code=policy_block, policy_id=finops_v1, agent_id=ap01, initiator=svc_finops, correlation_id=xyz123. Alarm går i SIEM, ansvarlig person vurderer anmodning, enten godkender midlertidig policy‑undtagelse eller kører rollback til sidste fungerende policy_version. Øvelsen handler om, om alarmen aktiveres, om loggen kan følges til initiator, og om rollback‑planen virker uden panik.
Modargumenter og svar
Skeptikere vil påpege Windows‑binding. Fair. De stærkeste garantier ligger tæt på kernel, og portabilitet bliver sværere. Andre vil pege på performance‑omkostninger ved micro‑VMs. Vi har ingen offentlige målinger i kilderne. Planlæg egne tests, før I ruller bredt ud.
Isolation er aldrig totalt. Spektrum‑designet lader jer vælge niveau pr. workflow. Vi har sjældent set ét niveau dække alt. Det er faktisk sund fornuft, for det tvinger til at vurdere risiko pr. opgave.
Hvad vi kigger efter de næste måneder
Tre ting: 1) Benchmarks fra Microsoft eller partnere for isolationsvalgene. 2) Integrationsvejledninger for tredjepartsagenter, ikke kun Microsofts egne. 3) Klarhed om log‑ejerskab og multi‑tenant i Windows 365.
Vi planlægger selv en test i vores lab, når SDK’et er tilgængeligt, med WSL og to policies, for at få konkrete tal. Målet er færre overraskelser i drift. Man opdager først forskellen, når man sidder med det i hænderne.
