AI Factory Security

What an AI Factory Is and Why Its Security Is Different

An AI factory is a dedicated computing environment that enables AI to be produced at industrial scale. Traditional data centers run a wide range of general-purpose workloads, whereas an AI factory is optimized end to end for one job: training and serving AI models. This results in a tightly aligned high-performance stack with a well-defined AI function.

GPU clusters sit at the compute layer, which are specialized processors that make large-scale model training possible. Those GPUs are joined by ultra-high-bandwidth interconnects such as NVLink within a server, and InfiniBand across servers. This allows thousands of processors to act as a single machine. On top of the hardware runs an orchestration layer, such as Kubernetes, which provisions resources, places workloads, and manages the data pipelines that feed the models.

This is closer to high-performance computing (HPC) than to conventional enterprise IT, which is exactly why most of the relevant security guidance now leans more toward HPC best practice instead of standard cloud security.

In this environment, security characteristics follow from ownership. When an enterprise uses a managed cloud AI service, the provider is responsible for securing the underpinning infrastructure through a shared responsibility model. An AI factory removes that provider. The enterprise now owns the GPUs, the interconnects, the orchestration layer, the model weights, and the training data, so responsibility for securing every one of those layers falls to the enterprise as well.

Understanding AI security is the starting point, but an AI factory adds even more requirements: the most sensitive asset is not only the data – there is also a multimillion-dollar computation estate to consider, and the proprietary models that it generates.

The Expanded Attack Surface of an AI Factory

Concentrating so much value into one tightly integrated environment broadens the attack surface across four individual layers at once. The first step toward an accurate asset inventory is to map them, which is a critical step because AI factories differ from the AI security risks and threats that enterprises already track for general AI use.

• The Compute Layer: Graphics Processing Units (GPUs), Data Processing Units (DPUs), firmware, and interconnects become primary targets for attackers. Their value, scarcity, and specialized firmware make them valuable to attackers to steal cycles from, and attacking them directly can cause more damage if successful.

• The Data Layer: Training datasets, fine-tuning data, and retrieval sources flow throughout the environment. Their integrity decides model behavior, which makes the pipeline a high-value target for tampering with as well as theft of the underlying logic.

• The Model Layer: Proprietary model weights are among the most valuable IP of an AI factory because they are generated from an enormous investment of resources and time. These weights can be stolen or reconstructed through inference attacks against deployed models.
• The Identity Layer: Researchers, engineers, automated pipelines, and service accounts all need access to AI factory infrastructure. The number and variety of these identities consist of human and non-human accounts, which creates a large and dynamic access surface.

On top of these is a structural problem that is unique to shared AI infrastructure. It is a layered, three-way trust dilemma. In many AI factory deployments (especially those that are run by cloud providers), three groups need to coexist on the same hardware. The infrastructure owner runs the physical estate, the model owner supplies the proprietary weights, and the data owner contributes sensitive training or inference data.

Each of these groups must trust the others without fully exposing their own assets, and no single group has complete visibility into the whole system. That gap, where trust is required but verification is not always possible, is where many AI factory risks start.

Core Threats to AI Factory Infrastructure

Not every AI factory threat is equal. Resources are finite, which makes prioritizing by potential blast radius crucial. The key deciding factor is how much damage a successful attack can inflict, and this is what separates a credible security program from a checklist.

The threats below are grouped into three tiers and range from those that compromise the infrastructure itself to those that target how the environment is used. Each tier is sorted with a priority ranking and focuses on the most common threats in the AI factory space.

Tier 1: Infrastructure and Model Compromise (Highest Blast Radius)

These threats strike the AI factory at its foundation. A successful attack can compromise the hardware every workload depends on or exfiltrate the single most valuable asset in the building.

• GPU-Targeted Malware and Cryptojacking: Attackers increasingly write malware aimed specifically at GPU resources, either to hijack idle cycles for cryptomining (also known as cryptojacking) or to establish a foothold on the most powerful and least-monitored hardware in the environment. Because GPU activity is often invisible to traditional endpoint tools, this abuse can run for long periods, remaining undetected while degrading legitimate AI workloads.

