What is AI Identity and Access Management and Where Should You Start?

On Tuesday afternoon, an engineer on your platform team connected a coding agent to your Git repos, your ticketing tool, and a production database through MCP. Nobody filed a request or approved anything, and the agent is now working with every permission that engineer has collected over four years. AI agent access management is the practice of deciding what each AI agent can reach, on whose authority, and for how long, and then proving what it did with that access.

Most of the agents your people run don't have access of their own yet. They borrow it from the humans who run them, which means your agent problem starts as a human-access problem. To govern them, you need answers to five questions about every agent: whether it exists on your books, what it can reach, who authorized it, what task it's performing, and what it's doing right now.

What makes AI agent access different from human access?

The access your people hold and rarely use goes live the moment an agent works on their behalf. Three things separate agent access from human access. Agents act on borrowed authority, they pick their tools at runtime, and they work at machine speed. Each one breaks an assumption your access model was built on: that the person using a permission is the person who earned it, that a role describes what someone will do, and that a reviewer has time to notice.

That combination changes the math on every entitlement you've ever granted. When we launched Lumos Labs, we put it this way: a permission that might sit dormant for a person can be exercised thousands of times by an agent. In July 2026, OpenAI disclosed that models in an internal cybersecurity evaluation, run with some safeguards deliberately lowered, chained a zero-day, privilege escalation, and stolen credentials to reach Hugging Face's production database. Read that as a lesson about reach: given a goal, an agent will use whatever credentials and paths it can find.

Take a sales engineer who still holds admin rights in your CRM from a data migration two years ago. The engineer hasn't touched that role since, so it sits quietly in a report nobody reads. Hand that engineer's session to an agent told to clean up duplicate accounts, and that dormant admin role becomes the agent's toolkit, exercised across every record it reaches in one afternoon.

The gap already shows up in breach data. In IBM's 2026 Cost of a Data Breach Report, roughly one in five organizations reported a breach involving their AI models or applications, and 92% of those lacked proper AI access controls. Access management for AI agents is an old problem running at a new speed, and it has a known fix.

How to discover every AI agent connected to your apps

You can't govern an agent you don't know exists, and most of yours arrived without a request. They come in through four doors: engineers add MCP servers to coding agents on their laptops, teams build agents inside the SaaS apps they already use, employees connect AI apps through personal OAuth consent, and browser agents ride sessions that are already signed in. None of those doors runs through your access-request queue or the identity governance software behind it.

Personal OAuth consent is the quietest door. An employee clicks "Allow" on an AI app's consent screen, and the app walks away with a token scoped to that employee's mail, files, or CRM records, with no ticket behind it and often no entry in the app inventory your team reviews. Pull OAuth grants from your identity provider and the admin consoles of your largest SaaS apps because that's where those consents leave a trail.

Discovery has to happen where agents connect, because that's the only place they show up. Lumos MCP Governance records every MCP server and tool call as people work, including servers employees added locally with no admin approval. We see browser agents as the next blind spot, since they can use signed-in sessions to reach apps without ever touching MCP.

Every agent you find needs a home and an owner. Lumos catalogs every agent and non-human identity it discovers and assigns each one a human owner. Pinterest already runs Lumos as the de facto software inventory for more than 8,000 employees, and agent connections belong in that kind of inventory, next to the apps people already use.

Start each inventory entry with four fields: the agent, the human it runs for, the connections it uses, and the job it exists to do. Any agent without a human attached is your first problem to fix.

What permissions does an AI agent inherit from its user?

An agent's access is only as narrow as the access of the person it works for. An agent running in an employee's session inherits that person's entitlements, including any the employee stopped needing two reorgs ago. Add whatever its connections allow and any credential it can read, and you have its effective access, which is the honest answer to what your AI agent permissions really are.

Connections tend to be the widest layer. An MCP server or OAuth app asks for its scopes once, at setup, and people approve the broadest option so the integration works on the first try. The agent then carries those scopes into every task, including the ones that needed only read access.

We've watched the gap between intended and effective access open up in live agent activity. In one case we described when we launched MCP Governance, what looked like an agent making simple calls to Retool's MCP server turned out to be running arbitrary TypeScript against a read-write Salesforce connection, and the agent wrote updates along with its reads. The OpenID Foundation's whitepaper on agentic AI identity argues that agents should stop impersonating the users they serve and act under delegated authority instead. The operator's version of that argument is attribution: when an agent acts as the user, your logs can't tell the two apart, so AI agent identity management has to keep the agent visible as its own actor.

The fastest way to shrink what agents inherit is to right-size the access of the people they borrow from. Netskope cut standing access by 80% with Lumos, using usage-driven least privilege and just-in-time grants that expire on their own. Every entitlement you remove from a person is one no agent can borrow.

Map effective access per agent in three layers: what it inherits, what it was granted, and what it can reach. A support agent running under a team lead's account, for example, inherits that lead's admin role in the help desk app, holds a granted connection to the billing tool, and can read an API key someone pasted into a shared doc. Then cut the human layer first because one cleanup there shrinks every agent that person runs. Start with entitlements nobody has used in 90 days, since cutting them rarely breaks a workflow and they're exactly the dormant permissions an agent turns live.

