--- title: "Hope isn't security: the five parts of an enterprise agent" description: At GTC Berlin, Jensen Huang split an AI agent into five parts: the model, the harness, the sandbox, your company's knowledge and your tools. His advice to companies getting ready for agents starts with the sandbox, because today the only thing stopping an agent is asking it nicely. Notes on OpenShell, Sentry, the knowledge foundation, and where my own agents stand. date: 2026-10-23 tags: AI agents, agent security, NVIDIA, OpenShell, enterprise AI --- At GTC Berlin on October 21, Jensen Huang took an AI agent apart into five pieces: the model, the harness, the sandbox the harness runs in, your company's knowledge and your tools. His advice to every company getting ready for agents starts with the sandbox, not the model. Today the only thing between an agent and your SSH keys is a prompt asking it nicely. NVIDIA's answer, OpenShell, moves the rules outside the agent, where a policy checks every file, system call and network connection. The agent part of the [keynote](https://www.youtube.com/watch?v=PvFjbPYEOZI&t=2502s) runs from about minute 41 to minute 66. It's the clearest checklist I've seen for what a company needs before agents touch its systems. It's also a vendor keynote, so I flag the claims that came without a number. I run a fleet of OpenClaw agents on a Mac mini, and at the end I hold my own setup against the list. ## An agent is five parts, and only one is the model Jensen opened with the shift of the year. Agents think, reason, iterate and use tools, and that burns an enormous amount of tokens: token consumption, in his words, "has gone through the roof", and GPU demand with it. He credited OpenClaw, which NVIDIA talked about at the start of the year, with starting the open-source agent wave we see everywhere today. Then the anatomy. The language model generates tokens. The harness consumes them; Jensen calls it the exoskeleton, and his example is OpenClaw. The harness sits inside a sandbox that isolates it from the rest of the system. The last two parts are knowledge and tools. NVIDIA's diagram draws the harness as a loop: take in context, reason, plan, act, go around again, with knowledge and tools wired in underneath. The model does the thinking. The other four decide what that thinking can touch.

1Model

generates the tokens

3Sandbox isolates it from the rest of the system

2Harness the exoskeleton

  1. Context
  2. Reason
  3. Plan
  4. Act

4Knowledge

your company's data

5Tools

what the agent acts with

Jensen"Models, sandbox, harness, knowledge and tools. These are the five elements of an agent."

The loop is NVIDIA's own drawing of the harness, redrawn and numbered in Jensen's order. The highlight walks the four steps; the squares are tokens.
## Please don't is not a security model Before making agents useful, Jensen said, you have to make them secure. An agent is an autonomous system with access to files, resources, networks and tools. Its privileges have to be minimal, and it has to be watched all the time. The video that came next has the best line of the keynote. Today, the only thing stopping an agent from misusing its access is asking it nicely. "Please don't delete anything. Please don't touch my SSH keys." NVIDIA calls it the please-don't approach, and answers it in three words: hope isn't security. I've written those prompts. Anyone who runs agents has. The trouble is where they live: in the agent's own context, the same place a prompt injection from an email or a web page lands. The video's comparison is the early web. Viruses were everywhere until browsers enforced strict limits on what a page could do. Nobody asked the page nicely. OpenShell wants to be that browser for agents: you write a policy for what each agent can touch, and it's enforced on system calls, file access and network connections, outside the agent, "not just in LLM guardrails".

The please-don't approach

Ask nicely

In the prompt

Please don't delete anything.

Please don't touch my SSH keys.

Reached the keys

The rule sits in the agent's own context

vs

Enforced outside the agent

A policy

In the policy

files: ~/.ssh not allowed

network: approved hosts only

Denied at the policy

The check sits where the agent can't edit it

The early webViruses were everywhere until browsers enforced strict limits on what a page could do.

