Playing with Sharp Objects.

When enterprises started connecting PCs to networks in the 1990s, the identity model in place was built for a different assumption: one person, one machine, one set of credentials. It took a generation of painful incidents before the industry rebuilt access governance around networked reality. The same gap is opening now, and most organizations aren’t asking the question yet.

Your identity governance model was built for humans. It assumes a person submits an access request, a manager approves it, a role is assigned, and access is revoked when the person leaves. That model has worked for decades, imperfectly but well enough, and it breaks when you deploy AI agents at scale.

I’ve spent the last two years working in enterprise AI adoption and security governance, including as a founding member of my organization’s Gen AI Council. What I’ve seen consistently: most enterprises are deploying AI agents with no meaningful changes to their identity governance framework. The access model, review cadence, and tooling remain unchanged, but the risk profile has changed.

The Problem with Human-Centric Identity Models

Traditional identity governance rests on three assumptions that AI agents violate immediately.

Assumption 1: Access requests are human-initiated.

In a human-centric model, access is requested deliberately. A person needs something, makes a request, and a human reviews it. This creates a natural throttle on access sprawl: humans only request what they actually need, and managers can evaluate whether the need is legitimate.

AI agents don’t request access in this sense. They inherit the permissions of the user or service account that activated them, and then act continuously, autonomously, and at machine speed within whatever scope those permissions allow, with no request submitted and no approval granted.

Assumption 2: Access scope is bounded by job function.

Human access reviews are grounded in job function. Does this person need access to this system to do their job? If not, why do they have it?

AI agents don’t have job functions in the traditional sense. What they have are instructions: prompts, workflows, and automations they pursue across every system they can reach. The question “does this agent need access to this system” is harder to answer because the agent’s function may legitimately span systems in ways that would look excessive for any individual human.

Assumption 3: The identity being governed is a person.

IGA tools are designed around a human identity with a lifecycle: hired, onboarded, role-changed, terminated. Provisioning and deprovisioning follow that lifecycle.

AI agents don’t have lifecycles in this sense. A Copilot agent can be created by any licensed user in minutes, operated indefinitely, and never formally decommissioned. Service principals attached to AI automations persist long after the automation changes or the person who created it leaves the organization, and your IGA tool almost certainly cannot see any of it.

What the Gaps Look Like in Practice

These gaps are not theoretical.

Gap 1: Agent identity is invisible to your IGA.

Most enterprise IGA tools were built to manage human identities and, to varying degrees, privileged service accounts. They were not built to discover, catalog, or govern AI agent identities, which exist as a combination of service principals, API keys, OAuth tokens, and delegated user permissions.

When I ask security teams how many AI agents are running in their environment, the answer is almost always a guess, and frequently a significant underestimate. The agents exist, the permissions exist, the activity exists, and none of it is in the identity governance model.

Gap 2: Delegated permissions create invisible blast radius.

Copilot and similar tools operate under delegated permissions: they act as the user who activated them, inheriting that user’s full access scope. This is by design. It is also a significant governance problem.

A user with broad SharePoint access activates a Copilot agent to help with document summarization. The agent can now read every document that user can read, across every site, every library, every folder. If that user’s access was never properly scoped (and in most enterprises it wasn’t), the agent’s effective access is wider than anyone intended. Your access reviews, data classification policies, and DLP rules almost certainly didn’t account for any of it.

Gap 3: Service principals attached to AI systems are ungoverned.

Enterprise AI deployments run through service principals: Azure OpenAI integrations, Power Platform automations, custom LLM workflows. These SPs are provisioned during implementation, often with broad permissions to ensure the integration works, and then rarely reviewed.

OWASP’s Agentic AI framework identifies Excessive Agency as a top risk: an AI agent that can do more than it needs to. In my experience, the Excessive Agency problem is almost always rooted in an overly permissive service principal that was never scoped down after initial deployment. Your IGA tool is not reviewing these SPs on a regular cadence, and if it is, it’s almost certainly not flagging them for the right reasons.

Gap 4: The access review process assumes human accountability.

Access reviews work because a human manager is accountable for approving continued access for a human employee. That accountability loop doesn’t exist for AI agents.

