AI agent governance is lagging behind enterprise access sprawl

At a glance

What this is: This analysis argues that AI agents are now part of the identity landscape and must be governed as access-bearing identities with ownership, least privilege, and SoD controls.

Why it matters: IAM, IGA, and GRC teams need to fold agent identities into existing governance because human-only reviews will miss combined access risk and accountability gaps.

👉 Read Nexis' article on governing AI agents already in your Microsoft tenant

Context

AI agents in enterprise settings can hold permissions, join groups, and act inside business workflows, which makes them part of the access landscape rather than a side tool. The governance problem is that many programmes still inventory people well but cannot explain which agents exist, who owns them, or what they can reach.

For identity teams, the hard part is not only visibility into the agent itself. It is understanding how agent access interacts with human access, business process ownership, and segregation of duties, especially when an employee can operate an agent with broader permissions than the person alone should have.

Key questions

Q: What breaks when AI agents are reviewed like human users?

A: Human review assumes access is stable long enough to be observed, approved, and recertified. Agentic workflows often complete within one session and can change scope mid-execution, so the review cycle arrives too late to matter. The result is a governance gap where the action has already happened before anyone can certify it.

Q: Why do AI agents create compliance risk even when policies exist on paper?

A: Policies do not satisfy auditors if the organisation cannot prove enforcement. AI agents can call APIs, move between tools, and access data dynamically, so compliance depends on evidence of real-time control, not written intent. The practical test is whether you can reconstruct every sensitive action after the fact without guesswork.

Q: How should teams govern AI agents that act inside customer accounts?

A: Treat them as delegated non-human identities, not as ordinary customer sessions. Governance should require explicit consent, narrow authorization scope, token binding, and a complete audit record tying each action back to the human principal that approved it.

Q: What is the difference between agent inventory and agent governance?

A: Inventory tells you which agents exist and what they can reach. Governance adds ownership, accountability, access review, and segregation of duties so that the organisation can decide whether the access is appropriate and who can be held responsible for it.

Technical breakdown

AI agent identity inventory and reach

AI agent governance begins with inventory: knowing which agents exist, where they were created, and what systems they can reach. In Microsoft-centric environments, an agent may appear as a tenant object with permissions, application roles, or group memberships, which makes it operationally closer to an identity than a simple workflow. The technical risk is reach without context, because reach alone does not show purpose, ownership, or approval path. Without a reliable inventory, governance cannot distinguish sanctioned business automation from orphaned experimentation.

Practical implication: build a dated inventory of every agent, its origin, and the resources it can touch.

Cross-identity segregation of duties

Segregation of duties fails when human and non-human access are reviewed separately. An employee can be compliant on paper while an agent they operate holds additional permissions that create a combined conflict, such as initiating and approving the same transaction path. This is not a new SoD principle, but a different review boundary: the control must evaluate the combined effective access of the operator and the agent, not each identity in isolation. That is why separate reports miss the real governance defect.

Practical implication: evaluate SoD across the human-plus-agent access path, not per identity type.

Ownership, accountability, and auditable control

An AI agent with access is only governable when it has a responsible owner and a traceable accountability chain. Ownership is the control that connects technical access to business intent, review, and revocation. In practice, that means agents without a named owner create the same governance problem as orphaned service accounts: nobody can certify purpose, approve scope, or trigger removal when the use case changes. Auditable control depends on mapping the agent to a workflow, not just a directory object.

Practical implication: require named ownership before an agent is allowed to keep or expand access.

Threat narrative

Attacker objective: The objective is to convert hidden agent access into unreviewed business capability that can bypass segregation of duties, widen data reach, or enable unauthorized action chains.

1. Entry occurs when a user creates or connects an AI agent to business systems such as collaboration tools, CRM platforms, or directory-backed applications. The agent inherits access from its configuration and operating context rather than from a traditional user login path.
2. Escalation happens when the agent accumulates permissions, roles, or group memberships beyond the original task scope, especially if the human operator has additional access that combines with the agent's own reach. The effective privilege set becomes larger than any single review usually captures.
3. Impact follows when hidden combined access enables sensitive actions, including initiating and approving the same workflow, reaching protected data, or acting on behalf of a user without a clear governance owner. The breach condition is invisible access composition rather than a single compromised login.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent governance is an identity problem before it is an AI problem. The article is right to treat agents as access-bearing entities with ownership, permissions, and accountability. Once an agent can enter group memberships or application roles, the governance question becomes familiar IAM, not novelty management. Practitioners should place AI agents inside the same identity governance framework they already use for privileged business access.