• Side-Channel Attacks: In a shared environment, a malicious workload on one GPU can infer information about a neighboring workload by observing physical characteristics such as timing, power draw, or memory access patterns, instead of breaking into it directly. In an AI factory, this can mean leaking fragments of another tenant’s model or data across an isolation boundary.

• Firmware and Hardware Vulnerabilities: GPUs, DPUs, and network cards run their own firmware, which sits below the operating system and outside the view of most security tools. A compromise at this level is both extremely hard to detect and extremely difficult to remediate, since it can persist through reinstalls and survive at the deepest layer of the tech stack.

• Model Intellectual Property Theft: Proprietary model weights hold the core value and ROI of an AI investment. They can be stolen directly if access controls fail, or reconstructed indirectly through model extraction and inversion attacks. These attacks probe a deployed model until its behavior, or its training data, can be reasonably approximated. Either path hands a competitor or adversary the most valuable output of the entire AI factory.

Tier 2: Supply Chain and Data Integrity Threats

These threats enter through the materials and dependencies an AI factory relies on. They are dangerous because they exploit trusted inputs, and because their effects can remain dormant until the model reaches production. 

• AI Supply Chain Attacks: Modern models are created from a variety of sources. These include open-source frameworks, pre-trained base models, public datasets, and container images. Each is a dependency that an attacker can target. A backdoor introduced into any of these components can persist silently into production, and inherit the trust placed in the upstream source.

• Data Poisoning: By deliberately corrupting training or fine-tuning data, an attacker can manipulate how a model behaves, introducing biases, blind spots, or hidden triggers. Because the manipulation happens at the data layer, it is difficult to detect by inspecting the model alone, and can undermine a model’s reliability long after training is complete.

• Compromised Model and Container Integrity: If model weights or the container images that package them are altered in transit or at rest, the production system can be running tampered artifacts without anyone noticing. Verifying integrity end to end, from build to deployment, is the most effective method for closing this gap.

Tier 3: Usage and Insider Threats

These threats surface from how people and processes interact with the AI factory. They are usually less destructive than an infrastructure compromise, but they are common. When they occur, they widen the surface that higher-tier threats can exploit.

• Shadow AI: When teams deploy unsanctioned models, pipelines, or GPU workloads outside official governance, security loses visibility and control. Unmonitored assets cannot be patched, inventoried, or defended, and they frequently become the weakest point in an otherwise hardened environment.

• Insider Threats: Researchers, engineers, and administrators hold privileged access to extremely valuable assets. Insider threats could be driven by malice, compromise, or simple error. Insiders can exfiltrate model weights, expose data, or misconfigure controls in ways that external attackers would struggle to achieve on their own.

Multi-Tenancy and Identity Risks

Two of the threats above, side-channel leakage and insider abuse, point to a deeper structural challenge: the difficulty of isolating workloads and identities in a shared, high-performance environment. These risks deserve a closer look because they are where AI factory security most often breaks down in practice.

Multi-tenancy is when a provider runs multiple workloads, often from different teams or customers, on the same physical GPU infrastructure to maximize the overall use of expensive hardware. The problem is that the same interconnects and shared memory that make an AI factory fast also make strong isolation hard.

Weak separation between tenants can allow data or model fragments to leak across boundaries, or let a noisy or malicious workload degrade its neighbors. Enforcing least-privilege access through the principle of least privilege is essential, but it must be enforced at the infrastructure layer, not just in software.

The NIST guidance for high-performance computing security provides a useful reference architecture, splitting an HPC system into functional zones – access, management, compute, and data storage, each with its own security requirements, instead of treating the whole environment as a single flat network.

NIST Special Publication 800-223 defines that zone-based architecture, and its companion, Special Publication 800-234, provides a security control overlay customized for HPC environments. Together, they give AI factory operators a credible, standards-based starting point for isolation and access design.

Securing the AI Supply Chain

Because so much AI factory risk enters through trusted dependencies, the supply chain needs its own controls. AI supply chain risk covers three categories: the datasets a model learns from, the open-source models and frameworks it is built on, and the software components and container images that package and run it. A weakness in any of these can become a weakness in production.

