An identity model that treats each execution of an agent, workflow, or CI job as a distinct security subject. This matters when the same non-human actor can behave differently per invocation, so access and audit need to follow the run rather than only the underlying principal.
What Run-level Identity Changes
Run-level Identity treats each invocation as the security subject, not just the underlying principal. That shift matters because a single agent, workflow, or CI job can execute many times with different purpose, context, data, approvals, and audit expectations.
Instead of asking only “which identity launched this system,” the model asks “which run is doing the work right now.” That distinction is useful when the same automation framework reuses credentials, but each execution should still be isolated, traceable, and governed on its own terms.
Why Run-level Identity Exists
The core problem is that a stable principal does not always describe a stable security boundary. A workflow may run under one service account, yet each run can carry a different ticket, dataset, target environment, or approval trail. Run-level Identity makes those differences visible.
This is especially important for ephemeral automation, where the security question is not merely who owns the automation, but which specific invocation created an action, touched a secret, or accessed a privileged tool. NHIMG’s Ultimate Guide to NHIs is useful background for the broader identity model that run-level thinking extends.
Run-scoped identity also helps separate one execution from another for audit, approval, and incident review. NHIMG’s NHI Lifecycle Management Guide supports this lifecycle view by showing why provisioning, rotation, offboarding, and visibility all need to be tied to identity governance.
Where Run-level Identity Shows Up
Run-level Identity appears in CI pipelines, automation jobs, orchestrated workflows, scheduled tasks, and agent executions. In each case, the run may need its own traceability even when the platform uses a shared underlying identity to start the process.
The concept is also relevant when one execution should not inherit another execution’s assumptions. A build run, a deployment run, and a remediation run may share tooling, but they should not share history, permissions, or audit meaning unless that has been explicitly designed.
That is why run-level identity is often discussed alongside workload identity, ephemeral access, and environment segregation. A good reference point for the wider control landscape is Ultimate Guide to NHIs, Standards, which places identity controls in context with workload and trust frameworks.
How Run-level Identity Affects Control and Audit
When the run is the subject, access decisions become more granular. A run may be allowed to read one secret, call one API, or deploy to one environment, while the next run receives a different entitlement profile based on its inputs or approval state.
Audit also becomes more precise. Instead of recording only that “the bot did it,” the record can show which run, from which trigger, with which context, under which policy, and for which outcome. That makes investigations, replay, and exception handling far more defensible.
Run-level thinking also reduces overbroad reuse. If a platform cannot distinguish runs, it is easier for privileges, secrets, and logs to blur together. NHIMG’s Top 10 NHI Issues is a strong companion for understanding how reuse, excessive permissions, and weak lifecycle handling create identity risk.
Risk and Threat Considerations
Run-level Identity reduces ambiguity, but it also exposes a common weak point: when organisations keep treating all invocations as one identity, they lose the ability to spot misuse, overprivilege, or unauthorized reuse across runs. That can make a compromised automation path look normal until damage has already spread.
Failure mechanism: Shared principals, long-lived credentials, or coarse audit trails collapse distinct executions into one control plane record, which hides privilege creep, makes attribution unreliable, and weakens containment after compromise.
Impact: Attackers or faulty automation can reuse the same execution path across multiple runs, increasing the chance of secret exposure, unauthorized tool use, lateral movement, or false confidence in post-incident review.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Run-level identity concerns authenticating distinct non-human executions |
| AU-2 — Event Logging | Run-level identity depends on execution-specific audit events and attribution | |
| AC-6 — Least Privilege | Run-scoped access should limit what each execution can do | |
| Recommendation — Bind each run to a verifiable identity context and separate it from other executions. Log each run with unique execution context, inputs, and outcomes. Constrain each run to the minimum permissions required for that invocation. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Run-level identity is an IAM pattern for governing distinct execution subjects |
| Recommendation — Model each execution as a governed identity subject within IAM controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Run-level identity addresses overbroad permissions across repeated executions |
| Recommendation — Scope permissions per run to avoid inherited overprivilege across executions. | ||
Practitioner Guidance
Why practitioners should care: The practical question is whether your automation platform can prove what a specific run was allowed to do, not just which service account started it. If the answer is no, your audit story and your containment story are both weaker than they appear.
Common misunderstanding: Teams often assume that a stable service identity is enough. In practice, the run often needs separate context, logging, and authorization boundaries so that approval, execution, and review remain distinguishable.
Practitioner takeaway: Use run-level identity whenever the execution itself changes the security meaning of the action, especially for ephemeral, high-impact, or highly automated workflows.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- What breaks when an AI identity has production-level privileges but no clear owner?
- What breaks when identity controls stop at table-level permissions?
- What breaks when an agent spawns subagents without chain-level identity tracking?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org