The Practical Guide to AI Agent Identity Governance

Inside Lumos, we counted more than 450,000 agent actions in a single week in September 2026, across a company of fewer than 200 people. That's more than 2,000 actions per person in one week. We build with agents every day, so treat the number as a preview of heavy adoption and of how fast agent activity outgrows any review cycle built for people.

AI agent identity governance is the practice of controlling what access AI agents hold, who answers for each one, and what they're allowed to do with that access at the moment they act. Some agents get a non-human identity of their own, but many of the ones your employees run every day don't. They act on your employees' access, which gives governance two jobs: right-size the access agents inherit, and decide each action before it runs.

In this article, you will learn how agents inherit permissions from the people who run them, which three paths they take into your apps, and why trimming human access is the quickest way to limit what any agent can reach. The article also covers ownership, per-task access, and authorization at the moment of each tool call, along with a four-tier model for sorting those calls by the damage they could do. The final sections explain how to certify agent access without rubber-stamping it and how to build an audit trail that holds up under SOX, SOC 2, and ISO 27001.

How do AI agents inherit their users' permissions?

Many of the AI agents in your company don't log in as themselves. They log in as your people.

The pattern is everywhere. An engineer connects a coding agent to Salesforce, Slack, the internal wiki, and production infrastructure through MCP (the Model Context Protocol, the open standard agents use to reach tools and data), signing in with their own OAuth grant or pasting in a personal access token. Then they ask the agent to investigate an incident, pull context from three tools, and fix what it finds.

That's useful work, and it's exactly how access slips past your controls. The agent can now reach whatever each connection allows, which is usually the engineer's own access and sometimes more. The engineer clicked through a consent screen, and that was the whole approval process. No ticket opened, no one reviewed what the agent could touch, and no joiner event fired.

We've watched this play out inside our own company. In our MCP Governance launch post, co-founder Leo Mehr describes employees driving agents to change production feature flags, publish applications, and delete knowledge base files in the course of real work. In one case, what looked like simple calls to a Retool MCP server turned out to be the agent running arbitrary TypeScript against a read-write Salesforce connection. Most of the calls were reads, but the connection allowed updates, and the agent made them.

Look at what's missing from those examples: a privilege escalation. Every action rode on access somebody had legitimately granted, either to the employee or to the connector. The Retool case points to the harder of the two, because a shared connection runs on its own stored credentials and can carry more access than the employee holds directly.

That's why your current reviews miss it. Some apps log which connected client made each call, but nobody reads those logs at review time, because identity governance software has long built access reviews around people and entitlements. Your quarterly certification asks whether Priya still needs Salesforce. Nothing in it asks what Priya's agent did there last Tuesday.

None of this makes your engineers reckless. The exposure lives in the gap between what one task needs and what the connection allows, and AI agent access management has to close it, because agents already work inside that gap at machine speed.

Three AI agent identity paths and where each one breaks

Before you can govern an agent, you need to know how it gets in. Every agent reaches your apps through one of three paths, and each one breaks in a different place.

‍

Classify before you build controls. Take your ten most-used agent workflows and tag each one by path this week. The path decides which control applies, so the tagging tells you where to start.

1. Borrowed human access

This is the pattern described at the top of this article. The agent acts with a person's OAuth grant, personal token, or browser session, so it can reach whatever that person can.

The registry model most guidance recommends barely touches this path, which is where agents your engineers wire up themselves tend to land. A program that starts and ends with registering agent identities covers the agents your platform team built and misses the ones your engineers connected last week.

This path is also getting harder to see. We see browser use as an emerging blind spot: when an agent operates an authenticated browser, it uses whatever access those sessions carry and reaches apps without touching MCP. An MCP gateway never sees that traffic. Right-sizing the human, covered in the least privilege section below, is the first control.

2. Machine credentials

Machine credentials are a familiar non-human identity problem with a new consumer. An agent that pulls an API key from a config file inherits every weakness that key already had, so gaps in your service account security become gaps in your agent security. The shared Retool connection belongs here too, since the agent inherits whatever that stored credential can do.

Registries cover this path only partially, but it already has a home. Agents that authenticate with keys and tokens belong in your NHI lifecycle, with an owner, rotation, and right-sizing like any service account. Personal access tokens straddle this path and borrowed access, carrying one person's access with the shelf life of a machine secret, so they need both sets of controls.

3. Native agent identity

Native agent identities are the newest path, issued by your identity provider or agent platform with their own scopes and lifecycle. This is the path the registry model governs well, because each identity is created on purpose and can carry an owner from the start. Its weak spot is fragmentation, since each platform's registry sees only its own agents, and the ownership section later in this article takes that up.

AI agent least privilege starts with right-sizing human access

An agent running on a person's own access can reach as far as that person can, and no further. That makes right-sizing human access the fastest agent control you already own.

