How to Deliver AI Agents with OpenShell and Kargo

A proof of concept for releasing agent behavior and permissions together.

An AI agent’s prompt, model, or tools can change its behavior without a new container image. In Amplify Partners’ 2025 AI Engineering Report, 70% of respondents updated prompts at least monthly, and more than half updated models that often. Teams need to version these changes, verify them before they advance, and restore earlier behavior and permissions when needed.

In this demo, Kargo Enterprise on the Akuity Platform invokes NVIDIA OpenShell’s policy prover before deployment, then runs behavioral evaluations (evals) against the live agent. OpenShell enforces access at runtime, while Argo CD manages the underlying Kubernetes platform.

The demo repository includes the code, setup instructions, and a walkthrough of the policy checks, evals, and rollback.

What are NVIDIA OpenShell and Kargo?

What is NVIDIA OpenShell?

NVIDIA OpenShell is an open-source runtime for running AI agents in isolated sandboxes. It enforces filesystem, network, and process restrictions independently of the model’s instructions. The demo uses its supervisor, gateway, and policy prover:

• Supervisor: checks outbound network requests against the sandbox policy and supplies provider credentials only where authorized. The agent workload does not hold the provider’s API key.

• Gateway: manages sandbox lifecycles, policies, and provider configuration through an API.

• Policy prover: compares a candidate policy with the maximum access an environment permits.

What is Kargo?

Kargo is an open-source continuous promotion tool that moves versioned code and configuration through environments. Argo CD reconciles Kubernetes resources from Git; Kargo controls which version each environment receives and when. This demo uses Kargo Enterprise on the Akuity Platform.

How do OpenShell and Kargo work together?

Kargo controls which agent version and sandbox policy reach each environment; OpenShell enforces that policy while the agent runs. In this proof of concept, a support agent for fictional retailer Acme Outfitters moves through dev, prod-us, and prod-eu.

Kargo tracks the agent image and versioned bundle as one release, then promotes it through dev to prod-us and prod-eu.

The workflow uses released Kargo Enterprise capabilities. Custom Steps let teams run containerized tools during promotion. In this demo, one step invokes OpenShell’s policy prover and another creates or updates the sandbox through the gateway.

Argo CD manages the platform’s Kubernetes components, including OpenShell’s gateway and the Agent Sandbox controller. OpenShell provisions each sandbox’s workload and supervisor at runtime.

Each release goes through promotion, then verification:

1. Kargo invokes OpenShell’s prover against the target environment’s boundary. A failing, unsupported, or inconclusive result stops the promotion.

2. If the policy check passes, Kargo applies the agent release to the sandbox through OpenShell’s gateway.

3. After promotion succeeds, Kargo starts a verification job that runs evals against the live agent.

In this demo, each verification run executes every configured eval once. All must pass before the release can advance to the next stage.

What should an AI agent release include?

An AI agent release should identify the versions of its model configuration, prompt, tools, orchestration code, sandbox policy, and evals. Together, these inputs define what a team reviews, promotes, and restores.

A container build may package some of those parts. Others may live in a configuration file, prompt registry, or provider setting. If the delivery workflow tracks only the image, it can miss changes that affect what the agent does.

Kargo’s unit of promotion, Freight, references a set of artifact revisions that travel together. For an agent, an image digest can be paired with a Git commit containing the model configuration, prompt, tool definitions, policy, and evals. Each environment receives the selected combination through a deliberate promotion.

How do OpenShell and Kargo control agent permissions?

OpenShell enforces runtime access through network, filesystem, and process controls. Before deployment, Kargo invokes OpenShell’s policy prover to check the release’s requested permissions against the target environment’s boundary. For example, a prompt can instruct a support agent to avoid issuing refunds, while a runtime policy restricts the API calls that would issue one.

On Kubernetes, network isolation directs the workload’s outbound traffic through the supervisor. Network rules can constrain REST requests by HTTP method, path, and query parameters.

The prover can return a counterexample when the candidate policy exceeds the boundary. A passing check covers only the policy domains the prover models; it does not establish that an agent will behave correctly.

Agent teams version the requested policy. Platform and security teams maintain each environment’s boundary separately from the agent release. A policy that passes for one environment can still exceed another environment’s permissions.

How to verify AI agent behavior and permissions

Verifying an AI agent release combines two complementary checks: a policy check against the environment’s permission boundary before deployment, followed by behavioral evals against the live agent after deployment. Each catches failures the other misses.

First, a prompt edit drops the instruction to arrange specialist follow-up for damaged deliveries. Its permissions still fit the boundary, so the release reaches dev. Evals against the live agent catch the behavioral regression. Verification fails, and both production stages retain the earlier version.

The refund-handoff eval fails in dev. Six of seven evals pass, but the release cannot advance to production.

Next, a release adds a refund tool and the permission to call it. The US boundary allows refunds; the EU boundary does not. The prover finds the policy within the US boundary but outside the EU boundary, so Kargo blocks the EU promotion before the sandbox changes. Each environment’s boundary determines whether the release can proceed.

The prover identifies a refund request outside prod-eu’s boundary. Kargo stops the promotion before applying the change to the sandbox.

The first check catches a problem with behavior. The second catches excessive permissions. Both are needed: valid permissions do not guarantee a good customer response, and passing behavioral scenarios does not authorize broader access.

How to roll back an AI agent release

Rolling back an AI agent release means re-promoting an earlier version, restoring its prompt, tools, and permissions together and rerunning verification.

This walkthrough triggers rollback manually and removes the refund permission by re-promoting the earlier version. It does not undo refunds already issued, so teams still need recovery procedures for external actions.

Kargo Enterprise 1.11 or later also supports automated rollbacks when enabled, which re-promote a stage’s last verified Freight after verification fails.

OpenShell can reload network rules at runtime. Changes to filesystem or process restrictions require recreating the sandbox.

What does the proof of concept show?

For platform teams, the value is a repeatable process for agent changes: version the whole agent, check its permissions against each environment’s boundary, and verify its behavior before advancing to the next environment. Kargo supplies that release workflow; OpenShell enforces the permissions while the agent runs.

Common questions

Is this production-ready?

No. This integration is a proof of concept built on released Kargo Enterprise capabilities. The demo does not establish production readiness for OpenShell.

Can Argo CD deploy OpenShell sandboxes directly?

This demo uses OpenShell’s gateway API to create and update sandboxes. Argo CD manages the underlying Kubernetes platform, including the Agent Sandbox controller; it does not reconcile the agent sandboxes directly. Managing the controller does not make each sandbox a Git-managed resource.

Configuration checked November 5, 2026: the OpenShell gateway chart and CLI/prover tooling are pinned to 0.1.6; setup requires Kargo Enterprise 1.11 or later.

Explore the walkthrough to see policy checks, evals, and rollback in action.

Related reading: the Akuity Agentic Control Plane covers agents operating delivery tools through MCP, the other side of the agent delivery story.