Who is accountable for the access scope of a Copilot agent deployed by a business analyst? The technical answer is the user who deployed it, but in practice nobody reviewed the agent’s access scope, nobody monitors it, and nobody will catch a problem until something goes wrong.

Gap 5: Prompt injection turns your agents into insider threats.

The four gaps above are about what agents can access. This one is about what agents can be made to do with that access.

Prompt injection comes in two forms. Direct injection is a user manipulating an agent through their own input, a known risk with established mitigations. Indirect injection is the more dangerous variant in the context of enterprise agents: malicious content embedded in a document, email, or web page the agent reads hijacks its instructions without any user involvement. The attacker never interacts with the agent directly. They just need to get a poisoned document into a system the agent can reach.

An agent with broad access and no prompt injection controls is a pre-positioned tool for any attacker who can get a malicious document in front of it. Traditional IGA has no concept for this because it never had to account for an identity that could be manipulated through content. The defenses are known: input validation, output filtering, sandboxed execution, human-in-the-loop checkpoints for high-risk actions. None of them are in a governance framework that didn’t anticipate agents. Deploy 50 agents without addressing prompt injection and you’ve handed an attacker 50 ways to act inside your environment using your own permissions.

What the Teams Doing This Well Have in Common

There is no framework that solves this cleanly yet. What I can say is what the organizations ahead of this problem have in common, and where AI tooling is starting to make each step more tractable.

They built an agent inventory first.

You cannot govern what you cannot see. The first step is a complete inventory of AI agents in the environment: what they are, who created them, what permissions they run under, and what systems they can reach.

AI helps here more than most teams realize. Tools like Microsoft Entra, Wiz, and Varonis can crawl for service principals and OAuth grants automatically. LLMs can classify what’s AI-adjacent by analyzing naming conventions, permission patterns, and API call logs at a scale no human team can match manually. The inventory still requires a human to own the findings and make disposition decisions, but the discovery problem is one AI is well-suited to accelerate.

The harder problem is shadow AI: agents created casually by non-security personnel through interfaces designed to make deployment easy, which no tool catches because no tool knows to look for it.

They applied least privilege to service principals explicitly.

Every service principal attached to an AI system should be scoped to the minimum permissions required for that system’s function, reviewed on the same cadence as privileged human accounts.

AI accelerates the scoping work by comparing current permissions against actual usage in logs, flagging permissions that exist but have never been exercised. Cloud Infrastructure Entitlement Management tools do some of this today. The output is a prioritized list of SPs where granted permissions significantly exceed used permissions, which is the right starting point for a cleanup effort. The decisions still require human judgment about what each SP’s function actually demands.

They updated access reviews to include agent-mediated access.

When you review a user’s access, you now need to ask: what AI agents is this user running, and what can those agents reach under this user’s permissions? A user’s effective access is the union of their direct permissions and everything their agents can do on their behalf.

AI can pre-populate these reviews with context that makes them useful rather than perfunctory: last-used timestamps, risk scores, anomalous activity flags, and a plain-language summary of what the agent has actually done in the review period. This doesn’t replace the human approval, since the accountability signature is the point, but it closes the gap between checkbox compliance and genuine oversight.

They established ownership for every agent identity.

Every AI agent in the environment needs a named owner: a human accountable for that agent’s access scope, behavior, and decommissioning. Without it, agents operate indefinitely with no one responsible for reviewing or revoking their access.

AI can suggest owners based on who created the agent, who most frequently invokes it, and org chart proximity to the relevant function. The suggestion still needs human confirmation, since ownership without informed consent is accountability theater, but automated suggestions dramatically reduce the friction of getting to a complete ownership map.

The Question to Start With

The question I’d start with is not “do we have a governance framework for AI agents?” Most organizations don’t, and building one from scratch is a multi-quarter effort.

The question to start with is: can you produce a list of every AI agent currently operating in your environment, the permissions it runs under, and the human accountable for it? If the answer is no, and for most enterprises it will be, that’s your first project, because everything else depends on getting the inventory right.

The identity governance model you built for humans is not going to fail loudly: it will quietly allow AI agents to accumulate access, act autonomously at scale, and leave no clean audit trail until an attacker finds a document that tells one of your agents to do something you never intended. By the time that gap is visible, it will have been open for months. The organizations that avoid that outcome are the ones asking the question before an incident forces it.