An agent asked to finish a task has a powerful incentive to keep going. That is useful when it finds a missing dependency. It is a problem when finishing the task requires reaching beyond the permissions it was given.
The September 28 announcement
NVIDIA introduced its Open Agent Safety Platform on September 28, 2026. It combines OpenShell, open-source runtime software, with the Sentry reference system design. NVIDIA describes OpenShell as a policy-enforcing boundary that traces agent actions, and Sentry as an independent watchdog running on BlueField‑4 DPUs. The company says Sentry can quarantine agents that attempt to cross their boundaries. These are NVIDIA’s product claims, not an independent security assessment. The press release also includes availability and forward-looking qualifications; an announcement should not be treated as proof that every described configuration is ready for a particular deployment. NVIDIA’s original announcement.
A permission is a system property
My analysis is that this is the right level at which to discuss agent authority. A prompt can describe a rule. A runtime, identity layer or database grant can enforce it.
For a data assistant, “read-only” should mean a database role that cannot write, not merely an instruction to avoid updates. Access should be restricted to approved views and the smallest useful slice of data. Separate the assistant’s credentials from a human administrator’s account.
The same principle applies to files and network access. A report-writing agent may need a temporary output directory and selected data endpoints. It does not automatically need the entire shared drive or unrestricted outbound connections.
These controls are independent of a model’s reasoning quality. A more capable model can still misunderstand a request or follow misleading information in a document. The failure should encounter a boundary before it becomes an incident.
The audit trail must explain the action
A final answer is insufficient evidence of what happened. Record which tool was used, which identity made the request, what resource was targeted and whether the action was allowed. Protect the log from modification by the process being monitored.
For a hypothetical analytical workflow, the reviewer should be able to connect a chart to its query and that query to an approved dataset version. If the agent tried an unapproved endpoint, that attempt belongs in the record even if the final report looks correct.
Do not collect secrets or unnecessary personal data merely to make the logs comprehensive. Useful observability has a defined retention policy and a clear audience.
Test the boundary before the demonstration
A polished successful run tells you little about containment. Test a document that contains instructions unrelated to the user’s task. Test expired credentials, unavailable tools and incomplete data. Check whether the workflow fails visibly and whether an operator can stop it.
Also test recovery. Can a task resume without repeating an irreversible action? Can temporary access be revoked? Can you distinguish a legitimate escalation from a request that merely tries to broaden its own authority?
The evaluation should document what was attempted and what the enforcement layer prevented. Avoid calling a system “safe” because it refused one carefully chosen prompt.
OpenAI Dots illustrates why this discussion is timely: persistent assistants turn permission design into an everyday operational concern. The sensible next step is a constrained pilot with observable actions and a tested stop mechanism.
News analysis of the September 28, 2026 release. Control recommendations and examples are the author’s engineering analysis; no security certification or product test is claimed.