The math is unforgiving. An over-provisioned employee hands an over-provisioned agent to anything that can prompt it, including a poisoned document or a malicious web page. An admin's agent is an admin, and every standing entitlement you've meant to clean up is now reachable at machine speed.

Every customer result in this article comes from governing human access, and for agents on borrowed access, that work doubles as agentic AI security. Roku adopted a North Star policy of two global admins per application to keep its SOX compliance clean, and used Lumos to enforce it. Read that policy with agents in mind: in any app, at most two people's agents can act as a global admin. The same logic holds at offboarding, which is why Lumos surfaces the service accounts and agent connections a departing employee owned and puts them into review alongside the person's exit.

Movers matter as much as leavers. When someone changes teams and keeps their old access, their agent keeps it too, and keeps acting on it long after the person stops thinking about that app. With agents in the loop, mover cleanup becomes blast-radius control.

None of this replaces agent-specific controls. Shared connections with their own stored credentials sit outside the ceiling entirely, so they need owners and right-sizing of their own. For everything that runs on a person's access, a lower ceiling makes every decision below it easier.

Who should own an AI agent's identity and lifecycle?

Every agent with an identity of its own needs a named human owner, because AI agent lifecycle management has nothing to hang on without one. These agents are the easiest to see and the easiest to forget. Your identity provider or agent platform issues the identity, a platform team deploys the agent, and six months later the person who asked for it has moved teams.

Assign that owner at creation, and treat a missing owner as a reason to block deployment. The owner answers three questions at every review: what the agent is for, what it should be able to reach, and when it should stop running. An agent nobody will answer for is an agent you can't safely leave running.

Expect these identities to live in more than one place. Each agent platform registers its own agents, so a company running agents in two clouds, a CRM, and a coding platform ends up with several registries that never reconcile, which is non-human identity sprawl in its newest form. Pull them into the same inventory as your people and service accounts, so one review cycle covers all of them.

Tie each agent's lifecycle to events you already track. When the owner leaves or changes teams, the agent goes to review with the rest of their access, and when the project it served ends, the agent gets disabled before it's deleted. Agents don't trigger joiner-mover-leaver events on their own, so they have to inherit those events from the human who owns them.

How do you grant AI agents access safely?

Grant AI agents access per task, scoped to that task and set to expire on its own. An agent that holds access around the clock is a credential waiting for the wrong prompt, and its needs change with every task.

Standards bodies are working the same problem. In its concept paper Accelerating the Adoption of Software and AI Agent Identity and Authorization, NIST's National Cybersecurity Center of Excellence asks how to establish least privilege for an agent whose required actions may not be fully predictable when it's deployed. It also asks whether authorization policies should update as an agent's context changes. The paper, published in February 2026, is still gathering comments, and it reads best as a map of the questions everyone in identity is now trying to answer.

The unpredictability is the point. You can't write a static role for an actor that decides its own next step, and any role broad enough to cover every possible step is too broad to be safe. Per-task grants fit the scope to the work in front of the agent.

The mechanics are familiar. A human or an agent requests access through Slack, your ITSM, or MCP. Policy checks the request, the grant goes out with a tight scope and a short expiry, and access revokes itself on schedule whether anyone remembers or not.

This already works at scale for human access. Netskope paired usage-driven role mining and policy management in Lumos with granular just-in-time grants that give the exact permission for the exact time, expire on their own, and log the evidence, and the combination cut its standing access by 80%. Each of those grants records who asked, what for, and how long it lasted, which is the same evidence an agent's grant needs.

Start with the access agents need least often and could abuse most. Production write, admin consoles, and customer data are the first entitlements to move from standing to per-task, because those are the grants an attacker with a hijacked agent goes looking for.

Borrowed access complicates the picture. When an agent runs on a person's OAuth grant, the just-in-time grant goes to the person, and the agent inherits it for the whole window. You can time-box that access, but you can't scope it to what the agent is doing, which is why per-task grants need a second check at the moment of action.

AI agent authorization has to happen before each tool call runs

AI agent authorization is the check that decides whether a specific action should happen right now, and it has to run before each tool call. Inventory and permissions are inputs to that decision, and neither one makes it.

Inventory still matters, starting with the agents nobody registered. Discovery has to reach the MCP servers employees add locally with no admin approval, because that's where shadow AI agents live and no vendor API will list them.

Permissions set the upper bound, and that's all they set. An engineer may legitimately need to update Salesforce, and that still doesn't mean their agent should change hundreds of records in one pass. Knowing what an agent can reach tells you nothing about what it's about to do.

Lumos MCP Governance, launched in September 2026 for Claude Code and Codex, governs the moment before an action runs. Inside those agents it sees every MCP server and tool call, including locally added servers, and it checks policy before each tool call runs, returning allow or deny and logging who called which tool, when, and the verdict.

