Start by separating identity behaviour, then unify reporting and policy intent only where the controls genuinely overlap. Humans need authentication and access review discipline, machine identities need secrets, certificate, and lifecycle control, and AI agents need runtime entitlement boundaries. A single programme can cover all three, but it must not force identical enforcement patterns onto different identity types.
Why This Matters for Security Teams
One programme can govern human, machine, and AI agent identities, but only if it respects that each identity type behaves differently under load, risk, and change. Humans need authentication, approval, and access review discipline. Machine identities need secrets, certificate, and lifecycle control. AI agents need runtime boundaries because their tool use changes by task, prompt, and context.
The practical risk is cross-contamination: teams build one control model, then apply it everywhere, which either weakens humans with machine-style automation or over-restricts agents with static access rules that do not fit their behaviour. Current guidance from NIST Cybersecurity Framework 2.0 and NHIMG lifecycle guidance for NHIs points toward shared governance, not shared enforcement. That distinction matters because governance is the common layer, while the control pattern must still follow identity behaviour.
In practice, many security teams encounter identity sprawl only after an audit failure or an incident has already exposed the mismatch between policy intent and actual enforcement.
How It Works in Practice
Start by defining a common identity governance model with three lanes: human, machine, and agent. The shared layer should cover inventory, ownership, risk tiering, policy exceptions, logging, and reporting. The enforcement layer should differ by identity type. For humans, that usually means SSO, MFA, RBAC, and periodic access reviews. For machine identities, it means certificate and secret lifecycle management, rotation, and workload attestation. For agents, it means runtime authorisation, scoped tool access, and short-lived credentials tied to task context.
For AI agents, static IAM breaks down because the agent’s effective privilege is not fixed. A policy written for a known human role cannot safely model an autonomous workflow that can chain tools, pivot across systems, or request new permissions mid-task. Best practice is evolving toward intent-based or context-aware authorisation, where decisions are evaluated at request time using policy-as-code and workload identity. That is why standards work such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework emphasize runtime governance, traceability, and bounded autonomy.
- Use a single identity inventory, but tag each record by type, owner, purpose, and TTL.
- Assign humans to approval and review workflows, machines to secret and certificate hygiene, and agents to task-scoped entitlements.
- Prefer ephemeral tokens and workload identity for agents rather than long-lived shared secrets.
- Evaluate policy at execution time, not only at onboarding time.
NHIMG research on The State of Non-Human Identity Security shows that credential rotation, monitoring, and over-privilege remain major attack drivers, which is exactly why one programme needs separate control paths. These controls tend to break down when legacy applications require static shared credentials because there is no clean place to enforce per-task identity or revocation.
Common Variations and Edge Cases
Tighter identity governance often increases operational overhead, requiring organisations to balance stronger control against deployment speed and application compatibility. That tradeoff is most visible in legacy environments, shared service accounts, and vendor integrations where short-lived credentials or per-request policy checks are hard to retrofit.
There is no universal standard for one blended control model yet. Current guidance suggests keeping the policy intent unified while allowing enforcement to diverge. In practice, that means one set of reporting metrics for risk, ownership, and exceptions, but separate control baselines for humans, machines, and agents. For example, a human may be removed through access recertification, a service account through secret rotation, and an AI agent through revocation of its workload token or tool grant.
Edge cases also matter. Shared platform identities, API gateways, and delegated admin tools can blur the line between machine and agent. In those cases, security teams should treat the identity according to its behaviour at runtime rather than its label in a directory. The most useful reference point is often NHIMG’s AI LLM hijack breach coverage, which illustrates how quickly credentials and autonomy become exploitable once an agent can act on behalf of a broader system. This is also where the CSA MAESTRO agentic AI threat modeling framework is especially useful for deciding whether a control failure belongs in identity, policy, or orchestration. The hard part is not naming the identity type correctly, but stopping one control model from pretending all three types behave the same way.
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 | Covers lifecycle and rotation discipline for machine identities and secrets. |
| OWASP Agentic AI Top 10 | A1 | Agentic systems need runtime boundaries, not static role assumptions. |
| CSA MAESTRO | MAESTRO addresses governance and threat modeling across autonomous agent workflows. |
Inventory non-human identities, enforce rotation, and revoke stale secrets on a fixed lifecycle.