Cross-identity SoD is the named concept this market needs. Separate reviews for human users and AI agents create a false sense of compliance because the risk emerges only when their access is combined. That is a governance blind spot, not merely an inventory gap. The implication is that identity programmes must measure effective access across the operator and the agent together, or they will certify the wrong thing.

Ownership is the missing control that turns agent sprawl into governable inventory. The article correctly highlights that an agent without an accountable owner cannot be reviewed, certified, or removed with confidence. That is the same failure mode seen in orphaned machine identities and stale access objects. Practitioners should treat ownership assignment as a prerequisite to governance, not a cleanup task after deployment.

Microsoft-centric visibility is necessary but not sufficient for AI agent control. The article focuses on agents visible in a tenant, which is a useful baseline but not the full estate. Organisations will also need to account for agents that sit behind service accounts or stored credentials, because those identities do not disappear from governance simply because they are less visible. The field should stop equating directory visibility with complete control.

The EU AI Act raises the floor, but IAM still does the operational work. Regulatory obligations can define accountability expectations, yet they do not by themselves tell teams how to inventory, review, and constrain agent access. That gap is where IAM and GRC must converge. Practitioners should use AI governance requirements as a trigger to extend existing access governance, not as a replacement for it.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Use OWASP Agentic Applications Top 10 to map agent-goal hijack, tool misuse, and identity abuse to your control testing programme.

What this signals

Cross-identity SoD: AI agent governance will increasingly sit inside existing IAM and GRC workflows, not beside them. The practical shift is to certify effective access across the person, the agent, and the process together, because separate review cycles will keep missing the real conflict boundary. Teams that cannot produce that joined view will struggle to defend access decisions to auditors and business owners alike.

The bigger programme signal is that agent governance is becoming a lifecycle issue, not a one-time inventory exercise. Once agents can be created, shared, expanded, and forgotten at business speed, recertification and ownership workflows need to track their change rate, not just their existence. That makes identity governance a continuous operating model rather than a periodic control.

For practitioners

• Inventory all AI agents in the tenant Build a dated register of every agent, its origin, its reachable applications, and the business process it supports. Do not allow agent governance to begin with policy language before you know what is actually present.
• Review combined human-plus-agent access Run segregation of duties checks across the employee and the agent they operate, not as separate populations. Flag cases where the combination enables initiation and approval of the same sensitive workflow.
• Assign accountable ownership before expansion Require a named business and technical owner for every agent before permissions can be extended or retained. If no owner can certify purpose and scope, the agent should not keep access.
• Extend access reviews beyond visible tenant objects Include agent-like access paths that rely on service accounts or stored credentials so the governance view is not limited to directory-visible agents. This keeps hidden reach from escaping recertification.

Key takeaways

• AI agents are now access-bearing identities, so treating them as isolated technical objects leaves governance incomplete.
• The most dangerous failure mode is cross-identity SoD, where human and agent access combine into a conflict no single review exposes.
• Ownership, inventory, and combined access review are the controls that turn agent sprawl into something IAM can actually govern.

Key terms

• AI Agent Governance: AI Agent Governance is the set of policies, controls, and oversight practices used to direct how autonomous software agents behave. It defines allowed actions, approval paths, identity boundaries, logging, monitoring, and accountability so agent decisions remain traceable, constrained, and aligned with business, security, legal, and ethical requirements.
• Cross-App Segregation Of Duties: A SoD approach that evaluates whether a single identity can perform conflicting actions across multiple systems, not just within one application. It is essential in SaaS and cloud environments where business processes span tools and where conflicts often emerge only when permissions are considered together.
• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• Agent ownership: The assignment of accountable business and technical responsibility for an AI agent or automated workflow. Ownership should include approval authority, review cadence, and a clear connection to the identity that the agent uses, so that access and liability do not disappear when the workflow scales.

What's in the full article

Nexis' full article covers the operational detail this post intentionally leaves for the source:

• The exact four-step health check workflow for scoping, data import, analysis, and findings presentation.
• The tenant-focused inventory method Nexis uses to identify agents, ownership gaps, and access concentration.
• The benchmark comparison approach used to position results against anonymized peer data.
• The practical distinctions between visible tenant agents and agent-like identities using service accounts or stored credentials.

👉 The full Nexis article covers the health check workflow, tenant inventory approach, and benchmarked findings.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.