A triage agent is asked why a nightly job keeps failing. It reads the log, identifies a timeout against an internal service, and decides that the fastest path to a diagnosis is to post the stack trace to a third-party paste service for analysis. The command is well formed, the reasoning is sound, and the agent works exactly as designed. The stack trace also carries a service token. No vulnerability was exploited and no adversary was involved: the model chose an action nobody had anticipated, and the credential left the network before anyone read the transcript.
That gap between what an agent can do and what anyone can verify it did is often what holds agentic pilots up in security review. Familiar controls each cover part of it:
Workload isolation stops an agent escaping its container but not sending data out of it.
Prompt-level guardrails improve behavior, but they share a context window with whatever the agent reads, including injected instructions.
Network rules work at the level of “this workload may reach the internet,” not “only curl may read from this one API, and nothing may post anywhere.”
Closing the gap takes an enforcement point next to the agent, outside the model’s reach. That point needs to see each outbound connection, know which program opened it, and decide before the request leaves. OpenShell provides one, and it is now available as an optional component of the Intel® AI for Enterprise Agent Toolkit.
How it integrates with the Intel® AI for Enterprise Agent Toolkit
OpenShell is an open-source (Apache-2.0) runtime that runs AI agents in sandboxes governed by declarative policies implemented in YAML files. It protects files, credentials and the network from unintended access.
Hardware protection underneath. For data-in-use protection, the toolkit’s Kubernetes nodes can run as Intel® Trust Domain Extensions (Intel® TDX) confidential VMs. Memory is then encrypted and isolated from the host and hypervisor, and OpenShell’s policy enforcement runs unchanged inside.
What OpenShell adds is the enforcement:
| Added | Role |
|---|---|
| Gateway | The control plane for sandboxes, policies, and credentials |
| Supervisor (in every sandbox) | Filesystem, network, and process rules, enforced from the application layer down to the kernel |
| Provider access | Which endpoints and binaries are allowed, and credential injection bound to those endpoints |
Table 1: What OpenShell contributes to the toolkit
What matters most for the toolkit is that the integration runs on what is already there: OpenShell creates its sandboxes through the Kubernetes Agent Sandbox API, on the Agent Sandbox controller the toolkit already deploys, so the existing sandbox path keeps working alongside it, and it reaches models served on Intel® Xeon® through the toolkit's own GenAI Gateway (LiteLLM), registered as an OpenShell provider.
Every outbound connection pass through the policy engine, which allows it, denies and logs it, or attaches a credential to it. That last case is the interesting one. The toolkit mints a dedicated model key for sandboxes, and the agent never receives it: the sandbox sees a placeholder, and the real key is substituted only into requests policy has already approved. Because the key is dedicated, model usage by sandboxed agents is tracked separately in the GenAI Gateway. Administrators can limit it with the gateway’s own model lists and budgets.
Figure 1 shows why that holds in every case. Everything OpenShell contributes is highlighted in yellow, namely the gateway that holds sandboxes, policies, and credentials, the sandbox itself, and the supervisor inside it, while the unhighlighted boxes were already in the toolkit and run unchanged. The agent's loop stays inside the sandbox, and its model calls and tool calls have exactly one route out, through that supervisor. Allowed model traffic goes to the GenAI Gateway and on to vLLM or SGLang on Intel® Xeon®, allowed external traffic goes through the proxy to the hosts the policy names, and everything else is denied and recorded.
Figure 1: OpenShell in the Intel® AI for Enterprise Agent Toolkit
Summary
OpenShell adds a policy layer to the Intel® AI for Enterprise Agent Toolkit that sits next to the agent but outside the model's reach. It provides:
- default-deny egress at the level of program, host, HTTP method, and path;
- endpoint-bound credentials the agent never holds;
- decision logs that are independent of the agent's own account of what it did;
- model usage tracked on a dedicated gateway key.
The integration is additive. It reuses the sandbox controller, inference gateway, proxy settings, and deployment framework already in the toolkit; it is off by default; and it is built on the community Kubernetes Agent Sandbox API, so each layer stays independently replaceable.
As agents move from assisting to acting, enforcement needs to sit close to the action. Prompt-level guardrails remain a valuable quality layer, but the controls an audit can rely on are the ones that operate outside the model's context window.
Try it out
OpenShell is off by default, and switching it on is a line of configuration inside the toolkit's normal QuickStart rather than a separate install:
- Clone the repository and complete the prerequisites, covering hardware, SSH keys, and DNS and TLS setup.
- Choose your components in core/inventory/agentic-config.cfg.
OpenShell needs deploy_openshell=on together with deploy_agent_sandbox=on in the same run, plus an explicit authentication mode, or the deployment stops before installing anything. - Deploy with ./deploy-agentic-stack.sh, the same script that brings up the gateway, inference, memory, and observability layers. It installs the OpenShell gateway, applies the sandbox network policy, mints the dedicated model key, and registers the GenAI Gateway as an OpenShell provider.
The Quick Start Guide covers the base stack, and OpenShell in the toolkit takes it from there: the settings, verification steps, how to connect the CLI, and a full end-to-end example to run against.
Learn more:
- OpenShell in the toolkit: the integration guide, covering configuration settings, deployment and verification steps, where credentials live, the end-to-end example, and the known limitations.
- Intel® AI for Enterprise Agent Toolkit: the toolkit itself, its seven provider blocks, and the quickstart for the base stack.
- Nvidia OpenShell: the upstream runtime, including the policy schema reference and CLI releases.
- Kubernetes SIG Agent Sandbox: the community sandbox API and controller that both sandbox paths are built on.
