I’ve had a good think about this, and while it’s good to see them finally answering bubblewrap, the truth is that we as an industry have been ridiculously at permissioning for some time and this does not solve this. It’s all very well saying we have read only resource access, but then you connect up to JIRA and all of a sudden you’ve got a different identity system, different resource model and and more complexity than you can shake a stick at.
Our current answer of just making the security model more and more complex isn’t working. It just means that, when things inevitably fail, we can say “well, they didn’t secure it correctly”. When even describing what is correct is hard, and setting it up is harder.
Honestly, this looks good, but we need a root and branch rethink of security if we want something that can protect us from rogue agents.
Microsoft security is a bimodal. They might have exquisite delineation for network resources in Sharepoint or Azure but consumer applications are a joke.
Excel, VSCode, Outlook, etc the permission model is a modal, "Do you trust this?" binary choice to enable full permissions to everything.
End users aren't expected to care about security and if they do, usually they are in an enterprise setting where it's taken care of automatically by enterprise settings.
Not to say it's good or bad, just not the target market.
> Excel, VSCode, Outlook, etc the permission model is a modal, "Do you trust this?" binary choice to enable full permissions to everything.
Because years of experience has shown that even users who should know better (developers) get extreme permission fatigue. The demand end users make is "it should just know without me having to click 'approve' all the time." Well, that's tough. You're basically stuck between a rock (fine-grained permissions) and a hard place (don't make me deal with it).
Seriously. Mobile devices have done a better job with this (in some ways) but it really should be a standardised thing of least permissions by default. And way. Way less confusing.
How do you describe the various different capabilities and access modes that a software application might need in a way that a non-technical user can comprehend and make decisions about. Even at a high level "access local files" or "access the network" is a distinction that many people will not fully understand.
I feel like there's got to be something more core around how many things we could make revertable. You can't "un-leak" a document, but you could reverse financial transactions / structure as escrow, and we know that having version control removes certain permanent loss scenarios.
Sometimes this may be just law. In the UK we have "direct debit" from accounts which fundamentally lets companies I approve take money from my account - as much as they choose. But the way of managing that risk is that banks will immediately and in full refund any money taken if I say so. Frankly lots of payment is the same online, we hand over enough information for the other party to take money from us, rather than explicitly sending it - with guarantees that we can get it back if it shouldn't have been allowed.
They tried to do proper sandboxing and capabilities and such with UWP around the Windows 8 timeframe and developers at the time totally revolted and claimed Microsoft was taking away their freedom lol. Because clearly every app needs full disk and network and key logging access.
Sadly, skimming the docs about how the different backends work makes me think that almost this entire project was done by a recent-gen LLM that interpreted its instructions as “make these things work at all costs” instead of “make a considered design that cleanly and securely fits its use case”.
Even the bubblewrap integration docs are basically a stream of consciousness vibe splat. I have approximately zero confidence in the results.
I am really struggling to imagine the abstraction that maps well to both bubblewrap and hyperlight. (They’re both great projects. They solve different problems in different ways, although both fit with the word “sandbox”.)
I’m sure I could come up with an awkward abstraction, but bad abstractions are a bad way to build secure systems.
LLM-driven programming doesn't necessarily imply slop. I know some very good developers that use LLMs carefully. As a research tool, code reviewer, Q&A about a large codebase, error message decoder, bug-hunter, and for first-pass implementations. They're always on the newest models and they care about the craft.
Not everybody is oneshotting with Sonnet medium and pushing unreviewable code.
The biggest news - and the most welcome one - is that W11 25H2 August cumulative update now allows anyone to set up App containers without administrative privileges. Then they built mxc on top of that.
This is a first step: uncertain, unstable, with many improvements to build upon; but always a step, enabling pioneers out there to explore something new.
Thats huge for enterprise, chatgpt desktop windows sandbox setup for users is a slog at the moment. Second big thing, Intune and identity via agent365 is on the way!
Most of the features are undocumented. I think because most of the behavior is not really defined and varies greatly between the different backends.
The backends are also not documented, you need to try out what's working and what isn't working. It doesn't explain the supported and unsupported features of each backend, neither their quirks.
A lot of behavior is surprising. For example if you have powershell in path on windows inside MXC it will just silently add the whole C drive with read-only permissions. Circumventing all other policies. https://github.com/microsoft/mxc/issues/1455
A lot of common error cases regularly happen and don't provide reasonable error messages. No documentation how to deal with them.
Check the issues on GitHub, there are many things that are expected to just work and they don't. One would at least expect some documentation why it doesn't work and where the limitations are: https://github.com/microsoft/mxc/issues
I disagree with that. MXC seems generally useful, but it's just poorly executed. I don't know about any cross-platform sandboxes that promise this kind of flexibility. There are always going to be differences between the backends, that's what makes it so complex, but equally useful if someone manages to deal with that complexity.
PS: velocity of the project is much lower than you would expect from a Microsoft project. It feels more like some hobbyist project, that deals with major bugs whenever the maintainer has time off.
I'd give it a whirl, but wiped my last windows machine a year ago precisely because stuff like this "just works" on linux. VM, containers, process containment all have matured options and have for years
Can I use this as a generic app permissions boundary or do I have to somehow fake it as an "agent"? We are well past the point where I need to be able to lock down that my music player has no ability to read my SSH keys or whatever.
Naturally, this will be gated to corporate customers - the plebs do not get access to better security unless they pay for a top tier license.
FANTASTIC question here. I've been locking down agents by running them as untrusted users (mostly linux here) as even docker boundaries aren't really great. Firecracker is a step in the right direction (older tech, sure, but useful). I really want a local hashicorp-like vault that I can give agents specific access permissions and it can take forever to review and manage those access boundaries.
I want a super-simple way to restrict an app's read/write to a specific dir. This is an incredibly useful solution that should have existed 20+ years ago. Why is this not a thing? This will basically solve most security issues immediately, in a super user-friendly way.
I don't believe this is what MXC accomplishes. Happy to be told otherwise!
You can launch arbitrary executables with MXC but different backends provide different security guarantees. Some backends like LPAC on Windows cause many exes to straight up fail during startup (powershell for instance)
I don't want to care about backends or whatever! And I wrote a programming lang / IDE / high-perf database. Imagine a "normal" user! Why the over-engineering? Thanks for the info, btw!
Docker Sandboxes are just that. The default file access is just the directory you create the sandbox under. They lock down most network access also, with whitelisting of domains and a firewall.
Microsoft has created trust issues (again) with their AI decisions.
This seems like a nice-to-have, but I’d much rather see Azure 2.0. A ground up rebuild of a cloud that has a modern foundation with networking and security architected natively.
> An agent cannot be its own security authority. It must run within a boundary defined by the developer or organization and enforced independently of the agent itself.
...so make it its own security principal, distinct from the human user?
> Without a managed execution boundary, the agent may decide that changing the server configuration is the fastest way to complete the task and potentially break the production site.
It can decide that even with the execution boundary in place, you know. What matters if it can actually act that out.
All in all, a very sloppily written announcement. Almost as if it was written by—
Windows already has a multi-user security context, with file- and API-level permissioning. We often call it “Users” or “RBAC”. I’ve read it and I’m still not sure what I can do now that I couldn’t a week ago.
It is possible with IIS, although it may require writing an actual plugin (which I did once, to do per-user routing; wasn't pleasant in the slightest). I don't know if it can be done out of the box.
I'm assuming they mean egress not ingress. Unless you restrict the machine egress to another machine running IIS both on the same AD and configure IIS as an http proxy with Windows Identity integration.
You're then brining an entire MS tech stack from the mid 2000s just to achieve something that has been solved by virtualization with a lot less caveats a long time ago.
I do mean egress. There was some way to force the machine to always go through the IIS proxy IIRC.
> You're then brining an entire MS tech stack from the mid 2000s just to achieve something that has been solved by virtualization with a lot less caveats a long time ago.
Well, yes. Honestly, it'd be nice to have an OS where recursive virtualization is a built-in primitive instead of whatever the hell we've been doing for the last 40 years over and over.
Pretty trivial to do on Linux. I do this for, e.g., apps I only want to talk to other specific apps. As a dumb example, it’s easy for gate something so it can only talk to Google.
Yes, you can apply firewall rules per process on both platforms. I believe you can also set nftable rules on Linux or WFP rules on Windows per uid/gid. However, any daemon running under a different uid can still proxy traffic for the user, so now you need to go and figure out all the daemons/services running on the machine that might allow that (printers, resolved, dockerd, etc) and see if there is a way you can trick them into sending the traffic on your behalf. privilege escalation through an insecure daemon running in a different security boundary is always the hardest part when you're dealing with these multi-user per machine systems. It's a massive attack service that you now need to worry about.
It's more deterministic to put an external proxy completely outside the machine, and treat the entire machine as 1 context then filter traffic externally. (externally can mean outside a VM on the same machine)
The same-machine-multi-user security paradigm has been dead for a long time. Even on linux, you pretty much assume root or non-root and leave it at that. You then use other layers (namespacing, kvm, etc) to enforce actual security isolation and controls.
root/non-root split is almost entirely used as a "don't let people accidentally shoot themselves in the foot" mechanism these days. Like you don't want your point-of-sale operator to accidentally disable the network or mess up the firewall rules effectively bricking the machine. Requiring an IT person to make the trip to fix it for them. But you would never "trust" the separate user profile on that POS machine as something keeping a purposefully malicious employee out of a secure system. The entire machine, regardless of the user profile, is the same security context. The uid/gid concept is an antique from the 80s that stopped working a long time ago. It's just an organizational primitive now for the most part.
I remember the fun days of the 90s and early 2000s when there were shared machines that a ton of people would ssh or rdp into with different user account and "share compute". It was fun, but absolutely no bueno for a long time now.
> The same-machine-multi-user security paradigm has been dead for a long time.
I ... what? Huge swaths of the computing landscape depend entirely that model. Schools (from primary to academic research), Windows Active Directory workplaces, thousands of cheap VPS providers ... the list is very long. All of those contexts absolutely use user accounts on the same running OS kernel as a security boundary. I've seen more than a few academic and government worksites where effectively radioactive data owned by one user was on the physical machine that other users routinely used--just not in an account they could access. Those places' infosec history wasn't perfect, but not because of the insider-threat-on-shared-machine risk.
In cloud/webtech, I think it's easy to overlook just how many massive organizations rely on stuff like shared AD workstations, cheap user-based shared hosting, or shared HPC a la "every member of the university gets an account on the SLURM cluster and we slice compute allocations by account--and separate accounts prevent the new intern from seeing protected IP".
Like, malicious employees can attack such systems, yes. But with adequate mitigations (network partitioning, internet access control, auditing/telemetry, good SEIM, user data encryption where appropriate, patching...all the usual good practices) this is a perfectly viable security model. Not perfect, but nothing's perfectly secure and every security paradigm has tradeoffs.
Those environments aren't dinosaurs or asking for a security disaster; they've made considered risk assessments and decided that the multi-user-machine security model works for them.
I’ve had a good think about this, and while it’s good to see them finally answering bubblewrap, the truth is that we as an industry have been ridiculously at permissioning for some time and this does not solve this. It’s all very well saying we have read only resource access, but then you connect up to JIRA and all of a sudden you’ve got a different identity system, different resource model and and more complexity than you can shake a stick at.
Our current answer of just making the security model more and more complex isn’t working. It just means that, when things inevitably fail, we can say “well, they didn’t secure it correctly”. When even describing what is correct is hard, and setting it up is harder.
Honestly, this looks good, but we need a root and branch rethink of security if we want something that can protect us from rogue agents.
Microsoft security is a bimodal. They might have exquisite delineation for network resources in Sharepoint or Azure but consumer applications are a joke.
Excel, VSCode, Outlook, etc the permission model is a modal, "Do you trust this?" binary choice to enable full permissions to everything.
End users aren't expected to care about security and if they do, usually they are in an enterprise setting where it's taken care of automatically by enterprise settings.
Not to say it's good or bad, just not the target market.
End users should be expected to care about security. They should not be the only guard rail, but they are part of the defense in depth plan.
You do know about all those security training courses HR makes your take every year that you skip over?
Unfortunately they are there for compliance, unless there is a strong IT in place, which then again, makes them hated by everyone else.
VSCode is targeted at a step above the standard end user, but even there extensions are not sand-boxed and the Workspace Trust is a single toggle.
Don't even get me started on PowerBI...
> Excel, VSCode, Outlook, etc the permission model is a modal, "Do you trust this?" binary choice to enable full permissions to everything.
Because years of experience has shown that even users who should know better (developers) get extreme permission fatigue. The demand end users make is "it should just know without me having to click 'approve' all the time." Well, that's tough. You're basically stuck between a rock (fine-grained permissions) and a hard place (don't make me deal with it).
Seriously. Mobile devices have done a better job with this (in some ways) but it really should be a standardised thing of least permissions by default. And way. Way less confusing.
How do you describe the various different capabilities and access modes that a software application might need in a way that a non-technical user can comprehend and make decisions about. Even at a high level "access local files" or "access the network" is a distinction that many people will not fully understand.
I feel like there's got to be something more core around how many things we could make revertable. You can't "un-leak" a document, but you could reverse financial transactions / structure as escrow, and we know that having version control removes certain permanent loss scenarios.
Sometimes this may be just law. In the UK we have "direct debit" from accounts which fundamentally lets companies I approve take money from my account - as much as they choose. But the way of managing that risk is that banks will immediately and in full refund any money taken if I say so. Frankly lots of payment is the same online, we hand over enough information for the other party to take money from us, rather than explicitly sending it - with guarantees that we can get it back if it shouldn't have been allowed.
They tried to do proper sandboxing and capabilities and such with UWP around the Windows 8 timeframe and developers at the time totally revolted and claimed Microsoft was taking away their freedom lol. Because clearly every app needs full disk and network and key logging access.
Sadly, skimming the docs about how the different backends work makes me think that almost this entire project was done by a recent-gen LLM that interpreted its instructions as “make these things work at all costs” instead of “make a considered design that cleanly and securely fits its use case”.
Even the bubblewrap integration docs are basically a stream of consciousness vibe splat. I have approximately zero confidence in the results.
(reposted from the other copy of basically this post: https://news.ycombinator.com/item?id=50026061)
I've watched the project for a while and tried different versions. It all looks very sloppy. And documentation is basically non-existent.
I think it's a good idea to create such an abstraction, but it's still far away from a 1.0 release.
I am really struggling to imagine the abstraction that maps well to both bubblewrap and hyperlight. (They’re both great projects. They solve different problems in different ways, although both fit with the word “sandbox”.)
I’m sure I could come up with an awkward abstraction, but bad abstractions are a bad way to build secure systems.
LLM driven programming is now mandatory at many companies, even more so at those that sell AI products.
LLM-driven programming doesn't necessarily imply slop. I know some very good developers that use LLMs carefully. As a research tool, code reviewer, Q&A about a large codebase, error message decoder, bug-hunter, and for first-pass implementations. They're always on the newest models and they care about the craft.
Not everybody is oneshotting with Sonnet medium and pushing unreviewable code.
I thought the role model is how DHH does coding. /s
I don't see why I want to use this wrapper over using bubblewrap directly.
Maybe Microsoft can claim they have a cross-platform policy but I doubt people want to use it.
My comment on the other thread: https://news.ycombinator.com/item?id=50018898
The biggest news - and the most welcome one - is that W11 25H2 August cumulative update now allows anyone to set up App containers without administrative privileges. Then they built mxc on top of that.
This is a first step: uncertain, unstable, with many improvements to build upon; but always a step, enabling pioneers out there to explore something new.
Thanks for sharing!
Thats huge for enterprise, chatgpt desktop windows sandbox setup for users is a slog at the moment. Second big thing, Intune and identity via agent365 is on the way!
How are you creating the sandbox or you do specifically mean any requested sandboxing the from the Windows Store running ChatGPT desktop app?
I'm talking about this being the offered path for centralized provisioning of the windows sandbox for ChatGPT Desktop https://learn.chatgpt.com/docs/windows/windows-sandbox#it-le...
With that- I was running into essentially what is described here https://github.com/openai/codex/issues/47383
What are these people running from? They're not! They're running to the world's toughest competition in town!
Most Extreme Elimination Challenge (MXC)
https://en.wikipedia.org/wiki/Most_Extreme_Elimination_Chall...
I've tried it, it's not a 1.0 release. This is more like an early tech preview.
Can you elaborate on this?
Most of the features are undocumented. I think because most of the behavior is not really defined and varies greatly between the different backends.
The backends are also not documented, you need to try out what's working and what isn't working. It doesn't explain the supported and unsupported features of each backend, neither their quirks.
A lot of behavior is surprising. For example if you have powershell in path on windows inside MXC it will just silently add the whole C drive with read-only permissions. Circumventing all other policies. https://github.com/microsoft/mxc/issues/1455
A lot of common error cases regularly happen and don't provide reasonable error messages. No documentation how to deal with them.
Check the issues on GitHub, there are many things that are expected to just work and they don't. One would at least expect some documentation why it doesn't work and where the limitations are: https://github.com/microsoft/mxc/issues
Thanks!
This actually confirms my guess: https://news.ycombinator.com/item?id=50018898
I disagree with that. MXC seems generally useful, but it's just poorly executed. I don't know about any cross-platform sandboxes that promise this kind of flexibility. There are always going to be differences between the backends, that's what makes it so complex, but equally useful if someone manages to deal with that complexity.
> I don't know about any cross-platform sandboxes that promise this kind of flexibility.
But if it doesn't deliver...?
And maybe no other tools tried to do this because it's not a good idea in the first place (and I have plenty to say about that)?
PS: velocity of the project is much lower than you would expect from a Microsoft project. It feels more like some hobbyist project, that deals with major bugs whenever the maintainer has time off.
I'd give it a whirl, but wiped my last windows machine a year ago precisely because stuff like this "just works" on linux. VM, containers, process containment all have matured options and have for years
I thought this was going to be Microsoft's version of docker.
https://xkcd.com/2044/
Can I use this as a generic app permissions boundary or do I have to somehow fake it as an "agent"? We are well past the point where I need to be able to lock down that my music player has no ability to read my SSH keys or whatever.
Naturally, this will be gated to corporate customers - the plebs do not get access to better security unless they pay for a top tier license.
There are many things that would be good to lock down. NPM install comes to mind.
I wonder if I will be able to integrate this with dev containers somehow, so my dev container could run in stricter isolation.
I've seen folks using the VS Code workspaces concept for this. It's a bit limited but a good step in the direction I prefer.
VS Code workspaces doesn't seem to offer any protection:
https://code.visualstudio.com/docs/editing/workspaces/worksp...
Maybe you use GitHub codespaces?
No, I did mean VS Code workspaces. Now I'm going to go down this rabbit hole to better understand the boundary limits :)
I did some reading of the docs and can't see anything in VS Code workspaces that would help.
FANTASTIC question here. I've been locking down agents by running them as untrusted users (mostly linux here) as even docker boundaries aren't really great. Firecracker is a step in the right direction (older tech, sure, but useful). I really want a local hashicorp-like vault that I can give agents specific access permissions and it can take forever to review and manage those access boundaries.
Indeed, Linux users pretty much provide enough protection and if you are willing to fiddle with SELinux you can get whatever you need.
I guess buy a Mac then.
I want a super-simple way to restrict an app's read/write to a specific dir. This is an incredibly useful solution that should have existed 20+ years ago. Why is this not a thing? This will basically solve most security issues immediately, in a super user-friendly way.
I don't believe this is what MXC accomplishes. Happy to be told otherwise!
You can launch arbitrary executables with MXC but different backends provide different security guarantees. Some backends like LPAC on Windows cause many exes to straight up fail during startup (powershell for instance)
I don't want to care about backends or whatever! And I wrote a programming lang / IDE / high-perf database. Imagine a "normal" user! Why the over-engineering? Thanks for the info, btw!
Docker Sandboxes are just that. The default file access is just the directory you create the sandbox under. They lock down most network access also, with whitelisting of domains and a firewall.
Nope! Still possible to "get out". I want a kernel-level solution!
Microsoft has created trust issues (again) with their AI decisions.
This seems like a nice-to-have, but I’d much rather see Azure 2.0. A ground up rebuild of a cloud that has a modern foundation with networking and security architected natively.
> An agent cannot be its own security authority. It must run within a boundary defined by the developer or organization and enforced independently of the agent itself.
...so make it its own security principal, distinct from the human user?
> Without a managed execution boundary, the agent may decide that changing the server configuration is the fastest way to complete the task and potentially break the production site.
It can decide that even with the execution boundary in place, you know. What matters if it can actually act that out.
All in all, a very sloppily written announcement. Almost as if it was written by—
> ...so make it its own security principal, distinct from the human user?
That presumes the existence of a security context, which this product provides. Where do you configure the security principal otherwise?
Windows already has a multi-user security context, with file- and API-level permissioning. We often call it “Users” or “RBAC”. I’ve read it and I’m still not sure what I can do now that I couldn’t a week ago.
Can you restrict accessible IP ranges by user?
It is possible with IIS, although it may require writing an actual plugin (which I did once, to do per-user routing; wasn't pleasant in the slightest). I don't know if it can be done out of the box.
I'm assuming they mean egress not ingress. Unless you restrict the machine egress to another machine running IIS both on the same AD and configure IIS as an http proxy with Windows Identity integration.
You're then brining an entire MS tech stack from the mid 2000s just to achieve something that has been solved by virtualization with a lot less caveats a long time ago.
I do mean egress. There was some way to force the machine to always go through the IIS proxy IIRC.
> You're then brining an entire MS tech stack from the mid 2000s just to achieve something that has been solved by virtualization with a lot less caveats a long time ago.
Well, yes. Honestly, it'd be nice to have an OS where recursive virtualization is a built-in primitive instead of whatever the hell we've been doing for the last 40 years over and over.
Pretty trivial to do on Linux. I do this for, e.g., apps I only want to talk to other specific apps. As a dumb example, it’s easy for gate something so it can only talk to Google.
Yes, you can apply firewall rules per process on both platforms. I believe you can also set nftable rules on Linux or WFP rules on Windows per uid/gid. However, any daemon running under a different uid can still proxy traffic for the user, so now you need to go and figure out all the daemons/services running on the machine that might allow that (printers, resolved, dockerd, etc) and see if there is a way you can trick them into sending the traffic on your behalf. privilege escalation through an insecure daemon running in a different security boundary is always the hardest part when you're dealing with these multi-user per machine systems. It's a massive attack service that you now need to worry about.
It's more deterministic to put an external proxy completely outside the machine, and treat the entire machine as 1 context then filter traffic externally. (externally can mean outside a VM on the same machine)
A rather obvious question is why you have “resolved” running in the first place.
Or you could just run dockers, a VM, etc which is simply a roundabout way to get to the same thing.
The same-machine-multi-user security paradigm has been dead for a long time. Even on linux, you pretty much assume root or non-root and leave it at that. You then use other layers (namespacing, kvm, etc) to enforce actual security isolation and controls.
root/non-root split is almost entirely used as a "don't let people accidentally shoot themselves in the foot" mechanism these days. Like you don't want your point-of-sale operator to accidentally disable the network or mess up the firewall rules effectively bricking the machine. Requiring an IT person to make the trip to fix it for them. But you would never "trust" the separate user profile on that POS machine as something keeping a purposefully malicious employee out of a secure system. The entire machine, regardless of the user profile, is the same security context. The uid/gid concept is an antique from the 80s that stopped working a long time ago. It's just an organizational primitive now for the most part.
I remember the fun days of the 90s and early 2000s when there were shared machines that a ton of people would ssh or rdp into with different user account and "share compute". It was fun, but absolutely no bueno for a long time now.
> The same-machine-multi-user security paradigm has been dead for a long time.
I ... what? Huge swaths of the computing landscape depend entirely that model. Schools (from primary to academic research), Windows Active Directory workplaces, thousands of cheap VPS providers ... the list is very long. All of those contexts absolutely use user accounts on the same running OS kernel as a security boundary. I've seen more than a few academic and government worksites where effectively radioactive data owned by one user was on the physical machine that other users routinely used--just not in an account they could access. Those places' infosec history wasn't perfect, but not because of the insider-threat-on-shared-machine risk.
In cloud/webtech, I think it's easy to overlook just how many massive organizations rely on stuff like shared AD workstations, cheap user-based shared hosting, or shared HPC a la "every member of the university gets an account on the SLURM cluster and we slice compute allocations by account--and separate accounts prevent the new intern from seeing protected IP".
Like, malicious employees can attack such systems, yes. But with adequate mitigations (network partitioning, internet access control, auditing/telemetry, good SEIM, user data encryption where appropriate, patching...all the usual good practices) this is a perfectly viable security model. Not perfect, but nothing's perfectly secure and every security paradigm has tradeoffs.
Those environments aren't dinosaurs or asking for a security disaster; they've made considered risk assessments and decided that the multi-user-machine security model works for them.
That’s what I was thinking. This has been there since NT 3.1.
"...for running untrusted code (model output, ..."
Hmm...
How does this compare to WSL Containers or Hyperlight?
Its a good idea and enterprise customers will love it.