Agentic access management is the part of an identity program that governs access when the actor is an AI agent. It covers the access agents use on someone's behalf, the access granted to them directly, and what they do with that access at the moment they act. Security leaders sorting through agentic AI governance challenges are hearing that this calls for its own stack, built from scratch for a new kind of identity.

The evidence points the other way. Agents run on credentials, roles, and grants that an identity program already issues, reviews, and revokes, but they use them at a speed and scale that strains controls built for people. Two layers are new: a policy decision on each action an agent takes and a record of the human who answers for it. Everything else is the program you already run, extended to agents.

In this article you will learn which identity controls carry over to agents, which break, and which have to be added. It closes with a clear answer on which team should own the work.

Is agentic access management a new category or an extension of IAM?

The case for a separate stack starts from real differences. Agents are non-deterministic, so the same request can lead to different actions on different runs. They act at machine speed and chain tools together in ways nobody planned, which means no approver can pre-clear every task an agent might attempt. Identity governance and privileged access tools were designed around people who sign in, work a shift, and leave a trail a reviewer can follow.

All of that is true, and it explains why some vendors describe agentic access management as a new category with its own controls. That framing treats the agent as the unit of control. Yet the access an agent uses was usually granted to someone or something else first: a person, a service account, or an integration a team connected months ago. A layer that starts from the agent sees the actor and misses where its reach came from.

Lumos's co-founders say nearly every security conversation they have now turns to agent governance, and they describe the agent identity and NHI markets as converging, with practical first moves that don't require a new tool category. The questions buyers ask most are basic ones: how many agents exist, who owns them, what they can reach, and what breaks when one is turned off. Each of those maps to a control an identity program already has or should have.

Why AI agent access starts in your existing identity program

Before an agent takes its first action, someone has already decided what it can reach. Lumos's platform datasheet names the three routes an agent gets that reach, acting with access someone already granted through an employee's account, a service account key, or an API token. That splits the work in two: managing the access people, machines, and agents hold, and controlling what agents do with it. The first half is the job identity teams already do.

Inheritance is where agent risk starts, since an agent's reach is set by grants it never requested. That's why AI agent identity and access management begins with the access people and machines already hold. If the access starts in your identity program, the controls on it belong there too.

An industry paper from the Coalition for Secure AI (CoSAI), Agentic Identity and Access Management, reaches the same conclusion from the architecture side. It says an agent's own rights should stay separate from the rights it uses on someone's behalf, with the delegation chain visible in credentials and logs. It also recommends that existing IAM remain the primary control plane for agentic IAM rather than a parallel stack built only for agents. Because the paper comes from a multi-company working group, that recommendation doesn't rest on one vendor's roadmap.

How IGA, PAM, and NHI controls carry over to AI agents

Most of the work of governing agents is existing identity work under new load. The map below takes seven controls an identity team already runs and sorts what applies to agents as it stands, what breaks once agents start using it, and what has to be added.

‍

Five of the seven rows are work an identity team already does, pointed at a new kind of actor. The entitlement row shows how small the change can look and how much it matters. Lumos's Entitlement Analyst translates permissions into plain English, so an approver sees that NS_FIN_ADMIN_7 means write access to every invoice in NetSuite before saying yes.

Because Lumos maps every human, NHI, and agent down to the fine-grained permissions inside each app, that translation describes what an agent could do with a grant, which a group name never shows. An approver who reads a role name signs off on a label. An approver who reads what it grants signs off on a blast radius.

The two new rows are where a buyer should spend evaluation time, because runtime policy and attribution have no human-era equivalent. The joiner-mover-leaver row mostly needs agent grants tied to the person who set them up, which is the core of AI agent lifecycle management. Everything else in the map is a cadence or coverage change to controls that already exist.

How AI agents inherit the non-human identity ownership gap

Ownership is the control agents inherit in the worst shape. In customer environments Lumos has analyzed, more than 95% of non-human identities have no human owner, and no owner means no reviews and no lifecycle policy. Those service accounts, keys, and tokens are the credentials agents run on, so knowing how to secure AI agents starts with knowing who owns each one. An agent that picks up an orphaned key also picks up its missing review history.

