On October 21, 2026, NVIDIA announced the "OpenShell Reference Architecture," a design for running AI agents safely across enterprise IT systems and edge devices. The configuration splits AI model inference, agent tool execution, and the monitoring and control of access permissions across separate computing resources, extending the existing OpenShell runtime environment into enterprise infrastructure. As companies entrust more work to AI agents, key questions are how far to delegate employees' access permissions and where business data ends up being sent. An implementation example released by Cisco the same day showed how to combine a mechanism for running agents in isolation with a company's identity management and audit functions.
Extending the safety foundation announced in September into an enterprise architecture
In the new reference architecture, Vera Rubin handles AI model inference, while the Vera CPU runs the software that controls agent execution along with various tools. In addition, "Sentry" runs on the BlueField-4 DPU, a dedicated processor, monitoring and controlling the agent's behavior from an environment independent of the host that runs the agent. The design separates the environment where the agent performs its work from the mechanism that restricts its permissions. According to NVIDIA's announcement, the configuration can be deployed not only in corporate data centers but also in edge environments using products such as RTX Spark and DGX Spark.
However, the security foundation that combines OpenShell and Sentry is not being announced for the first time. In its "Open Agent Safety Platform" announcement on September 28, NVIDIA had already introduced software-based restrictions on agent execution and an independent monitoring mechanism using BlueField-4. The latest announcement can be seen as systematizing these elements, including integration with computing platforms such as Vera Rubin and with enterprise software, into a reference architecture designed for real-world deployment.
OpenShell supports Linux and Kubernetes environments, as well as Windows environments that use Microsoft Execution Containers. It is also said to run on cloud environments such as AWS, Google Cloud and Microsoft Azure, so it is not limited to specific data centers or hardware. At the same time, it is necessary to distinguish between using OpenShell as software and combining it with hardware-side monitoring by BlueField-4.
NVIDIA's technical explanation positions Sentry as an additional hardware protection mechanism. In the reference architecture, BlueField-4 sits in the input/output path between the agent running on Vera and the AI model it uses, and Sentry monitors requests and responses. Monitoring also covers network communications, file operations and some host memory. The aim is to verify and control actual behavior from outside the host, rather than relying solely on the execution results reported by the agent itself.
Cisco's "DefenseClaw" links enterprise identity management to agent permissions
Cisco's newly released "DefenseClaw" uses OS sign-in information to set AI agent permissions according to the user and the groups they belong to. According to Cisco's technical explanation, settings applied to a user can restrict the network destinations an agent may connect to, the credentials it may use, and the MCP servers it is allowed to work with. Administrators can also specify which coding agents are permitted and require certain agents to run inside an isolated environment.
OpenShell, which carries out these controls, incorporates several mechanisms with distinct roles. "Gateway" creates and destroys isolated environments and manages policies, while "Sandbox" restricts access to files and processes. "Supervisor," which runs outside the Sandbox, checks external access requests from the agent against policy and mediates the use of credentials. In addition, "Policy prover" formally verifies that the permissions set for an agent do not exceed the limits defined by the organization.
Network communications are also designed to pass through the trusted Supervisor rather than having the agent connect directly to external services. According to Cisco, the Supervisor checks whether a request complies with policy and attaches the necessary credentials only to permitted communications. Real credentials are not handed to the isolated environment where the agent runs; instead, placeholder strings are used. This reduces the risk that the agent obtains the credentials themselves during processing.
With this design, even if an AI agent is launched under an employee's account, it does not need to be given all of that employee's access permissions. For example, if an administrator sets a policy requiring execution in an isolated environment, DefenseClaw reportedly refuses to launch the agent directly on the host and instead points the user to the command for running it in isolation. Rather than simply instructing the agent about what is prohibited, the system itself controls how the agent is run and what it can access, as set by the company.
Usage statistics, audit logs and business-data inspection each work differently
When deploying this system in a company, it is necessary to check not only the security features themselves but also what data is sent externally during operation. The Register reported that OpenShell's telemetry is enabled by default, and noted that even if it is turned off, the privacy terms of each integrated third-party service still apply. However, the usage statistics OpenShell collects are not the same as the data sent to inspect an agent's business activity.
Specifically, OpenShell's anonymous usage statistics, DefenseClaw's audit logs and Cisco AI Defense's content inspection each handle different data and have different transmission purposes. The differences, based on OpenShell's official telemetry documentation (Latest v0.1.5) and Cisco's explanation dated October 21, are summarized below.
| Category | Data handled and purpose | Destination and scope of opt-out |
|---|---|---|
| OpenShell anonymous usage statistics | Aggregate information about usage, such as the results of isolated-environment creation and counts of policy decisions. Described as not collecting prompts, credentials or user content | OpenShell's own usage statistics can be disabled in settings. However, this does not apply to data transmission by third-party services |
| DefenseClaw audit logs | Records of denied and approved operations and policy decisions, linked to the agent, isolated environment and applied rules | Can be sent to destinations that support Splunk or OpenTelemetry. However, external forwarding is not described as enabled by default |
| Cisco AI Defense content inspection | Inspects prompts, tool calls and response content, and makes determinations based on the organization's security policy | Sends the data to be inspected to Cisco AI Defense. It is not a mechanism that routes all of the agent's network communications |
This distinction matters because disabling OpenShell's usage statistics does not stop the transmission of business data to integrated services. According to OpenShell's official documentation, setting the environment variable OPENSHELL_TELEMETRY_ENABLED=false disables OpenShell's usage statistics. When deploying with Helm, the same can be achieved with server.telemetryEnabled=false. On the other hand, when integrating with Cisco AI Defense, it is explicitly stated that prompts and tool response content are sent for security inspection.
In other words, running an agent in an isolated environment does not prevent all data from being sent to permitted external services. In addition to deciding which operations to allow the agent, companies need to separately check the business content sent for security inspection and where audit logs are stored and forwarded. Especially in environments that handle confidential information, it is important to verify before deployment that the scope of data each feature sends is consistent with the company's information management rules.
Publishing a reference architecture is a separate matter from safety in production
NVIDIA has announced that the OpenShell Reference Architecture is available, but the state of adoption among partner companies varies. SAP is moving to integrate it into the runtime foundation of Joule Studio, the development environment for its AI assistant Joule, while the banks BBVA and Santander are considering it as a framework for strengthening AI agent safety and governance. Even though these companies are presented as partners, that does not mean production deployment has been completed across all products or customer environments.
As for Sentry's performance, NVIDIA says it can isolate an agent within milliseconds when it detects a threat or policy violation. However, this is a performance characteristic presented by the company, not a guarantee that every improper operation or malfunction will be reliably detected. And even if Policy prover confirms that an agent's permissions stay within the range the organization has set, whether each individual task executed with those permissions is appropriate is a separate question. Even technically permitted operations may still lead to outcomes that are undesirable from a business standpoint.
When deploying in an actual production environment, companies need to check the connection paths to the AI models and business systems they use, and specifically match the operations OpenShell restricts against those Sentry can monitor and control. In addition to setting access permissions according to employees' affiliations and roles, they must also verify whether data transmission for content inspection and auditing complies with internal rules. The publication of the reference architecture provides design guidelines for combining these mechanisms; it does not guarantee safety in any individual company's environment.
The direction NVIDIA has set out is not only to improve AI agents' decision-making capabilities but also to build a foundation that lets their execution permissions be managed from the outside. If the agent's execution environment can be separated from the monitoring and control mechanisms and linked with a company's identity management and audit systems, companies should find it easier to assign more work to autonomous processing while retaining the authority to restrict or stop operations. Going forward, key factors in companies' adoption decisions will be how effectively these mechanisms work in real business environments and how much performance and operational burden their deployment brings.