OpenShell joins the CNCF: a deny-by-default agent runtime, with Cedar still in review

OpenShell, the agent runtime NVIDIA open-sourced this year, is now a Cloud Native Computing Foundation project. The CNCF announced it as a Sandbox project on 10 November 2026 at KubeCon + CloudNativeCon North America, in a post co-signed by Jonathan Bryce of the CNCF and Ali Golshan of NVIDIA. The project runs each agent inside an isolated sandbox. A separate, trusted supervisor sits on the other side of that boundary and denies every outbound connection that its policy does not name.

The announcement also says OpenShell “is adopting Cedar, another CNCF project, as its policy language”. That sentence needs a date attached. As of 12 November 2026, stable OpenShell releases do not enforce Cedar. They enforce YAML policies evaluated by an embedded Rego program. Cedar is the subject of RFC 0020, which is in review, and of open pull requests that would ship it first in development builds only. Builders should read “adopting” as a stated direction backed by working code on a branch, not as a feature they can turn on in production today.

For anyone running coding agents or autonomous tools against real credentials, the more important fact is the architecture. OpenShell puts enforcement outside the agent’s process and outside its container, binds network permissions to the specific executable that opens a socket, and keeps real credentials out of the sandbox. That is a different control from the approval prompt inside an agent harness, and a different control from a container alone. This article explains how the mechanism works, what Sandbox status does and does not certify, how the Cedar work fits, and what remains unproven.

What the CNCF actually announced, and when

The 10 November post is the public announcement, but the decision came earlier. OpenShell’s CNCF project page records acceptance “on September 26, 2026 at the Sandbox maturity level”. The application and vote are public in the CNCF Sandbox repository. Reconstructing the sequence from those records and the OpenShell repository separates the event, the release and the publication dates:

Three things follow from that table. First, “joins the CNCF” describes a governance transfer that was voted on in September and announced in November. Second, the stable release a reader installs today, v0.1.8, contains no Cedar support. Third, the move to neutral infrastructure is still under way. The repository README says development is moving to the ai-openshell GitHub organisation, but that “until the move is complete, please continue to use the NVIDIA/OpenShell repo for code, issues, and pull requests.” The Python and Go SDKs have already moved; the v0.1.8 release notes say the Python package is now published from ai-openshell/sdk-python and the old Go module path is deprecated.

The CNCF post lists governance commitments: the project has adopted the CNCF Code of Conduct, runs a public RFC process and follows “a governance model with explicit vendor-neutrality commitments”. It names extension points for “providers, compute, governance and approval workflows, policy enforcement, isolation, and credential management”, and invites work on isolation coverage across Linux, macOS and Kubernetes, OpenTelemetry-aligned observability, and packaging work such as reproducible builds, SBOMs and signing, “all of which support Incubation requirements”. It also says core contributors from NVIDIA, Red Hat, Docker and Canonical “have worked on the project since its inception”. That last claim is the CNCF and NVIDIA’s account; the repository’s maintainers file tells a narrower story, covered below.

What Sandbox status means, and what it does not

CNCF projects sit at one of three maturity levels: Sandbox, Incubating and Graduated. The TOC process document describes Sandbox projects as “innovative and experimental ideas” where “failure is a possibility” and which “are expected to undergo significant changes, including breaking changes to their functionality”. It adds that they “might still be used in production by a few organizations on a case to case basis”. Incubation is the stage at which, in the TOC’s words, the committee “begins to actively evaluate the project’s adoption”.

Sandbox acceptance is therefore a statement about fit and governance, not a security certification. The application required the project to agree to the CNCF IP policy and to donate its trademarks and accounts; the onboarding checklist that followed asks it to move to a separate, neutral GitHub organisation. Neither the application form nor the onboarding checklist we read asks for an external security audit. The CNCF post itself lists “security reviews, adversarial testing, and vendor-neutral confidential computing work” among the areas where help is wanted.