• Protect Model Weights: Treat trained model weights as the high-value intellectual property they are. Encrypt them at rest and in transit, restrict access tightly, and monitor for unauthorized copying or movement. The weights are both the most valuable and the most portable assets in the environment.

• Verify Container Image Integrity: Scan and cryptographically verify every container image before it runs, and re-verify through the pipeline. This prevents tampered or backdoored images from reaching production.

• Maintain an AI Bill of Materials (AI-BOM): Keep a complete, current inventory of every model, dataset, framework, and component in use, along with its provenance. A software bill of materials (SBOM) that is extended to AI assets is what makes it possible to respond quickly when a vulnerability or backdoor is discovered in an upstream dependency.

• Validate Data Provenance: Track where training and fine-tuning data comes from and validate it before it enters the pipeline. Establishing trusted data sources is the most direct way to defend against poisoning that is introduced through the supply chain.

Detection, Monitoring, and Runtime Security

Traditional security tools don’t serve an AI factory well, and it’s for a structural reason: most security tools were built to run as software agents on the host CPU. In an environment that is obsessed with performance, that overhead is not viable. Worse still is that a host-based agent is practically blind to GPU and firmware activity, and can be disabled if the host itself is compromised. Securing an AI factory calls for monitoring that sits closer to the infrastructure layer and stays independent of the workloads it watches.

The current approach pushes runtime threat detection down to the DPU – the smart network card that sits between the host and the network. Running security telemetry at the DPU level allows an entire compute node to be monitored for anomalies, including memory-level and process behavior, without consuming GPU cycles and without trusting the host operating system.

Industry frameworks built on this model, such as DPU-based runtime detection running on NVIDIA BlueField hardware, can detect threats while staying out of reach of an attacker who has compromised the host. This is the general direction that infrastructure-native AI security is moving toward.

Detection only delivers value if it connects to response. Telemetry from the AI factory should feed into the wider security operations stack, integrating with existing security solutions. These include:

• Security Information and Event Management (SIEM)
• Security Orchestration, Automation, and Response (SOAR)
• Extended Detection and Response (XDR) Platforms

Incident containment playbooks should be defined ahead of time for AI-specific scenarios, such as isolating a compromised node or revoking a tenant’s access, so that response is instant, and not improvised during an incident.

Enterprise Controls and Best Practices for AI Factory Security

Bringing the threats that we have covered under control requires a defense-in-depth stack that is built specifically for AI infrastructure, not repurposed from generic IT security. The controls below work together: no single one is enough on its own. When used together, they address each layer of the attack surface. For organizations adopting agentic workloads inside the factory, these pair naturally with dedicated AI agent security and a maturing AI security posture management (AI-SPM) practice.

• Zero Trust Architecture: Assumes no implicit trust between any components, tenants, or identities. Every request to access a resource is authenticated and authorized explicitly, which directly counters lateral movement, privilege escalation, and the weak-isolation risks associated with multi-tenancy installations.

• Hardware-Enforced Isolation and Trusted Execution Environments: Use trusted execution environments (TEEs) and hardware-level isolation so that models and data can be processed in protected enclaves, shielded even from a compromised host or a malicious co-tenant. This is a foundational solution to the three-way trust dilemma.

• Cryptographic Attestation: Verify that hardware, firmware, and software are in a known-good, untampered state before workloads can run on them. Attestation provides the verifiable trust that the shared-infrastructure model lacks otherwise.

• Least-Privilege Identity and Access Management: Grant every identity, human and non-human, only the minimum access needed, and manage credentials through their full lifecycle. Structured identity and access management (IAM) is the most effective control against identity sprawl and insider risk.

• Hardened Containers: Run workloads in containers that are configured to a strict security baseline, with minimal privileges and a reduced attack surface. This ensures that a compromise in one workload is contained and not allowed to spread.

• Continuous Vulnerability Scanning: Scan the entire stack, including images, dependencies, and components, on an ongoing basis instead of at a single gate. Continuous scanning catches newly disclosed vulnerabilities in the supply chain before attackers can exploit them.

• Comprehensive Audit Logging: Log activity across the AI factory in a tamper-resistant way to support detection, incident investigation, and compliance. Aligning these controls to a recognized framework like the NIST HPC guidance gives the program a defensible structure that is based on standards.