AI agent governance needs identity foundations before production scale

At a glance

What this is: This conference takeaways piece argues that AI agent governance is now an identity governance problem, not a future strategy topic, because current IAM models were built for human lifecycles rather than agent behaviour.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to govern agents with ownership, segregation of duties, and recertification models that can withstand production use.

By the numbers:

• By mid-2026, non-human identities outnumber human identities by 50 to 140 times in large enterprises.

👉 Read Nexis' takeaways on AI agent governance from EIC 2026

Context

AI agent governance is the problem of assigning authority, ownership, and policy control to software actors that can act with enterprise access. The primary gap is that classical IAM assumes a human lifecycle with joiner, mover, and leaver events, while AI agents can be created, repurposed, and left active without those triggers.

The conference takeaway is not that agent deployment is theoretical, but that governance is lagging deployment. That gap is already affecting NHI, IAM, IGA, and PAM programmes because the same controls that manage human access do not automatically govern agents that inherit broad entitlements and act across systems.

Key questions

Q: How should IAM teams govern AI agents without trying to review every instance individually?

A: They should govern AI agents through policy clusters, named ownership, and approved capability boundaries rather than by treating each agent as a separate certification item. That approach scales better because the real control object is the policy that creates access, not the individual agent record. It also gives governance committees something stable to review as deployments multiply.

Q: Why do AI agents create problems for joiner-mover-leaver processes?

A: AI agents do not fit the human JML model because they do not join, move, or leave in the same way people do. They can be instantiated, reused, or left active without the normal organisational events that trigger access changes. That means ownership and retirement controls must be designed explicitly for non-human actors.

Q: What breaks when segregation of duties is only enforced for human identities?

A: The control breaks at the policy layer because agent activity can repeat the same sensitive workflow pattern at machine speed and scale. If SoD is not extended to non-human actors, the organisation may still separate duties for staff while allowing agents to concentrate conflicting capabilities. That creates audit risk and hidden privilege overlap.

Q: Who should be accountable when an external AI agent acts on enterprise data?

A: Accountability should sit with the human owner of the agent cluster and the business function that authorised its use. External agents should be handled as third-party identity risk, with the same expectations for documented scope, access review, and revocation that apply to other outsourced access relationships.

Technical breakdown

Why classical IAM breaks for AI agent governance

Classical IAM depends on stable identity events, predictable ownership, and access decisions tied to a person or service lifecycle. AI agents break that pattern because they may execute many tasks, across many systems, without a single durable role or manager relationship. That makes entitlement growth, access review, and offboarding difficult to express in existing models. When an agent can be instantiated for a task and later reused for another, governance shifts from identity records to policy-bearing operating rules. Practical implication: treat AI agents as governed entities with explicit ownership and policy scope, not as generic automation endpoints.

Practical implication: define AI agents as governed entities with explicit ownership and policy scope, not as generic automation endpoints.

Segregation of duties becomes a policy problem, not a per-agent setting

SoD for agents cannot be managed only by configuring individual instances, because the risk is in the policy pattern, not the single deployment. If the same governance rule is copied into hundreds of agents, the control still fails at the policy layer when business intent, developer intent, and organisational intent are not separated. The article's core point is that recertifying thousands of agents one by one is not scalable. Instead, SoD must be expressed in policy coverage that applies across all agents in a cluster or function. Practical implication: move SoD enforcement upward into policy design and governance review.

Practical implication: move SoD enforcement upward into policy design and governance review.

Policy-level recertification is the only scalable review model

The article argues that agent governance should be recertified at the policy level rather than at the level of every agent configuration. That is an important shift because the volume problem is not just operational, it is structural. If one employee can have many agents and each agent can hold many entitlements, then review cycles built for human access lists will not keep up. Policy recertification allows IAM and IGA teams to validate the rules that govern access instead of endlessly chasing individual artefacts. Practical implication: redesign access review around policies, ownership clusters, and approved capability boundaries.

Practical implication: redesign access review around policies, ownership clusters, and approved capability boundaries.

NHI Mgmt Group analysis

AI agent governance exposes a lifecycle assumption that human IAM never had to confront. Classical joiner-mover-leaver design assumes a stable subject with a hire date, manager, and offboarding event. That assumption fails when the identity is an AI agent that can be created for a task, reused, and left active without a human transition point. The implication is not merely operational complexity, but a governance model that no longer matches the subject being governed.