The same request, twice. The policy lines are my sketch, not OpenShell's syntax.
## The keys never enter the sandbox This is the part worth copying even if you never install OpenShell. It's open source under Apache 2.0, and its [architecture docs](https://docs.nvidia.com/openshell/latest/about/architecture) split the job four ways. - The sandbox holds the agent and has no direct route to the network. It catches every connection and DNS lookup, names the program behind it and hands it on. It never decides anything. - The supervisor sits outside the sandbox and makes the decisions. It checks each request against the policy, opens the real connection if it's allowed, and holds the credentials. - The gateway is the control plane: identity, policies and the life of each sandbox. - The policy prover runs in the gateway and checks proposed policy changes with formal verification. The credential trick is the one I like most. A provider maps a service to a stored credential, and the supervisor adds it only to requests bound for an endpoint the policy approves. The agent never sees the real key. As the video puts it, a compromised agent can't leak a key it never had. The rules don't all move at the same speed either. Filesystem and process rules are locked when the sandbox is created. Network rules reload while it runs, and credentials can be attached, rotated or revoked at runtime.

Gatewaycontrol plane: identity, policy, sandboxespolicy prover

  1. 1AgentOpens a connection or a DNS lookup. The sandbox has no direct route out.
  2. 2SandboxCatches it, names the program behind it, hands it on. Decides nothing.
  3. 3SupervisorChecks the request against the policy, outside the sandbox.
  4. 4SupervisorAdds the credential for an approved endpoint only, then opens the real connection.
  5. 5SupervisorA host the policy doesn't approve: denied.

The videoA compromised agent can't leak a key it never had.

One allowed request, then one denied. The square is the request: it turns cobalt when the supervisor adds the key, red when it's refused.
## Every launch gets different privileges Back on stage, Jensen made the point that turns a container into a product. Every level of capability, every task you give the agent, every person who uses it: each combination needs a different level of privilege. Every time an agent launches, the privileges are different. So the privileges, the policy enforcement and the monitoring all have to happen at runtime. That's the prover's job. When an agent asks for new access, OpenShell checks what the change would allow before applying it. The docs list what gets flagged: new reach with credentials, a new HTTP method, access to cloud metadata. Any finding blocks auto-approval, so the change waits for a human. The video's version: agents never gain more access than intended. He also said this isn't only for the companies that build agents. It's for every company that will receive agents and let them run inside. That's the enterprise ask in one line: you need the runtime even if you never write an agent. On the same stage he announced that Anthropic and NVIDIA are partnering on Claude agents that run in OpenShell. It's the conclusion Jiquan Ngiam reached in my [note on AI coworkers in Slack](/notes/ai-coworkers-slack-agent-identity.html) too: the right permissions depend on who asked, who will see the answer and what the task is, so they get decided per message.

Capability+Task+Person=This launch's privileges

The prover flagsNew reach with credentials, a new HTTP method, cloud metadata access. Any finding blocks auto-approval.

Locked at creationFilesystem and process rules. Network rules and credentials change while it runs.

Bar heights are schematic: NVIDIA gives no numbers. The flagged list and the layers come from OpenShell's docs.
## A second guard on its own chip OpenShell enforces from the host's kernel. NVIDIA's optional extra leaves the host altogether. Sentry runs on a BlueField-4, a DPU: a processor on the server's network card, in its own hardware domain. The agent's reasoning traffic to the model passes through it. If the agent plans something unintended, Sentry updates the policy and cuts the connection to the model, quarantining the agent, NVIDIA says, in milliseconds. It keeps tamper-evident records for the security team and doesn't rely on logs from the host or the agent. Two caveats. NVIDIA calls Sentry optional, a layer on top, not a requirement. And I couldn't find a published method behind "milliseconds". In Berlin it's packaged as the OpenShell reference architecture: Vera Rubin for model inference, Vera CPUs for harnesses and tools, BlueField-4 running Sentry.

RecordTamper-evident, for detection, investigation and response

NVIDIA's claimQuarantine in milliseconds, even if the host is compromised. No method published.

