AI agent governance starts with identity, not model security

At a glance

What this is: This is a webinar briefing on enterprise AI agent governance, centered on the claim that security has to start with agents themselves rather than siloed model, identity, endpoint, or application controls.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern rapidly multiplying agent identities whose permissions, scope, and runtime behaviour can drift faster than conventional review and control cycles.

By the numbers:

• 74% of enterprises expect their organizations will have over 100 agents live by the end of 2026.
• 53% of participants noted that agents exceeded intended permissions or acted out of scope.
• 47% experienced a security incident involving an agent in the last year.

👉 Register for Zenity's June 15 live briefing on AI agent governance

Context

Enterprise AI agent governance is becoming an identity problem because agents do not stay inside one control plane. They span workflows, touch multiple tools, and can shift from one decision point to the next without fitting cleanly into model security, endpoint security, or application security alone. For IAM teams, that means the subject is no longer just AI risk, but the lifecycle and authority of the agent identity itself.

The webinar frames that gap around scale and control failure. As agent populations grow, organisations need to understand where existing governance assumptions break, especially when access is ephemeral, delegated, and distributed across systems that were designed to manage human users or static service accounts. That makes AI agent identity governance a practical programme issue, not a future architecture debate.

Key questions

Q: How should security teams govern AI agents that can act across multiple workflows?

A: Treat the agent as an identity with bounded authority, not as a model feature. Define its tool access, data reach, and workflow scope in one policy model, then monitor runtime behaviour for drift. If the agent can accumulate permissions across systems without a single owner, governance will fail at the handoff points.

Q: Why do AI agents complicate traditional IAM and PAM controls?

A: They complicate IAM and PAM because the access decision is no longer static. An agent can combine tools, choose actions, and move through workflows in ways that were not fully known at provisioning time, which makes entitlement reviews and privilege boundaries harder to certify. The control problem becomes runtime authorisation, not just access assignment.

Q: What breaks when siloed security teams each control only part of the agent stack?

A: What breaks is the ability to see total authority. Identity, model, application, and endpoint teams may each believe a control exists, but none of them can prove the agent's combined blast radius. When authority is split across domains, over-permissioned behaviour can persist until an incident exposes it.

Q: Who should be accountable for AI agent security incidents?

A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.

Background and context

Why siloed controls miss agent identity risk

Agents sit between models, tools, and workflows, which means no single security layer sees the full behaviour. Identity controls can know who or what was provisioned, endpoint tools can see device or runtime signals, and application controls can log actions, but none of them alone explain whether an agent should have combined those permissions in that sequence. That is why agent risk shows up as governance drift, not just access misconfiguration. The important distinction is that the control gap is cross-domain: the agent is not contained by a single boundary, so policy has to follow the identity across contexts.

Practical implication: Map agent permissions, tool access, and workflow scope in one control view rather than treating each security layer as a separate owner.

Agentic applications and the OWASP risk model

OWASP’s agentic application guidance matters because it treats agents as runtime actors with their own attack surface, not as passive applications with AI features. That changes the security question from whether the model is safe to whether the agent can be manipulated, over-scoped, or redirected while executing a task. In practice, this includes prompt injection, tool misuse, and unintended delegation paths, all of which are identity and authorisation problems as much as application issues. The value of the framework is that it helps practitioners model the chain from intent to action, rather than evaluating the model in isolation.

Practical implication: Use agent-specific threat modelling to test tool access, delegation paths, and approval boundaries before broad rollout.

Secure-by-design for agents needs runtime guardrails

Secure-by-design is often discussed as a development principle, but for agents it has to become an operational discipline. Once an agent is live, the question is whether its authority can be constrained, observed, and revoked as the task changes. If not, the organisation inherits an identity that can act outside the original design assumptions. That is why agent governance has to include entitlement scoping, runtime telemetry, and revocation paths that work at the speed of the agent, not at the cadence of quarterly review. Without that, secure-by-design remains a label rather than a control state.

Practical implication: Build runtime guardrails that can narrow, observe, and revoke agent authority while the agent is actively working.

NHI Mgmt Group analysis

AI agent governance is now an identity governance problem, not a model governance side issue. The article's core signal is that enterprises are putting agents into production faster than traditional control boundaries can describe their authority. When agents span workflows, model security alone cannot answer who or what has permission to act. Practitioners should treat agent identity as a first-class governance object.