Assign a human owner and an end date to every AI agent

Every agent needs a human owner who answers for it. We call that owner the sponsor, a role that comes with a short record: the business purpose, the connections the agent may use, and the date its access ends. Ownership is the control everything else hangs on, because reviews need a reviewer, approvals need an approver, and incidents need someone to call. Good service account security already bans shared credentials, and agents need the same rule: no agent should run on a team alias, a shared service account, or the credentials of someone who left..

AI agent lifecycle management works only if each agent rides its sponsor's lifecycle. When the sponsor changes roles, the agent's grants get a fresh look against the new job. When the sponsor leaves, the agent stops on the same day the sponsor's laptop gets wiped.. When the sponsor changes roles, the agent's grants get a fresh look against the new job. When the sponsor leaves, the agent stops on the same day the sponsor's laptop gets wiped.

Agents that hand work to other agents need the same chain of accountability. When an orchestrating agent calls a sub-agent, the sub-agent should get a subset of the parent's access, and the log should carry the original human all the way down. If a chain of agents can end up with more reach than the person who started it, you've built an escalation path.

Offboarding is where most programs leak. Disabling a departing employee's single sign-on doesn't always revoke the OAuth tokens and connections that employee's agents hold, so a leaver workflow that stops at the identity provider can leave agents running on borrowed credentials. Your offboarding has to reach those tokens too.

Unclaimed agents are where non-human identity sprawl starts. When discovery turns up one, treat it like an orphaned admin account. Disable it first, give its last known users a short window to speak up, and delete it if nobody does.

Agents can ride the same non-human identity lifecycle as your service accounts, with one addition: a named human on every record. Write the sponsorship rule this week and enforce it before the next agent goes live.

How long should an AI agent keep its access?

An agent should hold nothing between tasks. Standing access is the default failure mode for agents because a connection an employee approved once keeps working long after the task that justified it. For an agent, the right window is the task itself, which usually means minutes for a lookup and an hour for a change. Scope matters as much as time, since read access to one CRM report carries a different risk than write access to the whole CRM.

Scheduled agents follow the same rule. A reconciliation agent that runs at 2 a.m. needs its access for the length of the run, so grant it when the job starts and revoke it when the job ends.

The Salesloft Drift breach shows what standing access costs. In August 2025, attackers used OAuth tokens stolen from Drift, an AI chat agent wired into Salesforce, to pull data out of many companies' Salesforce instances and then searched it for more credentials, according to Google Threat Intelligence Group. MFA, the control most IAM tools lean on, never came into play, because a token is access that was already granted. The campaign stopped once Salesloft and Salesforce revoked every active access and refresh token the app held.

The fix is access that's scoped to the task and expires on its own, so a stolen token has a short shelf life. In Lumos, people and agents request access the same way: in Slack, in your ITSM tool, or through MCP. The platform checks each request against policy, grants it just in time, and revokes it on schedule.

At Code42, verified on-call engineers get access to sensitive databases within seconds during an incident, and Lumos pulls it back within hours with time-based access. The company cut privileged access by 67% across its tech stack and brought access-request resolution down to four minutes.

List every standing token and long-lived connection your agents hold, starting with the ones that touch production or customer data. Give each one an expiry this quarter, and send anything that needs to outlive its task back through a request. Check refresh tokens too, since an access token that expires in an hour protects little if the refresh token behind it stays valid for months.

AI agent authorization belongs outside the model

Instructions are not permissions. A rule written into a prompt tells an agent what you want, and nothing forces the agent to comply.

SaaStr founder Jason Lemkin found that out in July 2025. During an explicit code freeze and after repeated instructions not to make changes, Replit's AI coding agent ran destructive commands against a live production database holding records on more than 1,200 executives. The freeze lived in the agent's instructions while its credentials still allowed writes to production, and the credentials won. Replit's own fix afterward was structural: separating development and production databases.

The same gap works against you from outside. A prompt injection hidden in a support ticket, a web page, or a shared doc can steer an agent toward actions its sponsor never intended, and the model can't reliably tell a planted instruction from a real one. Since you can't patch an agent's judgment, limit what any instruction, planted or legitimate, is able to reach.

The control that holds is a policy decision made outside the model, before the action runs. Lumos MCP Governance runs a hook before each tool call, returns a decision to allow or deny it, and records the tool, its inputs, the human behind it, and the verdict. Albus, our AI agent, drafts those policies in plain language from the usage it has already observed, so the rules reflect what agents do in your environment.

Appropriate permissions still leave questions open. Your sales reps may need to update Salesforce as part of their jobs, but should their agents change hundreds of records in a single run? That's the question AI agent access control has to answer at runtime, one call at a time.

Tool names won't settle it on their own. When the input is an arbitrary shell command, the same tool can list a directory or delete one, and a browser click can open a menu or submit a payment.

List the actions you'd never want an agent to take on its own, and then turn each one into an enforced policy. If a rule exists only in a prompt, treat it as missing.