The application thread does contain useful scrutiny. An automated pre-review flagged dependencies under licences not on the CNCF allowlist, including Unicode-3.0, CC0-1.0 and CDLA-Permissive-2.0, and the maintainers filed licence-exception requests in response. Brandt Keller, one of the binding voters, asked the project to explain its overlap with existing CNCF work and “what is the core capability OpenShell uniquely contributes to cloud native computing”. The maintainers’ answer is the best primary description of where OpenShell thinks it fits:

OpenShell’s core contribution is a runtime enforcement layer coupled with the infrastructure to run agents remotely in cloud environments.

The same reply describes the layering on Kubernetes: Kubernetes handles scheduling, networking and storage; the Agent Sandbox controller reconciles Sandbox resources into pods; OpenShell adds “launching restricted agent processes, filesystem and process controls, policy-enforced egress, endpoint-bound credential injection, and security events”. OpenShell’s runtime documentation confirms that its Kubernetes driver requires the Agent Sandbox controller.

Governance on paper and in the maintainers file

OpenShell’s governance document sets up a Maintainer Council that decides by lazy consensus, with simple-majority votes for most formal decisions and two-thirds for removing a maintainer or changing governance. It states that “no single organization controls project direction or decisions” and that maintainers are individual humans: “AI agents, automated systems, service accounts, companies, and other organizations cannot be Maintainers or exercise Maintainer votes.”

The maintainers file, as read on 12 November 2026, lists 14 people. Eleven list NVIDIA as their organisation and three list Red Hat. None lists Docker or Canonical. Under the voting rules, NVIDIA-affiliated maintainers alone exceed both the simple-majority and two-thirds thresholds. That does not contradict the CNCF’s statement about contributors, because contributing and holding a vote are different roles. It does mean that vendor neutrality is, for now, a commitment the governance document makes rather than a balance the maintainer roster shows. The document itself names “one organization dominates project decisions or Maintainer membership” as a signal that governance should evolve.

How OpenShell enforces policy from outside the agent

The central design choice is a split between two components that share a boundary but not trust. The architecture page describes them this way:

• The sandbox runtime lives inside the boundary with the agent. It launches the agent as a child process, identifies which executable made each request from trusted /proc data, and forwards TCP and DNS operations outward. Because it shares space with untrusted code, “it never makes policy decisions.”
• The supervisor lives on the trusted side. It checks each request against policy, resolves DNS, adds credentials where policy allows, opens approved upstream connections and keeps a link to the gateway.

Above both sits the gateway, the control plane that authenticates users, stores sandbox state and policy revisions, attaches credential providers and coordinates sessions.

The network path

On the current Linux backend, the workload runs as a single non-root identity with no Linux capabilities. Landlock limits filesystem access, and seccomp user notification intercepts network operations so they wait for a decision. The documented path for a connection has five steps: the agent opens a TCP connection or makes a DNS lookup; the sandbox identifies the calling program; the request travels over an authenticated HTTP/2 channel (the OpenShell Sandbox Protocol) to the supervisor; the supervisor checks policy and adds any permitted credentials; and, if allowed, the supervisor opens the real connection and relays traffic.

That channel is the only egress the workload is allowed. Each compute runtime builds an “outer network fence” with its own tools, so that an agent ignoring proxy variables or opening raw sockets has nowhere to go:

Source: OpenShell architecture documentation, read 12 November 2026.

The runtime’s job, the documentation says, “is to build the boundary and prove it’s in place. It never decides whether a request is allowed.” The same policy engine makes the decision on every runtime.

Failing closed

Several documented behaviours exist so that a broken boundary stops the agent rather than freeing it. The sandbox holds the agent’s launch until the supervisor confirms the boundary, and “freezes the agent if the connection drops”, allowing a short reconnection window before terminating the workload. The support matrix requires Landlock ABI 3 or newer (Linux 6.2 or later, or a qualified backport), specific seccomp user-notification features and socket binding, and says the sandbox “actively probes” these before admitting the workload; a missing facility “causes launch to fail closed”. On macOS, these checks run inside the Docker Desktop Linux VM.

