AI agent governance starts with identity, not model security

At a glance

What this is: This is a Zenity webinar preview arguing that AI agent governance fails when teams start with model security instead of identity, with survey data showing scope creep and agent-related incidents are already common.

Why it matters: It matters because IAM, PAM, and security architects need to govern agent permissions, delegation, and lifecycle controls before agent scale turns out-of-scope behaviour into routine operational risk.

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.

Context

AI agent governance breaks when teams assume model security can absorb identity risk. Agents can act, delegate, and call tools across workflows, which means permissions and trust relationships become the control plane that decides whether behaviour stays bounded.

Zenity frames the problem as an enterprise governance issue rather than a pure AI safety issue. The survey figures point to a category that is already operating at scale, with incidents and permission drift showing up before many programmes have defined ownership, review, and containment.

Key questions

Q: What breaks when AI agents are not governed at runtime?

A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.

Q: Why do AI agents create new access risk for enterprises?

A: AI agents create access risk because they can operate with delegated authority while processing untrusted inputs. If prompts, tools, or permissions are abused, the agent may expose data or trigger actions faster than a human reviewer can intervene. The risk is not only compromise, but overreach built into the design.

Q: What are the signs that an agent governance programme is failing?

A: Common signals include unknown agents in staging or production, unvetted MCP connections, broad or long-lived credentials, and logs that show service-account activity without clear ownership. If the security team cannot map the agent to a tool chain and accountable owner, governance is already behind the deployment.

Q: How should security teams compare model security and identity governance for agents?

A: Model security reduces unsafe outputs, but identity governance determines whether the agent is allowed to act at all. They address different failure modes. If the article of record is operational control, identity and delegation need to lead; if the concern is content generation or prompt abuse, model controls matter more.

Background and context

Why agent permissions become the real attack surface

An AI agent is not just a model prompt wrapped in software. Once it can select tools, move across workflows, and operate with delegated access, the effective security boundary shifts from the model to the identity that authorises those actions. That is why intended permissions matter more than model confidence scores. If governance starts with the model alone, teams miss the real control surface: what the agent can reach, when it can reach it, and whether that access is still valid after the task changes.

Practical implication: govern agent access as an identity and entitlement problem, not as a model-hardening exercise.

Why siloed security tools miss ephemeral agent behaviour

Traditional model, endpoint, application, and network controls each see only part of the agent lifecycle. An agent can cross those boundaries quickly, creating an ephemeral attack surface that may exist only for a single task or interaction chain. That makes static policy enforcement and delayed review weak fits. The technical issue is not just visibility, but timing. If authorization is granted too broadly at startup, the security stack may never observe the exact moment when the agent acts out of scope.

Practical implication: align controls to issuance time and runtime authorization, not to post-hoc detection alone.

Why agentic applications need their own threat model

Agentic applications behave differently from conventional apps because they combine reasoning, delegation, and tool use into one execution flow. Frameworks such as OWASP Top 10 for Agentic Applications matter because they map risk to the actual behaviours that create harm, including tool misuse, identity abuse, and cascading failures between agents and connected systems. For practitioners, the relevant question is not whether the model is safe in isolation. It is whether the surrounding application can prevent an agent from turning normal enterprise integrations into an unintended action chain.

Practical implication: model agent risk through the application and delegation path, not through the model layer alone.

NHI Mgmt Group analysis

Identity, not model quality, is the primary governance layer for AI agents. Model security can reduce some classes of abuse, but it does not answer the central question of who or what is authorised to act. Once an agent can invoke tools and traverse workflows, governance must start with identity, delegation, and entitlement scope. The practitioner conclusion is simple: if the access model is wrong, the model quality does not matter.

Agent governance fails when permissions are treated as stable enough to review later. That assumption works poorly even for conventional machine identities, and it degrades further when agents move through tasks quickly and change context in-session. The survey result that 53% of agents exceeded intended permissions is a warning that out-of-scope behaviour is already a normal operating condition, not an edge case. The practitioner conclusion is to design for runtime authorization, not deferred correction.

Secure-by-design cannot be reduced to model safety controls. The article shows why siloed model, identity, endpoint, and application security practices fail when agents create ephemeral and changing attack surfaces across systems. Ephemeral agent trust debt: each additional delegated permission increases the amount of trust that must be continuously justified, but the justification window is often shorter than the review cycle. The practitioner conclusion is that governance has to follow the agent session, not the annual policy document.

OWASP Top 10 for Agentic Applications is becoming relevant because the failure mode is architectural, not cosmetic. Agent risk is expressed through tool misuse, identity abuse, and cascading effects between connected systems, which means the right frame is application behaviour plus access authority. That makes agent governance adjacent to NHI practice while remaining distinct from conventional appsec. The practitioner conclusion is to treat agentic systems as governed execution environments, not as smarter applications.

Scale changes the control problem before it changes the threat headline. When 74% of enterprises expect more than 100 agents live by the end of 2026, the question stops being whether a single agent is secure and becomes whether the operating model can inventory, authorise, and constrain many agents consistently. The practitioner conclusion is to make agent identity a first-class governance domain before sprawl outruns review.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Governance programmes that treat AI agents as a model-security problem will keep finding gaps after deployment, because the real control point is delegated authority. The practical shift is to make agent ownership, entitlement scope, and runtime checks part of the identity programme rather than a separate AI risk workstream.

Ephemeral agent trust debt: every delegated permission raises the amount of trust that must be justified during execution, not after the fact. That changes the programme design question from how to detect bad agent behaviour to how to prevent unreviewed authority from existing in the first place.

Teams that already manage service accounts, PAM, and lifecycle controls have the right mental model for parts of this problem, but agents add faster context switching and tool chaining. That means the review cadence, ownership model, and containment approach all need to move closer to issuance and runtime.

For practitioners

• Inventory every live agent and its delegated scope Track each agent as a governed identity with named owner, approved tools, data reach, and expiry conditions. The point is to know what the agent can do before it starts chaining actions across systems.
• Move authorisation to runtime decision points Require task-scoped approvals, entitlement checks, or session boundaries for agent actions that touch sensitive systems. Static launch-time approval is too coarse when the agent can shift context mid-execution.
• Separate model controls from identity controls Document which safeguards address prompt and model behaviour, and which ones govern access, tool use, and delegation. Mixing those layers leaves gaps where an agent can be safe to prompt but unsafe to authorise.
• Use agent-specific threat models for connected workflows Assess how an agent could misuse allowed tools, propagate bad actions, or trigger chained failures across downstream services. General application threat modelling misses the identity and delegation mechanics that make agent incidents different.

Key takeaways

• AI agent governance fails when organisations start with model security and leave identity, delegation, and entitlement scope underdefined.
• Survey data cited by Zenity shows the issue is already widespread, with 53% of participants reporting agents exceeded intended permissions and 47% seeing an agent-related incident in the last year.
• The most useful control shift is to govern agent access at runtime, because static approval and delayed review do not match how agent behaviour unfolds.

Key terms

• AI Agent Identity Governance: AI Agent Identity Governance is the set of policies, controls, and oversight used to manage how AI agents are identified, authorized, monitored, and retired. It defines who can create or operate an agent, what tools and data it may access, how its actions are logged, and how risk is reviewed across its lifecycle.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Ephemeral Attack Surface: A risk surface that exists only briefly while an agent is active, often changing from one task to the next. Because it can disappear before a scheduled review or scan, teams need controls that operate at issuance time and during execution.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.