The Question
Enterprise AI security programs are growing rapidly. Threat modeling sessions are covering prompt injection, jailbreaking, model exfiltration, and adversarial inputs. Red teams are probing LLM endpoints for manipulation vulnerabilities. AI governance frameworks are addressing bias, hallucination, and content safety.
Very few of those programs are assessing the infrastructure layer below the model.
The GPU clusters running distributed training. The model registry storing production model weights. The CI/CD pipelines that build training environments and pull dependencies from package repositories. The inference endpoints that serve millions of requests per day. The service accounts with broad data access that run the training data pipelines. These components constitute the AI infrastructure attack surface — and they are, in most enterprises, assessed against neither the security standards applied to critical application infrastructure nor the AI-specific threat models being developed for the model layer.
The consequences of this gap are severe. A compromised model registry means a malicious model can be substituted for a legitimate one in production. A compromised training pipeline can alter model weights during training in ways that are extremely difficult to detect post-hoc. A GPU cluster with inadequate network isolation is a high-value target for cryptomining and IP theft simultaneously.
The AI security conversation has focused on the model because that is where the novel threats are most visible. The infrastructure security conversation is less novel — it is mostly cloud security, identity, and supply chain — but the business impact of infrastructure compromise is at least as severe as model-layer attacks.
AI infrastructure security is not a model-layer concern — it is a cloud security, identity, and supply chain concern that requires the same security controls applied to any critical enterprise compute infrastructure, plus AI-specific protections for the model registry and training pipeline.
Why This Matters Now
In mid-2024, security researchers at HiddenLayer published findings describing a class of attacks they termed "model supply chain attacks" — specifically, the use of malicious serialized model artifacts (PyTorch pickle files, Hugging Face safetensors files with embedded code) distributed through model repositories to execute arbitrary code on the machines that load them. Hugging Face's model hub, which hosts hundreds of thousands of public model artifacts, had been used as a distribution vector for malicious model files.
The threat was not theoretical. HiddenLayer confirmed real-world instances of malicious model artifacts being loaded by enterprise ML teams pulling "pre-trained" models from public repositories into internal training pipelines — bypassing the organization's software supply chain controls because model artifacts were not treated as code.
This incident crystallized a problem that had been building for years: enterprise AI teams were pulling model artifacts, training dependencies, and dataset loaders from public repositories with minimal or no security review — a practice that would have been unacceptable for application code or infrastructure dependencies in any mature security program, but that had not been examined in the AI context because "it's just a model."
Simultaneously, in the same period, cloud security researchers at Wiz documented multiple cases of misconfigured SageMaker training jobs and Vertex AI pipelines with overly permissive IAM roles — in several cases, training job service accounts with read access to entire S3 buckets or GCS buckets that contained sensitive enterprise data far beyond the scope needed for the specific training workload.
The pattern across both findings was the same: AI infrastructure was being treated as a research and engineering resource rather than a production security asset, and the standard enterprise security controls — least-privilege identity, artifact provenance, network isolation — had not been applied.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Infrastructure CURVE™ Report assessed security capabilities across five AI infrastructure vendor categories: cloud AI platform security (AWS SageMaker, Azure Machine Learning, Google Vertex AI), model registry security (MLflow, Weights & Biases, Hugging Face Enterprise Hub), training pipeline security (Kubeflow, Airflow with security configurations, GitHub Actions with ML workflows), inference endpoint security (NVIDIA Triton, vLLM, Seldon Core), and AI-specific security tooling (HiddenLayer, Protect AI, CalypsoAI).
The CURVE™ evaluation found that cloud AI platform native security controls have matured significantly since 2023, with all three major hyperscalers introducing AI-specific IAM capabilities, private endpoint configurations, and audit logging improvements. The largest gaps identified were in the model registry and training pipeline categories, where the adoption of security controls significantly lags the adoption of the platforms themselves.
The report also evaluated which model registry solutions support cryptographic artifact signing and provenance tracking — capabilities that are table-stakes for software supply chain security but are not universally implemented in the ML toolchain.
The full vendor rankings are in the 2026 Stackcurve AI Infrastructure CURVE™ Report — free to download.
The Gap Most Buyers Miss
AI infrastructure security gaps do not require AI-specific attack techniques. They require the application of standard cloud security, identity management, and supply chain security practices to an infrastructure domain that most security programs have not yet fully assessed.
GPU Cluster Security
GPU clusters running distributed training workloads are among the highest-value compute targets in the enterprise. They hold model weights (intellectual property), training data (often sensitive or regulated), and significant compute capacity (valuable for cryptomining). Despite this, GPU clusters are frequently deployed with less stringent network isolation than equivalent compute infrastructure in application environments.
Security requirements for training clusters: VPC or VNET isolation with no direct internet exposure, IAM-based access controls for cluster management APIs (no shared credentials), secrets management integration for training scripts (no hardcoded API keys or database credentials in training code or Dockerfiles), audit logging of all cluster access and job submissions, and data encryption at rest and in transit for training datasets.
Model Registry Poisoning
The model registry is the software supply chain for AI. It stores versioned model artifacts that are promoted from development to staging to production. An attacker with write access to the model registry — through a compromised service account, a misconfigured repository permission, or a supply chain attack — can substitute a malicious model artifact for a legitimate one. If the production deployment pipeline pulls from the registry without artifact integrity verification, the malicious model reaches production.
Controls: strict access controls on registry write operations (separate from read access), cryptographic signing of model artifacts at publication time (MLflow supports artifact signing; DVC supports content-addressed storage with hashing), provenance tracking that records which training job and dataset version produced each model artifact, and integrity verification in the deployment pipeline before serving traffic.
Training Pipeline Injection
ML training pipelines are CI/CD pipelines. They pull code from git repositories, install Python dependencies from package registries (PyPI, conda), and may pull base Docker images from container registries. All of these supply chain dependencies are potential attack vectors: a compromised PyPI package used as a training dependency, a typosquatting attack on a common ML library name, or a compromised base image could all result in malicious code executing during model training.
Controls: dependency pinning (specific version hashes rather than floating version ranges), software bill of materials (SBOM) generation for ML environments, execution in isolated environments with no persistent state between training runs, and scanning of training dependencies with tools like Snyk or Semgrep before pipeline execution.
Inference Endpoint Exposure
LLM inference endpoints are web services. They have the same exposure as any API: authentication bypass vulnerabilities, injection attacks against prompt construction logic, rate limiting bypass, and denial-of-service through resource-exhaustive inputs (extremely long inputs that consume disproportionate compute). Many enterprise inference deployments rely on network controls (IP allowlisting, VPC exposure) rather than application-layer authentication — a control that is insufficient for endpoints accessible to any internal network participant or any compromised internal system.
Controls: API-key or OAuth-based authentication on every inference endpoint (network controls are insufficient as a sole control), rate limiting with per-client tracking, WAF rules for inference endpoints that enforce maximum input length and flag injection patterns, and logging of all inference requests with sufficient detail for incident investigation.
Data Pipeline Service Account Over-Permissioning
Training data pipelines require read access to data sources. In practice, the service accounts running these pipelines are frequently granted broad read access to data stores — an entire S3 bucket, an entire database schema — rather than the minimal access required for the specific training workload. A compromised pipeline service account (through credential theft, SSRF in a pipeline environment, or compromised workflow automation) can therefore expose all data in the accessible store, not just the training data.
Controls: least-privilege service account configuration scoped to specific training data paths, periodic access review of pipeline service accounts, data access logging for service account activity, and environment isolation that prevents pipeline credentials from being accessible outside the pipeline execution context.
Questions Your Buying Team Should Be Asking
1. Has our security team performed a threat model on the AI infrastructure layer specifically — GPU clusters, model registry, training pipelines, and inference endpoints?
AI security programs frequently produce threat models for the model layer (prompt injection, data poisoning) without producing equivalent assessments of the infrastructure layer. Ask your CISO or security architecture team whether a formal infrastructure-layer threat model exists and when it was last reviewed.
2. What controls prevent unauthorized modification of artifacts in our model registry?
Ask specifically: who has write access to the production model registry, how are those permissions managed, are model artifacts cryptographically signed, and is artifact integrity verified before deployment? If the answer to any of these questions is "I'm not sure," the model registry is an uncontrolled write surface in the production deployment path.
3. Are training pipeline dependencies pinned to specific versions and hashes, and is there SBOM generation for training environments?
This question tests whether the training pipeline is treated with the same supply chain rigor as application code. Floating dependency versions in training pipelines are a supply chain attack vector. Ask for a recent training environment manifest and verify that version hashes are specified, not floating version ranges.
4. Are inference endpoint service accounts and API credentials scoped to the minimum required access, and are all inference requests logged with sufficient detail for incident investigation?
Over-permissioned inference endpoint service accounts can be leveraged to access data stores beyond the scope of inference operations. Ask for a demonstration of the inference endpoint's IAM configuration and confirm that request logging is enabled with sufficient fields to reconstruct the sequence of events in an incident.
5. What is the process for reviewing model artifacts sourced from public repositories before they are used in internal training pipelines?
Given the documented threat of malicious model artifacts in public repositories, any internal training pipeline that pulls model checkpoints from Hugging Face Hub or other public sources requires an artifact review process. Ask for the specific controls applied to externally-sourced model artifacts before they enter the internal training environment.
The Stackcurve Take
AI infrastructure security is not a new problem. It is the application of cloud security, identity management, and supply chain security to a set of infrastructure components — GPU clusters, model registries, training pipelines — that are newer and less familiar to enterprise security programs than application servers and databases, but that carry the same or greater business risk.
The organizations closing this gap are applying existing security frameworks (CIS Benchmarks for cloud, SLSA for supply chain, SOC 2 controls for access management) to AI infrastructure components rather than treating AI infrastructure as a separate security domain requiring novel approaches.
The organizations that remain exposed are those where the AI program reports to engineering or data science leadership rather than through the standard infrastructure provisioning and security review process — and where "it's a research environment" or "it's a proof of concept" has been used to exempt AI infrastructure from the security controls that would otherwise apply.
The AI infrastructure security posture of most enterprises is substantially weaker than their application infrastructure security posture. The delta is addressable, and it does not require AI-specific security tooling — it requires discipline in applying existing security controls to a new infrastructure domain.
The 2026 Stackcurve AI Infrastructure CURVE™ Report covers AI infrastructure security controls, cloud platform security assessments, and model registry and training pipeline security evaluations. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.