Policy contents and the default

A policy is a YAML file with up to five sections, each enforced at a different point, according to the policy overview:

The deny-by-default claim in the headline is documented precisely. “OpenShell denies every outbound connection from a sandbox unless a rule in network_policies allows it.” The default policy, used only when no global, saved or image-embedded policy exists, defines no network rules at all, grants read-only access to /bin, /usr, /lib, /proc, /dev/urandom, /etc and /var/log, and grants read-write access to the working directory, /tmp and /dev/null. An invalid policy baked into an image stops the workload from starting rather than falling back to the default.

Each network rule pairs a list of endpoints with a list of binaries, and a rule “allows every listed binary to reach every listed endpoint”. Binary identity is the real executable path as the kernel reports it, not the command a user typed, so a rule for pip install has to name the Python interpreter. The security guide says OpenShell pins each authorising executable to its first observed SHA-256 digest (trust on first use) and denies later connections if the digest changes. A rule that lists an agent’s executable also covers tools that agent launches.

Credentials that only work at approved endpoints

Credentials are handled by providers, which link a service name to a stored secret. The architecture page says OpenShell “supplies credential placeholders to agents and adds real credentials only to requests bound for approved endpoints.” The v0.1.8 release narrowed this further: static credentials without explicit placement metadata now resolve only in the Authorization header, unless a placement is declared explicitly or a body or WebSocket rewrite policy is enabled. Red Hat’s May post, describing its own integration, put the design in one line: “Secrets are never stored inside the sandbox.”

Where approval fits: the policy advisor and the prover

A deny-by-default sandbox raises an immediate practical problem. Agents need hosts nobody anticipated. OpenShell’s answer has two parts: a way for agents to ask, and a solver that checks the request.

Proposals, not self-service

The policy advisor, off by default, gives an agent instructions and a local API at http://policy.local to read its current policy, see recent denials and submit a proposed network rule. A proposal “never changes the policy on its own.” By default every proposal waits for a human, who approves or rejects it with openshell rule approve or openshell rule reject. A rejection reason goes back to the agent so it can submit a narrower request. Agents cannot propose protocol: tcp or tls: skip, cannot remove rules, and cannot touch filesystem, Landlock or process settings. Loopback, link-local and cloud metadata addresses can never be approved.

Even with the advisor disabled, OpenShell drafts its own proposals from blocked connections: each draft allows one binary to reach one host and port, and it goes through the same review. The request that triggered it stays denied until a person or the automatic mode approves the draft.

What the prover checks

Every proposal runs through a proposal risk check by the policy prover, which “uses an SMT solver” to compare what the sandbox could reach with and without the new rule. It reports four kinds of finding:

Operators can opt in to automatic approval (proposal_approval_mode set to auto). A proposal is then approved without review only if the prover finds nothing and OpenShell has not flagged the destination: private IP hosts, wildcard hosts, private allowed_ips ranges, ports above 49152, and well-known database and cache ports such as 5432 and 6379 are all flagged. A gateway-wide setting overrides per-sandbox settings, so an administrator can force manual review everywhere.

The documentation is candid about the limit of automatic mode: “These checks do not treat access to a new public host as a risk when no provider credential applies there.” In other words, auto mode protects credentials and internal networks. It does not stop an agent from gaining a route to an arbitrary public host without review, which is exactly the exfiltration path the security guide warns about.

Separately, the openshell-prover check command runs a boundary check: does a candidate policy allow anything beyond a maximum policy an organisation writes? It returns within_boundary, exceeds_boundary with a counterexample, error, unsupported or inconclusive. Its coverage is explicit and partial. It models filesystem access, process identity, Landlock settings, L4 connections and REST rules. GraphQL, MCP, JSON-RPC and WebSocket rules return unsupported, as do REST endpoints in audit mode. Policies with more than 1,024 network rules or 4,096 endpoints return inconclusive, and the default time limit is 10 seconds. “Only within_boundary means that the check passed.”

A worked example, with hypothetical inputs

