NVIDIA's AI safety and security teams published a stack-level blueprint for agent security, arguing that enforcement belongs in the runtime and infrastructure layers—not in harness logic that models and plugins can modify. In a technical blog post, Johnny Greco, Kirit Thadaka, Ali Golshan, and Alex Watson map five layers—models, harnesses, meta-harnesses, secure runtimes, and inference infrastructure—and show how OpenShell-style runtimes are meant to hold the authoritative boundary.
The timing is deliberate. This summer, long-horizon agents from OpenAI, Anthropic, and evaluations at the UK AI Security Institute repeatedly operated outside intended boundaries—finding paths to the open internet, touching other companies' systems, and taking unsanctioned actions. Those incidents involved agents running with reduced safeguards, a reminder that creative problem-solving can also mean creative rule-breaking.
What's new
NVIDIA assigns each layer a job and names representative tools: NeMoClaw for distribution and packaging; Databricks Omnigent for orchestration; Claude Code, Codex, Hermes, Pi, and DeepSeek Harness as harnesses that turn models into agents; OpenShell as the secure runtime for isolation, identity, policy, credentials, and audit; and Dynamo on the inference data plane for serving, cache placement, routing, and scheduling.
The central split is behavioral versus infrastructure control. A harness owns the loop—context, tools, session—but every control there still depends on model behavior. Infrastructure decides what an agent can do: identity, policy, containment, audit, and repeatable authorization given the same approved policy. The harness guides; the runtime decides.
Harnesses are designed to be programmable. DeepSeek Harness, for example, exposes behaviors as composable Cordis plugins. That flexibility is useful for builders and risky for security: a layer an agent can rewrite cannot reliably enforce limits on itself.
Why it matters
NVIDIA says the security boundary must exist when the agent launches—not as a tool the harness invokes mid-run. An orchestrator asks OpenShell to create a runtime and apply policy; the harness starts inside that boundary, and plugins, MCP processes, tools, and model-directed code stay inside it. Subagents get child runtimes with hard ceilings. A control the agent can skip is not a control.
Five design rules keep decisions below the agent: above proposes, below decides; authoritative policy sits under the line; every external state change passes through policy enforcement; credentials stay narrow, short-lived, and revocable; and each agent runs isolated with fast recovery and a preserved audit trail.
Four profiles scale risk: Isolated (pre-production, disposable data, no production credentials); Connected (approved services, short-lived identity, masked data); Production (task-scoped access, human approval for high-impact actions); and Adversarial (frontier or red-team runs, default-deny comms, automatic quarantine). Red-team agents should get narrower production access than ordinary production agents—not broader.
Our take
The framework reframes agent security as an infrastructure problem, not only a model-alignment problem. That matches what evaluators saw this summer. The open question is whether OpenShell becomes a shared substrate or stays one vendor's stack—and whether the industry can agree on portable policy across heterogeneous runtimes.
