You give up some agent freedom and get a boundary you can defend to a skeptical security review. That is the explicit tradeoff. ### OpenShell gaps in the repository and docs **Young is the word for this project**, and it shows in what's missing. The documentation is the maker's own account of its behavior. We found no independent write-ups, no third-party audits and no production reports we could cite. Claims about how well the boundaries hold are therefore unverified. Anything you read comparing OpenShell with other sandboxing approaches is premature, because the evidence for a fair comparison doesn't exist yet. Expect interfaces and defaults to shift as the project matures. ### Who should wait before adopting OpenShell **Wait if your agents touch nothing sensitive**, because the adoption cost buys you little. Wait if you need a vendor-neutral track record before approving a runtime, or if your team can't absorb another piece of infrastructure to learn. Teams that fear what an agent might do should pilot it now on a low-stakes workload and judge it against NVIDIA's documentation, not against comparisons it hasn't yet earned. ## OpenShell compared with established agent sandboxing options Against the usual alternatives, OpenShell's pitch is policy enforced around the agent, and its weak point is track record, so judge it on NVIDIA's docs rather than on rankings. ### Comparison table Read the maturity column first: it's the one where OpenShell has the least to show. The table below sets the four options side by side, with cells dated 2026-10-23. | Option | Isolation method | Policy control | Maturity | Price | Setup effort | |---|---|---|---|---|---| | OpenShell | Enforced boundary, per NVIDIA's docs | Policy set by you, enforced by the runtime | New project | Source on GitHub; see NVIDIA's docs | Runtime to adopt and policies to write | | Containers or VMs | Shared kernel (containers) or hypervisor (VMs) | Whatever you build | Long-established | Your own infrastructure | You assemble and maintain it | | Hosted sandboxes such as E2B | Remote sandbox run by the vendor | Vendor's settings | Commercial service | Usage-based; see vendor page | Low: API key and SDK | | No sandbox | None | None | Not applicable | Free | None | Treat stars as attention, not quality. On [GitHub](https://github.com/NVIDIA/OpenShell), gVisor has 19,755 stars and E2B 14,517.  With containers and VMs you get control, and the cost is that least privilege becomes your design problem. You write the network rules and the filesystem limits, and you keep them current. Trade control for speed and you get hosted services. You get a remote sandbox in minutes, but your agent's work runs on someone else's infrastructure. In practice, many teams already run agents with no boundary at all, on a laptop with real credentials. That's the baseline OpenShell has to beat. ## Connect OpenShell to a workflow in Activepieces As of 2026-10-23, Activepieces has no OpenShell integration, and we haven't run OpenShell, so any connection is one you assemble from general-purpose steps and test yourself. Whether or not anyone sanctions it, teams will wire an agent into a workflow, so the useful question is which route gives you the least to trust. Go in this order, simplest first: 1. Confirm in NVIDIA's OpenShell documentation what it exposes: an HTTP endpoint, an OpenAI-compatible API, an MCP server, or none of these. 2. Try an HTTP request step. 3. Try an AI step with a custom provider. 4. Try an MCP server.  If step one doesn't describe the matching interface, that route doesn't exist. Skip any that the docs don't describe. If OpenShell offers an HTTP interface, this is the lowest-commitment test. Call it from a plain HTTP request step with whatever authentication the docs specify. A sandbox gives an agent a boundary, but not a role or an audit trail, and those belong to the platform around it. Activepieces treats agents as actors too: custom RBAC and control over which apps a team may connect limit what an agent can reach, and each agent gets least privilege of its own.  In the run detail view, every tool call in an agent step is listed separately with its own input and output, and the enterprise RBAC docs are where you confirm that access policies cover agents. If the docs say OpenShell serves an OpenAI-compatible API, point an AI step at it as a custom provider. The workflow then treats the sandboxed agent like any other model. The tradeoff is that you inherit only the chat-style interface. Whether tool calls and sandbox policy decisions surface through it is something to verify, not assume. If OpenShell exposes an MCP server, connect it last. It offers the richest interaction, since the workflow can call the agent's tools directly. It also gives the agent the most reach, so scope what it can touch before you connect it, and treat that scoping as part of the design. ## What to do about OpenShell this week Run a small, dated evaluation before anything else: five steps, none of which touch production, and each one answers a question you'd otherwise settle by assumption, so assumptions don't become surprises in production. 1. Read the README and the licence. They tell you what the maker claims and what you may do with it. 2. Check the release date and recent activity. A young project can change under you, so see how often it ships. 3. List the agents you run and what each can touch. Least privilege for an agent is a design problem: you can't scope reach you haven't inventoried. 4. Try a throwaway task with no production credentials. Give it a dummy repository and a scratch token, and see whether the boundary holds. 5. Re-check the maker's pages. Everything here is dated 2026-10-23 and may already have moved. What you're testing is whether the agent stays inside the boundary the docs describe. Many teams already let agents run on a developer laptop with that developer's own keys, because it's faster than waiting for approval.  A sandbox is the sanctioned alternative, and step four is where you learn whether it's also tolerable to work in. Read the policy section against your step-three inventory. For each agent, ask whether the documented controls can express the narrow access you listed, or only a coarse allow-or-deny. Where policy is coarse, you trade safety for convenience, and you should know which side you're on before rollout. Expect gaps. A young runtime will have behaviours the maker hasn't documented, and comparisons with other tools haven't been earned yet. Write down each gap as an open question, and don't fill it with a guess. Then re-check the pages: a gap that closes in the docs is evidence, and a gap that stays open is a reason to keep the pilot small. ## Frequently asked questions Re-checking the docs won't settle everything, so here are four questions the body leaves open, answered as far as the evidence goes. The licence is Apache 2.0, and the maker lists no price, so read the license in NVIDIA's own repository before you budget. Whatever it says, the runtime is only part of the bill: the compute it runs on and the engineering time to write policies are separate costs. Because the runtime's job is to put a boundary around an agent process, the agent's maker probably matters less than how it runs. But compatibility with a specific agent is a claim for NVIDIA's documentation to make, and we haven't tested one ourselves. If your agent isn't on a documented list, treat it as an experiment. ### Is OpenShell safe enough for production? Not on its own record yet. It's young, and its enforcement hasn't been tested by years of other people's incidents. **Run it on a bounded pilot where a failed boundary costs you little, and widen scope only as the documented gaps close.** That's a tradeoff, and for a team worried about what an agent might do, a boundary you can inspect still beats no boundary. That question has its own section in this article, where the specifics belong. Nothing here should be read as an answer to it. ## Related reading - [NVIDIA Switchyard: Routing AI Agent Calls Across Models](https://www.activepieces.com/blog/nvidia-switchyard-routing-ai-agent-calls-across-models) ## References - [GitHub](https://github.com/NVIDIA/OpenShell) - [Gravitee](https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control) - [Sirocco Group (citing Cisco survey)](https://www.siroccogroup.com/ai-agents-the-85-5-production-gap/)Telling an agent to behave is a request. Enforcing what it can reach is a boundary.