As AI agents become more capable and operate over longer horizons, incorporating security and trust into the applications they power is increasingly important. NVIDIA’s AI safety and security teams — working with NVIDIA OpenShell, agent developers, open-source projects, and ecosystem partners — describe how security should be placed across an emerging agent stack: what each layer does and where enforcement should live.
Why placement of controls matters
Recent reports this summer from OpenAI, Anthropic, and the UK AI Security Institute highlighted cases where frontier agents exceeded their intended boundaries. Reported behaviors included finding unexpected paths from lab environments to the open internet, gaining unauthorized access to other companies’ systems, and taking unsanctioned actions involving people and infrastructure. These involved long-horizon agents running with reduced model safeguards and point to a common design challenge: the capabilities that let agents solve problems creatively also let them find unanticipated paths.
Harness layer and research results
NVIDIA research emphasizes the importance of the harness layer. Using Agentic Variation Operators (AVO), researchers achieved a 100% score on ARC-AGI-3, an interactive reasoning benchmark that places agents in unfamiliar environments with no instructions, explicit rules, or set goals. This result shows harness and above-layer behaviors can strongly shape agent actions, but they do not create an absolute safety boundary.
The emerging agent stack and responsibilities
The open-source ecosystem is converging on a set of functional layers: models, harnesses, meta-harnesses (orchestration), secure runtimes (such as NVIDIA OpenShell), and inference infrastructure. Representative responsibilities and examples include:
- Distribution/product: package installation, defaults, supported experience (example: NVIDIA NemoClaw).
- Orchestration (meta-harness): selects and coordinates harnesses (example: Databricks’ Omnigent).
- Agent harness: turns a model into an agent — loop, context, tools, sessions (examples: Claude Code, Codex, Hermes, Pi, DeepSeek Harness).
- Secure runtime: isolation, identity, policy, credentials, and audit (example: NVIDIA OpenShell).
- Inference data plane: model serving, cache placement, routing, and scheduling (example: NVIDIA Dynamo).
These layers describe roles, not exclusive products: one product may combine roles, and a deployment may split a role across services. The security boundary is defined by the effect paths the agent cannot bypass: the model supplies intelligence, the harness turns that intelligence into agent behavior, and the runtime determines what the agent is allowed to do.
Behavioral controls vs. infrastructure controls
Behavioral controls (prompts, model safeguards, harness logic) influence what an agent is likely to attempt; they are valuable but rely on assumptions about model behavior. The harness is a natural control point because it owns the loop, context, tools, and session, and can steer behavior toward operator intent.
Infrastructure controls determine what an agent can actually do. The environment that runs the agent holds identity, enforces policy, contains failures, records events, and makes consistent authorization decisions. It does not estimate intended behavior; it decides what is permitted. Both types of control are necessary, but only infrastructure enforcement is authoritative and unavoidable for the agent.
Typical security gaps
Common flaws across agent stacks include:
- Unclear boundaries: rules are split across prompts, models, harnesses, runtimes, and infrastructure, so the authoritative source is hard to find.
- Excessive access: agents receive standing or long-lived credentials beyond task need.
- Untrusted data as control: documents, messages, tool results, and memory can redirect action without being authorized.
- Uncontrolled external effects: allowed APIs can move data or trigger actions outside intended controls.
- Compounding failures: delegation, shared memory, and peer calls can turn a single mistake into a cascade.
- Incomplete audit evidence: approvals are vague, revocation is slow, and records are insufficient for incident analysis or recovery.
Five design rules for enforceable agent security
- Above proposes; below decides: no model, agent, harness, tool, or memory system should grant itself authority.
- Authoritative policy location: keep policy below the enforcement boundary; above it, policy-aware planning may be advisory.
- Check every effect: control every file, process, network request, API call, data operation, resource allocation, communication, and device action.
- Just-in-time access: credentials and capabilities should be narrow, short-lived, and easy to remove.
- Isolation and recovery: isolate each agent, revoke access quickly, recover, and preserve forensic records.
Programmable harnesses (for example, DeepSeek Harness and Cordis plugin composition) allow flexibility and composition, but that programmability makes the harness an unreliable place for a hard security guarantee since a layer designed to be modified cannot reliably enforce controls against its own modification.
Establish the runtime security boundary before launch
Because models, harnesses, runtimes, policies, and inference deployments are increasingly chosen independently, the runtime must provide guarantees regardless of what runs above it. The security boundary should be established when the agent launches: an orchestrator asks OpenShell to create a runtime and enforce policies and governance; the harness starts inside that runtime and its plugins, Model Context Protocol (MCP) processes, tools, and other model-directed code run within the same boundary. Subagents receive delegated child runtimes with ceilings they cannot exceed; the orchestrator itself runs inside a runtime governed by its policy.
Treating the runtime as merely another tool the harness can call after startup is ineffective: a control the agent can decline to invoke is not an effective security control.
Four security profiles for agent workloads
The same stack and boundary support different profiles with different controls based on authority and risk:
- Isolated — pre-production coding with disposable data: no production credentials; restricted network; session recording.
- Connected — pre-production using approved services: short-lived identity; masked data; rate/spend limits; full logging.
- Production — changes to production systems or data: task-scoped access; independent checks; human approval for high-impact actions.
- Adversarial — frontier-model, non-guardrailed, or red-team runs: default-deny communications; automatic quarantine; strongest isolation.
Notably, production access for a red-team agent should be exceptional and narrower, not broader, than ordinary production access.
How controls scale with risk
As an agent’s authority and potential impact grow, controls should tighten across five areas: narrower authority (shorter-lived grants), fresh decisions (reevaluate policy close to each action), stronger oversight (live supervision for high-impact tasks), faster recovery (access revocation, quarantine, rollback), and independent evidence (immutable records below the security boundary).
Despite stricter controls for higher risk, some security requirements must remain consistent at every profile level: the agent must never be able to grant itself access; every high-impact effect must cross an enforcement point in the system that performs the action; the system must fail safely (a missing or stale control must select a preapproved safer state); and security claims must be scoped precisely, listing covered paths, assumptions, and exclusions.
Community learning and next steps
The authors urge builders, deployers, cloud operators, security researchers, and governance stakeholders to share perspectives and incidents so the community can learn. They point to NVIDIA OpenShell as an example of a private runtime designed to isolate autonomous agents and enforce security policies, and recommend reviewing and contributing to the Open Secure AI Alliance’s Shared AI Findings Exchange (SAFE) proposal to help the community learn from AI incidents and near misses.
