# Where Security Fits in an AI Agent Stack > Source: > Published: 2026-08-21 13:00:00+00:00 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](https://developer.nvidia.com/blog/nvidia-avo-reaches-100-on-arc-agi-3-demonstrating-a-frontier-level-general-purpose-architecture-for-long-horizon-autonomous-agents/). This post maps the main layers of the emerging agent stack—models, [harnesses](https://developer.nvidia.com/blog/six-agent-harness-capabilities-for-higher-model-performance/), 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: Layer | What it does | Examples | |---|---|---| Distribution/product | Package installation, defaults, and the supported experience | NVIDIA NemoClaw | Orchestration (meta-harness) | Selects and coordinates different harnesses | Databricks’ Omnigent | Agent harness | Turns a model into an agent: loop, context, tools, sessions | Claude Code, Codex, Hermes, Pi, DeepSeek Harness | Secure runtime | Isolation, identity, policy, credentials, and audit | NVIDIA OpenShell | Inference data plane | Model serving, cache placement, routing, and scheduling | NVIDIA 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. **How the security boundary works** The boundary is effective only if every request is evaluated consistently. Three requirements make this possible. - Treat every component above the boundary as untrusted. It may be mistaken, compromised, or adversarial, and its requests carry no authority on their own. - Make the controls below the boundary authoritative. These layers bind each request to an identity, apply policy, and enforce the decision. - Use risk signals only to reduce authority. Signals such as anomaly scores may trigger tighter controls, but they must never grant additional access. Every action that changes the external state must pass through the policy and enforcement layers below the boundary. Any path that allows Layers 5-7 to bypass those controls is an architectural defect. **Four security profiles for agent workloads** All four profiles use the same stack, boundary, and interfaces. Each applies different controls based on the authority granted, the potential impact, and the likelihood of adversarial behavior. Level | Typical work | Required configuration | |---|---|---| | 1. Isolated | Coding in pre-production with disposable data. | No production credentials; restricted network; session recording. | | 2. Connected | Pre-production using approved services. | Short-lived identity; masked data; rate/spend limits; full logging. | | 3. Production | Changes to production systems or data. | Task-scoped access; independent checks; human approval for high-impact. | | 4. Adversarial | Frontier-model, non-guardrailed, or red-team runs. | Default-deny communications; automatic quarantine; strongest isolation. | *Table 2. Four security profiles for AI agent workloads and their required controls* **Important.** Production access for a red-team agent should be exceptional and narrower, not broader, than access granted to an ordinary production agent. **How agent security controls change as risk increases** As an agent gains more authority and the potential impact of its actions grows, strengthen controls in five areas. **Narrower authority.** Grants should become shorter-lived as risk rises.**Fresh decisions.** Reevaluate policy closer to each action.**Stronger oversight.** Add live supervision for high-impact work.**Faster recovery.** Plan for access revocation, quarantine, and rollback.**Independent evidence.** Keep immutable records below the security boundary. **Security requirements at every risk level** Although controls become stricter as risk increases, the following security requirements should remain consistent across every profile. **The agent never grants itself access.** Controls are enforced outside the agent process and beyond the agent’s control. This holds at every level.**Every in-scope, high-impact effect crosses an enforcement point.** The check occurs in the system that performs the action.**The system fails safely:** a missing or stale control selects a preapproved safer state. For physical and availability-critical systems, that state may require controlled operation rather than an abrupt stop.**Security claims remain scoped**. State the exact paths covered, assumptions made, and exclusions left outside the stack. **Help shape AI with in-market learning** Whether you build AI models, deploy AI systems, operate cloud infrastructure, conduct security research, or develop governance and standards, your perspective can help shape how the AI community learns from incidents. Explore [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) to learn how a safe, private runtime isolates autonomous agents and enforces security policies. Review and contribute to the Open Secure AI Alliance’s [Shared AI Findings Exchange (SAFE) proposal](https://github.com/OpenSecureAIAlliance/RFCs/blob/main/rfc-safe-proposal.md), which outlines a community framework for learning from AI incidents and near misses.