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 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
- Context
- Reason
- Plan
- 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."
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 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 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
- 1AgentOpens a connection or a DNS lookup. The sandbox has no direct route out.
- 2SandboxCatches it, names the program behind it, hands it on. Decides nothing.
- 3SupervisorChecks the request against the policy, outside the sandbox.
- 4SupervisorAdds the credential for an approved endpoint only, then opens the real connection.
- 5SupervisorA host the policy doesn't approve: denied.
The videoA compromised agent can't leak a key it never had.
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 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.
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.
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
- Open weights
- The training data
- The scripts to reproduce it
- Your data: post-train it
And keep improving it
JensenThese models "are not necessarily the frontier of frontiers, especially for the language model."
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.
1The notice
A document, so unstructured. Parse reads it.
2The orders
Rows in SQL. Kumo predicts which run short, and by how much.
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
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.
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.
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.
- ModelClaude for most agents, Qwen 3.6 on the mini for a fewMixed
- HarnessOpenClaw 2026.9.4Yes
- KnowledgeEight MCP servers into my own appsYes
- ToolsA deny list per agent. Rex has no shell; only Nova reaches the phoneInside
- 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.
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 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, the agent part from minute 41, and the OpenShell video at 44:17
- OpenShell on GitHub, Apache 2.0, with the architecture and policy docs
- NVIDIA Sentry, the BlueField-4 layer
- How autonomous AI agents become secure by design, NVIDIA's OpenShell launch post
- OpenClaw and Hermes Agent ship the same features with different defaults, where the sandbox defaults are compared
- AI coworkers in Slack need their own identity, 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.
Plain text: hope-isnt-security-enterprise-agents.md · Atom feed · All notes