Robot Runtime Safety: Permissions and Fail-Safe Controls

Giving an AI agent control over a robot creates two different safety problems. The first is whether software can stop the agent from accessing unauthorized tools, credentials, networks, files or control interfaces. The second is whether the physical machine remains safe when software, sensors, communications or mechanics fail.

Agent runtime controls can help with the first problem. They do not replace emergency stops, safety PLCs, speed and force limits, guarded operating zones, certified controllers or a system-level safety case.

Six layers that should not be collapsed

Layer	Primary question	Typical controls	What it does not prove
Model alignment	Does the model usually pursue the intended goal?	Training, evaluations, constitutions, refusal behavior	That actions are technically impossible outside the goal
Application guardrails	Does the robot application reject invalid plans and commands?	State machines, command validation, rate limits, workspace checks	Isolation from a compromised or bypassed application
Agent runtime sandboxing	What can the agent process read, write, execute or contact?	Filesystem, process and network isolation; credential brokering	Safe motion or certified stopping behavior
Permissions and identity	Which actor may invoke which robot capability?	Least privilege, scoped identities, approval gates, audit logs	That an authorized command is physically safe
Out-of-band monitoring	Can a separate trust domain observe or contain the agent?	Independent telemetry, watchdogs, infrastructure enforcement	Universal coverage of sensors, actuators or mechanical failure
Robotics functional safety	Does the machine reach or maintain a safe state after faults?	Safety PLCs, emergency stops, interlocks, speed/force limiting, hazard analysis	That the AI agent is secure or well aligned

A credible design uses several layers. It does not label one sandbox, policy engine or hardware watchdog as “robot safety.”

What NVIDIA OpenShell provides

NVIDIA OpenShell 0.1.0 is available as open-source runtime software. It places an agent inside a sandbox and applies policy outside the agent workload. Its documented controls cover:

• filesystem paths and process privileges;
• network destinations and request rules;
• credentials bound to approved endpoints;
• sandbox lifecycle, policy delivery and audit events;
• formal analysis of whether proposed permissions exceed a modeled boundary.

For robotics, the useful pattern is to expose a narrow control API instead of giving an agent unrestricted host or network access. A policy might allow a task agent to request an inspection route through one service while denying shell access, arbitrary outbound connections and direct access to maintenance credentials.

That boundary still depends on the robot application translating an authorized request into validated motion. OpenShell does not certify a trajectory, measure stopping distance or prove that a manipulator cannot collide with a person.

OpenShell and NVIDIA Sentry are different layers

NVIDIA’s Open Agent Safety Platform announcement combines two distinct elements:

Component	Current maturity	Enforcement location	Appropriate claim
OpenShell	Available open-source software	Agent runtime, sandbox, supervisor and policy path	Runtime permissions and isolation can be implemented and evaluated now
NVIDIA Sentry	Reference system design associated with NVIDIA Vera/BlueField-4 infrastructure	Isolated, out-of-band DPU trust domain	NVIDIA describes continuous monitoring and rapid containment; deployment effectiveness remains system-specific

Sentry is not a universally deployed robot-safety device. NVIDIA describes it as a BlueField-4/DOCA architecture for monitoring agent activity independently of the host. That is relevant to centralized agent infrastructure and some future robotics deployments, but it is not equivalent to an onboard safety PLC, certified robot controller or independent emergency-stop circuit.

The physical AI technology stack explains where BlueField-4 sits in off-robot infrastructure. Runtime policy and DPU enforcement must still be mapped to the actual path between an agent, robot-control service and hardware.

What robotics adoption currently establishes

Organization	Public evidence	Safe interpretation
Gecko Robotics	Gecko says it is testing OpenShell for robot control and describes an enforcement layer between an agent and its Komodo hardware	Confirmed company-reported testing; not independent evidence of complete safety coverage or certification
Figure	NVIDIA lists Figure among robotics companies building with OpenShell	Vendor-reported ecosystem participation; implementation scope and production status are not public
Skild AI	NVIDIA lists Skild AI among robotics companies building with OpenShell	Vendor-reported ecosystem participation; implementation scope and production status are not public

These signals establish active evaluation, not proven real-world effectiveness across every robot, task or failure mode.

A practical robot-agent permission model

Start with capabilities, not broad machine access:

1. List every action the agent can request: navigate, inspect, grasp, open, upload, update or stop.
2. Put a typed service boundary in front of each capability.
3. Give each agent a scoped identity and deny unlisted operations.
4. Validate parameters against operating envelopes before a command reaches motion control.
5. Require human approval for high-consequence or unusual actions.
6. Log requests, policy decisions, resulting robot state and operator intervention.
7. Define what happens when the agent, policy service, network or model is unavailable.
8. Test rollback, containment and emergency-stop paths independently.

Use the robot capability profile template to record permissions, degraded modes, watchdogs and evidence without converting them into one misleading safety score.

Questions to answer before deployment

• Is the agent isolated from raw actuator interfaces?
• Which component validates speed, force, workspace and collision constraints?
• Can the runtime policy be changed while the robot is moving?
• Who approves new permissions, and can the agent request them itself?
• What remains enforceable if the host operating system is compromised?
• Does loss of the model, network or policy service lead to a defined safe state?
• Are runtime security logs tied to robot telemetry and operator actions?
• Which controls have independent tests, and which are still vendor claims?
• Which applicable safety standards and certification obligations remain outside the agent-security stack?

Bottom line

Runtime sandboxes and permissions are a useful new layer for AI-controlled robots because they make some prohibited actions technically enforceable outside the model. Their value is greatest when robot capabilities are exposed through narrow, auditable interfaces.

They are one layer of a safety architecture. Physical deployments still require application validation, deterministic low-level controls, independent stopping mechanisms, hazard analysis and evidence that the complete system behaves safely under faults.

Sources

• NVIDIA Open Agent Safety Platform announcement — OpenShell availability, Sentry reference design and robotics ecosystem claims
• NVIDIA OpenShell product overview — runtime architecture, permission model and documented controls
• NVIDIA OpenShell GitHub repository — open-source implementation, architecture and license
• Gecko Robotics OpenShell collaboration — first-party robot-control testing statement
• NVIDIA Sentry architecture — BlueField-4/DOCA out-of-band reference architecture