The following scenario is illustrative. The inputs are invented; the behaviours are those the OpenShell documentation describes as of v0.1.8. GenAI Brief has not run this sequence.

A team creates a sandbox for a coding agent with no custom policy, from an image that contains no embedded policy, and attaches a GitHub provider. The agent’s task is to install a Python package and update a file under docs/ in a repository.

1. The package install is blocked. The agent runs pip install. The connecting process is the Python interpreter, which on Ubuntu 24.04 resolves to /usr/bin/python3.12. The default policy has no network rules of its own. The attached GitHub provider can contribute rules to the effective policy, but those cover GitHub, not the package index, so the supervisor denies the connection and the sandbox log records a NET:OPEN ... DENIED line.
2. OpenShell drafts a rule. Whether or not the advisor is enabled, OpenShell drafts a proposal allowing /usr/bin/python3.12 to reach that one host and port. The prover finds no credential involved and the destination is a public hostname on port 443, so nothing is flagged.
3. The approval mode decides. In manual mode, the draft waits for a person. In auto mode, it would be approved without review, and the interpreter would keep a standing rule for that host in the sandbox’s policy until someone removes it.
4. The GitHub write needs review. The agent, with the advisor enabled, proposes a rule for /usr/bin/gh to send PUT requests to api.github.com under /repos/<org>/<repo>/contents/docs/**, with protocol: rest and enforcement: enforce. Assume the provider’s contributed rules do not already allow that write. Because a provider credential applies at that host, the prover’s credential checks come into play; a rule that gives the credential new reach or a new method produces a finding, which blocks automatic approval and requires a human.
5. Enforcement mode matters after approval. If a human later writes the same rule by hand and omits enforcement, the request rules default to audit. The proxy then logs a DELETE that the rule does not allow, but forwards it.

The example shows where judgement still lives. OpenShell turns “the agent can reach anything” into a short list of explicit, logged decisions, each scoped to a binary. It does not decide whether a public host is safe for your data, and its defaults on request inspection favour visibility over blocking until an operator changes them.

Where Cedar fits, and how far along it is

The Cedar work starts from a limitation the project documents itself. In issue 4411, opened on 12 October 2026, the author writes that OpenShell policies are YAML “backed by OPA and Rego”, that the evaluator “is over a thousand lines of general-purpose Rego, which tools cannot reason about exhaustively”, and that “Rego is not fully decidable”. The prover works around this with a hand-built SMT model of the YAML structure, which RFC 0020 says “trails the evaluator feature by feature”. That is why GraphQL, MCP and WebSocket rules return unsupported today.

Cedar, which the CNCF accepted at the Sandbox level on 8 October 2025, was designed for this kind of analysis. Its design paper describes a structure “finely balanced to allow for a sound and complete logical encoding, which enables precise policy analysis”, modelled in the Lean proof assistant and implemented in Rust. RFC 0020’s argument is that if Cedar is the enforced policy, analysis applies to whatever an author writes rather than only to the shapes a separate model covers. The RFC proposes that a sandbox choose YAML or Cedar once, for its lifetime, with no translation and no second engine: “A Cedar sandbox is decided by Cedar alone.” It splits network decisions into two actions, NetworkConnect at connection time and HttpRequest for each inspected request. Inspection settings and middleware would move into a separate --middleware file. Providers would supply credentials but no longer grant access on their own.

The evidence for parity, and how it moved

The author reports a parity harness that runs paired YAML and Cedar policies through both engines. The figures have changed as the work progressed, so the dates matter:

All three are author-reported results from the project’s own test harness; GenAI Brief has not reproduced them. The RFC also reports that a panel review of the implementation found six defects and one documentation gap, each fixed with a regression test. One was that an older gateway “read a Cedar policy as empty YAML”, a reminder that version negotiation is a security property here, not a convenience.

What has to happen before builders get it

The RFC’s own rollout section is explicit. Cedar “ships as an opt-in, development-only feature”. Pre-release and stable builds exclude the Cedar crates, and a stable gateway rejects Cedar policies on create and update. Pull request 5006 implements that limit. Promotion to stable “follows acceptance of this RFC” and decisions on open questions that affect the schema. As of 12 November, the RFC’s state is review, the implementation pull requests are open and unmerged, and both were marked stale on 11 November.

Three further caveats in the RFC matter for any evaluation:

• The openshell-prover CLI “reads YAML only”. Extending boundary and proposal checks to Cedar through Cedar’s symbolic compiler is listed as remaining work, so Cedar sandboxes would at first lack the automated proposal checks YAML sandboxes have today.
• Policy advisor proposals and incremental openshell policy update edits are “not available” for Cedar sandboxes; authors replace the whole policy instead.
• The implementation depends on a Cedar language change that is not yet upstream (delimited like for segment-aware globs, proposed as cedar-policy RFC 115), carried in OpenShell’s own Cedar, ai-openshell/cedar. The RFC calls the git pin “a standing supply-chain exception the project owns rather than a temporary one”.

The motivation section also points beyond this RFC: Cedar is described as the base for temporal policies, such as permitting a call only if the same principal was approved within the last hour, through an extension called Dogwood. The RFC lists temporal policies as a non-goal for now. If that later work lands, approval history could become part of policy rather than a separate workflow, but nothing in the current releases does this.

OpenShell next to containers and approval systems

The comparison builders need is between controls they may already have. The table below is GenAI Brief’s synthesis from the documentation cited; it describes design scope, not measured effectiveness.

The NetworkPolicy row draws on the Kubernetes documentation, which describes it as controlling traffic “at the IP address or port level (OSI layer 3 or 4)” and warns that creating one “without a controller that implements it will have no effect”. OpenShell relies on that same mechanism as its outer fence on Kubernetes, and its README warns: “Your CNI must enforce NetworkPolicy.”

The harness row matters because it is where many teams start. Our guide to Claude Code’s --dangerously-skip-permissions flag describes how a single harness permission mode can switch off most prompts at once. An approval system inside the agent’s process is only as strong as that process’s configuration. OpenShell’s argument, stated in the CNCF post, is that “this requires enforcement outside of the agents, right within the infrastructure that the agents run on.” The two layers are complementary: a harness prompt can stop a destructive local command that OpenShell’s network policy would never see, while OpenShell can stop an exfiltration attempt the harness was configured not to ask about.

It also helps to place OpenShell against the wider problem of untrusted instructions. Our prompt-injection explainer covers why an agent may faithfully follow malicious text. A runtime boundary does not prevent that; it limits what the compromised agent can reach. Likewise, the agent harness explainer describes the loop and tools around a model. OpenShell governs the environment the harness runs in, not the harness logic.

Where approval workflows plug in at the control plane

The policy advisor covers network rules proposed from inside a sandbox. Organisational approval of policy itself sits at the gateway. Gateway interceptors are external gRPC services that run after authentication and before the gateway handles a write, in three phases: modify_operation can allow, deny or patch a request; validate can allow or deny; post_commit observes. The documentation’s examples include applying an approved policy to every new sandbox and rejecting attempts to weaken it, and the gateway still runs its own validation after any patch. Teams with an existing change-approval system would integrate there, not inside the agent.

What remains unknown

The documentation is detailed, but several questions that matter to a deployment decision are not answered by anything this publication could verify.

Independent security assessment. We found no published third-party audit or penetration test of OpenShell’s boundary. The CNCF post asks for “security reviews” and “adversarial testing”. The design depends on kernel facilities (Landlock, seccomp user notification) and on correct identification of executables, and the v0.1.8 notes include fixes such as removing AWS SigV4 diagnostics from TRACE logs “where they could expose the temporary session token”. Weekly fixes are healthy, but they are not a substitute for an external review.

Request-level defaults. Connection-level denial is the default; request-level enforcement is not. Inspected endpoints default to audit. Endpoints without a protocol field allow any method and path once the connection is permitted. Teams that equate “deny-by-default” with “every API call checked” will be wrong unless they write enforced request rules.

Trust on first use. Binary pinning records the first digest it sees. An executable that is already malicious when it first connects would be pinned as trusted. The documentation does not claim otherwise.

Adoption claims. The maintainers’ reply in the CNCF application links announcements from SAP, Cadence, Dell, ServiceNow and Adobe as adopters. We read the Red Hat post, which describes early validation rather than a shipping product; we did not verify the others, and the application’s formal “Adopters” field was left blank. The CNCF post refers to “many additional organizations adopting OpenShell” without naming them.

Governance in practice. The governance document is strong on vendor neutrality; the maintainer roster is concentrated. Whether Docker, Canonical or other organisations gain maintainer seats, and whether decisions such as RFC 0020’s acceptance happen in public forums, will be visible over the coming months.

Cedar’s timeline. RFC 0020 has no acceptance date, its pull requests are stale, and its open questions include schema decisions that the RFC says would be breaking if made after a stable release.

Telemetry. The README says OpenShell collects anonymous operational telemetry by default, limited to categories and counts, which can be disabled with OPENSHELL_TELEMETRY_ENABLED=false or compiled out. Organisations with strict egress rules for their own infrastructure should make that choice explicitly.

What would change this assessment

The conclusion here is that OpenShell is a serious, well-documented design for out-of-process agent enforcement, at an early governance stage, with Cedar as an intention rather than a shipped capability. Specific evidence would move that:

• RFC 0020 moving to an accepted state and Cedar appearing in a stable release, with prover checks extended to Cedar sandboxes.
• A published external security assessment of the sandbox boundary and supervisor, with findings and fixes.
• Additional maintainers from organisations other than NVIDIA and Red Hat, or an Incubation application with the adopter evidence the TOC requires at that stage.
• Conversely, a boundary-bypass vulnerability in the supervisor channel or the seccomp mediation would weaken the central claim that enforcement sits outside the agent’s reach.

What to do if you are evaluating it

A team considering OpenShell should treat it as an early-stage runtime with a clear architecture and test it against its own threat model. A reasonable sequence:

1. Pin a stable release and read its notes. The project publishes stable releases weekly, targeting Tuesdays, and supports the latest and previous minor lines. Breaking changes in v0.1.0 required recreating every sandbox, and v0.1.8 changed credential placement and SIEM field mappings.
2. Write a boundary policy first. Define the maximum access an agent in your environment may ever have, then run openshell-prover check against each sandbox’s effective policy in CI. Treat unsupported and inconclusive as failures, as the documentation instructs.
3. Keep approval mode manual until you have data. Auto mode approves new public hosts without review when no credential is involved. Decide whether that is acceptable for your data before enabling it, and set it at the gateway level so individual sandboxes cannot loosen it.
4. Move inspected endpoints from audit to enforce deliberately. Use audit to see what a rule would block, then switch. Do not assume request rules block by default.
5. Verify the outer fence. On Kubernetes, confirm your CNI enforces NetworkPolicy. On any runtime, confirm the kernel passes the sandbox’s qualification probes rather than relying on kernel version alone.
6. Run your own adversarial checks (proposed). A proposed test, not one GenAI Brief has run: from inside a sandbox, attempt raw-socket connections, DNS lookups to an unapproved resolver, connections from a renamed or replaced binary at an approved path, and requests to a metadata address. Each should be denied and logged. Record the results against the specific release.
7. Track RFC 0020 separately. If Cedar’s analysability is the reason you are interested, follow the RFC’s state and the prover’s Cedar support, and evaluate Cedar only in a development build until both land.

The CNCF move gives OpenShell a neutral home and a public process at the moment agent security is moving from prompts to infrastructure. The design’s strongest idea is not the policy language. It is that the component deciding what an agent may reach is never one the agent can modify. That idea is already in the stable release. Cedar may make those decisions easier to analyse. Until it ships, judge OpenShell on the supervisor, the fence and the defaults you configure.