Restrict permissions where operations execute

Suppose an AI agent is asked to investigate a system failure. Reading the relevant logs may be enough to do the job. If the agent also has permission to change production systems, however, an attempted repair can become an actual change. Asking it to investigate only and making the system reject updates require separate design decisions.

On September 28, 2026, NVIDIA announced its Open Agent Safety Platform, a foundation for setting boundaries on AI agents across software, hardware, and robotics.

Our interest in this announcement is the design principle of placing permission controls that the agent cannot change on the path from an AI decision to an executed operation. This limits what can be executed when an agent follows misleading external content or drifts from its original task while trying to solve a problem. It applies to agents automating business processes and to robots acting in the physical world.

The roles of OpenShell and Sentry

The announcement describes two main components: OpenShell for runtime controls and Sentry for additional independent monitoring.

Component Role described by NVIDIA
OpenShell An open-source runtime that runs agents in isolated environments and applies policies to file, process, and external service access
Sentry An additional layer in the reference system design that independently monitors and controls agent activity on BlueField-4 DPUs

A runtime is the environment in which a program executes. Applying restrictions there provides a place to enforce controls when an agent uses a shell or generated code. Sentry is described as placing monitoring outside the environment where the agent runs. NVIDIA’s technical explanation

OpenShell and the Sentry reference design, which uses specific hardware, need separate consideration of deployment requirements. Assess the supported capabilities and limitations of the version and runtime environment you intend to use.

Define permitted operations as well as destinations

The OpenShell architecture separates the isolated agent environment from a Supervisor that makes access decisions. Outbound communication passes through the Supervisor, and real credentials are handled outside the agent.

NVIDIA’s OpenShell technical walkthrough describes allowing reads while rejecting writes for HTTP, GraphQL, and MCP traffic configured for inspection. It also describes formal analysis of the access a policy change would grant. That analysis concerns modeled permissions.

For businesses, the question extends from which services an agent can reach to what it may do through those services. The following is our proposed design for a hypothetical agent investigating failures.

Operation Example design
Read investigation logs Allow access to specified systems and time periods
Prepare a proposed fix Save it in a working environment and use a separate approval path for production changes
Change production data Do not grant this permission to the investigation agent
Add destinations or permissions Have an administrator independent of the agent review the need and the scope of the change

If a policy grants excessive access, controls can work as configured and still permit unwanted operations. Sending confidential information to an allowed API or writing incorrect values through an allowed update operation may require checks beyond access control. Design validation of operation targets, transmitted content, and proposed changes around the business process.

Robots also need validation of operating conditions

On the same day, Gecko Robotics announced its collaboration with NVIDIA, using OpenShell to explore keeping AI-powered robots within human-defined permissions. Its announcement describes an independent enforcement layer between the AI agent and hardware in its Komodo robot.

For robotics, we consider both permission to perform an operation and its validity under current conditions. A mobile robot may be authorized to receive movement commands, but its permitted area, speed limits, and consistency with its current state still need validation before execution. Adversarial interference with camera input could also lead to dangerous choices within the set of authorized operations.

Define these checks for the intended application. Control engineers and safety personnel need to decide motion constraints, how to handle stale sensor information, and the state to enter if communication with monitoring systems fails. When an arm holds a load, stopping the agent’s processing also requires controls that keep the load safely supported.

Isolating or stopping an agent and moving a machine into a safe state are connected design tasks. The motion checks above are our design proposals; the cited announcements do not establish that OpenShell or Sentry implements them. Our article on Security Design for Physical AI also discusses separation of responsibilities and behavior under faults.

Start with the paths through which permitted operations execute

When considering deployment, first map the path from AI output to an executed API request or machine command. Check for paths that bypass controls, and identify who can change credentials and policies.

Then define permitted operations for each business task. Verify that necessary operations succeed and that disallowed operations are rejected. For robots, also test rejection of commands that violate operating constraints and transitions to predefined states when monitoring or communication is lost. Record executed and rejected operations with the policies applied, and repeat the checks after changes.

We see this announcement as a concrete step toward managing the scope of AI activity through its execution environment. Choosing a product goes together with deciding what to permit, where to validate it, and how the system should behave under faults.

For AI agent and robotics design or proof-of-concept work, see our custom AI system development and contact form.

Reference materials

Sources checked October 6, 2026. Descriptions of product components and initiatives are based on the companies’ published information. The investigation example, robot validation conditions, and deployment checks are U-Rec, Inc.’s analysis and design proposals. This article does not report hands-on testing of these products by U-Rec.