Give an AI agent a terminal and its mistakes can reach beyond the conversation. A wrong answer can be corrected. A wrong command can overwrite a file, expose a credential, or touch a system that had nothing to do with the task.

On September 28, 2026, NVIDIA announced its Open Agent Safety Platform, combining software that constrains agents at runtime with a reference design for infrastructure-level monitoring. Its two main components are OpenShell, an open-source runtime that restricts agent access, and Sentry, a separate watchdog running on BlueField-4 DPUs.

The announcement matters for teams letting agents work longer and reach more services. An instruction such as “do not change production” is useful. The execution environment also needs to refuse that change if the agent tries it anyway.

The cover illustration was created for Linmas to depict agent access boundaries. It is an editorial illustration, not an official NVIDIA architecture diagram.

What NVIDIA announced

In its architecture walkthrough published the same day, NVIDIA separates agent protection into three layers: application, runtime, and infrastructure. Models, tools, and data sit in the application layer. The runtime manages where agents work and enforces permissions. Infrastructure supplies the computing resources and additional controls.

OpenShell runs agents inside sandboxes. Operators define the access a task needs, and controls outside the agent workload restrict files, processes, networks, and credentials. An agent can decide to attempt an action, but that action still has to pass the environment’s rules.

Sentry adds monitoring through BlueField-4 hardware, separate from the host running the agent. NVIDIA says this arrangement supports observation and policy enforcement from a trust domain outside the agent’s reach. It also claims Sentry can quarantine agents in milliseconds. That timing is a vendor claim, not a result independently tested for this article.

The distinction matters when deciding what to adopt. OpenShell is open-source software. The Sentry layer described in the reference design uses BlueField-4. Installing OpenShell alone does not provide every hardware protection discussed in the announcement.

When untrusted instructions become attempted actions

Suppose an agent is asked to summarize repository issues. One comment tells it to read a credential file and send the contents to an external service. This is an example of indirect prompt injection: malicious instructions arrive in material the agent should treat as data. The scenario illustrates a risk; it does not describe a reported incident.

The model might recognize and ignore those instructions. The operational questions arise when it fails: can it read the credential file? Is the destination allowed? Do child processes inherit the same restrictions?

Runtime controls address these questions by checking attempted actions. Sensitive files can sit outside the agent’s readable workspace. Network requests can be denied. The attempt can also leave a record for an operator to investigate.

Prompt injection remains a problem. These controls limit the actions available to an agent and the damage it can cause after following the wrong instruction.

OpenShell checks more than the destination

The OpenShell 0.1.0 technical guide describes a supervisor that can inspect configured HTTP, GraphQL, and Model Context Protocol traffic. With an appropriate policy, it can allow reads from a service while rejecting writes.

Allowing a connection to a repository service leaves an important question unanswered: may the agent read an issue, modify a file, or delete something? One destination can expose operations with very different consequences.

NVIDIA also describes a mechanism that keeps real credentials outside the agent workload. Credentials are substituted along an authorized request path, so the agent does not need to receive the secret itself. The destination service still enforces the credential’s permissions; OpenShell adds restrictions on how the agent uses that access.

Permission changes have their own review path. With policy advisor enabled, an agent can propose a narrowly scoped change. According to the guide, proposals await human review by default, and agents cannot approve their own requests. Network access changes can take effect while a sandbox runs. Changes to filesystem and process restrictions require a new sandbox.

What still needs testing

OpenShell includes a policy prover that uses formal logic to examine the permissions a policy grants. It can show whether modeled permissions stay within an operator-defined boundary or identify an action that crosses it.

“Modeled” sets the limit of that conclusion. A policy proof does not establish that an entire application, its dependencies, and its deployment configuration are free of vulnerabilities. A rule can also be logically consistent while granting more access than the business needs.

NVIDIA reports adversarial experiments lasting up to two hours, in which agents tried to obtain permission to modify a protected repository. In those tests, the combination of review and runtime controls prevented writes to that repository. The result provides evidence for that scenario. It does not settle how your configuration will behave with different tools, identities, or access paths.

Five checks before granting broader agent access

For a development team, this announcement is a useful reason to revisit an agent workflow already in use. Pick a real task and check:

  1. The minimum access the task needs. An issue-summary agent usually does not need repository write access or deployment credentials. Start there when assigning permissions.
  2. Every route to the same action. Blocking one tool is insufficient if a shell, generated code, or child process can still perform the operation another way.
  3. Who requests access and who approves it. Requests should name the purpose and scope of additional permissions. Avoid broad approvals just to keep the task moving.
  4. Records that support an investigation. Capture the agent identity, attempted action, policy decision, and outcome. Keep tokens and unnecessary sensitive content out of those records.
  5. How to cut off access. Test credential revocation, session termination, and workload shutdown with test data. Operators need a clear response when an agent moves beyond its assigned scope.

Run these checks in an environment prepared for testing. Record which operations succeeded, which were denied, and whether legitimate work could still finish. A policy that blocks everything is unlikely to survive contact with the team’s daily work.

Where security review fits

Runtime controls and code review address different parts of the job. A sandbox can restrict an agent’s access, yet the code it produces may still contain an authorization flaw or a mistaken business assumption. That code needs review before it becomes part of the application.

At Linmas, security review for AI-generated code starts with a defined change, evidence of risk, a fix, and verification. That workflow can help a team assess the boundaries it intends to enforce. Linmas is a collection of defensive review skills; it does not provide a runtime sandbox or replace OpenShell or Sentry.

Before granting the next agent more access, choose one action that should be forbidden and demonstrate that the execution environment rejects it. Keep the evidence alongside the configuration you tested. Repeat the check when the model, tools, or task changes.

Sources and editorial notes

This article was written on September 29, 2026, using NVIDIA’s official announcements and documentation accessed that day. Product capabilities are attributed to the vendor. The risk examples and suggested checks are Linmas editorial analysis; this article does not report hands-on testing of OpenShell or Sentry.