Notifications
Clear all
Topic starter
24/07/2026 4:08 pm
TL;DR: AI agents share ownership, review, and delegation patterns with human identities, while still requiring dedicated machine identities, vault-based secrets, and least privilege, according to Noma Security. The governance gap is that runtime behaviour, delegation chains, and session-level manipulation cannot be handled by either human IAM or service account models alone.
NHIMG editorial — based on content published by Noma Security: AI Agent Identity Governance: What Belongs to Users, What Belongs to Services?
Questions worth separating out
Q: How should security teams govern AI agents that inherit authority from other identities?
A: Security teams should govern AI agents by tracking identity lineage, not just credentials.
Q: Why do AI agents complicate least-privilege access?
A: AI agents can change their path to a goal, so a role that looks narrow at provisioning time may still be too broad at runtime.
Q: What do security teams get wrong about delegation in AI agent workflows?
A: They often assume a delegation chain is just a workflow detail.
Practitioner guidance
- Define a separate agent identity model Classify each agent as a non-human identity with an explicit owner, scoped purpose, and revocation path.
- Bound every delegation chain Document which identity is used at each hop in a multi-agent workflow, including parent agent, sub-agent, and downstream tool.
- Shift elevation to session scope Issue just-in-time access for task-scoped elevation and expire credentials when the task completes.
What's in the full article
Noma Security's full post covers the operational detail this post intentionally leaves for the source:
- A more granular breakdown of how owners, approvers, and revocation responsibilities should be assigned across agent workflows.
- Specific guidance on how to structure delegation chains so sub-agents do not inherit more authority than intended.
- Examples of how just-in-time access can be scoped to task completion rather than static account permissions.
- The article's full discussion of runtime policy enforcement and how it differs from provisioning-time governance.
👉 Read Noma Security's analysis of AI agent identity governance and runtime delegation →
AI agent identity governance: what belongs to users, what belongs to services?
Explore further
24/07/2026 4:13 pm
AI agent identity is neither a user problem nor a service account problem alone. Agents inherit the accountability expectations of human identity and the authentication patterns of NHI, but they also introduce runtime behaviour that static IAM models do not describe cleanly. That makes hybrid governance the correct baseline, not an edge case. Practitioners should stop trying to force agents into a single legacy identity category.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: AI agent identity governance needs a hybrid model, not a user clone
