Keep OpenShell. Govern it with SixWays.
OpenShell runs your agents. SixWays sets what every agent may do, in OpenShell and everywhere else, and proves the policy is enforced. Attach to your existing gateway with no migration.
Three layers, three jobs.
SixWays builds on the runtime and the OS sandbox rather than rebuilding them.
| OS process sandbox | NVIDIA OpenShell | SixWays | |
|---|---|---|---|
| What it is | Confinement for one process tree | A runtime for agent workloads: gateway, compute driver, supervisor, egress proxy, credentials | Governance, inspection, and verification across every placement |
| The question it answers | Can this process open that file or socket? | Run this agent somewhere isolated, with this sandbox policy | What may every agent do, is it enforced, what did it send to the model, and who approved the exception? |
| Policy scope | One launch | One sandbox, one gateway | Organization, group, user, and endpoint |
| Models, MCP, and git | No | Providers and egress; no MCP or git governance | Yes |
| Fleet, licensing, admin console | No | Gateway CLI and API | Yes |
What SixWays adds to an OpenShell deployment.
OpenShell applies Landlock, seccomp, a non-root identity, and per-binary egress rules. We test those controls with SixWays-compiled policies, then add the parts a runtime leaves to you.
Attach without migration
The SixWays connector attaches to your existing OpenShell gateway and drives create, connect, policy readback, stop, and delete through OpenShell’s own API. Your images and provider keys stay where they are.
One policy authority
Your organization’s policy compiles into OpenShell’s sandbox policy without broadening any required constraint, and the gateway receives exactly the body and hash SixWays computed.
Governed changes
Attempts to weaken a sandbox through the native OpenShell API are denied. A denied change can become an approval request, and an approved retry runs exactly once.
Inspection of model traffic
SixWays inspection attaches to OpenShell’s network middleware path. Content split across streamed chunks is still caught, and encodings that cannot be inspected are refused.
MCP governance
MCP tool calls from inside an OpenShell sandbox reach SixWays MCP governance through an authenticated relay bound to that sandbox’s workload identity.
Signed proof of enforcement
After a policy is applied, a canary probe inside the sandbox signs a receipt of what the policy actually allowed and denied. If SixWays loses contact, the status shows as expired.
Extra kernel rules on Linux
Free SixWays eBPF enforcement adds deny rules Landlock cannot express, such as a credential directory inside an allowed home directory, and checks them independently of the OpenShell supervisor.
Signed deployment
Deploy the governed gateway with the SixWays Compose recipe or Helm chart. Every image is signed and can be verified offline against the SixWays release key.
Where each agent runs.
One policy everywhere. The placement depends on where the agent runs and what your policy requires.
| Situation | Placement |
|---|---|
| A developer runs an agent on their own machine | SixWays native process sandbox under sw run |
| Your team already runs OpenShell | Keep OpenShell and attach SixWays through the connector, interceptor, and middleware |
| Agents run off the laptop: CI, cloud, shared runners | OpenShell on Docker or Kubernetes, or SixWays Cloud Sandbox |
| Policy requires stronger isolation than either guarantees | SixWays microVM in required mode, which refuses weaker placements |
| A required control is unavailable where the agent would run | The launch is refused. SixWays never downgrades silently |
Start free, govern when you’re ready.
Free
Attach and see
Connect the open-source endpoint to your gateway, inventory every sandbox, and see which ones SixWays covers.
Team and Enterprise
Govern and prove
Policy authority, the interceptor with approvals, canary probe receipts, and the evidence ledger.
Gateway add-ons
Inspect
Inspection on the OpenShell middleware path: signature and semantic checks with Gateway Basic, model-based checks with Gateway Advanced.
Questions.
Do you replace OpenShell?
No. Each workload has one lifecycle manager. If you use OpenShell, OpenShell runs the workload and SixWays governs it. If your policy requires SixWays-controlled execution, SixWays runs that workload directly.
Isn’t OpenShell’s sandbox enough?
For confinement, OpenShell is solid. Confinement controls whether a process can reach a file or host. It does not show what the agent sent to the model, decide which MCP tools it may call, or apply the same policy to agents that never run in OpenShell.
Which OpenShell versions do you support?
SixWays currently supports OpenShell v0.1.3.
Is SixWays an NVIDIA product or partner?
No. SixWays integrates with the open-source OpenShell project. It is not affiliated with, endorsed by, or certified by NVIDIA.
Get early access.
Tell us about your agents and your team, and we will set you up.