NVIDIA Adds AI-Agent Controls That Can Block API Writes Even With a Write-Capable Key

An AI agent with a key that can write to a service does not have to get permission to write. NVIDIA’s newly released OpenShell 0.1.0 puts a policy check outside the agent’s workload, where it can allow a data request while blocking a change through the same API. The open-source runtime is designed to wrap existing agents without rewriting them.

A key is not the whole permission

Many agents need access to private services to do their jobs. OpenShell keeps the real credential outside the agent workload and substitutes it only for a request to an authorized endpoint. The receiving service still applies the key’s own permissions; OpenShell adds another check on how the agent may use them. A policy that permits inspected API reads can therefore reject a write even if the key itself would allow one.

NVIDIA illustrates the difference with a GitHub API policy. After applying a read-only rule, a request to read a public endpoint is allowed, while a POST request to that endpoint is blocked. OpenShell can inspect configured HTTP, GraphQL and Model Context Protocol traffic, so a rule can distinguish operations within a service rather than simply allowing or denying the entire connection. The GitHub example demonstrates the configured policy, not every API an organization might connect.

Where the check sits

OpenShell splits the work among three components. A gateway manages sandboxes and their policies. Each sandbox runs the agent with operating-system controls over files and processes, while a supervisor outside the workload checks outbound requests. The sandbox has no network path except through that supervisor. NVIDIA says the restrictions remain in force when an agent opens a shell, runs generated code or starts child processes.

That separation is the point of the release: an agent can choose tools and revise its approach, but it cannot change a rule simply by changing its own instructions. OpenShell also records policy decisions in an audit trail. For a blocked inspected request, it can return an error describing the denial, giving the agent a chance to choose an allowed route or ask for access.

An agent can ask, not grant

A long-running task may need a service that was not in its original policy. With OpenShell’s policy advisor enabled, the agent can propose a narrowly scoped change to network or file access after a request is denied. The proposal waits for human review by default, and the requesting agent cannot approve it itself. NVIDIA says an operator or an AI agent approver can review a denial.

Approval has a practical boundary. OpenShell can load a new network or file rule into a running sandbox, letting the agent retry without restarting its work. Filesystem and process restrictions set when the sandbox starts are different: changing those controls requires a new sandbox. That leaves operators with a choice between granting access mid-task and rebuilding the environment for changes to its deeper limits.

What a permission proof can show

Reviewing one blocked request is not enough if another permitted tool can make the same change. OpenShell’s policy prover uses formal logic to check the permissions a policy grants, including access contributed by service configurations. It can show whether modeled permissions stay within an operator’s defined boundary or identify an action that crosses it. The proof concerns the policy model; it is not a guarantee that every real-world agent task will be safe.

NVIDIA says adversarial experiments tested agents trying to persuade an AI reviewer to grant access to a protected GitHub repository; no protected writes occurred in those tests. It also says work to analyze permissions combined across multiple agents is ongoing. That distinction matters for teams deploying fleets: proving what one policy allows does not yet establish what several agents might be able to do together.

The runtime is open source and available for teams to install. NVIDIA says Cadence uses it in chip design, Slack is building an on-demand agent platform on it, and Gecko Robotics uses it to govern agents making decisions on physical robots. Those applications put the same access-control question in different settings: which actions should an agent be allowed to take after it has been given a useful tool?