They create risk because machine-speed workflows can combine APIs, secrets, and delegated authority faster than conventional review cycles can observe. That breaks assumptions built around human-paced approval, auditing, and recertification. The result is not just more access, but less clarity about which component exercised that access and whether it was still appropriate.
Why This Matters for Security Teams
AI infrastructure programmes change identity risk because they introduce software that can act, decide, and chain permissions faster than conventional governance can keep pace. A platform may look like a normal workload on paper while behaving like a delegated operator in practice, which makes static approval models and periodic recertification too slow to be reliable. NIST’s NIST Cybersecurity Framework 2.0 helps frame the control problem, but it does not remove the need to map which components can request, hold, and spend authority at machine speed.
That gap is already visible in the field. In the The 2026 Infrastructure Identity Survey, 70% of organisations said they grant AI systems more access than they would give a human employee doing the same job, and only 44% had policies to manage AI agents. NHI Management Group’s Top 10 NHI Issues also shows that lifecycle and ownership gaps are recurring failure points, not edge cases. In practice, many security teams discover identity sprawl only after autonomous tooling has already changed infrastructure or touched production secrets.
How It Works in Practice
The core governance shift is to treat AI infrastructure components as non-human actors with scoped, time-bound authority rather than as ordinary service accounts. Static RBAC still matters, but by itself it is too blunt for autonomous workflows because the same agent may need different access depending on the task, the data source, and the change being proposed. Current guidance suggests combining workload identity, just-in-time access, and runtime policy evaluation so the system proves what it is before it receives what it needs.
Practically, that means using cryptographic workload identity as the trust anchor, such as SPIFFE/SPIRE or OIDC-based workload tokens, then issuing ephemeral secrets only for the duration of a single action or session. Controls should be evaluated at request time, not only at onboarding, using policy-as-code engines such as OPA or Cedar to check context like purpose, data classification, environment, and approval state. This is especially important when agents can call tools, hand off subtasks to other agents, or trigger infrastructure changes without human pacing.
- Bind each agent or automation path to a distinct workload identity.
- Replace standing secrets with short-lived credentials and revocation on completion.
- Require policy checks at the moment of tool use, not just during provisioning.
- Log the acting identity, the parent task, and the resource touched for every change.
The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it maps governance to issuance, rotation, and retirement rather than to one-time registration. CSA’s MAESTRO model and the OWASP Top 10 for LLM Applications both reinforce that agentic systems need runtime controls, not just pre-approved entitlements. These controls tend to break down in loosely governed cloud estates where infrastructure-as-code, ad hoc service accounts, and shared automation tokens are still used interchangeably.
Common Variations and Edge Cases
Tighter identity control often increases operational overhead, requiring organisations to balance speed of automation against the cost of stronger governance. That tradeoff is real in fast-moving platform teams, where per-task credentials, approval callbacks, and policy checks can add friction if the workflow is not designed around them.
Best practice is evolving for hybrid environments. Some agents are fully autonomous, while others are effectively supervised automation with human escalation points. There is no universal standard for this yet, so governance should reflect actual autonomy level rather than vendor labels. A low-risk build agent, a production remediation bot, and a multi-agent planner should not share the same access model even if they use the same underlying model family.
One common edge case is inherited privilege through orchestration layers. A workflow may appear low risk at the agent layer but still inherit broad platform permissions from the scheduler, CI runner, or secrets manager. Another is human fallback paths, where manual break-glass access is introduced for exceptions and then quietly becomes standing access. The 52 NHI Breaches Analysis is a reminder that compromise usually follows weak lifecycle discipline and unclear ownership, not just weak passwords.
Where teams rely on shared credentials, long TTL tokens, or permissive service meshes, this guidance breaks down because it becomes impossible to tell which component exercised authority and whether the access was still appropriate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A10 | Agentic systems need runtime controls for tool use and delegated actions. |
| CSA MAESTRO | MAESTRO frames governance for autonomous workflows and multi-agent trust boundaries. | |
| NIST AI RMF | AI RMF addresses governance, accountability, and risk management for AI systems. |
Gate every agent action with request-time policy checks and task-scoped credentials.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
