Project Arc and NVIDIA OpenShell: The first credible sandbox layer for autonomous desktop agents

The 90-second summary

ServiceNow and NVIDIA introduced Project Arc and the open-source runtime OpenShell, providing what productive agent setups have been missing: a sandbox layer that defines, per agent, what it can see, call and write to — plus a Control Tower that turns every action into an auditable stream.

What is new?

An openly licensed sandbox runtime (NVIDIA OpenShell) plus a governance platform (ServiceNow AI Control Tower).

Why now?

A Fortune report from the same week documents an incident in which an agent with write privileges deleted a production database in nine seconds.

Who should care?

Any organisation running more than three agents in parallel against productive data.

Mittelstand recommendation?

Plan the sandbox layer, keep the vendor open — OpenShell as open source is the strongest candidate. The Control Tower is not a mandatory add-on.

Immediate action?

A permissions inventory across all running and planned agents — before the next pilot.

What happened

At Knowledge 2026 in Las Vegas, ServiceNow and NVIDIA announced an extended partnership that brings two building blocks to market. NVIDIA OpenShell is a sandbox runtime for autonomous agents, released as open source. It borrows from the logic of isolated container runtimes but is built specifically for AI agents: per agent, it defines which applications are visible, which tool calls are allowed and which data space may be written to. ServiceNow AI Control Tower is the commercial governance layer on top — a central control room that consolidates action logs, permission requests and behavioural data from every running agent into a continuous audit stream.

The combination is marketed as Project Arc and primarily targets large enterprises managing tens of thousands of agents on employee desktops. The architecture itself is at least as relevant for the Mittelstand, and in places more so, because sandbox discipline is often not yet established there.

Who should look closely

We recommend a close look for four constellations:

• You run or pilot more than two autonomous agents in parallel against productive systems.
• At least one agent has write privileges on a database, a filesystem or a productive API.
• You do not have a central audit trail today that logs agent actions independently of the agent itself.
• Your procurement will be buying agent software in the next twelve months — regardless of vendor.

If none of these four constellations applies, you can keep the topic comfortably in the backlog. In every other case, the question “who is liable when an agent triggers a wrong action?” will land on your desk within the next two quarters, and you should have a documented architecture pattern in your pocket before your insurer asks for it.

Impact

Three consequences are immediately foreseeable.

The first concerns procurement. From Q3 2026, vendors will have to demonstrate in RFPs how their agents are scoped, which actions are logged and how permissions can be revoked with an audit trail. If a vendor answers that with “we use the OpenAI API”, that is not enough. We recommend adding the sandbox layer and the audit sink explicitly to procurement templates.

The second concerns architecture. The sandbox layer is a layer you should control, not the model vendor. OpenShell as open source allows that. An equivalent proprietary layer from a single vendor does not — it makes you replaceable in the one place where you should not be.

The third concerns accountability inside your organisation. You need a named person who grants and revokes agent permissions, and who does not work in the tool chain whose permissions they manage. This is the same separation you know from classic access management, and it survives the agent wave only if it is designed in from day one.

Immediate operational actions

Concrete steps, in this order:

1. Permissions inventory across all running and planned agents. Which tools, which data spaces, which write privileges? A spreadsheet is enough — no tool required.
2. Audit stream for every agent that can write. At minimum: timestamp, calling context, tool name, result. Written into a sink the agent itself cannot write to.
3. Sandbox sketch for one of your productive setups — even if you use neither OpenShell nor Control Tower today. What does the agent see? What does it not see? Which actions are a no-go?

Decision matrix: when to act now, when to monitor?

• Act now when productive write privileges exist without an audit stream or without clearly named calling contexts.
• Plan into the next sprint when audit stream and permission model are in place but no sandbox layer exists.
• Monitor and review when no productive write privileges exist — then preparation for the first write use case is the next step.

What we actually do

In our own platforms — TYPO3 managed hosting, DevSecOps stack, MCP tooling — agents have been running productively since last quarter. We enforce three principles, long before evaluating any commercial Control Tower:

• Keep write privileges minimal. Every agent gets a clearly defined write space (a database schema, a repo, a FAL folder), and no agent writes directly into productive databases without a second layer (approval, soft-delete pattern, time-delayed apply) protecting the action.
• Audit trail independent of the agent. Actions land in an append-only sink the agent itself cannot write to. Classically: a dedicated database schema with INSERT permission, no UPDATE, no DELETE.
• MCP tooling as the sandbox boundary. Our own MCP layer (webmcp, business-agent-pro) is the permission boundary. What the agent cannot call there does not exist for it.

We are evaluating OpenShell as an additional isolation layer for customer stacks running more than three parallel agents. Initial assessment: solid OSS core, sensible licence, low lock-in risk — a candidate for inclusion in our platform standards. We will communicate where we land once a customer pilot has finished.

Technical deep dive

OpenShell follows the logic of an isolated container runtime with agent-specific extensions. Three building blocks are technically interesting:

The tool manifest layer declaratively defines which tools the agent has access to. It includes MCP servers at this point and is therefore compatible with the evolving MCP 2026 roadmap, which is expected to deliver stateless HTTP transport, audit trails and SSO integration in the next releases. If you run MCP today, you can use the tool manifest layer as a bridge.

The action capture layer writes every tool invocation, every argument and every return value into a structured stream. Importantly, this stream is not in the agent's reach. That is the technical prerequisite for an auditable trail — a property proprietary agent frameworks have rarely satisfied cleanly so far.

The policy engine evaluates, before every tool invocation, whether the action is allowed. Policies are written as code (Rego-like), versionable and testable. This is the mechanism that technically enforces “the agent may do anything inside the sandbox, but it only sees what we want”.

The ServiceNow AI Control Tower sits on top as a visualisation and correlation layer. Of practical interest for Mittelstand organisations are the open interfaces — action streams can be fed into existing SIEM systems (Wazuh, Elastic, Splunk) without you having to buy the ServiceNow suite.

Conclusion

Project Arc and OpenShell do not change model capability — they change how reliably autonomous agents can be plugged into productive stacks. For the Mittelstand, that is a more important movement than the next model release. We recommend making the sandbox layer an architecture decision now, keeping the vendor open and evaluating OpenShell seriously — while measuring the Control Tower soberly against your actual agent inventory, not against the marketing promise.