Notifications
Clear all
Topic starter
24/07/2026 4:09 pm
TL;DR: AI agents are spreading across homegrown, SaaS, and developer environments, but most teams still govern them as if they were service accounts and API keys, according to Noma Security. That model misses runtime delegation, ownerless agents, and tool-chaining behaviour that makes identity control and accountability materially harder.
NHIMG editorial — based on content published by Noma Security: AI Agent Identity & Access Control: Everything You Need to Know
By the numbers:
- Companies we work with typically discover 10 to 100 times more of these agents than they expected.
Questions worth separating out
Q: How should security teams govern AI tools that inherit user permissions on endpoints?
A: Treat each OAuth-connected assistant, plug-in, or local model as a non-human identity with delegated authority.
Q: Why do AI agents create more identity risk than ordinary SaaS integrations?
A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight.
Q: What breaks when agent access is approved but never monitored at runtime?
A: A registry can confirm that access was allowed, but it cannot show whether the session used that access safely.
Practitioner guidance
- Inventory all agent entry points Map homegrown platforms, SaaS builders, and developer copilots separately so you can see where agents exist, who owns them, and which systems they can reach.
- Separate maker credentials from user delegation Reject shared builder identity patterns and require the current user's scope to control what the agent can do on each tool and each session.
- Trace the full delegation chain Record who created the agent, who shared it, which tools it can invoke, and whether any sub-agent inheritance expands access beyond the original approval.
What's in the full article
Noma Security's full article covers the operational detail this post intentionally leaves for the source:
- Environment-by-environment examples across homegrown agents, SaaS agent builders, and coding assistants.
- Operational discussion of discovery, access control, and runtime behavioural detection working together.
- Concrete guidance on tracing ownership, delegation, and tool paths across agent sessions.
- Examples of the highest-risk prebuilt agent surfaces and why they should be prioritised first.
👉 Read Noma Security's analysis of AI agent identity and access control →
AI agent identity and the governance gap teams are missing?
Explore further
24/07/2026 4:14 pm
AI agent identity is creating a governance class that service-account thinking cannot fully absorb. Static NHI controls assume a workload will behave consistently enough for provisioning, review, and revocation to keep pace. The article shows that agents can change behaviour at runtime, chain tools, and delegate work without a human rewriting the policy in real time. The implication is that identity governance now has to treat runtime choice as part of the identity problem, not as an application detail.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how weak the discovery baseline still is for non-human identity governance.
A question worth separating out:
Q: How can organisations reduce risk from shadow AI agents already inside the enterprise?
A: Organisations should combine continuous scanning, access reduction, and credential revalidation for any agent found outside formal governance. The priority is to move unknown agents into a managed state, then decide whether they are sanctioned, constrained, or removed. That sequence is more effective than waiting for a full platform redesign.
👉 Read our full editorial: AI agent identity is outgrowing service account governance
