They miss the operational reality that service accounts, API keys, tokens, certificates, and AI agents can hold powerful access and create exposure at scale. That gap leads to weak visibility, stale credentials, and excessive privilege. Mature programmes govern human and non-human identities together so risk decisions reflect how systems actually use access.
Why This Matters for Security Teams
identity security breaks down when organisations define it as a workforce IAM problem and ignore the machines, services, and autonomous agents that actually consume the most sensitive access. That blind spot leaves secrets scattered across pipelines, over-privileged workloads, and access paths that no HR-driven joiner-mover-leaver process will ever see. The risk is not theoretical: NHIMG’s Ultimate Guide to NHIs and 52 NHI Breaches Analysis show that non-human identities are now a primary attack surface, not an edge case. NIST SP 800-53 Rev. 5 also treats access control, audit, and credential management as core security functions, not workforce-only concerns. In the 2024 Non-Human Identity Security Report, 88.5% of organisations said their non-human IAM practices lag behind or merely match human IAM efforts, which is a strong signal that most programmes are still under-scoping the problem. In practice, many security teams discover this only after a token, API key, or service account has already been used to move laterally or pull data at scale, rather than through intentional inventory and governance.
How It Works in Practice
The practical fix is to govern identity by use and trust context, not by whether a subject is human. That means building one control plane for workforce identities, service accounts, secrets, certificates, and AI agents, then applying policy based on what is requesting access, from where, and for how long. A mature programme inventories NHIs, maps each one to an owner and business purpose, and removes standing access wherever possible. For workloads, current guidance suggests treating workload identity as the primary primitive and using short-lived cryptographic credentials instead of reusable long-lived secrets. Standards such as SPIFFE are useful here because they let teams assert what a workload is, while NIST SP 800-53 Rev. 5 supports the broader controls for least privilege, authentication, logging, and revocation.
For AI agents and automated pipelines, the model has to go further. Static RBAC often fails because an agent’s actions are goal-driven and variable, not fixed and repetitive. Intent-based or context-aware authorisation, evaluated at request time, is a better fit. That is where policy engines and runtime controls matter: approve the task, issue a JIT credential, constrain scope, monitor tool use, and revoke automatically on completion. NHIMG’s Azure Key Vault privilege escalation exposure illustrates how quickly secret sprawl and excessive permissions can turn into privilege escalation when access is not continuously governed. The control pattern is simple in concept but operationally demanding:
- discover all non-human identities and classify them by workload, pipeline, or agent function;
- replace static shared secrets with short-lived tokens, certificates, or ephemeral credentials;
- bind access to workload identity and runtime policy, not just a role name;
- centralise logging so machine-to-machine actions are attributable and reviewable;
- revoke access automatically when a job, deployment, or agent task ends.
These controls tend to break down in highly distributed multi-cloud environments where ownership is fragmented and credential issuance is embedded in dozens of build and runtime systems.
Common Variations and Edge Cases
Tighter control over non-human identities often increases operational overhead, so organisations have to balance stronger governance against deployment speed and platform complexity. The hard part is not agreeing that least privilege matters, but deciding how much runtime friction is acceptable for pipelines, ephemeral jobs, and agents that need to chain tools quickly.
There is no universal standard for AI agent identity governance yet, so best practice is evolving. For autonomous systems, the emerging pattern is to pair workload identity with real-time policy evaluation and narrow-scoped JIT access rather than rely on broad standing privileges. That approach is especially important when agents can call external tools, create follow-on tasks, or access third-party services through OAuth. NHIMG’s JetBrains GitHub plugin token exposure and JetBrains Marketplace AI Plugin Campaign are reminders that token exposure in developer ecosystems can cascade quickly into broader identity compromise. In mature environments, identity teams and platform teams share ownership, because treating NHIs as someone else’s problem usually means they are first addressed after secrets have already been copied into code, logs, or unmanaged integrations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity inventory and ownership are foundational when NHIs are treated as a separate risk class. |
| OWASP Agentic AI Top 10 | A-03 | Autonomous agents need runtime constraints, not static workforce IAM assumptions. |
| CSA MAESTRO | IAM | MAESTRO addresses identity and access controls for agentic and machine workloads. |
| NIST AI RMF | AI RMF governance applies when agents make access-relevant decisions autonomously. | |
| NIST CSF 2.0 | PR.AA-01 | Access control must cover machines and services, not just human accounts. |
Define ownership, monitoring, and escalation paths for any AI system that can use privileged access.
Related resources from NHI Mgmt Group
- What do security teams get wrong when they treat channel enablement as separate from identity governance?
- What do organisations get wrong when they treat partner enablement as a sales-only function?
- What do organisations get wrong when they treat identity verification as a pilot project?
- What do teams get wrong when they treat AI security as a detection-only problem?
