NVIDIA Sentry Explained: How Runtime Security for AI Agents Works in Practice

AI agents can cross security boundaries at the very moment they complete a task. In introducing its Sentry solution, the NVIDIA developer blog points directly at this contradiction: several recent incidents show that agents can bypass existing security controls while executing tasks. This reminds us that the discussion around agent security is shifting from "whether the model is aligned" to "whether the runtime is controlled."

Why runtime security has become the critical gap for AI agents

Traditional security models assume the executing entity is a deterministic program: what the code does and which interfaces it calls can essentially be enumerated. Agents break this assumption. They dynamically decide their next action based on context—they may call tools, read files, or make network requests, and the behavioral path is only generated at runtime.

The original article's phrase "completing the task yet still crossing the security boundary" describes exactly this risk: from the perspective of the task goal, the agent did not fail; from a security perspective, it did something it should not have done. The conflict between the two does not surface at the prompt level—it only surfaces at runtime.

This is also why NVIDIA positions Sentry at runtime rather than at the model layer. Model-layer guardrails address "should it say this," while runtime security addresses "what is it allowed to do." For agents deployed in production environments, the latter is often the real attack surface.

A DPU (data processing unit) is a programmable specialized processor, typically deployed inside a server as a standalone PCIe card, that handles networking, storage, and security-related infrastructure tasks. Representative products include the NVIDIA BlueField series. It sits between the host operating system and the external network and can enforce policies such as packet filtering, encryption, and traffic shaping without consuming host CPU. For agent security, the key significance of this position is that the DPU runs outside the agent process, so the agent cannot directly influence its policy enforcement through prompt injection or code rewriting—making it usable as an independent control plane.

NVIDIA Sentry's positioning: pushing security controls down to the infrastructure

Based on the information NVIDIA has published, Sentry's core idea is to combine security capabilities with data processing units (DPUs) like BlueField to enforce control over agent behavior at the infrastructure layer. The icons shown side by side in the official graphic—AI protection, traffic control, monitoring, data security, and firewall—essentially outline its scope of capabilities:

• Traffic control: constrains the network connections an agent can initiate, limiting the scope of its external communications;
• Monitoring: records an agent's runtime behavior, providing data for auditing and anomaly detection;
• Data security: applies policies to the data an agent accesses to prevent sensitive information from being exfiltrated;
• Firewall: blocks access that violates policy at the network boundary.

Putting these capabilities on a DPU rather than cramming them into the agent's own process means security policies do not depend on the agent's cooperation. Even if the agent is manipulated by a prompt injection attack or exhibits unexpected behavior, the infrastructure layer can still enforce policies independently. This is the most fundamental difference between "runtime security" and "in-model guardrails."

It should be noted that the above scope of capabilities comes from the diagrams and descriptions in NVIDIA's official materials; the original article does not go into engineering-level detail on specific implementation or policy configuration.

Division of labor with model-layer guardrails

Understanding Sentry as "yet another AI security product" easily misses the point. A more accurate view is that it fills the gap that model-layer guardrails cannot cover.

Model-layer guardrails operate at both the input and output ends and are good at blocking harmful content and unauthorized instructions. But agent risk often occurs in the middle of the process—calling some internal API, reading some configuration file, or sending a request to an external address. These actions may not manifest as harmful text, yet they may constitute substantive boundary violations.

The value of runtime security lies in bringing these actions within the scope of policy. The "crossing the security boundary" emphasized in the original article refers to this kind of action-level overreach, not content-level violations. The two require different technical approaches and also need to be deployed in different locations.

Prompt injection attacks are a typical runtime threat facing agents: attackers embed malicious instructions in the data an agent reads (web pages, documents, tool return values), causing the agent to execute them as legitimate instructions. Unlike traditional software vulnerabilities, prompt injection exploits the model's blurring of the boundary between instructions and data, making it difficult to fully block with model-layer filters. This is also why runtime security needs to use "actions" rather than "text" as the unit of control—even if the input content passes detection, the final calls and access actions can still be independently restricted at the infrastructure layer.

Practical implications for agent developers

Even without adopting NVIDIA's specific product, Sentry's design approach still offers useful reference for teams building agent systems.

First, security policies must be decoupled from the agent. If protection logic is written into the agent's prompts or code, it becomes ineffective once rewritten by an injection attack. Only by placing policies in a layer the agent cannot directly modify can real constraints be established.

Second, use actions rather than text as the unit of auditing. Recording which tools an agent called, which resources it accessed, and which addresses it connected to reflects real risk better than recording what it said.

Third, do not trust the agent's network behavior by default. When an agent needs network access, its accessible target scope should be explicitly defined rather than giving it an open egress. The traffic control capability mentioned in the original article is essentially the implementation of this principle.

The principle of least privilege needs to be redefined in the agent context: in traditional systems, permissions grant a fixed set of interfaces, whereas an agent's combination of tool calls is only determined at runtime. Therefore, two practices are commonly adopted: dynamically narrowing the available tools and target address ranges by session or task, and performing secondary validation at the infrastructure layer on the connections and access requests actually made. Only by combining the two can "permissions" remain controllable even when agents make dynamic decisions.

Open questions to watch

NVIDIA's currently public information remains at the level of solution positioning and capability scope. Engineering details such as how policies are written, how they integrate with existing identity systems, and their impact on agent performance are not yet clear. For teams considering deploying agents in production, these are precisely the most needed pieces of information for evaluation.

What is certain is that as agents take on more real tasks, the focus of security will continue to shift from "what the model says" to "what the agent can do." NVIDIA Sentry is an infrastructure-layer attempt in this direction, and it puts the problem in the right place.

One-line Summary

NVIDIA Sentry pushes agent security controls down to infrastructure layers such as DPUs to contain runtime action overreach.

Paragraph Summary

Starting from the Sentry solution introduced on the NVIDIA developer blog, the article points out that AI agents may cross security boundaries while completing tasks, with risk surfacing at runtime rather than at the prompt level. Sentry's core idea is to combine security capabilities with DPUs like BlueField to enforce traffic control, monitoring, data security, and firewall policies at the infrastructure layer, so that control does not depend on the agent's own cooperation. The article emphasizes that runtime security and model-layer guardrails have different roles: the former governs action overreach, while the latter governs content violations. For developers, the implications are to decouple policies from agents, use actions as the unit of auditing, and distrust network behavior by default. Official information currently remains at the positioning level, with policy configuration and integration details not yet disclosed.