Questions, answered.

A sandbox controls whether a process can reach a file or host. It does not inspect what the agent sends to the model, hold a risky tool call for a human, or prove the policy was enforced. SixWays does all three, with one policy across native agents, containers, NVIDIA OpenShell, microVMs, and cloud sandboxes.

Keep it. SixWays attaches to your existing gateway without replacing your images or moving your provider keys. OpenShell confines and runs the workload; SixWays adds company-wide policy, inspection of model traffic, approvals, MCP governance, and evidence that the controls held.

An LLM firewall inspects model traffic. SixWays does that too, and also governs what the agent does on the machine: where it runs, what it can touch, and which tool calls need approval. You can run both.

Keep it. EDR monitors processes and malware across the whole host. SixWays governs agents: their policy, model traffic, tool calls, and actions. It runs alongside your EDR.

Yes. A denied change becomes an approval request bound to the exact payload, and the approved retry runs exactly once; a changed payload, an expired grant, or a replay is refused. MCP tool calls can be held for approval too, on the desktop or in the SixWays mobile app.

SixWays recognizes 26 coding agents and applies the same policy to each. It does not ship a coding agent of its own.

Yes. The endpoint and its container sandbox run on all three; on Linux, build the endpoint from source for now. The OS-native process sandbox runs on macOS, Linux, and Windows 11, and refuses a launch it cannot confine. Required-mode microVMs run on macOS and Linux. The Endpoint page lists which sandbox each launch path uses by default.

With the open-source endpoint on its own, only update checks; sessions stay in a local database. With a Server connected, the endpoint sends it the telemetry your policy asks for. The Server can be a dedicated tenant or one you host.

No. The Firewall runs in your own network, so prompt and response content never transits SixWays infrastructure. SixWays Cloud handles licenses and billing, not agent traffic, code, or telemetry.

Agents hold opaque sndr:// references instead of raw keys. The gateway or the endpoint resolves them at the point of use, so keys stay out of prompts, logs, and agent memory, and recorded terminal sessions have secret values removed. The exception is an MCP server that runs locally over stdio: it reads the real credential from its environment. MCP servers reached over HTTP get their credentials from the gateway.

It governs your company’s agents on your company’s machines, the way you already govern CI runners and service accounts. It does not grade developers.

The endpoint is open source, with no machine limit. eBPF enforcement is free on every tier, and so is the OS-native process sandbox for local use. You pay for central policy, approvals, evidence, the Firewall, or the add-ons. For one developer without a Server, Pro adds Pulse, the Trusted MCP Catalog, microVM isolation, and local session undo.

Yes. Team has a 14-day trial with no card needed. Pro has no trial.

Billing never weakens isolation. Paid features stay on through a 14-day grace window. After that, paid governance and management features stop, but the process sandbox and eBPF enforcement keep enforcing until you change your policy. Administrators can always revoke, deny, stop, and tighten.

Not yet. A SOC 2 Type I audit is planned for about six months after general availability, and Type II about six months later. Until then we provide architecture documentation, data-flow diagrams, and security questionnaire responses, and our fleet compliance reports map to SOC 2, HIPAA, NIST AI RMF, and ISO 42001 to support your own audits.

The Server supports per-organization SSO, SCIM provisioning on Enterprise, signed webhooks, and evidence export, so your identity provider and SIEM can consume it.

Not yet. Marketplace purchasing through AWS, Azure, and Google Cloud is coming. Until then, buy directly from SixWays.