Segregation of Duties for AI agents is a policy-design problem, not a per-instance controls problem. The article is right to push the control boundary upward, because copying the same access pattern into thousands of agents does not create governance. It creates scale on top of unresolved policy gaps. Practitioners should treat SoD as an enterprise rule set spanning human and non-human identities, not a checklist inside each agent configuration.

Policy recertification is the named concept that best captures the real governance shift. The article's most useful insight is that reviewing every agent individually does not scale, while reviewing the policy framework can. That matters because the programme object changes from thousands of identities to a smaller set of approved decision rules. Practitioners should redesign certification around policy ownership, approved scope, and exception handling.

AI agent governance is now an NHI programme issue, not a side topic for innovation teams. Once agents operate with enterprise access, they belong in the same governance conversation as service accounts, tokens, and workload identities. The field should stop treating agent governance as a separate novelty and start folding it into NHI, IGA, and PAM operating models. Practitioners need one control framework that spans all non-human actors.

External-agent exposure should be treated as third-party identity risk from the start. The article correctly notes that agents not built and operated internally bring a different accountability problem. That is the same pattern identity teams already manage in third-party access, but with more dynamic behaviour and weaker human oversight. Practitioners should align this risk with existing governance and vendor-access processes.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• That confidence gap sits alongside another warning sign: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the same report.
• For teams building AI agent governance, the next step is to align policy ownership, lifecycle control, and identity visibility using Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

What this signals

Policy-level governance is becoming the only workable control plane for agentic identity. As agent counts rise, per-instance review quickly becomes operational theatre rather than control. The practical signal for IAM and IGA teams is that ownership clusters, policy recertification, and entitlement boundaries will matter more than agent inventory size, especially when agents can be created and reused faster than review cycles can keep up.

AI agent programmes should now be measured by whether governance can survive scale, not by how many pilots exist. The article shows a familiar enterprise pattern: enthusiasm is high, but controls are not yet mature. A useful benchmark is whether your programme can map agent access to named ownership, approved scope, and retirement paths before production use expands.

The governance pattern here is already visible in broader NHI research. With 92% agreeing that governing AI agents is critical to enterprise security, yet only 44% having implemented any policies to do so, the gap is no longer awareness but execution, according to SailPoint's AI Agents: The New Attack Surface report.

For practitioners

• Assign ownership by agent cluster Group AI agents by business function and assign a named human owner for each cluster. Tie that ownership to entitlement review, exception handling, and accountability for changes in scope. This avoids orphaned governance when individual agents are created faster than they can be individually managed.
• Extend SoD policy to non-human actors Review your existing SoD matrix and explicitly add agent scenarios where the same person, workflow, or system can both request and approve sensitive actions. Make the rule set apply to agent clusters and task types, not only to human roles.
• Recertify governance rules, not each agent Shift access review from individual agent inventories to the policy framework that authorises them. Certify approved intent layers, capability boundaries, and exception paths on a schedule that your governance committee can actually sustain.
• Treat external agents as third-party risk Bring externally operated agents into third-party access review, onboarding, and offboarding workflows. Require documented ownership, data access boundaries, and evidence of revocation when the relationship changes or the use case ends.
• Map agent lifecycle into identity operations Define how an AI agent is approved, modified, suspended, and retired so that lifecycle events are visible to IAM and IGA teams. Without that mapping, agent access will outlive the process that created it.

Key takeaways

• AI agent governance fails when human IAM assumptions are carried over unchanged into non-human identity programmes.
• The scale problem is already real, with non-human identities outnumbering human identities by 50 to 140 times in large enterprises.
• Practitioners should shift from per-agent review to policy-level ownership, SoD, and lifecycle governance.

Key terms

• AI Agent Governance: The policies, ownership structures, and enforcement controls that determine what an AI agent may do, on whose authority, and under what limits. In practice, it combines lifecycle oversight, entitlement management, and accountability for actions taken by a non-human actor.
• Policy Recertification: A governance process that reviews the rules authorising access rather than each individual identity one by one. For AI agents, this is often more scalable than per-agent review because the control object is the approved policy set, not the ever-growing inventory of agent instances.
• Segregation of Duties: A control that prevents one actor from owning incompatible parts of a sensitive process. In AI agent governance, SoD must be expressed across policy and function, because repeated machine execution can recreate conflicting access patterns at scale even when human roles appear separated.
• Non-Human Identity: Any digital identity used by software, systems, workloads, or agents to access resources without a person authenticating directly. NHI governance covers creation, authorization, monitoring, rotation, and retirement across these identities so they do not become unmanaged access pathways.

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.

This post draws on content published by Nexis: Conference takeaways on AI agent governance from EIC 2026. Read the original.