An execution identity is the non-human identity that performs a task at runtime, such as a Terraform role, Kubernetes controller, or CI/CD service account. It is the identity that matters when evaluating who can actually retrieve or decrypt a secret in production.
Expanded Definition
An execution identity is the runtime identity that actually performs work, not merely the identity that declares or configures it. In NHI and IAM practice, that distinction matters because the entity executing a workload often has the effective power to read secrets, call APIs, mint tokens, or decrypt data. The concept is closely related to workload identity, but it is narrower: it emphasizes the identity in control at the moment of execution, such as a Kubernetes controller, Terraform runner, or CI/CD service account.
Definitions vary across vendors and platforms, but the governance question is consistent: who or what is authorized when code is running, and under what conditions. NIST Cybersecurity Framework 2.0 frames this as a core access and protection concern, while modern NHI programs treat execution identities as first-class security subjects rather than implementation details. When these identities are long-lived or over-privileged, they become the fastest path from routine automation to production compromise.
The most common misapplication is treating the deployment identity as the execution identity, which occurs when teams review the pipeline account but ignore the runtime service account that actually touches secrets.
Examples and Use Cases
Implementing execution identity rigorously often introduces operational overhead, requiring organisations to weigh faster automation against tighter runtime control, shorter credential lifetimes, and more frequent access review.
- A Terraform automation role applies infrastructure changes in cloud accounts, but a separate execution identity retrieves the secret needed to authenticate to the destination environment.
- A Kubernetes controller uses its service account to reconcile resources and request credentials only at runtime, aligning with the identity model discussed in the Ultimate Guide to NHIs.
- A CI/CD job signs artifacts and deploys releases through a narrowly scoped service account, while the underlying runner identity determines whether secret material can be decrypted.
- A workload running under ephemeral credentials exchanges its execution identity for a short-lived token, a pattern often compared with NIST Cybersecurity Framework 2.0 principles for least privilege and access control.
- During incident review, analysts trace which runtime identity accessed production APIs after a token leak, using evidence from cases like the 52 NHI Breaches Analysis.
Why It Matters in NHI Security
Execution identities are where policy becomes real. If the wrong identity is allowed to execute in production, privilege boundaries collapse even when vaults, roles, and approval workflows appear well designed on paper. This is why execution identity belongs at the center of NHI governance: it determines whether an automation path can read secrets, invoke sensitive APIs, or escalate through chained permissions. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes runtime identity scoping a practical control point rather than a theoretical one.
The risk is especially high in environments where secrets are stored outside approved managers, because runtime access often becomes the easiest route to exposure. The Top 10 NHI Issues and the Ultimate Guide to NHIs both highlight how poor visibility and weak rotation turn routine automation into persistent attack surface. Organisations typically encounter the consequence only after a leaked token, a compromised pipeline, or an unauthorized secret read, at which point execution identity 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 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-01 | Covers over-privileged runtime identities and their access paths to secrets. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed for the identity that actually executes tasks. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous verification of workload and service execution identities. |
Inventory runtime identities and reduce their permissions to only the actions needed at execution time.
