From the NVIDIA edition of October 7, 2026
NVIDIA OpenShell RFC #2050: the Windows MXC driver translates OpenShell policy lossily (64 access-broadening errors across five example policies) and MXC host filtering is not yet enforced on Windows
NVIDIA (OpenShell open-source project) · Technology vendor (open-source agent sandbox) · Global
- Publisher
- GitHub — NVIDIA/OpenShell issues
- Original publication
- 2026-06-29T19:39:47Z
- Source retrieved
- 2026-10-08
- Event date
- 2026-10-07
What happened
An NVIDIA engineer's RFC (opened June 29, 2026, still open) designs OpenShell's native Windows support on MXC. Rather than porting OpenShell's Linux in-sandbox enforcer, it moves egress and L7 policy to a host proxy and uses MXC as a coarse kernel-level allowlist. It reports that across five OpenShell example policies every generated MXC config was schema-valid but lossy, with 64 access-broadening errors, 32 warnings and 4 info items; MXC cannot express port, protocol, per-binary or L7 rules. Its risk table says MXC allowedHosts/blockedHosts were not enforced on Windows, OCSF audit loses in-process events, credentials briefly appear in process arguments, and MXC defaults to allow when the network block is omitted.
Why it matters
Why now: on Oct 7 Microsoft made MXC generally available and said NVIDIA has integrated OpenShell into it. Public-sector security teams evaluating that combination should know, from NVIDIA's own design record, that on Windows the fine-grained OpenShell policies they may have reviewed on Linux are enforced by a host proxy, not by the OS container, and that audit coverage is narrower.
Evidence and measured results
Opened the GitHub issue page and the issue body and comments via the GitHub API (two comments: an RFC-number assignment and a stale-bot notice). Design analysis by the project, not a test of the shipped GA release.
Limitations and uncertainty
Design RFC dated June 29, 2026; the GA release may have changed some items (for example host-filter enforcement). Not an independent test. The issue was marked stale in July with no later activity visible.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-08; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Security teams may assume NVIDIA's agent sandbox gives the same guarantees on Windows as on Linux.
- Stakeholders
- CISO / security architecture
- Endpoint engineering
- Developer platform lead
- Audit or compliance office
- Discovery questions
- Which OpenShell policies have you approved, and on which OS?
- Do you rely on OCSF audit events for agent oversight?
- Who reviews policy changes when the platform updates?
- Value hypothesis
- A policy-fidelity review can prevent approving Windows agent pilots on the basis of Linux-only guarantees (interpretation).
- Potential engagement
- A short Windows policy-fidelity review: run the mapper on approved policies, document the loss report and test the host proxy.
- Unsupported claims
- Linux-equivalent isolation on Windows
- Complete OCSF audit coverage on Windows
- That the June RFC limits are unchanged in the GA release
Pre-sales engineering
Role takeaway
- Fit
- Workable for egress-controlled developer agents on Windows; weaker where kernel-enforced per-binary or port rules are required.
- Architecture and integration
- OpenShell gateway runs a host CONNECT proxy; MXC process or isolation-session container redirects network to it; policy mapper emits a block-by-default MXC config plus a loss report.
- Prerequisites
- Windows 11 with MXC
- OpenShell gateway deployed as a service
- Policy mapper loss report for each policy
- Constraints
- MXC cannot encode ports, protocols, per-binary or L7 rules
- Host filtering not enforced by MXC on Windows per the RFC
- OCSF events limited to network and lifecycle
- Single-session limit for isolation_session
- Security
- Treat the host proxy as the enforcing layer; set network defaultPolicy to block explicitly; avoid passing credentials in arguments.
- Proof of value
- Compare Linux and Windows enforcement for the same policy
- Attempt per-binary and port-scoped bypasses on Windows
- Restart the gateway and check for orphaned sessions
Delivery
Role takeaway
- Work
- Add a Windows-specific OpenShell policy review and bypass test to agent pilot onboarding.
- Dependencies
- OpenShell and MXC release notes
- Security engineering time
- Host proxy logging
- Ownership
- Security engineering signs off each Windows agent policy; platform team operates the gateway.
- Skills and adoption
- Reviewers learn to read the mapper loss report and test host-proxy enforcement.
- Governance checkpoints
- Loss-report review
- Bypass test before production
- Re-review on each OpenShell or MXC update
- Acceptance criteria
- No unreviewed access-broadening items in production policy (proposed)
- Bypass tests fail closed (proposed)
- Risks
- Gateway restart orphaning sessions
- Credential exposure in process listings
- Design drift between RFC and shipped release
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Windows deployment is three parts: the OpenShell gateway, a Windows-only MXC driver in-process, and Microsoft's wxc-exec binary, with no OpenShell code inside the sandbox. Rich policy depends on the host CONNECT proxy correctly attributing each loopback connection to its sandbox.
Governance
Who approves, reviews and stays accountable for outcomes?
Policy approvals made for Linux OpenShell deployments do not transfer one-to-one to Windows; reviewers should require the mapper's loss report for each policy.
Security and privacy
What data, permissions and controls need testing?
No kernel-level defense-in-depth beneath the host proxy for host filtering on Windows per the RFC; reduced OCSF visibility; credentials passed in argv; MXC's default-allow when network policy is omitted means hand-written MXC configs must set block explicitly.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Requires security staff comfortable with policy-as-code and proxy troubleshooting; smaller IT shops may need outside help.
Procurement
What should contracts, pricing and exit terms secure?
Ask NVIDIA or integrators for the current Windows loss report and the status of each RFC risk item in the GA release before approving deployments.
Operating model
Which teams own the service once it runs?
Windows agent sandboxing depends on a long-running gateway service, adding an operational component endpoint teams must monitor.
Publication history
- 2026-10-07NVIDIA · Issue 328 resources
Stable resource ID: nvidia-openshell-issue-2050-mxc-windows-driver-lossy-policy-translation-20260629