Runtime scope drift is the failure mode this category now exposes. The article points to agents exceeding intended permissions and acting out of scope, which shows that static provisioning assumptions do not survive real execution. That is not just a missing control, it is a category of behaviour that existing review cycles are too slow to catch. Practitioners should re-evaluate whether their entitlement model can follow live agent behaviour.

Agentic application risk should be framed through OWASP-style attack paths, not generic AI assurance language. The relevant concern is not whether the model can reason, but whether the agent can be manipulated into using tools, chaining actions, or stepping outside policy. That makes prompt injection, tool misuse, and delegation abuse identity-adjacent failure modes, not abstract AI hazards. Practitioners should model agent security as a runtime authorisation problem.

Identity blast radius: the agent's effective risk is determined by how much combined tool and data access it can accumulate during execution. That concept matters because the article shows how consequential agents become once security is not purposefully considered. The more workflows an agent spans, the larger its blast radius becomes if permissions are not tightly bounded. Practitioners should design for narrow, auditable agent authority from the start.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly one identity failure can recur.
• That same governance pressure is why practitioners should pair 52 NHI Breaches Analysis with agent-specific control design, so breach patterns inform runtime policy rather than post-incident review only.

What this signals

Identity blast radius is becoming the right planning concept for agent programmes because access risk now scales with how many tools, datasets, and workflow steps an agent can chain together in one execution path. As agent populations grow, teams should expect governance to shift from periodic review toward continuous entitlement observation.

The structural lesson is that agent security cannot be bolted on as an adjacent AI initiative. Programmes that already struggle with NHI ownership, scope, and lifecycle will see the same issues accelerate when those identities become dynamic and business-critical. That is why practitioner readiness should be measured by control convergence, not by model accuracy or rollout speed.

For teams building policy around agents, the practical benchmark is whether access can be explained, limited, and revoked in the same language used for other high-risk identities. If the answer is no, the organisation has a governance gap that will widen as agent adoption passes into operational scale.

For practitioners

• Inventory every live agent identity Build a current register of all agents, the workflows they touch, and the tools and data sources they can reach. Include shadow AI and agent-like automations so governance starts from actual runtime exposure, not procurement records alone.
• Collapse siloed ownership into one control model Tie identity, application, endpoint, and model security into a single operating view for agents so permissions, logging, and revocation are evaluated together. Separate teams can still execute controls, but they need a shared source of truth for agent authority.
• Test for out-of-scope action chains Run scenario testing for prompt injection, tool misuse, and unintended delegation paths, then verify whether the agent can be pushed beyond its intended workflow. Use those tests to identify where approval gates and policy checks fail under real execution.
• Set revocation paths that work at runtime speed Ensure access can be narrowed or withdrawn while an agent is active, not only after a review cycle. That requires telemetry, policy enforcement, and entitlement boundaries that can respond before the task completes.

Key takeaways

• AI agents are now a governance problem for IAM and NHI teams because their runtime behaviour can exceed the assumptions built into static access models.
• CSA's survey shows the issue is already operational at scale, with most enterprises expecting 100-plus agents and many reporting out-of-scope behaviour or incidents.
• The control priority is not model reassurance, but a single identity view that can bound, observe, and revoke agent authority while it is in use.

Key terms

• AI Agent Identity: An AI agent identity is the set of credentials, permissions, and governance rules that let an agent act inside enterprise systems. Unlike a human identity, it may operate at machine speed across multiple tools, so scope, monitoring, and revocation must be defined for runtime behaviour as well as provisioned access.
• Runtime Scope Drift: Runtime scope drift is the condition where an agent's effective authority expands or changes during execution, beyond the access originally intended by the organisation. In practice, it appears when an agent chains tools, reuses permissions, or crosses workflow boundaries in ways that static reviews did not anticipate.
• Identity Blast Radius: Identity blast radius is the amount of damage or reach an identity can create if it is misused or over-scoped. For AI agents, the blast radius grows with each additional system, dataset, and tool the agent can touch during a task, which makes tightly bounded authority a core control objective.

Deepen your knowledge

AI agent governance and runtime identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is now dealing with agent sprawl, this is the right place to build the governance baseline.

This post draws on content published by Zenity: Securing Enterprise AI in Practice, with a focus on AI agent governance. Read the original.