The gap persists for a practical reason. Nobody can say what breaks when an unowned credential is turned off, so it stays live, and every month it stays live makes the question harder to answer. Agents raise the stakes because they use credentials continuously, so a key that sat idle in a vault can become an active path into production the day an agent is pointed at it.

Closing the gap at agent scale takes automation on both ends, finding the owner and retiring what nobody claims. Lumos's Agent Ownership Finder catalogs every agent and NHI and assigns each a human owner, and the NHI Owner Hunter Agent watches service accounts, keys, and tokens and shuts down the risk when one is dormant or overscoped. With an owner attached, the question of what breaks finally has someone to answer it, and a retirement path becomes possible.

What delta access reviews and inactivity workflows teach about agent access

The mechanics agent access needs have already been proven on people. At Marqeta, the Head of Identity Security observed that identity governance has historically been built by engineers rather than identity specialists, and the team centralized it in Lumos across more than 150 apps. Two mechanics carried the work. Delta reviews highlight only the changes since the last review, and inactivity workflows automatically reclaimed unused SaaS licenses, with exceptions for VIP stakeholders who couldn't lose access without warning.

The payoff showed up in the second cycle, when access reviews ran 40% faster than the first. Reviewers spent their time on access that had changed, and unused licenses came back without anyone chasing them.

Those are the two habits agent access needs most. Reviewing only what changed is how a review keeps pace with identities that appear and disappear between quarters. Removing what goes unused, with a human exception path, is how a team retires agent credentials without breaking the workflows that depend on them.

What do AI agents need that human access controls don't cover?

Two rows in the map have no human-era equivalent. Both sit at the moment an agent acts, where an entitlement stops being a line in a catalog and becomes an action.

Runtime policy before each tool call

Lumos frames the gap with two questions: who has access to your AI platforms, and what can those platforms' agents do with that access. Most teams can partly answer the first, and very few can answer the second. Entitlements set the ceiling on what an agent could do, and agentic access control decides what it does inside that ceiling, one call at a time.

Lumos MCP Governance installs a hook in Claude Code and Codex that checks each tool call against policy before it runs, with no gateway and no rerouted traffic. It also captures bash commands, file edits, and browser use in those clients, so the record covers more than MCP. What a policy should weigh on each call deserves its own design work, and AI agent access control breaks that decision into its inputs.

Attribution to a named human

Every agent action needs two names: the agent that took it and the person or team that answers for it. Without the second name, an audit log shows a service account changing records and nobody who can explain why. MCP Governance records each call with the server, the tool, the human identity behind it, the time, and the verdict. Tool call arguments are stored by default and can be turned off, while prompts, model responses, and tool results are never sent to Lumos or stored.

That record answers the question auditors ask first, which is who allowed this action. The answer belongs in the same report as human access, because the person behind an agent answers for it the same way they answer for their own account.

Should the identity team or security engineering own AI agent access?

The identity team should own agent access because it already governs the grants agents run on. Splitting the work into a separate agent-security function means two teams reviewing the same service account from different consoles, with neither holding the full picture. Owning the program doesn't mean doing every task, though.

The roles divide cleanly. Security or platform engineering rolls runtime hooks out to agent clients through central deployment, with no setup for the person using the agent. Whoever administers each AI platform holds those admin roles under the privileged access program, with time-bound elevation and a named owner. App and data owners approve the sensitive boundaries, such as which agents can write to financial records or change production configuration.

Routine decisions should run on their own under written AI agent access policies, with people approving sensitive boundaries and exceptions. Lumos positions this as one platform and one audit trail with no new console, and its Identity Agent Force applies the policies, guardrails, and approval thresholds people set. That division of labor is what agentic identity governance looks like in practice: people design the rules, and agents handle the volume.

Extend your identity program to AI agents without a new tool

Agentic access management works best as an extension of the identity program you already run, with two new layers where agents act. Three moves get a team started. Bring agent credentials and AI platform admin roles into the reviews and privileged access program already running. Give every credential an agent can use an owner and a retirement path, then turn on runtime visibility before writing a single blocking policy.

Lumos runs all three moves on one platform. It applies the same governance model to employees, non-human identities, and AI agents, and its Agent Ownership Finder gives each new agent a human owner before it starts work. MCP Governance shows every tool call in Claude Code and Codex from the day it's turned on, so your team can write blocking policy from real usage. To see what your agents can reach today, book a demo or request a free identity assessment.