Wink Pings

NVIDIA's Ali Golshan Says Sandboxing Is Obsolete; the Comment Section Disagrees First

OpenShell pitches zero permissions, on-demand authorization, and secret isolation as selling points. The replies are asking about something else: when tool calls, prompt injection, and audit records collide, is sandboxing really obsolete?

NVIDIA's Ali Golshan, in an interview with Hesamation at GTC Berlin, made a blunt statement: applying sandboxing to agents is obsolete technology. He leads NVIDIA's open-source agent runtime OpenShell. According to the original article, OpenShell is already built into Anthropic's Claude Managed Agents.

In the interview, Ali laid out three key points for OpenShell:

  • agents start with zero permissions
  • more access is granted only when necessary
  • secrets stay outside a controlled boundary; agents cannot access them directly

The interview chapters are also clearly marked: 1:15 Are AI security risks exaggerated; 6:06 Do we need new AI regulation; 7:47 What is OpenShell, and how is it different from a sandbox; 10:20 Can OpenShell stop Hugging Face-type incidents; 13:44 alignment and security; 16:04 advice for entering AI security.

The point of contention is right at 7:47. Ali says sandboxing is obsolete, but OpenShell's design sounds like a more granular sandbox: no permissions by default, then privilege escalation as the task requires, while keeping secrets outside. X user AI Quanting replied bluntly: zero permissions plus on-demand privilege escalation is exactly what a sandbox is supposed to do. Calling that idea obsolete may help the product narrative, but it does little to explain the technical boundary.

The replies contain several follow-up questions that are more concrete than the word "obsolete."

X user Elvis Sautet mentioned that Factory had just released Droid 1.0; the key approach is to have the agent write a JS program that runs in a sandbox and then trigger hundreds of tool calls. The denser the tool calls, the more you need that box. X user Benjamin Wolfe said the real boundary is using scoped, short-lived secrets for each task. If you only have a sandbox without this kind of secret management, the sense of security is illusory. X user Jatin Garg added a sharp point: the broker also has to reject harmful requests coming from an authorized agent. X user Samuel Jefroykin asked: who approves additional permissions mid-task—a human or another agent—and is there a usage record afterward? X user Steve ReinharzAI focused on the difficulty of the audit trail: if the agent does not hold the original secrets, it is indeed harder to leak them; but humans need to be able to review which authorizations were used and why.

The replies also surface a tougher case. X user llevy said he found an RCE caused by indirect prompt injection in a widely used open-source agent, including a sandbox escape. More than two months passed without a patch, and communication from the maintainers was poor. He asked whether to disclose it publicly. Some replies said two months of silence is the answer; others suggested giving a written deadline and publishing after it passes.

This case brings the discussion back down to earth. The word "sandbox" may be old, but permissions, secrets, fail-closed behavior, and audit records are not old at all. Ali's description of OpenShell is worth a look; zero permissions, on-demand authorization, and secret isolation are all real problems. But calling sandboxing obsolete risks obscuring the questions that really need to be tested: can the system deny by default when a tool fails, can secrets be kept out of the agent's hands, and can privilege escalations be logged and questioned? If OpenShell can make these things the default, then it can talk about being "obsolete" with some weight. Otherwise, it is just a different way of saying the same thing.

发布时间: 2026-11-01 04:26