Organisations should govern all three through one identity model, but with actor-specific controls for provisioning, review, and revocation. Human access still relies on authentication and lifecycle processes, machine identities need secret and credential governance, and AI agents need runtime authority boundaries. The goal is consistent ownership and auditability across different actors.
Why This Matters for Security Teams
One programme is the right answer because the attack surface is shared, even when the actors are not. Humans, service accounts, workloads, and AI agents all end up calling the same APIs, reaching the same data, and triggering the same business processes. The failure mode is usually organisational: separate teams, separate inventories, and separate approval paths that leave gaps between identity, secrets, and runtime authority. NHIMG’s The State of Secrets in AppSec shows how fragmented secrets management already is, and that fragmentation becomes more dangerous when autonomous systems can act on those secrets.
For governance to work, the programme has to treat each actor through the same control plane while still recognising different assurance needs. Humans need strong authentication, joiner-mover-leaver processes, and access review. Machines need workload identity, secret rotation, and tight lifecycle control. AI agents need bounded execution, runtime policy checks, and revocation that happens after the task, not at the next quarterly review. That aligns with current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, both of which emphasise identity visibility, least privilege, and lifecycle control across non-human access. In practice, many security teams discover the overlap only after a leaked secret or over-permissioned agent has already crossed from one actor class into another.
How It Works in Practice
The practical model is a single identity governance programme with actor-specific policy paths. That means one inventory, one ownership model, one audit trail, and different enforcement rules depending on whether the subject is human, machine, or AI agent. Human identities stay anchored in workforce IAM and MFA. Machine identities should be tied to workload identity rather than hard-coded secrets, using cryptographic proof of what the workload is, not just what credential it holds. For AI agents, the more relevant boundary is task scope and runtime authorisation, not a static role that assumes predictable behaviour.
In implementation terms, organisations usually combine these controls:
- Humans: identity proofing, MFA, RBAC or attribute-based access where appropriate, and periodic access reviews.
- Machines: short-lived tokens, certificate lifecycle management, secret scanning, and rotation enforced by policy.
- AI agents: JIT credentials, per-task entitlements, explicit tool allowlists, and runtime policy evaluation before each action.
Current guidance suggests that agentic systems should not inherit broad standing access simply because they were launched by a trusted user. The safer pattern is to issue an ephemeral credential or token only for the requested task, then revoke it on completion. That approach is consistent with the direction of the NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework, which both push organisations toward context-aware control and explicit governance of AI behaviour. NHIMG’s OWASP NHI Top 10 also reinforces the need to manage identity and credentials as runtime attack surfaces, not just administrative records. These controls tend to break down in event-driven architectures with many chained microservices because each hop creates a new opportunity for privilege to expand faster than review processes can follow.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, so organisations have to balance visibility and containment against deployment speed. That tradeoff is most visible when human and machine identities are embedded in the same CI/CD pipeline, or when an AI agent needs to call both internal tools and external SaaS services in a single workflow. In those cases, best practice is evolving rather than settled, especially around whether an agent should receive its own NHI record, borrow the invoking user’s entitlements, or operate through a brokered service account.
The safest pattern is to avoid credential sharing across actor types. If a developer approves an agentic workflow, that approval should not translate into a reusable long-lived token for the agent. Likewise, a service account used for batch processing should not be repurposed as a surrogate for a human approver. Where a programme does allow delegation, there should be explicit provenance, constrained scope, and short TTLs, with audit logs that show which actor triggered which action. NHIMG research on AI LLM hijack breach and Top 10 NHI Issues illustrates why broad credentials and unclear ownership remain recurring failure points. The model is strongest when the programme is unified, but the control decisions remain actor-specific and continuously evaluated.
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 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived credentials and rotation are central to governing machine identities. |
| OWASP Agentic AI Top 10 | Agentic systems need runtime boundaries, not static access assumptions. | |
| CSA MAESTRO | MAESTRO addresses governance and threat modeling for autonomous agents. |
Replace standing secrets with short-lived, auditable credentials and enforce automatic rotation.
Related resources from NHI Mgmt Group
- How should organisations govern human, NHI, and AI agent access in one programme?
- How should security teams govern human, NHI, and AI-assisted access in one programme?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
