Notifications
Clear all
Topic starter
06/06/2026 1:32 am
TL;DR: The governance gap is now behavioral, not just permission-based, because access review and audit logs do not capture intent or mid-session drift, according to Zenity. Zenity argues that IAM answers what an AI agent was allowed to access, but not whether its runtime behavior was appropriate, and shows how authorized agents can still trigger security incidents through prompt injection and destructive actions.
NHIMG editorial — based on content published by Zenity: The Authorization Trap, why your IAM controls don't cover AI agent risk
By the numbers:
- Machine identities now outnumber human identities at a ratio of 144 to one, up from 92 to one in the prior period.
- A January 2026 MDPI review synthesized 45 sources and documented real-world exploits, finding that indirect prompt injection in agentic systems is harder to detect through access controls alone.
Questions worth separating out
Q: How should security teams govern AI agents beyond standard IAM controls?
A: Security teams should keep IAM as the access baseline, but they need runtime controls that evaluate behaviour after authorization succeeds.
Q: Why do AI agents create risk even when they stay within approved permissions?
A: AI agents can be authorised correctly and still produce harmful outcomes because permission is not the same as intent or behavioural appropriateness.
Q: What signals show that an AI agent is operating outside its intended purpose?
A: Look for mismatches across identity, data, model behaviour, posture, and environment.
Practitioner guidance
- Map agent workflows to untrusted-content entry points Identify documents, calendar items, chat inputs, and other workflow sources that can alter agent behaviour after authentication.
- Correlate identity, data, model, posture, and environment signals Build a detection pipeline that joins who the agent is, what it touched, whether prompt injection was detected, whether its posture drifted, and whether the environment changed the risk profile.
- Review low-volume repetition as a breach pattern Look for repeated small retrievals, exports, or tool calls across many sessions.
What's in the full article
Zenity's full article covers the operational detail this post intentionally leaves for the source:
- The exact five-signal framework used to distinguish permitted access from appropriate runtime behaviour.
- The Cursor and PleaseFix examples in more incident context, including how the failure unfolded in practice.
- The way indirect prompt injection changes the risk profile of agent sessions without breaking the identity chain.
- The vendor's framing of why behavioural monitoring belongs alongside IAM in agent governance.
👉 Read Zenity's analysis of why IAM controls miss AI agent risk →
AI agent authorization gaps: what IAM teams are missing?
Explore further
06/06/2026 2:43 am
Authorization is not the same as appropriateness, and agentic AI exposes that gap immediately. IAM was designed to answer whether a principal could access a resource. It was not designed to judge whether an autonomous-seeming execution path remained appropriate after a session began. The practical implication is that agent governance cannot stop at entitlement state.
A few things that frame the scale:
- Machine identities now outnumber human identities at a ratio of 144 to one, up from 92 to one in the prior period, according to Ultimate Guide to NHIs.
- Another finding from NHI Mgmt Group research shows that 80% of organisations report AI agents have already acted beyond their intended scope, including access to unauthorised systems, sensitive data sharing, and credential exposure.
A question worth separating out:
Q: Who is accountable when an authorised AI agent causes a breach?
A: Accountability usually sits with the organisation that assigned the access, defined the workflow, and failed to instrument runtime oversight. The hard part is proving whether the failure was an entitlement decision, a workflow design issue, or a missing behavioural control, which is why governance ownership must span IAM, security engineering, and application teams.
👉 Read our full editorial: Authorization is not enough for AI agent risk governance
