Why do legacy identity stacks create more risk in AI-first environments?

Why This Matters for Security Teams

Legacy identity stacks were built for human users, stable endpoints, and predictable request paths. AI-first environments break those assumptions. Agents can call tools, chain actions, and generate new access paths at runtime, so authentication, authorization, and logging must work as a single control plane. When they do not, teams lose the ability to answer a basic question: what was this identity allowed to do, at the exact moment it did it?

That gap is not theoretical. NHI Management Group has documented that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a useful proxy for how fragmented identity oversight still is. NIST Cybersecurity Framework 2.0 treats identity and access as core governance concerns, but legacy stacks often implement them as separate products rather than one operational model. In AI-first environments, that separation creates blind spots around privilege, token reuse, and agent-to-agent trust.

In practice, many security teams encounter the real failure only after an agent has already chained permissions across tools, rather than through intentional identity design.

How It Works in Practice

The safer model for AI-first environments is to treat the agent as a workload identity, not as a proxy for a human account. That means using short-lived credentials, runtime authorization, and policy evaluation at the moment of use. Static RBAC can still describe coarse boundaries, but it is too blunt for autonomous systems whose actions are shaped by prompts, tool outputs, and changing context.

Operationally, this usually means combining workload identity, JIT provisioning, and real-time policy checks. A common pattern is to issue ephemeral tokens for a single task, bind them to a narrowly scoped workload identity, and revoke them automatically when the task ends. Standards such as SPIFFE and Open Policy Agent help teams separate proof of identity from the policy decision itself. NIST AI Risk Management Framework and NIST CSF 2.0 both support this direction by emphasising governable, auditable decision-making rather than blanket trust.

That is also where NHI discipline matters. The Ultimate Guide to NHIs highlights how excessive privilege and poor rotation remain common, and those problems become more dangerous when the identity is an autonomous agent rather than a batch job. AI systems can also create indirect access paths through plugins, APIs, and chained tools, which means the control point must move from fixed entitlement review to runtime authorisation. Current guidance suggests policy-as-code, context-aware approval, and automatic secret expiry as the minimum viable baseline. These controls tend to break down in heavily federated environments where separate teams own auth, secrets, and observability because policy context is lost between systems.

• Use workload identity for the agent itself, not a shared service account.
• Issue per-task credentials with short TTLs and automatic revocation.
• Evaluate policy at request time using task context, data sensitivity, and tool scope.
• Log the full decision path so security teams can reconstruct what the agent attempted, not just what succeeded.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance faster agent execution against stronger containment. That tradeoff is real, especially when teams want low-latency automation across multiple systems. There is no universal standard for this yet, so best practice is still evolving around how much context an authoriser should inspect and how much autonomy an agent should retain.

One common edge case is delegated access, where an agent needs to act on behalf of a person for a narrow workflow. In those cases, the identity model should preserve clear delegation boundaries rather than collapsing the agent into the human’s account. Another is multi-agent orchestration, where one agent supplies context and another executes a tool call. Without strict separation of identities and permissions, lateral movement can occur inside the workflow itself. The OWASP OWASP NHI Top 10 and Top 10 NHI Issues are useful reminders that the risk is not just credential theft, but uncontrolled behaviour under partial trust.

Teams also need to be careful with “one-time” secrets that are not actually one-time in practice. If revocation, audit, and propagation are delayed, a short-lived token can still become a durable foothold. The 2025 lessons are clear: identity stacks fail in AI-first environments when they preserve human-era assumptions about stable users, stable devices, and stable intent.

Related resources from NHI Mgmt Group

• Why do AI infrastructure programmes create new identity governance risk?
• Why do shadow AI tools create identity governance risk?
• Why do non-human identities create audit risk in modern environments?
• Why do mislabeled files create risk in AI governance programs?