Trusted AI Infrastructure: BlueField Security and Continuous Firmware Assurance

AI systems inherit the security of the infrastructure beneath them. That dependency becomes more consequential as agents gain access to sensitive data, tools and enterprise systems. NVIDIA BlueField and Eclypsium address different parts of the problem: BlueField provides a hardware-based control point for infrastructure services, while Eclypsium checks hardware, firmware and configuration for signs of risk or change.

The pairing reflects a useful principle for AI operators: trust should rest on evidence that can be checked over time. A system can start from an approved configuration and later drift because of a vulnerability, an unauthorized modification or a compromised component. Secure boot and device attestation help establish platform state, but operators also need visibility into what changes after deployment.

Separating infrastructure services from host workloads

NVIDIA BlueField DPUs combine networking, programmable compute and hardware acceleration. They run infrastructure services independently of the host workloads, creating separate trust domains for applications and the systems that manage underlying resources. Cloud providers and enterprises can use that separation to shape access controls and security boundaries around their own operating needs.

BlueField includes Arm CPU cores, an operating system, firmware and a management controller. It also moves data directly into host and GPU memory during normal operation. That privileged position makes the DPU part of the security perimeter: operators need to include it in asset inventories, configuration reviews and monitoring.

BlueField runs NVIDIA Sentry, which is part of the NVIDIA OpenShell Reference Architecture. Because Sentry is intended to help protect autonomous AI agents, the security of the DPU that hosts its controls matters. The DPU can act as an independent point for infrastructure management, separated from the workloads it helps protect.

BlueField’s defenses span hardware, firmware, operating systems, software and device management. They include a hardware root of trust, authenticated boot, hardware-enforced isolation, protected key management, authenticated firmware updates, rollback protection and device attestation. Together, these mechanisms are designed to protect platform integrity and maintain security boundaries.

Those protections sit alongside NVIDIA’s secure development work, which includes threat modeling, architecture and code reviews, automated security analysis, vulnerability management, fuzzing and offensive security research. No complex platform is free of vulnerabilities, so continuing response work and software and firmware updates remain part of the security model throughout the supported product lifecycle.

Configuring trust boundaries for each deployment

Infrastructure operators face different trust assumptions depending on how systems are used. A multi-tenant cloud, a single-tenant enterprise AI cluster and an air-gapped environment may need different controls for administrative privileges, management interfaces, device access and isolation.

BlueField’s programmable compute allows operators to configure which capabilities are enabled, which interfaces are exposed and how infrastructure access is controlled. For example, a cloud provider can keep tenant workloads and the host operating system in one trust domain while placing provider-managed infrastructure services in another. BlueField can also lock configurations into cryptographically attestable trust profiles, giving operators a way to check whether the intended boundaries are in place.

Direct memory access is one area where configuration deserves particular attention. DPUs, GPUs and management controllers can read or write system memory directly. Eclypsium research points to host protections such as IOMMU translation, PCIe Access Control Services and Address Translation Services as important safeguards. Its assessment tools can help operators verify these hardware settings instead of relying on assumptions.

The practical point is that a platform’s available features don’t all need to be exposed in every deployment. Operators need to define the trust model first, then configure the device to match it. That gives teams room to balance isolation, performance and operational needs.

Adding independent infrastructure checks

BlueField’s built-in mechanisms form one layer of defense. Eclypsium adds infrastructure visibility and ongoing checks focused on firmware integrity, configuration and changes below the operating system. Its AI Infrastructure Assurance offering compares hardware and firmware against known-good baselines, identifies vulnerabilities and insecure settings, monitors device posture, and looks for drift, unauthorized changes and persistent threats.

That scope matters because AI environments contain more than host servers and model files. GPUs, DPUs, management controllers, networking equipment and other components all contribute to the system’s security. Eclypsium’s assessment capabilities can help teams identify infrastructure components, evaluate firmware and configuration risks, and track changes across those devices as environments grow.

A deployment could establish an approved configuration at setup, use BlueField’s controls to protect platform integrity, then apply Eclypsium checks to flag an unexpected change or emerging firmware risk. No single control establishes trust across the whole stack. Platform protections, independent assessment and continuous monitoring provide different forms of evidence and are more useful when they reinforce each other.

Keeping assurance through updates and reassignment

Infrastructure passes through manufacturing, provisioning, deployment, operation, updates, recovery and eventual reassignment or decommissioning. Each transition can change the device’s state or the context in which it is trusted.

BlueField includes secure provisioning, authenticated firmware updates, rollback protection and device attestation to help maintain platform integrity as systems change. Eclypsium’s assessment and monitoring can complement those mechanisms by tracking components, firmware risks, vulnerabilities and configuration changes over time.

Operationally, teams can establish an approved configuration before deployment, monitor devices in service and reassess them after updates or recovery. Each DPU, GPU and management controller should be treated as an asset with its own firmware versions, configuration and owner, and included in vulnerability management alongside the host operating system. Management-interface telemetry, including baseboard management controller and Redfish logs, can add useful evidence. Since these components can persist through an operating system reinstall, teams should reassess them after incident response and before assigning hardware to a new tenant.

Different checks answer different questions. Secure boot authenticates boot components. Attestation reports measured platform state. Configuration assessment checks how the system is set up and managed. None alone describes the device’s full current behavior: boot measurements show how a system started, and checking a model file’s integrity says nothing about whether the model running in memory matches that file.

Runtime verification can help find changes after startup. Independent views of the same device—such as host settings, PCIe topology, management-controller firmware and change history—also make it harder for a hidden compromise to present a consistent picture across every check.

Research exposes limits of file checks

NVIDIA and Eclypsium have examined how compromised infrastructure could affect a model’s behavior without changing the stored model file. In their research demonstration, the model file, its hash and its signature remained valid while the model running in memory behaved differently. The example shows why checking an artifact on disk cannot, by itself, establish the integrity of the system executing it.

The issue applies across accelerator designs. GPU systems, alternative accelerators and custom ASICs rely on privileged components beneath the model, including host processors, accelerator firmware, management controllers and smart network adapters. Those components can access memory where model data runs or help move it between devices.

NVIDIA says it continues to assess reported findings and provide updates or guidance as appropriate. Eclypsium contributes independent research and infrastructure assessment expertise; NVIDIA brings product knowledge, development practices and vulnerability response processes. That exchange can turn research into deployment guidance, product changes and shared evaluation methods. The Open Secure AI Alliance is one effort intended to support shared checks and defenses.

Extending the model to AI agents

Agents increase the demands on infrastructure because they can reason, reach sensitive data, use tools and take actions. Protecting them calls for controls that can observe behavior independently of the agent and enforce access rules while it runs.

NVIDIA’s OpenShell Reference Architecture extends hardware-isolated infrastructure security to agent workloads. BlueField-4 provides the infrastructure foundation for NVIDIA Sentry, a security software framework built on NVIDIA DOCA. Sentry is designed to operate independently of the host and outside the agent’s control, providing out-of-band monitoring and in-silicon policy enforcement to help detect and contain threats.

This infrastructure layer complements OpenShell’s software execution boundaries. Eclypsium adds checks on hardware and firmware across the environment. Together, the approach links infrastructure verification with controls over agent access and actions, plus ongoing monitoring for changes that could weaken trust. For operators, the useful takeaway is to treat the DPU, GPU and management components as part of the AI system itself—and keep checking their state after deployment.