In an AI Agent Stack, the Runtime Must Own Security
Prompts and harnesses can guide an agent, but authoritative identity, policy, isolation, effect checks, and audit belong below the modifiable agent boundary.
Source: NVIDIA Technical Blog: Where Security Fits in an AI Agent Stack
TL;DR
NVIDIA separates behavioral controls, which influence what an agent tries to do, from infrastructure controls, which determine what it can do. Prompts and harnesses remain useful, but a modifiable layer cannot be the final authority over its own permissions. The runtime should establish identity, policy, isolation, effect checks, just-in-time access, recovery, and audit below the agent boundary. Netics’ rule is direct: above the boundary proposes; below the boundary decides. The article defines where the enforcement boundary belongs, five design rules for enforceable agents, and what the model means for European deployments.
Guidance is not authority
AI agents combine a model, a harness, tools, memory, and often other agents. The model proposes actions. The harness runs the loop, manages context, and selects tools. Those layers are valuable because they shape behavior, but shaping behavior is not the same as enforcing authority.
NVIDIA’s argument is a familiar systems-security principle applied to a new stack: least privilege, defense in depth, isolation, explicit authorization, and auditability still matter. The difficult question is where those controls should live when the software above them can be modified, replaced, or influenced by untrusted data.
A prompt can say “never access production.” A harness can reject a tool call. But if the same agent can change the prompt, load a different harness plugin, or find another path to the effect, the control is guidance. The hard boundary needs to sit underneath.
Where the enforcement boundary belongs
NVIDIA describes the environment as the place that holds identity, enforces policy, contains failures, records what happened, and reaches a repeatable authorization decision from approved policy and verified state.
That boundary should exist when the agent launches. Treating the runtime as another tool that the harness may call later is weaker: an agent that can decline to invoke the control can route around it. The orchestrator should create the runtime, apply its policy, and start the selected harness inside the boundary. Plugins, MCP processes, tools, and model-directed code then operate inside the same controlled environment.
Subagents can receive delegated child runtimes with ceilings they cannot exceed. This is a better shape than giving a parent agent a broad credential and trusting it to distribute authority correctly.
Five design rules for enforceable agents
NVIDIA’s model can be translated into five practical rules:
- Above proposes; below decides. No model, agent, harness, tool, or memory system grants itself authority.
- Keep policy below the line. Policy-aware planning is useful above the boundary, but enforcement remains below it.
- Check every effect. Files, processes, network requests, APIs, data operations, compute allocation, communications, and device actions all need an enforcement path.
- Use just-in-time access. Capabilities should be narrow, short-lived, and easy to revoke.
- Design isolation and recovery together. Containment without recovery leaves an incident expensive; recovery without evidence leaves it unexplained.
These rules also expose a common mistake: treating a tool permission as the security model. A tool is only one effect path. The boundary must cover what the tool can cause, not only the function name presented to the model.
Risk profiles should change controls
Not every workload needs the same operational profile. NVIDIA describes four profiles: isolated pre-production work with disposable data; connected pre-production with approved services; production work with task-scoped access and independent checks; and adversarial runs with default-deny communication and strong quarantine.
The useful part is not the labels. It is the principle that controls should rise with authority and impact. A red-team agent should not receive broader production access merely because it is testing defenses. It should receive narrower access, stronger isolation, faster quarantine, and better evidence.
As risk rises, Netics recommends five changes: narrower grants, fresher authorization decisions, stronger human oversight, faster revocation and rollback, and independent records below the agent boundary.
What this means for European deployments
European teams should treat the runtime boundary as an architecture decision, not a vendor checkbox. The questions are concrete:
- Which identity does every effect use?
- Where is the authoritative policy stored?
- Can a prompt, document, tool result, or memory entry grant additional authority?
- Which layer can revoke access without asking the agent’s permission?
- What evidence remains after a failed or partially completed action?
This is especially important for systems that combine cloud services, private infrastructure, and external tools. The stack can be assembled from many vendors, but the enforcement contract must remain clear across the seams.
The same principle appears in Netics’ production-readiness work: a working model proves capability, not operational control. Your AI prototype is not production-ready because the model works. Security belongs in the part of the system that the model cannot rewrite.
FAQ
Can prompts and system instructions secure an AI agent?
They can influence behavior, but they are not sufficient as the final authority. Runtime and infrastructure controls must restrict the effects the agent can actually cause.
Why should the runtime be created before the harness starts?
If the runtime is merely a tool available after startup, the agent may decline to invoke it or route around it. Establishing the boundary at launch makes the environment authoritative from the beginning.
What are the minimum runtime properties?
At minimum, define identity, least privilege, policy enforcement, isolation, effect checks, revocation or recovery, and durable audit evidence.
Netics’ conclusion
For teams reviewing AI agent security architecture, the control boundary matters more than the platform label.
The agent stack is not secured by making the model sound more cautious. It is secured by moving authority below the layers that can be modified, replaced, or influenced by untrusted input. Let the model and harness propose. Let the runtime decide. Let the infrastructure record and recover. That is the boundary that survives a clever prompt.
Source: NVIDIA Technical Blog, Where Security Fits in an AI Agent Stack — https://developer.nvidia.com/blog/where-security-fits-in-an-ai-agent-stack/