Sentry is optional, a layer on top of OpenShell. The three boxes follow the OpenShell reference architecture announced in Berlin.
## Rent the general model, own the special one Then models. Jensen doesn't expect any company to run everything on one model. When the work is fairly generic, a general model does an incredibly good job. When the work captures too much of your proprietary knowledge, and you want to keep improving it, you take an open model and post-train it on your own data. Every company, he says, will use both. NVIDIA's open family is Nemotron, shipped with the open weights, the training data and the scripts to reproduce it, so you know where the model came from. He was candid about the catch: these models "are not necessarily the frontier of frontiers", especially for language. The claim is that post-trained on your data, they reach frontier level for your use case. He backed it with partner pairs, Baseten with CodeRabbit and Scale with Skydance among them, and no benchmark on stage. My fleet already splits that way. Most of my agents run on Claude. Fortuna, the one that reads my finance app, runs on Qwen 3.6 on the Mac mini itself.

Fairly generic work

Rent

General modelclosed or open, used as it comes

"Going to do an incredibly good job"

Every company will use these

and

Your proprietary knowledge

Own

  1. Open weights
  2. The training data
  3. The scripts to reproduce it
  4. Your data: post-train it

And keep improving it

JensenThese models "are not necessarily the frontier of frontiers, especially for the language model."

Both, not either. The recipe is what NVIDIA ships with Nemotron's weights; the last line is the part only you have.
## Knowledge turns agents into super agents "What turns these agents into super agents is that you give them access to your company's knowledge." NVIDIA's piece for that is the agent knowledge foundation: libraries and models that pull meaning out of your data, whether it's unstructured, like PDFs that need an AI to read them, or structured, like rows in a database. He named the parts one at a time. Nemotron Parse reads documents. Nemotron Embed matches a query to what's in a vector database. Nemotron Rerank takes the many sources a query matched and ranks them by relevance. Kumo predicts what's likely to happen from a structured database. Then his example. A notice arrives that a supplier will be short or late: that's a document. Your orders sit in a SQL database. Kumo predicts which orders will run short and by how much. Then vector search finds the engineering document for a replacement component. One question, and it crosses a document, a database and an archive. That's the part closest to my day job. I connect commerce systems for a living, and an agent can only answer that question once somebody has wired it to the order system.

  1. 1The notice

    A document, so unstructured. Parse reads it.

  2. 2The orders

    Rows in SQL. Kumo predicts which run short, and by how much.

  3. 3The fix

    Vector search finds the engineering doc for a replacement.

Parsereads documentsEmbedmatches a query to the vector databaseRerankorders the sources by relevanceKumopredicts from structured data

His example, step by step. The four names under it are the parts of NVIDIA's agent knowledge foundation he listed on stage.
## Tools are the trade The last part is tools. NVIDIA's CUDA-X libraries are simulators, solvers, data processing engines and domain libraries, and Jensen calls them the crown jewels of the company. The video's line: the most intelligent scientist still needs a laboratory, and the best engineer still needs simulators and solvers. He also said why coding went first. Software was one of the first fields agents took on, and there a compiler or Python is all the agent needs. Other work needs more tools. The video showed three. Lila Sciences, designing a therapy for B-cell lymphoma: the Iris agent turns the goal into an experimental plan, agents run millions of virtual experiments in a computational dry lab, the best candidates go to an AI science factory where robots make and test them, and the results go back to Iris. Siemens, at its electronics factory in Erlangen: agents make virtual prototypes and synthetic data, recommend production plans from orders, supplies and line setups, and a digital twin checks those plans with physics simulation before anything changes on the floor. Dassault Systèmes, adapting a Volkswagen Golf door for the Tiguan: a simulation agent finds a vibration problem, sends it back to the design agent, and the engineer picks the final design. His summary afterwards: "Building agents is not that hard." Five parts. The model and the harness come in closed and open versions. Then the OpenShell runtime, "and then most importantly, the knowledge and tools, and those knowledge and tools belong to you. That's your expertise."

