What breaks when organisations use human IGA for non-human identities?

Why Human IGA Fails for Non-Human Identities

Human IGA is built around people: managers approve access, HR drives joiner-mover-leaver events, and periodic reviews assume a stable job role. That model breaks for service accounts, bots, API keys, and AI agents because they are created by pipelines, inherit access from code, and may never have a human owner who can attest necessity. The result is certification theatre, where existence is reviewed but usage, scope, and business need remain unknown.

This is not a theoretical gap. The NHI Management Group Ultimate Guide to NHIs reports that only 5.7% of organisations have full visibility into their service accounts, which means most teams are trying to govern identities they cannot reliably enumerate. NIST’s NIST Cybersecurity Framework 2.0 reinforces that identity governance has to support asset visibility, access control, and continuous risk treatment, not just periodic attestation. In practice, many security teams discover the mismatch only after a leaked secret, a dormant account is reactivated, or an automation chain has already expanded access beyond the original intent.

How It Works in Practice

Effective NHI governance starts by treating machine identities as workloads, not employees. That means cataloguing them by owner system, business function, runtime environment, credential type, and rotation policy. It also means separating human approval flows from machine lifecycle events: a CI/CD pipeline may create an API key, but a security control should still enforce scope, expiry, and revocation. Static RBAC alone is too blunt for autonomous systems because the same agent may need different permissions depending on task, context, and confidence level.

For that reason, current guidance suggests pairing least privilege with runtime checks such as JIT credential issuance, policy-as-code, and short-lived secrets. The core design goal is to reduce standing access and make privilege proportional to the specific action. Where available, workload identity standards such as SPIFFE/SPIRE and OIDC-based assertions help prove what the workload is, while policy engines such as OPA or Cedar can decide what it may do at request time. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations toward continuous governance rather than annual review cycles. For breach-driven evidence of why static credentials fail, the JetBrains GitHub plugin token exposure is a useful reminder that a single exposed token can become an organisation-wide trust problem.

• Assign an accountable system or service owner for every NHI, even when no human “user” exists.
• Issue secrets with short TTLs and revoke them automatically after task completion or pipeline termination.
• Review effective permissions, not just account presence, and alert on privilege drift.
• Prefer workload-bound identity over shared credentials so compromise is harder to reuse.
• Log runtime authorisation decisions so reviewers can see why access was granted, not only that it existed.

These controls tend to break down in legacy environments with shared service accounts, hard-coded secrets in CI/CD, and integrations that cannot support short-lived tokens.

Common Variations and Edge Cases

Tighter machine-identity control often increases engineering overhead, requiring organisations to balance operational speed against revocation discipline and auditability. That tradeoff becomes more visible in high-frequency automation, where a bot or agent may need dozens of ephemeral credentials across one workflow. Best practice is evolving, but there is no universal standard for every authorisation pattern yet, especially for multi-agent systems and deeply nested tool chains.

AI agents are the clearest edge case because they can behave autonomously, chain tools, and pursue goals in ways that defeat static role design. In those environments, intent-based authorisation is more useful than pre-defined access lists: the decision is made at runtime based on what the agent is trying to do, the risk of the action, and the current context. The JetBrains GitHub plugin token exposure shows how quickly a developer tool or integration token can become a broader compromise path. NIST’s NIST Cybersecurity Framework 2.0 supports the broader principle, while the stronger operational answer for agents is to combine Zero Trust thinking with policy evaluation at the moment of use.

The practical exception is system-to-system connectivity that cannot yet support workload identity or JIT secrets. In those cases, teams often have to wrap legacy access with compensating controls such as vaulting, segmentation, tighter monitoring, and aggressive rotation until the dependency can be modernised. Human IGA can still be a reporting input, but it should not be the control plane for non-human identities.

Related resources from NHI Mgmt Group

• What breaks when organisations cannot see their non-human identities?
• What breaks when organisations cannot see all of their non-human identities?
• What breaks when organisations try to govern non-human identities without lifecycle ownership?
• Why do AI agents make non-human identity governance harder?