The architecture matters if you've lived through a proxy rollout. The check runs inside the call through a tool-use hook, so nothing reroutes through a central chokepoint and nobody reconnects their servers. The same placement narrows the browser blind spot from earlier, since inside those agents the hook sees browser actions, shell commands, and file operations that never touch an MCP server. Browser agents running outside a supported client stay outside its view.

Policies don't require a policy language. Albus, the Lumos AI agent, turns a rule you describe in plain English, such as letting only on-call engineers change production feature flags, into a policy you review before it takes effect. Teams can start by watching, then add controls where the activity shows they're needed.

The timing is the whole argument. By the time anyone reads an agent's logs, it has made thousands more decisions, so the moment before the action is the last place left to govern.

A four-tier AI agent access control model for tool calls

Not every agent action deserves the same scrutiny, so stop giving them all the same policy. A four-tier rubric based on reversibility and blast radius tells you where to allow, where to require a grant or approval, and where to deny by default.

"Least privilege for agents" is the advice everyone gives, and it stalls the moment you try to apply it to a coding agent with forty tools. You need a way to sort the actions, because the actions carry the risk.

‍

Tier by what the input does. A tool's name tells you very little: a tool called "run query" can mutate data if the connection allows writes, a bash command can do anything the shell can, and a browser click can open a menu or submit a payment. That last example is why authenticated browser actions sit in tier 4 by default, since you can't tell what a click will do until it happens.

Two examples make it concrete. A tool that changes feature flags, pointed at production, is tier 3, so restrict it to on-call engineers and require a time-boxed grant. A code-execution tool sitting on a read-write CRM connection is tier 4, so deny it outside a sandbox no matter who's driving.

Tier 2 is where you'll spend the most judgment. Single-record updates and messages are reversible, and blocking them kills the productivity that justified agents in the first place. Allow them inside the human's role, log them, and sample them in reviews.

Write the tiers down before you write a single policy. A one-page tier map, owned by security and agreed with engineering, turns every future agent decision into a lookup.

How do you certify AI agent access without rubber-stamping?

Certify AI agent access by reviewing each person together with the agents acting on their access, and send reviewers only what changed. Certifying every agent connection every quarter recreates rubber-stamping at machine scale, and reviewers who approve every agent grant will approve the wrong one too.

Show the reviewer what moved since last time: new connectors, new scopes, tier 3 and tier 4 calls, and spikes in denied calls. That's a delta access review, and it's the only version of agent review a human can finish.

Everything policy already decided should stay out of the app owner's queue. Intercom moved to rule-based access with Lumos, which lets its IT team handle 90% of reviews centrally and escalate only true exceptions to app owners. Agent reviews can follow the same split, with policy-covered grants handled centrally and only the exceptions going to the people closest to the data.

Route each exception to two reviewers. The agent's accountable human confirms the business need, and the app owner confirms the data is fine to touch. Neither should wade through the thousands of grants that didn't change.

The payoff shows up in review hours and in catch rate. A reviewer looking at twelve real changes spots the one that matters. A reviewer looking at nine thousand approves it with the rest.

Building an AI agent audit trail for SOX, SOC 2, and ISO 27001

Expect your auditor to ask who allowed each agent action, and to want the answer in the same report as your human access. Logical access controls under SOX, SOC 2, and ISO 27001 apply to any actor touching in-scope apps, and an agent changing a financial record is an actor.

These frameworks don't carry agent-specific access controls today, and you don't need them to. The existing questions still hold: who authorized this access, who approved this change, and can you prove it? With agents, the evidence record needs a few more fields: the agent and the human it acted for, the tool it called, the policy that allowed or denied the call, and any grant that made it possible.

Keep that evidence in one report. ChargePoint runs its access reviews in Lumos, generates audit reports with one click across SOC 2, SOX, PCI, FedRAMP, and ISO 27001, and now completes twice as many reviews. Agent evidence belongs in that same report, because a separate agent report is one more thing to reconcile at quarter-end.

Produce the record as the agent works. Rebuilding it from three log sources the week before fieldwork is how teams end up with an agent appendix nobody trusts.

Why AI agent governance has to move at agent speed

Your agents don't wait for the next review cycle. They've made thousands of decisions since your last certification, on access nobody evaluated with an agent in mind, and a quarterly review of last quarter's access can't govern an actor like that.

The controls exist today. Right-size the people agents borrow from, grant per task, tier the actions, and check each one before it runs. Teams that put those in place this quarter will hand agents more access with confidence while everyone else is still building the registry.

Your agents already work at machine speed, and Lumos puts your governance on the same clock. It catalogs employees, service accounts, and agent connections in one inventory, grants access just in time, and runs delta access reviews, while MCP Governance checks agent tool calls against your policy before they run. Albus, the Lumos AI agent, turns the rules you describe in plain English into those policies, so your team sets the guardrails and Lumos applies them on every request. Book a demo to see how Lumos finds the agents already running on your employees' access and governs what they do next.

‍