An agent may read files, run commands, install packages, call APIs and use credentials to complete a task. These abilities make it useful. They also mean a mistaken instruction, a compromised tool or an unexpected sequence of actions can have effects outside the chat window. A prompt telling the agent to behave safely is not an enforceable boundary around its process.
That is the gap NVIDIA is addressing with its Open Agent Safety Platform announcement of 28 September 2026. The platform includes the open-source OpenShell runtime and the Sentry reference system design. OpenShell places controls around the environment in which an agent executes, outside the model and agent harness.
A boundary the agent runs inside
OpenShell’s architecture uses an isolated sandbox and a trusted supervisor. Its policies govern file access, system calls, network connections and access to approved services. Credentials are supplied only to requests bound for permitted endpoints, rather than handed unrestricted to the agent. Proposed policy changes can be checked before an operator grants new access.
This moves an important decision out of the agent’s own reasoning: permission to reach a resource becomes something the surrounding system can enforce. An agent can still do useful work, but within boundaries that an operator can inspect and change.
Visibility matters as much as enforcement. OpenShell records structured runtime events, including allowed and denied network activity and policy changes. Its documentation describes ways to inspect those logs and export them for longer-term storage. The question is how teams use these records alongside evidence from the workflows where agents deliver work.
Coding agents carry the question into the repository
A coding agent’s work does not end when its process exits. It may leave an authentication change, a dependency update or a new infrastructure configuration for a team to review and merge. The runtime record helps explain the conditions under which the agent operated. The development record must also show what changed and how that change was handled.
For a sensitive change, a reviewer may need to answer:
- Which human initiated the work, and which agent session acted on it?
- Which files were read or changed, and what diff was proposed?
- Were risky paths or behaviours identified before the change entered CI?
- What evidence did reviewers consider, and who approved the final change?
Answering these questions calls for records from the coding agent, repository, CI and review workflow, linked with enough identity and integrity information to make the sequence inspectable. Runtime logs are valuable inputs to that record, while repository events and review decisions provide the outcome.
Consider an agent asked to modify an authentication flow. A runtime boundary can restrict its network destinations, limit filesystem access and record attempts to cross those limits. The team receiving the patch also needs a dependable account of the files touched, the agent session behind the change, the risk signals raised and the review decision. Each record strengthens a different part of the explanation.
An opportunity to connect the evidence
A useful future workflow would let teams follow an authorized task through agent execution, a proposed diff, CI checks and human review. That requires correlation across systems: consistent identities, timestamps, references to the repository artifact and retention of the underlying evidence. It also requires care about incomplete capture. A missing event should be visible as a gap, not silently treated as proof that nothing happened.
OpenShell’s contribution is to make agent execution more bounded and observable. Coding-agent and source-control workflows can carry that accountability forward to the code a team ultimately accepts.
It is encouraging to see the industry treating agent safety as an engineering problem with enforceable controls and inspectable evidence. NVIDIA’s work on OpenShell is a strong step in that direction. As coding agents become part of everyday development, the next step is for runtime, development and review systems to work together so teams can understand both what an agent was allowed to do and what software change it actually delivered.