GoalA therapy for B-cell lymphoma

PlanIris turns the goal into an experimental plan

Dry labBioNeMo runs millions of virtual experiments

Science factoryRobots make and test the best candidates

ResultsBack to Iris, shaping the next designs

Siemens, ErlangenVirtual prototypes and synthetic data, production plans from orders and line setups, a digital twin checks them first

Dassault SystèmesA Golf door reshaped for the Tiguan. Simulation finds a vibration, design fixes it, the engineer picks

The videoThe most intelligent scientist still needs a laboratory.

Lila's loop as the video narrates it. The highlight walks it the way the results do: around, and around again.
## Where my own agents stand So I held my OpenClaw fleet against the five parts. The model is mixed: Claude for most agents, Qwen 3.6 locally for a few. The harness is OpenClaw 2026.9.4. Knowledge comes through eight MCP servers into my own apps. Tools are gated by a deny list per agent in openclaw.json: Rex, my nutrition coach, has no shell at all, and only Nova can reach my phone. The sandbox is the empty row. My agents run their tools on the host, which is OpenClaw's default and the thing I warned about in my [OpenClaw and Hermes comparison](/notes/hermes-agent-vs-openclaw.html). Those deny lists are real code, not a please. But the harness enforces them, on the same machine as the agent, and they name tools. Any agent that still has a shell can reach whatever my user account can. That's the inside-the-agent enforcement NVIDIA says isn't enough.
  1. ModelClaude for most agents, Qwen 3.6 on the mini for a fewMixed
  2. HarnessOpenClaw 2026.9.4Yes
  3. KnowledgeEight MCP servers into my own appsYes
  4. ToolsA deny list per agent. Rex has no shell; only Nova reaches the phoneInside
  5. SandboxNone: tools run on the host, OpenClaw's defaultNot yet

The gapMy rules live inside the harness. NVIDIA's point is to put them outside the agent.

My own setup on October 23, read from my openclaw.json. The last row is the one the keynote says to do first.
## Try it OpenShell runs on Linux, macOS on Apple Silicon, or Windows with WSL 2, with Docker, Podman or host virtualization. Two commands: ``` curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh openshell sandbox create --name demo ``` The installer sets up the CLI and a local gateway, and the default sandbox is a minimal Ubuntu with no agent in it. The [Run your first agent](https://docs.nvidia.com/openshell/latest/about/run-your-first-agent) guide puts OpenCode inside on a free OpenRouter model and shows how you approve new access as the agent asks for it. I haven't run it yet, so read this note as the reading, not the review. If you want more: - [The GTC Berlin keynote](https://www.youtube.com/watch?v=PvFjbPYEOZI&t=2502s), the agent part from minute 41, and [the OpenShell video](https://www.youtube.com/watch?v=PvFjbPYEOZI&t=2657s) at 44:17 - [OpenShell on GitHub](https://github.com/NVIDIA/OpenShell), Apache 2.0, with the [architecture](https://docs.nvidia.com/openshell/latest/about/architecture) and [policy](https://docs.nvidia.com/openshell/latest/how-it-works/policies/overview) docs - [NVIDIA Sentry](https://www.nvidia.com/en-us/networking/products/software/sentry/), the BlueField-4 layer - [How autonomous AI agents become secure by design](https://blogs.nvidia.com/blog/secure-autonomous-ai-agents-openshell/), NVIDIA's OpenShell launch post - [OpenClaw and Hermes Agent ship the same features with different defaults](/notes/hermes-agent-vs-openclaw.html), where the sandbox defaults are compared - [AI coworkers in Slack need their own identity](/notes/ai-coworkers-slack-agent-identity.html), on permissions decided at runtime If your company is getting ready for agents, start with the dull part. Write down what each agent may touch, and put that check somewhere the agent can't edit. If you try OpenShell before I do, tell me how many approvals it took before your agent was useful.