---
title: "NVIDIA's OpenShell Locks Down AI Agents With Google Vertex AI Support"
subtitle: "OpenShell v0.0.55 adds Google Vertex AI as an inference provider, profile-backed policy visibility, and more reliable Podman and GPU sandbox behavior"
url: "https://alphasignal.ai/news/nvidia-s-openshell-locks-down-ai-agents-with-google-vertex-ai-support"
author: "AlphaSignal Newsroom"
author_url: "https://alphasignal.ai/editorial-team"
company: "NVIDIA AI"
company_url: "https://alphasignal.ai/company/nvidiaai"
published: "2026-06-03T16:29:20.000Z"
updated: "2026-06-16T20:26:36.031Z"
type: "News"
topics:
  - "Agents"
  - "Open Source"
subtopics:
  - "Agent Frameworks"
  - "Tool Use"
upvotes: 197
read_time: "6 min"
source_url: "https://github.com/NVIDIA/OpenShell/releases/tag/v0.0.55"
comments: 0
---

# NVIDIA's OpenShell Locks Down AI Agents With Google Vertex AI Support

> OpenShell v0.0.55 adds Google Vertex AI as an inference provider, profile-backed policy visibility, and more reliable Podman and GPU sandbox behavior

[NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) is quietly becoming one of the more interesting pieces of infrastructure in the agentic AI stack. It is not a model, a framework, or a fine-tune. It is a runtime: a secure execution layer that sits between an autonomous AI agent and your actual machine, deciding what the agent is and is not allowed to do. Version 0.0.55 is out, and while the changelog is compact, the additions matter for teams running agents against Google Cloud.

## What OpenShell actually does

OpenShell is an open-source, secure-by-design runtime that executes autonomous AI agents inside kernel-level sandboxes governed by declarative policy. Agents such as OpenClaw, Claude Code, and Codex run unmodified while OpenShell enforces filesystem, network, and process controls with a full audit trail of every allow and deny decision.

The core insight behind the project is that prompting an agent to behave safely is not enforcement.
Writing "don't do that" in the prompt is not sufficient. A prompt is persuasion, not enforcement. OpenShell takes a different approach: placing constraints outside the agent, where the agent cannot reach them.
It works by ensuring each agent runs inside its own sandbox, separating application-layer operations from infrastructure-layer policy enforcement. This means security policies are out of reach of the agent -- they are applied at the system level.

It provides sandboxed execution environments that protect your data, credentials, and infrastructure. The CLI auto-discovers credentials for recognized agents (Claude, Codex, OpenCode, Copilot) from your shell environment, or you can create providers explicitly with `openshell provider create`. Credentials never leak into the sandbox filesystem; they are injected as environment variables at runtime.

## The four walls of the sandbox

OpenShell enforces isolation across four independent layers, each governed by a declarative YAML policy:

- **Filesystem** -- Prevents reads and writes outside explicitly allowed paths, locked at sandbox creation using Linux Landlock.
- **Network** -- Blocks unauthorized outbound connections. This layer is hot-reloadable at runtime, so you can tighten or loosen network rules without restarting the agent.
- **Process** -- Blocks privilege escalation and dangerous syscalls via seccomp. Also locked at creation.
- **Inference** -- Routes model API calls through a local gateway (`inference.local`), stripping the agent's credentials and injecting the real backend token. Also hot-reloadable.

OpenShell handles live policy updates to grant developer approvals in real-time and keeps the full audit trail, so every allow and deny decision is logged for forensic-level oversight.
The practical effect is that you get a compliance-ready record of everything an agent attempted, not just what it succeeded at.

## What's new in v0.0.55

The headline addition is **Google Vertex AI as a first-class inference provider**. Before this release, OpenShell shipped with profiles for OpenAI, Anthropic, and NVIDIA endpoints. Vertex AI is now in that same tier, with full gateway-managed credential refresh built in.

This matters because
several inference providers use short-lived credentials that require periodic refresh: Google Vertex AI and Azure OpenAI with Entra ID use OAuth2 tokens with a one-hour expiry.
OpenShell handles that rotation automatically at the gateway level.
The raw service-account JSON and private key are not sandbox runtime credentials and are not exposed to sandboxes. Runtime inference requests use short-lived access tokens minted by the gateway and stored under a separate credential key.

Setting it up for local development takes three commands:

```
# Authenticate with gcloud
gcloud auth application-default login
# Create the provider (reads your ADC automatically)
openshell provider create \
  --name vertex-local \
  --type google-vertex-ai \
  --from-gcloud-adc \
  --config VERTEX_AI_PROJECT_ID=my-gcp-project \
  --config VERTEX_AI_REGION=us-central1
# Point inference.local at Vertex and launch a sandbox
openshell inference set --provider vertex-local --model claude-sonnet-4-6
openshell sandbox create --name my-sandbox --provider vertex-local
```

Inside the sandbox, the agent connects to `https://inference.local` as normal. The gateway handles the Vertex-specific request shaping behind the scenes -- for Anthropic models it builds the rawPredict path and injects `anthropic_version` into the request body; for Gemini and other models it routes through Vertex's OpenAI-compatible Chat Completions endpoint.

## Policy visibility and the other fixes

The second notable feature is **profile-backed policy visibility**.
Providers v2 is available for profile-backed provider policy, provider-owned network rules, and gateway-managed credential refresh.
In practice, this means that when you create a provider, OpenShell can now surface the network endpoints and permissions that provider requires -- so you see the policy implications of adding Vertex AI before you approve them, rather than discovering them after an agent gets blocked.

The remaining fixes address real operational pain points:

- **Better Podman detection** -- The gateway now tries harder to detect Podman as the container runtime. Teams running rootless containers on RHEL or Fedora were hitting detection failures that caused sandbox creation to fall back incorrectly.
- **Restored GPU procfs baseline** -- A regression had broken the default behavior for reading GPU process information from `/proc` inside sandboxes. This is restored, which matters for any workload that queries GPU utilization or device state from within the sandbox.
- **CI and docs fixes** -- Ubuntu Snap and Fedora RPM canary installs are now at parity, and example paths in the local-inference README were corrected.

## Who should care

The biggest reason enterprises cannot adopt autonomous AI agents is not model performance or cost. It is security. If an agent can read files, execute code, and call external APIs on production systems without any means to control its behavior, no enterprise will adopt it.
OpenShell is a direct answer to that problem.

The practical use cases it covers well today:

- Running Claude Code, OpenCode, or OpenClaw with constrained file and network access on developer machines
- Routing inference to self-hosted or private backends while keeping sensitive context off third-party servers
- Auditing an unfamiliar MCP server in an isolated environment before trusting it in production
- Running parallel agent evaluations without state collisions between runs
- Compliance workflows where policy-as-code YAML needs to be version-controlled and reviewed

The project is still in alpha --
alpha software, single-player mode
-- and the GPU passthrough feature carries an explicit caveat:
experimental, GPU passthrough works on supported hosts but is under active development. Expect rough edges and breaking changes.
That said, the repo has accumulated
6.7k stars and 795 forks
, which suggests the problem it is solving resonates well beyond early adopters.

## Getting started

OpenShell is free and open source under Apache 2.0. Install the latest release with a single command:

```
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | OPENSHELL_VERSION=v0.0.55 sh
```

From there, the [official quickstart](https://docs.nvidia.com/openshell/get-started/quickstart) walks through creating your first sandbox in two commands. The [Vertex AI provider docs](https://docs.nvidia.com/openshell/providers/google-vertex-ai) cover both service account key and ADC-based authentication flows in full detail.
NVIDIA is collaborating with security partners, including Cisco, CrowdStrike, Google Cloud, Microsoft Security and TrendAI, to align runtime policy management and enforcement for agents across the enterprise stack
-- so the provider list is likely to grow from here.

## Sources

- [X post by @nvidiaai](https://x.com/nvidiaai/status/2062210034109677665)
- [Release OpenShell v0.0.55 · NVIDIA/OpenShell](https://github.com/NVIDIA/OpenShell/releases/tag/v0.0.55)
- [Overview of NVIDIA OpenShell | NVIDIA OpenShell Docs](https://docs.nvidia.com/openshell/about/overview)
- [Google Vertex AI Provider | NVIDIA OpenShell Docs](https://docs.nvidia.com/openshell/providers/google-vertex-ai)
- [How Autonomous AI Agents Become Secure by Design With NVIDIA OpenShell | NVIDIA Blog](https://blogs.nvidia.com/blog/secure-autonomous-ai-agents-openshell/)
- [GitHub - NVIDIA/OpenShell](https://github.com/NVIDIA/OpenShell)
