Treat identity issuance as part of the runtime control plane, not as a back-office approval task. If an autonomous workflow can create resources and the identities that govern them, security teams need guardrails on creation, scope, and expiry before the task completes.
What changes when identities are created at runtime?
When an autonomous workflow creates identities on the fly, the security boundary moves from approval workflow to runtime control. That means the system that launches the work must also constrain who or what gets an identity, what it can do, how long it lives, and how it is audited. Treating those decisions as part of execution reduces the chance that access outlives the task that needed it.
Ad hoc identity creation is not just an operational convenience. It can become a standing access path if creation rules are loose, ownership is unclear, or expiry is missing. The practical question is not whether the workflow can create an identity, but whether the platform can prove the identity was created for a specific task, with a bounded purpose, and with a clear revocation path.
In mature environments, this shifts design toward policy-driven issuance rather than manual exception handling. A workflow should request an identity through a controlled mechanism, receive only the minimum scope needed, and inherit enough metadata for later review. That makes the identity part of the system’s control plane, not an invisible side effect of automation.
How should creation, scope, and expiry be governed?
Start with issuance policy. Every on-the-fly identity should be created from a narrow set of approved templates or rules, so the workflow cannot silently invent broad permissions. Scope should be task-specific, environment-specific, and time-bounded, with default expiry that is shorter than the business task unless a human explicitly extends it.
Guardrails also need to define who owns the identity after creation. If no team owns rotation, review, and removal, the identity will persist beyond its intended use. This is where lifecycle discipline matters most: creation, update, use, and retirement must all be visible in the same governance path, even if the workflow is fully automated.
Practitioners should also separate identity issuance from privilege assignment. A workflow may need to create a resource identity quickly, but that does not justify broad action rights on day one. The safer pattern is to issue a minimal identity first, then elevate only after policy evaluation confirms the exact operation being performed.
Why do runtime identities create control and audit problems?
Runtime identities are harder to govern because they multiply quickly and can blend into normal automation noise. If they are not logged with a stable owner, a task reference, and a clear expiry signal, teams lose the ability to distinguish legitimate short-lived access from unintended persistence. That creates a hidden inventory problem as much as an access problem.
The other failure mode is scope creep. A workflow that is trusted to create its own identity can become a shortcut around access review unless the system enforces least privilege at creation time. The control weakness is not the existence of automation, it is the assumption that automation will self-limit without policy enforcement.
For practitioners, the audit requirement is simple: you should be able to answer who created the identity, why it existed, what it could access, and when it stopped being valid. If any one of those answers is weak, the identity is already too permissive for autonomous use.
Risk and Threat Considerations
autonomous identity creation increases exposure when the workflow can mint access faster than teams can inspect it. If the identity is over-scoped, long-lived, or poorly attributed, an attacker who compromises the workflow can inherit the same creation path and turn a convenience feature into an access factory.
Failure mechanism: The workflow creates identities with excessive privilege, missing expiry, or weak ownership, then those identities persist after the original task is complete or are reused by another process.
Impact: That can lead to privilege sprawl, difficult revocation, broader blast radius after compromise, and audit gaps that make it hard to prove whether access was legitimate.
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 NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime-created identities depend on controlled credential issuance and expiry. |
| AC-6 — Least Privilege | Autonomous workflows need scoped access that cannot exceed task needs. | |
| AU-2 — Event Logging | Traceable creation and use of ephemeral identities requires auditable records. | |
| Recommendation — Enforce lifecycle limits and rotation for every runtime-issued credential. Limit each new identity to the minimum permissions needed for the task. Log identity creation, scope, owner, and expiry for every automated issuance. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Per-request verification and no standing trust fit runtime identity issuance. |
| Recommendation — Require policy checks at creation time and again before each privileged action. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | On-the-fly identities fail when they gain broader permissions than the task needs. |
| Recommendation — Bind each newly created identity to the smallest viable permission set. | ||
Practitioner Guidance
What to verify: Confirm that every runtime-created identity has a bounded owner, a short default lifetime, and a policy record that explains the exact task it was created for. If you cannot trace those three items, the identity should be treated as incomplete provisioning rather than successful automation.
Decision rule: If the workflow can create identities without a policy check, stop and add a creation gate before expanding the automation. If the workflow can create identities only within a pre-approved template, focus next on tightening scope and expiry rather than blocking the automation outright.
Practitioner takeaway: The goal is not to eliminate autonomous issuance, but to make identity creation provably narrow, short-lived, and reversible before the workflow finishes its job.