Where human approval belongs in AI agent governance

The instinct to keep a human in the loop for every agent action is understandable, but at agent volume that approval step turns into a rubber stamp. You've watched it happen to quarterly access reviews: hand managers hundreds of near-identical approvals, and they stop reading. Approval queues for agents fail the same way, only faster.

We take the opposite position. Routine, low-risk actions should run autonomously under policy, people should approve the sensitive boundaries and the exceptions, and everything should get reviewed after the fact. That last step is where governance earns its keep: in Lumos agentic access reviews, Albus runs the first pass, Lumos certifies safe access on its own, and people see only the items that need a human call. Sun Country Airlines saved 50 hours a quarter by automating its access reviews with Lumos.

Policy does the sorting before any review happens. The matrix below decides which agent actions run on their own and which wait for a person.

‍

Here's how it plays out. A coding agent reading production logs gets an automatic grant, and its sponsor gets a notification. The same agent trying to flip a production feature flag waits for its sponsor's approval and gets a one-hour window, and an agent about to change hundreds of customer records in Salesforce lands in that same cell. Bulk reads of sensitive data sit in the bottom row on purpose, since no rollback brings exposed data back.

A few rules never bend, because they enforce separation of duties for software. An agent can't approve its own request or another agent's, can't extend its own access, and can't edit the policy that governs it or switch off the logs that record it.

When policy denies an action, send it to the sponsor as a request with the context attached: the agent, the task, the action it tried, and the rule that stopped it. A denial that dead-ends pushes engineers to work around it by handing agents broad standing tokens, which puts you back where you started. An approval the sponsor can grant from Slack in a few seconds keeps the boundary in place without stalling the work.

Sort your agents' current permissions into the nine cells this month. Anything in the bottom row that runs without an approval today is your first fix.

How to build an audit trail for every AI agent action

Your next SOX or SOC 2 audit will ask about agents, and "we told it not to" won't count as a control. Auditors will want four things for each agent: the sponsor and purpose, every grant with its approver and expiry, every revocation, and a record of each tool call with the human behind it.

Attribution is the part that breaks first. When an agent changes a SOX-scoped app under a person's credentials, the change has to be traced to both the agent and the person, or the evidence falls apart. Reconstructing that trail from chat transcripts after the fact won't satisfy anyone, least of all the auditor.

That evidence should come from the same user access review software that already produces your human-access evidence. ChargePoint uses Lumos to pull in access data, run access reviews, and notify reviewers in one place, which helps it stay compliant across SOC 2, SOX, PCI, FedRAMP, and ISO 27001. Agent grants and tool calls belong in that same record, next to the human access your auditors already trust.

Picture the record you want to hand over: a release agent, sponsored by a named engineer, received write access to the payments repo for 45 minutes on a specific date, its sponsor approved the grant, and the call log shows the one commit it pushed. If you can produce that for every agent in scope, the audit conversation gets short.

Add agents to the scope of your next access-review campaign. Do it before an auditor adds them for you.

A five-question checklist for AI agent access

Start with five questions and the agents whose mistakes would hurt most. We'd put three kinds of agents first: the ones that move money, the ones that change production infrastructure, and the ones that work with sensitive customer data. That's where a mistake carries the biggest consequence and where an unanswered question costs the most.

Run each of those agents through the checklist below. Every question you can't answer goes on the worklist, and the five questions turn AI agent access management into a finite list of fixes. A "we don't know" on the first two questions is the most expensive answer on the sheet because every other control depends on them.

‍

Your first month follows from the table. Inventory those agents, assign each a sponsor, expire their standing tokens, and put runtime policy on every action in the bottom row of the approval matrix. Rerun the checklist every quarter because new agents will show up between audits whether you approve them or not.

Identity governance has to move at agent speed

Your access model was built for people who act slowly, intermittently, and mostly during business hours. Software now exercises that same access continuously, at machine speed, on everything its human could reach. Quarterly reviews and ticket-queue approvals can't keep up, and agents won't wait for them.

Governing that access at agent speed means discovery that never stops, grants that expire on their own, and policy that decides before every action. Your agents already work on autopilot, and their access should too.

Keeping up with agents takes agents of your own, and the Lumos Identity Agent Force puts a team of them on your access program. One catalogs every agent and non-human identity in your business and gives each a human owner; another grants access for exactly as long as a task needs and revokes it on its own; and a third shuts down service accounts, keys, and tokens that sit dormant or overscoped. Lumos MCP Governance covers the runtime gap by checking agent tool calls against your policy before they run. You turn your approval matrix into policies, guardrails, and approval thresholds, and the agents apply them around the clock.

Albus, the AI core of Lumos, explains the reasoning behind every recommendation and captures the evidence that justifies it, so your audit trail fills in as the work happens. Ask it which service accounts haven't been used in 90 days or who holds dormant admin access, and you'll have the list before an agent finds that access. Albus also runs alongside the identity governance and ITSM tools you already use, so you can start with your riskiest agents without a rip-and-replace project. Book a demo to see how Lumos maps what your agents can reach today and puts their access on autopilot.

‍