Securing AI agents requires securing the systems around them

Enterprise AI is changing from software that primarily generates information to software that can take action. AI agents can call APIs, invoke tools, access files and credentials, communicate over networks and interact directly with business systems. That capability is useful precisely because it gives agents more reach and more authority. It also changes what enterprises need to secure.

Model safeguards remain important, but they cannot carry the entire security burden. Once an agent can act on enterprise systems, security must extend beyond what the model is instructed to do. Organizations also need to control the agent's identity, permissions, access to tools and data, runtime environment, network connections and the infrastructure on which it operates. Securing an AI agent therefore means securing the system in which the agent acts.

As agents receive more authority, the controls surrounding that authority become increasingly important. Those controls should not depend solely on the agent behaving as intended. In fact, they should account for the possibility that an agent will behave unexpectedly. Enterprises need independent mechanisms that can limit what an agent can access, where it can communicate and what actions it can take, even when the agent, its instructions or one of its dependencies does not behave as expected.

Defense in depth for agentic AI

Like other areas of IT security, no single control addresses this type of risk. Layered security and mitigation approaches are needed, just as they are for deterministic systems.

These layers already encompass:

• Model and application guardrails to help detect or constrain undesirable interactions and behavior.
• Identity and authorization capabilities to determine what resources an agent can access.
• Tool controls to limit which capabilities are available to an agent.
• Sandboxing to restrict files, processes and execution environments.
• Workload isolation to limit the effect of a compromised or misbehaving process.
• Network policy to constrain where and how workloads communicate.

Observability and AgentOps add other important safeguards by helping organizations trace agent activity, tool interactions and the outcomes that follow. Together, these capabilities can help establish boundaries around agent behavior and provide information organizations can use to understand what occurred when something goes wrong.

None of these controls replaces the others. The practical approach is defense in depth, with multiple enforcement points that remain independent of the agent wherever possible. This isn't a new security concept. It's an established practice used to protect many of the world's most sensitive computing environments.

The broader platform therefore becomes part of the agent security architecture. Controls need to operate at different layers: around models and agents, within the workload and runtime, across the network, and at the operating system and infrastructure layers.

Red Hat AI brings these layers together across the hybrid cloud, with Red Hat OpenShift AI supporting the development and operation of AI workloads, Red Hat OpenShift providing workload isolation, policy and networking, and Red Hat Enterprise Linux providing the operating system foundation. Red Hat AI Inference provides a consistent model-serving layer across this environment. Combined with NVIDIA accelerated computing, networking, and AI software, these Red Hat technologies come together in Red Hat AI Factory with NVIDIA.

No individual platform control "secures the agent." The advantage of a layered architecture is that enterprises can establish and enforce controls around the agent rather than making the model itself the primary security boundary.

Connecting policy to technical controls

Another part of this engineering problem is determining which controls to apply in the first place.

Enterprise AI policies are typically expressed as requirements around acceptable behavior, risk and governance. Those requirements ultimately need to become technical controls that can be tested and enforced.

That is one of the problems the asago open source community is working to address. Founded by Red Hat with NVIDIA and other industry and research collaborators, asago is exploring how organizations can translate AI governance policies into identified risks, test scenarios and appropriate technical controls, with an auditable path from policy to implementation.

This creates an important connection between governance and enforcement. As the asago architecture evolves, policy-derived controls could be applied through different enforcement mechanisms across the AI stack. Agent runtimes such as OpenShell are one potential enforcement point, while infrastructure outside the agent workload could provide another.

The broader engineering question is therefore not only what an agent should be allowed to do, but how those requirements become controls that can be independently tested and enforced.

Moving some controls outside the agent workload

The same principle can extend further into infrastructure with the NVIDIA Open Agent Safety Platform.

As part of that effort, OpenShell introduces sandboxing and policy mechanisms intended to constrain autonomous agents. NVIDIA BlueField data processing units (DPUs) provide a hardware-isolated infrastructure environment for networking, security and other infrastructure services, separate from applications running on host compute.

That separation raises an important design question for agentic systems: which supervisory and enforcement functions can operate outside the environment controlled by the agent itself?

It also raises a related question: how can policies defined at the organizational level ultimately be translated into controls that these enforcement points can apply?

NVIDIA is introducing an architectural approach in which the agent workload remains on host compute while selected supervisory, networking, security or policy functions move across an independent hardware boundary on BlueField. This creates another place to constrain the agent without relying on the agent to recognize or honor those constraints.

For Red Hat, the significance of this approach is how that additional hardware boundary can complement controls already operating at the agent, workload, platform and operating system layers. Red Hat and NVIDIA contribute different, complementary capabilities: NVIDIA provides technologies such as OpenShell and NVIDIA DOCA software, and NVIDIA BlueField DPUs that can create additional enforcement points, while Red Hat provides the enterprise AI and hybrid cloud platform in which these controls can be integrated with identity, policy, workload isolation, networking and operations.

This should not be viewed as a single answer to AI safety or agent security. Hardware isolation addresses particular security and control problems. It works alongside model safeguards, identity, authorization, tool controls, sandboxing, workload isolation, network policy and observability. Its value comes from adding another independent monitoring and enforcement layer to the overall system.

The principle is familiar from other areas of enterprise security: when a workload has significant authority, some of the mechanisms controlling that workload should remain beyond its reach.

Trust also starts below the agent

Runtime controls address what an agent can do, but the security of an agentic system also depends on the integrity of the software underneath it.

Agents, frameworks, runtimes and AI services depend on large software stacks, including open source packages. Vulnerabilities in those dependencies become part of the security posture of the agentic application.

Through Lightwell, our joint initiative with IBM focused on securing the open source software supply chain, we're working to strengthen this layer through validated remediation, signed artifacts and software provenance. This differs from controlling an agent at runtime, but it reflects the same systems approach: security depends on controls across multiple layers rather than at a single point.

This principle also extends to ecosystem collaboration. As an inaugural participant in NVIDIA's Open Secure AI Alliance, Red Hat is working with other industry leaders on open tools and techniques for protecting the AI stack, including models and agent infrastructure. As AI systems become more interconnected, security controls will increasingly need to work across software, infrastructure and organizational boundaries.

Building systems that retain control

Enterprises already design critical systems around the assumption that applications can fail, behave unexpectedly or become compromised. They use identity, operating system controls, network segmentation, policy enforcement, isolation, monitoring, software supply chain protections and hardware security boundaries to limit the consequences.

Agentic AI requires the same discipline, with an additional consideration: agents may dynamically choose tools, assemble workflows and take actions that were not individually scripted in advance. That makes the boundaries around their authority as important as the instructions guiding their behavior.

As enterprises give agents greater authority, they will need security controls across the software supply chain, operating system, AI platform, agent runtime, identity, network and infrastructure. They will also need ways to connect organizational policies and risk requirements to the technical controls enforcing those boundaries.

Red Hat's role is to help make those controls open, interoperable and operational across the hybrid cloud. As part of the NVIDIA Open Agent Safety Platform, OpenShell and NVIDIA BlueField provide an opportunity to extend that architecture with enforcement mechanisms that can operate independently of the agent workload itself.

Together, those layers can help organizations expand what agents are permitted to do while maintaining clear control over the systems and resources available to them.