Add Runtime Controls to AI Agents with NVIDIA OpenShell

來源原標題

Add Runtime Controls to AI Agents with NVIDIA OpenShell

作者

Alex Watson

原始標籤

Agentic AI / Generative AI · Top Stories · Trustworthy AI / Cybersecurity · Open Agent Safety Platform · OpenShell · Security for AI · Trustworthy AI

原始連結

https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/

摘要原文

AI agents can be given a goal, write code, use tools, and keep working as new information becomes available. This opens the door to applications that investigate software failures, run experiments, and carry out business-critical actions and research over days or weeks. Useful agents need access to workspaces, compute resources, data, credentials, and external services. But broader access also creates more consequential failure modes, from changing production data or exposing confidential information to acting beyond the assigned task. NVIDIA OpenShell 0.1.0 is an open-source runtime for defining and enforcing which systems and data an agent can access. It combines sandboxed execution, controlled service access, credential management, and formal policy analysis. Teams can grant agents the capabilities a task requires while OpenShell enforces those permissions outside the workload. It supports Codex, Claude Code, Pi, Hermes, and future frameworks across enterprise applications, frontier research, and physical AI—from internal agent fleets and long-horizon research to robotics and edge systems. This post shows how NVIDIA OpenShell 0.1.0 places enforceable runtime controls around an existing AI agent—without rewriting it—so teams can restrict API operations, protect credentials, and review permission changes outside the agent workload. OpenShell provides the runtime layer of the broader NVIDIA Open Agent Safety Platform , which extends protection across the application, runtime, and infrastructure layers. Video 1. A walkthrough on how to set up your autonomous long-running agent How organizations are adopting OpenShell OpenShell is open source and available for enterprise adoption across a broad ecosystem of partners, which shapes the product itself. Organizations are adopting OpenShell across a range of applications, including chip design, enterprise automation, accelerated computing, and physical AI. Cadence uses OpenShell for chip design with its ChipStack Autonomous RTL Design Engineer. Slack is building an on-demand agent platform on OpenShell to automate tasks. Gecko Robotics uses OpenShell to govern agents making decisions on physical robots. OpenShell capabilities OpenShell 0.1.0 supports sandbox operations, policy verification, governance integration, credential protection, and flexible compute. Capability How it helps Multi-tenant platform support Operate agent services for multiple teams or customers with separate workspaces, permissions, and service access on shared infrastructure. Formal policy verification Show human and AI reviewers whether requested permissions remain within defined security boundaries, and identify where they exceed them. Extensible security and governance Connect third-party security services, governance systems, and custom checks to enforcement outside the agent workload. Credential-protected service access Use authenticated services while real credentials remain outside the agent workload and are bound to authorized requests. CPU and GPU execution Run experiments and data processing on CPUs or GPUs across containers, VMs, and Kubernetes environments. Table 1. New capabilities introduced in OpenShell 0.1.0 Enforce permissions outside the agent An agent can interpret instructions, choose tools, and evolve its approach over time. OpenShell preserves that flexibility while enforcing permissions outside the agent workload. OpenShell can manage fleets of agents and their sandboxes, each with its own permissions, and enable governance across groups at a time. Three components provide this control: OpenShell Gateway: Manages the lifecycles and policies of many sandboxes. OpenShell Supervisor: Paired with each sandbox, it runs outside the agent workload and checks outbound requests against policy. OpenShell Sandbox: Runs the workload with kernel-level controls over its filesystem and processes, and no network path except through the supervisor. Figure 1. OpenShell manages agent sandboxes. External supervisors restrict outbound communication to configured services The OpenShell sandbox runtime uses operating-system kernel controls to limit which files a workload can read or change and prevent it from acquiring additional system privileges. For network access, you can be more specific than allowing a connection to a service. The supervisor can inspect configured HTTP, GraphQL, and Model Context Protocol (MCP) traffic, allowing a data query while blocking a write through the same API. These controls remain in place when the agent starts a shell, runs generated code, launches child processes, or proposes task delegation to sub-agents. OpenShell records policy decisions in an Open Cybersecurity Schema Framework (OCSF) audit trail. When it blocks an inspected request, it can return a descriptive error that helps the agent decide what to do next. Watch a policy decision happen This example uses curl and an unauthenticated endpoint in the GitHub REST API, making each policy decision visible without requiring an API key or language model. The same controls apply when an agent makes the request. Install and start OpenShell 0.1.0 using the installation guide . Then download the accompanying no-network.yaml and github-readonly.yaml policy files into an examples directory. First, create a sandbox with no outbound network access: openshell sandbox create --name policy-demo \ --no-auto-providers \ --policy examples/no-network.yaml The create command opens a shell inside the sandbox. Try reading a public endpoint: curl -sS --max-time 10 https://api.github.com/zen The request fails because the sandbox has no outbound network permission. Open a second terminal on your host and check the logs to see which program made the request and why it was blocked: openshell logs policy-demo --since 5m Next, replace the sandbox policy with one that permits read-only access to the GitHub REST API. Policies are authored in YAML and compiled to OPA/Rego, which OpenShell evaluates for each outbound request. network_policies: github_api: name: github-api-readonly endpoints: - host: api.github.com port: 443 protocol: rest enforcement: enforce access: read-only binaries: - path: /usr/bin/curl This rule lets /usr/bin/curl reach the GitHub API on port 443. With the protocol: rest, OpenShell inspects HTTP requests, allowing reads while blocking writes. In your host terminal, apply the complete replacement policy without restarting the sandbox: openshell policy set policy-demo \ --policy examples/github-readonly.yaml --wait Return to the sandbox shell and try both requests: # Read: allowed curl -sS --max-time 10 https://api.github.com/zen # Write: blocked curl -sS --max-time 10 -X POST https://api.github.com/zen Check the host logs again to confirm OpenShell blocked the POST. An agent running these commands encounters the same restrictions. Access services without exposing credentials Many agents need model APIs or private services to complete their tasks. OpenShell authorizes that access while keeping the real credentials outside the agent workload. Figure 2. The real credential is substituted outside the agent workload and only for an authorized endpoint. Both network access and credential binding must permit the request Authorization for one service does not make the credential available to another. If the agent sends the placeholder to a destination outside the credential’s approved endpoints, OpenShell rejects the request. The receiving service still enforces the permissions attached to the real credential. OpenShell adds a separate control over how the agent can use it. For example, an inspected read-only API policy can block write requests even when the credential itself has write access. A provider profile defines the credentials, endpoints, and permitted programs for a service. Assuming a GitHub provider named github is already configured, attach it to a new sandbox and launch Codex.