When should organisations move from managing secrets to issuing dynamic identity for workloads and agents?

Organisations should move when static secrets become difficult to rotate, audit, and contain across distributed systems. Dynamic identity issuance is especially useful for ephemeral workloads, multi-cloud deployments, and AI agents that need time-bound access. It reduces reliance on stored credentials, improves revocation, and creates a cleaner control point for policy enforcement and monitoring.

Why This Matters for Security Teams

Static secrets work until scale, sprawl, and automation make them a liability. Once workloads are distributed across cloud accounts, CI/CD pipelines, and agentic systems, the real problem is not just credential storage but trust continuity. A secret can be copied, reused, and forgotten. A dynamic workload identity can be issued, constrained, observed, and revoked in context. That shift matters because machine identities already outnumber human ones in many environments, and NHIMG’s research notes that 69% of organisations now have more machine identities than human ones in The Critical Gaps in Machine Identity Management report.

The practical trigger is usually operational pain: expired certificates, unclear ownership, duplicate credentials, and weak revocation discipline. Static secrets also create a poor control surface for modern policy enforcement because the secret itself says nothing about the workload’s runtime state, intent, or location. Frameworks such as SPIFFE workload identity specification and the NIST AI Risk Management Framework both reflect the direction of travel: identity should be issued and evaluated as a living control, not a static artifact. In practice, many security teams encounter this only after a leaked token, failed rotation, or agent misuse has already expanded the blast radius.

How It Works in Practice

The move from secrets to dynamic identity starts by treating the workload, not the server, as the subject of trust. For standard services, that often means issuing short-lived X.509 or OIDC-based identities bound to a cryptographic attestation layer. For AI agents, the same idea applies, but runtime context becomes even more important because the agent may chain tools, change objectives, or request new permissions mid-task. Current guidance suggests using workload identity for proof of what the system is, then layering policy decisions on top of what it is trying to do.

In operational terms, the control path usually looks like this:

• Establish a workload identity anchor such as SPIFFE/SPIRE or equivalent federation.
• Issue ephemeral credentials only when a task is requested, and keep the TTL as short as the use case allows.
• Evaluate authorization at request time with policy-as-code, rather than relying only on pre-defined role maps.
• Bind sensitive actions to task context, such as environment, destination service, data class, or agent goal.
• Revoke credentials automatically on task completion, failure, or anomaly detection.

This model aligns well with NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, especially where ownership and lifecycle controls are the real weak point. It also fits the direction of the OWASP Top 10 for Agentic Applications 2026, which emphasizes runtime risk in autonomous systems. These controls tend to break down when legacy applications require shared, long-lived secrets across batch jobs, air-gapped systems, or vendor integrations that cannot yet consume federated identity.

Common Variations and Edge Cases

Tighter identity controls often increase integration overhead, requiring organisations to balance shorter-lived credentials against application compatibility and operational maturity. That tradeoff is real, especially where certificate handling, service meshes, or cross-account federation are still immature. Best practice is evolving, but there is no universal standard for replacing every secret with dynamic identity on day one.

Some environments justify a hybrid model. Legacy systems may still need a stored secret temporarily, while the surrounding orchestration layer uses dynamic identity for access, logging, and revocation. Regulated environments may also require additional evidence trails, so identity issuance must be paired with monitoring and asset inventory. NHIMG research shows how severe the visibility problem can be, including 57% of organisations lacking a complete inventory of their machine identities in The Critical Gaps in Machine Identity Management report and 44% of NHI tokens being exposed in the wild in The 2025 State of NHIs and Secrets in Cybersecurity.

For autonomous agents, the bar is higher because behaviour is less predictable than conventional services. That is why the combination of NIST AI Risk Management Framework, CSA MAESTRO agentic AI threat modeling framework, and OWASP Non-Human Identity Top 10 is most useful when identity issuance, policy evaluation, and monitoring are designed together. The common failure mode is assuming dynamic identity alone solves the problem when the real gap is weak task scoping, weak ownership, or uncontrolled agent tool access.

Related resources from NHI Mgmt Group

• When should organisations prioritise secrets management over other identity controls?
• Why do organisations struggle to keep secrets management and non-human identity governance under control as environments expand?
• When should organisations move from vault-based secrets to workload identity?
• How do organisations move from secrets management to identity-based authentication?