Execution Identity

What an execution identity is

An execution identity is the non-human runtime actor that actually carries out work, such as a Terraform role, Kubernetes controller, or CI/CD service account. The practical question is not who approved the action in theory, but which identity performed it in production, because that is the identity that can retrieve, use, or decrypt secrets.

That runtime focus makes execution identity a control boundary, not just a naming convention. It helps separate the human who requested a change, the platform component that orchestrated it, and the identity that ultimately exercised access against infrastructure, APIs, or secret stores.

Why execution identity matters for secret access

Execution identity becomes important whenever access to secrets, keys, certificates, or tokens is mediated by automation. The component that succeeds in authenticating at runtime is the one that can expose or decrypt sensitive material, so the effective security posture depends on the privileges and trust attached to that identity, not only on the workflow that launched it.

This is why teams often discover that the real access path is narrower or broader than the deployment diagram suggests. A pipeline may be designed for change delivery, but if its execution identity can read production secrets, then compromise of that automation path can become direct production access.

In practical terms, execution identity is where authorization meets runtime reality. It is the identity that determines whether a controller can reconcile resources, whether a deployment job can fetch a signing key, and whether a cloud task can decrypt environment secrets before the application starts.

How execution identity is governed across platforms

Different platforms implement execution identity differently, but the governance problem is the same: define which runtime identities exist, what they are allowed to do, and how their access is issued and removed. In Kubernetes this may be a controller or service account; in infrastructure-as-code it may be a role assumed by automation; in CI/CD it may be a pipeline credential tied to a deployment stage.

Good governance also means distinguishing execution identity from human access paths. Human administrators may need broad operational authority, but execution identities should usually be narrower, more deterministic, and easier to audit. When those boundaries blur, automation begins to inherit privileges it does not actually need.

For a broader view of how organisations structure identity governance across human, non-human, and AI agent identities, see Identity Security Programme Guide. For the adjacent IAM decisions around provider choice, lifecycle, and NHI support, the IAM and Identity Provider Buyer's Guide is a useful companion.

How to reason about runtime authority and secret exposure

The key analytical step is to trace the path from execution to sensitive action. If an identity can read a secret at runtime, decrypt an artifact, or call a privileged API, then that identity is part of the effective trust chain even if it is hidden from end users. Least privilege, short-lived access, and explicit scoping matter because the identity is only as safe as the permissions available during execution.

That logic also explains why reuse is risky. If the same execution identity is reused across environments, services, or pipelines, compromise in one context can spill into others. Strong separation between build, deploy, and operate identities reduces the blast radius when automation is misused or compromised.

Where organisations want a more concrete risk catalogue for non-human identities, the Top 10 NHI Issues provides a useful starting point. For platform hardening patterns that affect runtime authority and delegation, the Active Directory and Entra ID Hardening Guide helps connect identity design to operational control.

How execution identity shapes investigation and audit

When something accesses a secret or performs a privileged action, investigators should ask which execution identity was active at the moment of execution. That identity can clarify whether the event came from a legitimate automation path, a misconfigured workload, or a compromised runtime context.

Auditability improves when execution identities are explicit, consistently named, and tied to a clear owner and lifecycle. That makes it easier to answer who had effective access, which automation path used it, and whether the permissions still matched the task being performed.

For cloud runtime identity patterns, especially where workloads authenticate to each other, the SPIFFE workload identity specification is a strong external reference. For security teams mapping runtime access to detection and response, MITRE ATT&CK Enterprise Matrix is helpful for thinking about credential access, privilege escalation, and lateral movement once an execution identity is abused.

Related resources from NHI Mgmt Group

• Execution (MITRE ATT&CK Tactic)
• What should organisations do first to close identity execution gaps?
• How can security teams reduce risk from manual identity execution?
• How should teams reduce identity risk after application code execution exposure?