Run-scoped identity

A short-lived identity tied to one execution of an agent, CI job, or automated workflow. It helps distinguish one session from another, which is essential when access needs to be reviewed, attributed, or revoked at the level of a specific run instead of a static service name.

Expanded Definition

Run-scoped identity is a short-lived NHI that exists only for a single execution boundary, such as one agent action, CI job, or workflow run. It differs from a persistent service account because its trust and audit context are tied to the run itself, not to a long-lived workload name. That distinction matters when access needs to be attributed, constrained, and revoked at session granularity.

In practice, run-scoped identity is part of stronger ephemeral authentication patterns that align with modern guidance for OWASP Non-Human Identity Top 10 and Zero Trust. Definitions vary across vendors on whether the identity is minted by a control plane, workload broker, or federation layer, but the operational requirement is the same: each run should receive a unique, minimal-privilege identity with a clear expiry. The most common misapplication is treating a reusable service token as run-scoped, which occurs when teams rotate the token periodically but still reuse it across many executions.

Examples and Use Cases

Implementing run-scoped identity rigorously often introduces more issuer, policy, and audit complexity, requiring organisations to weigh stronger attribution against higher orchestration overhead.

• A CI pipeline mints a unique identity for one build, then discards it after artifact signing and deployment.
• An AI agent receives a per-run credential to call internal tools, with scope limited to the approved task list for that session.
• A batch job uses a temporary identity to access a single storage bucket and cannot reuse that credential for later scheduled runs.
• A federated workload exchanges a short-lived assertion for cloud access during one execution, then forces re-authentication on the next run.

These patterns are easier to govern when teams map execution identity to lifecycle controls described in the Ultimate Guide to NHIs and when they compare them with established workload identity practices in SPIFFE overview. For attack-path analysis, the 52 NHI Breaches Analysis is useful because many incidents hinge on static credentials surviving beyond the run that should have contained them.

Why It Matters in NHI Security

Run-scoped identity reduces the blast radius of compromised automation by making each execution separately accountable, but it only works if issuance, revocation, and logging are all aligned. Without that, a single leaked token can outlive the job that created it and silently become a reusable bearer credential. That is why NHI governance teams treat run scope as both an access-control and an observability problem.

This matters especially in environments where secrets are already poorly controlled. NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, including code, config files, and CI/CD tools. In that context, run-scoped identity can help break the pattern of long-lived credentials persisting across pipelines, which is a common precursor to lateral movement and unauthorized automation. It also complements CISA Zero Trust guidance by forcing each action to prove itself again rather than inheriting trust from a static workload label. Organisations typically encounter the need for run-scoped identity only after a pipeline credential leak or agent misuse, at which point session-level containment becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when pipeline identity is not scoped tightly enough?
• Why do autonomous agents increase identity risk when they run on employee devices?
• Terminal-scoped identity creation
• Task-Scoped Identity Boundary