If an AI agent can write to an ERP, CRM or finance system, design a separate sandbox and permission layer outside the model before production use. On 21 October 2026, NVIDIA announced the OpenShell Reference Architecture for building, containing and observing safe agents and enforcing their policies on enterprise infrastructure and edge systems.
The announcement does not justify an immediate platform migration. An OpenShell pilot is most relevant if you run or plan to run agents on owned or partner-operated infrastructure and those agents reach internal systems. If you use agents through a SaaS service, tighten permissions, logging and approval controls in your current tools first. OpenShell procurement can wait.
OpenShell sits between the agent and affected systems
The GTC Berlin keynote summary divides an agent into five elements: model, harness, sandbox, knowledge and tools. In this design, the sandbox isolates the harness from the systems the agent may affect.
NVIDIA describes OpenShell as an open-source, policy-controlled runtime with kernel-level sandboxing. The company says privileges, policy enforcement and monitoring must adapt dynamically because each launch may require different access. An autonomous agent may reach files, networks, resources and software tools, which creates a need for narrow permissions and monitoring.
Model behaviour is not an adequate technical boundary. A prohibition written in a prompt should be backed by an external layer that can deny an unauthorised file, network or ERP operation. The same decision is covered in the guide to restricting agents that perform external actions.
Agents that modify an ERP still need human approval
Separating permissions matters most when an agent can write to a business system. Relevant actions include changing supplier records, preparing a purchase order, updating a CRM status or entering financial data.
NVIDIA's GTC Berlin coverage from 19 October 2026 describes a Siemens Erlangen workflow built with the Factory Operations Blueprint. Agents use factory data and planning tools to recommend options, after which a production controller reviews the trade-offs and approves the plan before the agent applies permitted changes. Its structure provides a useful decision pattern: the agent can prepare an action while approval and execution authority remain separate.
For an agent connected to an ERP or finance platform, design these controls explicitly:
- grant each run access only to the required tools and data;
- separate read and write permissions;
- block unapproved network destinations at the sandbox layer;
- keep request, approval and execution logs outside the agent's own operation;
- require human approval before irreversible or financially material actions;
- make permissions revocable while a run is in progress.
Agent permissions in Microsoft 365 are covered in a separate buyer guide. OpenShell raises a broader infrastructure question: which layer enforces the rules when one agent works across several enterprise systems?
Your infrastructure determines whether a pilot is justified
NVIDIA's European GTC coverage presents banks, payment companies and financial data providers running open-weight models on their own infrastructure. The company says its European cloud partners are also setting boundaries on what agents can access and do.
| Buyer situation | Action now | Reason |
|---|---|---|
| An agent on owned NVIDIA infrastructure reaches internal systems | Request the reference documentation and test one bounded workflow. | The announced architecture most directly matches this environment. |
| A regulated financial firm runs open-weight models on its own infrastructure | Include OpenShell in the technical evaluation while keeping legal and security reviews separate. | The European financial examples follow this operating model. |
| Agents run through a cloud infrastructure partner | Ask how the partner isolates agents, enforces policies and stores logs. | The provider needs clear boundaries around agent access and actions. |
| The company uses SaaS agents and owns no GPU infrastructure | Review the current provider's permissions, logging and approval controls. | The reference architecture was presented for enterprise infrastructure and edge systems. |
| The agent only reads an internal knowledge base | Keep least-privilege access and logging, but do not rebuild infrastructure solely because of the launch. | Removing write access reduces the immediate impact of a failed action. |
| No agent pilot exists yet | Define the workflow, data and permitted actions first. | A sandbox can only be evaluated against specific tools and operations. |
Define the permission architecture before the pilot. Base an OpenShell procurement decision on supported environments, total cost and operational responsibility.
If you are planning an agent system on your own infrastructure, review the enterprise AI platforms page. Enterprise AI platforms
Resolve two questions in writing before procurement
The reference architecture is built on OpenShell, an open-source runtime, but that does not determine total cost. Compute, integration, policy maintenance, log management and security operations may all require separate resources.
Resolve two open questions before technical evaluation:
- Obtain a written compatibility statement covering hardware requirements, supported operating environments and non-NVIDIA GPU operation.
- Request itemised pricing, total operating cost, support terms, and written information on when and where the reference architecture can be deployed.
The contract should specify where logs are stored, who owns incident response and how the sandbox or policy-enforcement layer can later be replaced. Open source alone does not resolve support or vendor dependence.
Put GDPR and EU AI Act mapping in the procurement file as a separate assessment. Sandboxing and logging may support company controls, but the architecture alone does not establish legal compliance.
The pilot must test prohibited actions
A security pilot is incomplete if it only demonstrates that the agent can finish an authorised task. The system must also deny prohibited actions and produce a useful audit record.
Include six tests in the evaluation:
- Can the agent reach an ERP record outside the assigned task?
- Can it call a tool or network destination outside the approved list?
- Does the write restriction remain effective when a user prompt requests otherwise?
- Does execution stop when the approver rejects or ignores the request?
- Can the log reconstruct which data the agent read, which tool it called and what it changed?
- Does a new run receive a fresh, narrow permission set instead of inheriting earlier access?
Evaluate authorised task completion, blocked prohibited actions, approval time and audit-log completeness separately. OpenShell creates business value only if it enforces those boundaries more consistently or with less operating effort than the current infrastructure.
Who should start an OpenShell pilot now?
A pilot is justified for regulated firms and mid-sized organisations that run agents reaching internal systems on owned or partner-operated NVIDIA infrastructure. Select one workflow with limited, reversible actions, then create a permission matrix for its data, tools and operations.
If you mainly use agents through SaaS services, review the current provider's sandboxing, logging and approval controls first. If no agent pilot exists, define the business workflow and permitted actions before evaluating infrastructure.
Complete four tasks before making a platform decision:
- Document what the agent may read and modify.
- Separate read, write and approval permissions.
- Test authorised and prohibited actions in the same pilot.
- Compare the current controls with the OpenShell reference architecture, including cost and operational responsibility.