Securing AI Infrastructure: Workload Identity for AI Pipelines, Models and GPUs

Behind every AI agent sits an AI platform: data pipelines, notebooks, training jobs, model registries, inference endpoints, vector databases and GPU clusters. Each of those components authenticates to the others and to cloud services, usually with non-human identities that are over-privileged, long-lived and poorly inventoried. AI infrastructure also holds some of the most valuable assets an organisation has: training data, model weights, embeddings of internal documents and paid access to expensive compute. This guide explains the workload identities that run AI infrastructure, the risks specific to them, and how to apply workload identity best practice to the AI stack.

Key takeaways

• AI platforms create many NHIs: pipeline and job identities, notebook identities, serving identities, model provider API keys, vector database credentials and storage access tokens.
• The highest-value targets are training data, model weights, vector stores and paid model and GPU capacity. Stolen AI credentials are used for data theft and for running models at the victim's expense (LLM hijacking).
• Apply the same principles as for any cloud workload: platform-issued, short-lived identities; least privilege per component; environment separation; no static keys in notebooks or images.
• Pay particular attention to notebooks and shared research environments, which combine human access, broad data permissions and pasted credentials.

The AI infrastructure stack and its identities

Risks specific to AI infrastructure

1. Over-broad data access

Training and retrieval pipelines are often given read access to entire data lakes "because the model might need it". A compromised pipeline identity then exposes everything. The Microsoft SAS token exposure, where AI researchers shared an overly permissive storage token while publishing training materials, is the best-known example of a single AI-related token exposing far more than intended.

2. Credentials in notebooks, images and data sets

Notebooks mix code, output and credentials, and are shared, exported and committed. Container images for training and serving often have keys baked in. Data sets themselves can contain secrets: researchers found nearly 12,000 live secrets in a public data set widely used to train LLMs. Secrets used in training data can also be memorised and reproduced by models.

3. Model provider API keys and LLM hijacking

Keys for model providers and cloud AI services are valuable to attackers, who use them to run models at the victim's expense or resell access. See the AI LLM hijack breach, the Azure OpenAI hacking-as-a-service case and compromised AWS accounts used for crypto-mining, which targets the same GPU capacity.

4. Model and artefact integrity

Whoever can write to the model registry or artefact storage can replace a model with a backdoored one. Model files in some serialisation formats can execute code when loaded. Registry write access should be treated as privileged, and AI platforms themselves are targets, as the Hugging Face breach showed.

5. Vector stores as a data leak path

Vector databases hold embedded chunks of internal documents, often without the original documents' access controls. A single API key to the vector store can expose content from many sources, and retrieval that ignores the requesting user's permissions lets any user or agent see anything that was indexed.

6. Environment mixing

Research, staging and production AI environments often share identities and data. Experiments run with production credentials; production models are trained on data copied without controls. This is OWASP NHI8, Environment Isolation.

7. Exposed AI applications and platforms

Internal AI platforms and chat applications store prompts, conversations and uploaded files. Incidents at McKinsey's internal AI platform, OmniGPT and DeepSeek exposed chat histories and sensitive data at scale.

Controls by component

Pipelines, training and fine-tuning jobs

• Run each job under its own workload identity (cloud IAM role, managed identity, Kubernetes service account mapped to a cloud identity, or SPIFFE ID), never under a user account or a shared key.
• Scope data access to the specific data sets and prefixes the job needs, read-only unless it writes outputs.
• Issue credentials for the duration of the job; revoke on completion.
• Separate who can start jobs from who can push models to the production registry.

The Cloud Workload Identity Guide and Kubernetes NHI Security Guide cover the underlying mechanisms.

Notebooks and research environments

• Authenticate notebooks with the user's own identity plus a scoped workload identity for compute, not shared service accounts.
• Provide secrets through a secrets manager integration, never pasted into cells; scan notebooks and their outputs for secrets before sharing or committing.
• Give research environments access to de-identified or sampled data by default, with approval required for production data.
• Expire idle environments and their credentials automatically.

Model provider access

• Route model calls through a central AI gateway that holds provider credentials, so applications and teams authenticate to the gateway with their own identities instead of holding provider keys.
• Where providers support it, use workload identity federation or short-lived tokens instead of static API keys.
• Set per-key and per-team spend limits and alerts; unusual spend is often the first sign of stolen keys.
• Add model provider key patterns to secrets scanning.

Model registry and artefacts

• Treat registry write access as privileged; only controlled pipelines can publish to production.
• Sign models and artefacts and verify signatures before loading; prefer safe serialisation formats.
• Record provenance: which data, code and identity produced each model.

Inference and serving

• Give each serving deployment its own identity with access only to its model and required downstream services.
• Authenticate callers to inference endpoints; do not expose endpoints without authentication, even internally.
• Keep serving identities separate from agent tool credentials.

Vector databases and retrieval

• Carry source-document permissions into the index as metadata and filter retrieval by the requesting user's entitlements.
• Use separate collections or tenants for different sensitivity levels.
• Replace shared database API keys with per-service identities where supported; scope indexing and query rights separately.

GPU clusters

• Use Kubernetes projected service account tokens and workload identity, not long-lived tokens or node-wide credentials.
• Isolate tenants and projects with namespaces, network policies and separate identities.
• Monitor for unexpected workloads, a common sign of hijacked compute.

Practitioner checklist

• Inventory every identity in the AI stack: pipelines, notebooks, jobs, registries, serving, vector stores, gateways and clusters.
• Replace static keys with platform-issued, short-lived workload identities wherever possible.
• Scope data access per job and per service; no data-lake-wide read access by default.
• Keep secrets out of notebooks, images and training data; scan all three.
• Centralise model provider credentials in a gateway with per-team identities and spend limits.
• Protect model registry writes as privileged; sign and verify models.
• Enforce permission-aware retrieval in vector stores.
• Separate research, staging and production identities and data.

Standards and references

• OWASP Non-Human Identities Top 10 (2025): NHI2, NHI5, NHI7, NHI8
• OWASP Top 10 for LLM Applications (supply chain, data and model poisoning, sensitive information disclosure)
• MITRE ATLAS
• NIST AI 600-1 Generative AI Profile
• SPIFFE concepts
• SLSA supply chain framework

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Kubernetes NHI Security Guide · Guide to the Secret Sprawl Challenge · Agentic AI Security Guide