A workload that depends on graphics processing units for training or inference. These environments often introduce bursty consumption, specialised provisioning, and broader operational complexity, which means access governance must cover both compute allocation and the identities that can use it.
Expanded Definition
A GPU workload is a compute workload that relies on graphics processing units for parallel processing, typically for model training, inference, simulation, or high-throughput analytics. In NHI operations, the term matters because the workload is not just consuming compute, it is often acting through service accounts, API keys, tokens, and certificates that authorize access to data, clusters, and model-serving endpoints.
Definitions vary across vendors when GPU use is embedded in cloud platforms, Kubernetes, or AI orchestration layers, but the security boundary is usually the same: identity must govern who or what can request GPU capacity, attach to it, and move data into or out of it. That makes the topic closely related to workload identity patterns described in the SPIFFE workload identity specification and to the governance principles in Ultimate Guide to NHIs – Standards.
The most common misapplication is treating GPU access as a capacity-planning issue only, which occurs when teams approve compute reservations without tying them to the identities, secrets, and entitlements that actually use the workload.
Examples and Use Cases
Implementing GPU workload governance rigorously often introduces allocation friction, requiring organisations to balance developer speed against tighter approval, segmentation, and identity checks.
- An AI training job launches in a Kubernetes cluster and uses a short-lived token to pull datasets, which should be tied to a workload identity rather than a shared secret.
- A model-inference service autos-scales across GPU nodes, making certificate rotation and endpoint authorization part of the workload lifecycle, not an afterthought.
- A research team submits bursty jobs to a cloud GPU queue, where policy must distinguish sanctioned experimentation from unauthorized lateral movement into sensitive storage.
- A platform team adopts SPIFFE-based identity for GPU-backed services, aligning runtime trust with the guidance in the Guide to SPIFFE and SPIRE.
- An MLOps pipeline packages training, evaluation, and deployment into separate stages, each with distinct NHI controls for secrets, RBAC, and offboarding.
GPU workloads are also common where high-throughput processing needs temporary but tightly scoped access, such as regulated analytics or fraud detection pipelines. In those environments, the workload identity should be ephemeral, auditable, and bounded to the minimum permissions needed to access compute and data.
Why It Matters in NHI Security
GPU workloads concentrate both privilege and exposure. They often sit at the intersection of orchestration systems, secrets managers, data platforms, and model endpoints, which means a weak identity control can cascade quickly across environments. The NHI risk is amplified by operational sprawl: SailPoint reports that 57% of organisations lack a complete inventory of their machine identities, and NHIMG research shows 97% of NHIs carry excessive privileges. That combination makes GPU clusters a prime place for unmanaged service accounts, stale tokens, and overbroad access to persist unnoticed.
This is why GPU workload governance should be treated as part of NHI lifecycle control, not just infrastructure tuning. When secrets are embedded in deployment manifests or when runtime identities are shared across jobs, compromise becomes harder to detect and containment becomes slower. The issue is especially visible in environments that lack clear ownership or rotation discipline, as described in Ultimate Guide to NHIs – What are Non-Human Identities and in the operational gaps documented by SailPoint. Organisations typically encounter this risk after a leaked token, failed audit, or unexpected GPU spend spike, at which point GPU workload governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | GPU workloads often fail when secrets and workload identities are not scoped or rotated properly. |
| OWASP Agentic AI Top 10 | Agentic systems that trigger GPU jobs inherit the same execution and tool-access risks. | |
| NIST CSF 2.0 | PR.AC-4 | Access permissions for GPU resources map to least-privilege identity governance. |
| NIST Zero Trust (SP 800-207) | SC-7 | GPU clusters need segmented trust decisions for workloads, nodes, and data flows. |
| CSA MAESTRO | MAESTRO addresses agentic and automated workload execution that commonly lands on GPU infrastructure. |
Treat GPU-backed automation as a governed execution plane with identity, policy, and telemetry controls.
