Where Security Fits in an AI Agent Stack

As AI agents become more capable and operate over longer horizons, building security and trust into the applications they power becomes increasingly important. Drawing on work with NVIDIA OpenShell, agent developers, open-source projects, and partners across the ecosystem, AI safety and security teams at NVIDIA offer their perspective on the emerging agent stack—including the role of each layer and where security should live. Recent reports underscore why the placement of security controls matters. Within a few weeks this summer, OpenAI, Anthropic, and the UK AI Security Institute each reported frontier agents operating beyond their intended boundaries. The reported behaviors included exploiting an unexpected path out of lab environments to the open internet, gaining unauthorized access to other companies’ systems, and taking unsanctioned actions involving people and infrastructure. These cases involved long-horizon agents running with reduced model safeguards. But they point to the same design challenge: the capabilities that enable agents to solve problems creatively and pursue complex goals can also help them find paths that their original instructions did not anticipate. Recent NVIDIA research underscores the importance of the harness layer in the agent stack. Using Agentic Variation Operators (AVO), researchers achieved a 100% score on ARC-AGI-3, an interactive reasoning benchmark that places agents in unfamiliar environments without instructions, explicit rules, or stated goals. Learn more about the AVO research. This post maps the main layers of the emerging agent stack—models, harnesses, meta-harnesses, secure runtimes such as OpenShell, and inference infrastructure—and explains how each layer can help reduce risk. You’ll also learn which security properties become critical as these layers grow more capable and composable, including where authority should live, how access should be scoped, and how the runtime can contain and record an agent’s actions. Behavioral and infrastructure controls for AI agents Securing agents doesn’t require reinventing security. Decades of systems security provide durable principles, including least privilege, defense in depth, isolation, explicit authorization, and auditability. The challenge is determining where to apply them in an agent stack. Prompts, model safeguards, and harness logic all shape what an agent is likely to do, but they don’t create a hard boundary around what it can do. This distinction leads to two different kinds of control: behavioral controls that guide the agent and infrastructure controls that limit its authority. Behavioral controls influence agent actions The model and agent propose actions, and the harness directs them. Together, the model, agent, and harness interpret goals, work through ambiguity, and propose actions. The harness is the natural control point: it owns the loop, the context, the tools, and the session, and it can steer behavior toward what the operator intends. That steering is valuable, but every control implemented at this level still depends on how the model will behave. Infrastructure controls determine what an agent can do Final authority belongs to the environment in which the agent runs in. That environment holds identity, enforces policy, contains failures, records what happened, and reaches the same authorization decision every time, given the same approved policy and verified state. It doesn’t estimate what an agent will do. It determines what an agent can do. The harness guides what an agent tries. The infrastructure controls what an agent can do. Both are necessary; only one is authoritative. Infrastructure enforcement is not infallible. It means approved policy and verified configuration produce repeatable outcomes, and the agent cannot choose whether to comply. Policy can still be wrong, and external outcomes can remain uncertain. Mapping security controls This division maps onto the layers the open-source ecosystem is already converging on: LayerWhat it doesExamples Distribution/productPackage installation, defaults, and the supported experienceNVIDIA NemoClaw Orchestration (meta-harness)Selects and coordinates different harnessesDatabricks’ Omnigent Agent harnessTurns a model into an agent: loop, context, tools, sessionsClaude Code, Codex, Hermes, Pi, DeepSeek Harness Secure runtimeIsolation, identity, policy, credentials, and auditNVIDIA OpenShell Inference data planeModel serving, cache placement, routing, and schedulingNVIDIA Dynamo Table 1. Functional layers of the AI agent stack, their responsibilities, and representative technologies These layers describe functional roles. One product may combine several roles, and a deployment may split one role across multiple services. Here, each layer names a responsibility. The security boundary is defined by the effect paths that the agent cannot bypass. The model supplies intelligence; the harness turns that intelligence into an agent; the runtime determines what that agent is allowed to do. The harness layer is a spectrum rather than a fixed category. Codex and Claude Code are opinionated harnesses, while Pi and DeepSeek Harness (DSH) expose more of the harness as a programmable substrate. Through Cordis, DSH enables core behaviors that can be composed and replaced as plugins. This programmability makes the harness a poor place for a security guarantee: a layer designed to be modified cannot reliably enforce controls against its own modification. The alternative—relying on harness logic for safety—encodes assumptions about model behavior, and those assumptions go stale as models improve. A narrowly scoped credential limits potential harm, but keeping the raw credential out of the agent’s reach creates a stronger boundary enforced by the environment. Establish the AI agent runtime boundary before launch Models, harnesses, runtimes, policies, and inference deployments are increasingly selected independently. This approach only works if the runtime’s guarantees hold regardless of which components operate above it. That means a security boundary must be established when the agent launches. An orchestrator asks OpenShell to create a runtime and enforce policies and governance. The selected harness starts inside that runtime, and its plugins, Model Context Protocol (MCP) processes, tools, and other model-directed code run inside the same boundary. Subagents receive delegated child runtimes with ceilings they can’t exceed, while the orchestrator operates inside a runtime governed by its own policy. This approach is different from treating the runtime as another tool that a harness can invoke once it’s already running. A control that the agent can decline to invoke is not an effective security control. Common security gaps in agent stacks Many agent stacks share the same flaw: authorization decisions can be influenced by the agent or by untrusted data it reads. Unclear boundaries. Rules are split across prompts, models, agents, harnesses, runtimes, and infrastructure, so the authoritative version is hard to find. Excessive access. The agent receives standing, often long-lived credentials or permissions beyond what the current task needs. Untrusted data as control. Documents, messages, tool results, and memory can redirect action without being authorized as instructions. Uncontrolled external effects. An allowed API can move data, create compute, or trigger effects outside the intended controls. Compounding failures. Agents delegate, share memory, and call peers, so one mistake can become a fast cascade. Incomplete audit evidence. Approvals are vague, access is slow to revoke, and the record is not sufficient to explain an incident or support recovery. Design rules for enforceable agent security Five design rules help keep security decisions outside the agent’s control. Above proposes; below decides. No model, agent, harness, tool, or memory system grants itself authority. Authoritative policy location. Keep policy below the line. Policy-aware planning above the line is useful, but 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 the record. A layered security model for agents Like the OSI model, this agent stack assigns each layer one job and a clear interface. Higher layers can change without redefining the control layer below them. Figure 1. A layered AI agent stack separates behavioral components from infrastructure-enforced security controls