TL;DR: Workload identity is shifting from theory to practice as teams replace hardcoded secrets, broaden definitions beyond service accounts, and add context-aware access controls, according to Aembit. The pressure is now on IAM programmes to govern machine access across lifecycle, policy, and deployment boundaries instead of treating secrets as the whole problem.
NHIMG editorial — based on content published by Aembit: ten workload identity trends reshaping access, automation, and control
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams replace static secrets in workload environments?
A: Start with the highest-value secrets in code, config files, and CI/CD pipelines, then move toward runtime-issued credentials that are scoped, short-lived, and tied to workload identity.
Q: Why do static credentials create so much risk for machine identities?
A: Static credentials are hard to track, easy to copy, and often survive long after the workload that used them has changed.
Q: What do security teams get wrong about workload identity governance?
A: They often stop at visibility and logging, then assume observability equals control.
Practitioner guidance
- Inventory every machine identity class Map service accounts, API keys, OAuth tokens, certificates, and workload federation into one governance inventory so ownership and lifecycle state are visible.
- Phase out hardcoded secrets in active paths Prioritise the applications and automation paths where secrets are embedded in code, config, or CI/CD pipelines, then move those paths to runtime-issued credentials.
- Define contextual policy for workloads Use host posture, environment, deployment location, and runtime attestation to decide whether a workload call should be allowed at the moment of access.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Specific implementation patterns for replacing hardcoded secrets in production workloads
- The article's migration tactics for moving legacy services toward short-lived credentials
- Examples of deployment models across VMs, Kubernetes, serverless, and proxy-based integrations
- Practical discussion of managed versus bring-your-own PKI decisions in real estates
👉 Read Aembit's analysis of ten workload identity trends shaping enterprise access →
Workload identity expansion: what IAM teams need to know now?
Explore further
Workload identity is no longer a secrets problem, it is an access governance problem. The article shows that teams are moving beyond hardcoded credentials toward short-lived tokens, policy enforcement, and lifecycle control. That shift matters because the real failure mode is not only leakage, but unmanaged persistence across environments. For practitioners, the important conclusion is that machine access has to be governed as an identity lifecycle, not a storage location.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How can organisations govern workloads across cloud and legacy systems?
A: Use a migration model that supports both modern and older applications, including pass-through, detection, and substitution paths. This avoids forcing a rip-and-replace approach and gives security teams a way to phase out brittle authentication while maintaining service continuity.
👉 Read our full editorial: Workload identity is expanding beyond secrets and service accounts