Your AI council approved its agent policy in the spring, and its risk register still leads with hallucination, bias, and model drift. Last week, a support agent working under a team lead's account issued a dozen refunds the team lead never saw, and no one can say who approved the agent, who owns it, or what it was allowed to touch. The register tracks what a model might say, and those refunds came from the access the agent was given.

Agentic AI governance challenges are the problems that stop a company from deciding, enforcing, and proving what its AI agents may do, on whose authority, and who answers for the result. Agents act through credentials and grants, so most agentic AI challenges are questions your identity program answers for people every day and has rarely been asked about agents. Hallucination, bias, and drift belong to model governance, and they matter, but none of them decides what an agent can reach.

The seven challenges in this article all come back to that question of reach: what an agent can do, on whose say-so, and who answers for it. They build on one another, so the first two shape how hard the other five are to fix. Each one comes with a test you can run against your own environment this week and a clear way to close it.

1. AI agent authorization breaks when agents borrow a person's access

AI agent authorization breaks down because many agents run on the access of whoever started them, carrying authority that person never decided to hand over. That's where most challenges with AI agents begin: a person's access was approved for the person, at the speed a person works. An agent running in their session inherits all of it, including grants they stopped using years ago, and when agents call other agents, the original person's authority gets harder to see with every hop. Borrowed sessions are only one of the access paths AI agent identity governance has to cover, but they carry the most authority with the least record.

We see it in the work agents already do. When Leo Mehr, Lumos's cofounder and head of Lumos Labs, announced our runtime controls for agents, he described employees driving agents to modify production feature flags, publish applications, and delete knowledge base files. As he put it when launching Lumos Labs, a permission that sits dormant for a person "can be exercised thousands of times by an agent."

The National Cybersecurity Center of Excellence at NIST treats delegation as an open problem. Its February 2026 concept paper on agent identity and authorization asks how to handle delegation when an agent acts on someone's behalf and how to bind each action "back to human authorization." The project drew more than 600 responses, and one approach in its summary is credentials that narrow as they pass down a delegation chain, until a sub-agent holds only what its immediate task needs. If NIST hasn't settled delegation for agents, don't assume your agent vendors have.

How to tell you have it

Take five agents with write access. For each one, name the person whose authority it uses and show the record where anyone approved the agent using that authority. If the best answer is "it signs in as them," the agent holds authority no one delegated.

How Lumos handles it

Each agent action traces to the person behind it, and policy can hold the agent to less than that person holds. MCP Governance, which covers coding agents today, records each tool call against the person who triggered it and can block a tool for agents even when the person could use it. Agents working in Lumos itself follow the same rule, acting only for the signed-in user and limited to the overlap of the scopes that user consented to and their Lumos role. Trimming the person's access narrows every agent that runs as them, and Code42 shows how far that can go: time-based access for its most critical applications cut its privileged access by 67%.

Before your next agent rollout, remove the admin and production access your heaviest agent users haven't touched in 90 days. Every grant you remove there is one no agent can borrow.

2. AI agent accountability gaps start with agents no one owns

AI agent accountability gaps open when no named person owns an agent, because responsibility for what it does then lands on the company that deployed it. Agents get built in a sprint, bought as a feature, or connected by an employee, and none of those paths asks anyone to answer for the agent afterward. Ownership is the field later controls read: reviews route to it, revocations go through it, and incidents start with it.

Courts have started treating software that makes decisions as acting for the company that deployed it. In Mobley v. Workday, a job applicant alleged that Workday's AI screening tools, used by employers he applied to, had rejected him. A July 2024 order by Judge Rita Lin of the Northern District of California let his claims against Workday proceed on the theory that it acted as those employers' agent. The court reasoned that the federal anti-discrimination statutes don't distinguish "between delegating functions to an automated agent versus a live human one," and in May 2025 it conditionally certified a nationwide collective of applicants 40 and over.

The case is still open, and a screening tool is a long way from an autonomous agent, but the lesson carries: handing a decision to software leaves the accountability in place and can extend it to the vendor. Inside your company, that accountability needs a name, and in every enterprise we've analyzed, 95% or more of non-human identities have no assigned owner. Settle who decides each recurring question about an agent, from approving it to retiring it, as part of your enterprise AI agent governance model, with one named role per decision.

How to tell you have it

For your ten widest-reaching agents, write down the one person who'd get the call if each did something wrong tonight. A team alias, "IT," or "the vendor" counts as a blank.

How Lumos handles it

Agents get owners as Lumos finds them, and each approval goes to the person who owns the permission involved. The Agent Ownership Finder in our Identity Agent Force catalogs agents and non-human identities and assigns each a human owner, and new agents get one before they start work. Approval by Entitlement Owner sends each approval to that permission's owner and alerts admins when no owner resolves, which turns a blank owner field into a task someone has to close. At Sun Country Airlines, Lumos routes each access review to the right manager or application owner, and the airline's managed service accounts and privileged access are now fully certified.

Make a named owner, with a backup, a required field before any agent gets credentials. Until an owner is on record, treat the agent as an open finding.

3. AI agent visibility stops at the agents someone approved

AI agent visibility usually stops at the AI council's approved list, which misses every agent that exists only as access. Agents arrive as features switched on inside SaaS apps, as OAuth consents an employee clicked, as keys created in AI platform consoles, and as local tool servers a developer added on a Tuesday, the same entry points behind many AI agent security vulnerabilities. None of those paths files a request, but each leaves a trace you can look for: a consent record, a key, an admin setting, or a configuration file on a laptop.

How to tell you have it

Put the approved-agent list next to four others: OAuth consents to AI apps in your identity provider, API keys in your AI platform consoles, AI features switched on in your SaaS admin settings, and the tool servers configured in your developers' coding agents. Anything on those four lists that's missing from the approved one is an agent your inventory missed. Those four places are where AI agent identity and access management starts.

How Lumos handles it

Lumos builds the inventory from those traces, discovering service accounts, agents, and workload identities across your identity provider, cloud infrastructure, and SaaS apps. Its non-human identity inventory, now in beta, also pulls from AI platforms such as OpenAI and Anthropic and flags Anthropic keys that never expire or are tied to a person. MCP Governance adds the local MCP servers, shell scripts, and browser use in each person's coding agents, including servers no vendor API can list. Roku already manages SaaS access, licensing, and entitlements from a single view in Lumos, and agents belong in that view next to the people whose access they carry.

Repeat the comparison every month and track what appears on only one list. Each item tells you which path your intake process doesn't cover yet, and closing those paths is where AI agent lifecycle management begins.

4. AI agent least privilege breaks when the task isn't known in advance

Least privilege assumes you know what a job needs when you grant the access, and an AI agent decides its own steps after the grant is made. Scope an agent tightly and it fails halfway through a task, so teams grant broad access to keep it working, and that grant stays long after the task ends. The leftover breadth decides how far an agent's mistake can travel, which makes it the amplifier behind the other agentic AI risks on this list.

Picture a coding agent asked to fix a failing test. In one session it might read production logs, change a configuration file, restart a service, and open a pull request, and each step needs a permission no one listed when the agent was approved. Working out how to secure AI agents starts with sizing access for what an eager agent might try. The answer is to decide each action when the agent takes it, which is the approach behind AI agent access control: the check happens at the call, against the person the agent is acting for.

Access built to expire already works for people. With Lumos, Netskope cut standing access by 80% using just-in-time grants that give the exact permission for the exact time, expire on their own, and log full evidence.

How to tell you have it

For one agent, compare what it's allowed to do with what it did in the last 30 days. If the grant is many times wider than the use, or no one can say which permissions it'll need next week, its access is wider than its work.

How Lumos handles it

Agent actions get decided when they happen, and task access ends with the task. MCP Governance runs a hook before each tool call a coding agent makes and returns allow or deny, and teams start with visibility, then turn on blocking one tool at a time, with Albus drafting each policy from the usage it already sees. For access people request, Albus recommends the shortest window that fits, and the access expires on its own.

Choose one agent with write access to production and move its riskiest permission to a per-call or time-bound decision this quarter. Start with the permission whose misuse you couldn't undo.

5. Human-in-the-loop approval can't keep pace with AI agents

Human-in-the-loop approval breaks down at agent volume, because a person asked to approve each action eventually stops reading what they approve. At Lumos, a company of fewer than 200 people, we measured more than 450,000 agent actions in a single week. No approval queue keeps its attention at that volume.

Anthropic has measured what happens to the approvals that remain. In a March 2026 engineering post on Claude Code's auto mode, it reported that users accept 93% of permission prompts and that over time this leads to "approval fatigue, where people stop paying close attention to what they're approving." Its answer was to hand routine approvals to classifiers built to catch the dangerous actions. An approval granted nearly every time is barely a decision anymore.

How to tell you have it

Count last month's approvals for agents and agent requests, how many your team declined, and how long each took. A decline rate near zero, with approvals made in seconds, means people are clicking through.

How Lumos handles it

People set the rules and decide the hard cases, and agents handle the volume inside those rules. In our Identity Agent Force, you set the policies, guardrails, and approval thresholds, and the Access Review Agent certifies safe access on its own and brings people only the items that need a human call. Albus starts in copilot mode and explains each recommendation. For people's access, Tekion already works this way, with more than 1,500 requests a month and 95% resolved without manual intervention.

Write the approval your team grants most often into your AI agent access policies as a rule with a threshold, and send only the exceptions to a person for one cycle. Those exceptions are where your reviewers' attention belongs.

6. AI agent audit logs miss who authorized each action

AI agent audit logs record what an agent did, and your auditor will ask who it acted for and who authorized it. App and model logs record the action under whatever account ran it. An agent working in a person's session looks exactly like the person, and an agent on a shared service account looks like no one in particular. Neither log shows the approval, the policy in force, or whether the action stayed inside what someone authorized.

Regulators have started asking. FINRA's 2026 Annual Regulatory Oversight Report, written for broker-dealers, includes a new section on AI agents that names the risk of agents acting outside the user's actual or intended scope and authority. It warns that multi-step agent reasoning can make outcomes "difficult to trace or explain," and it asks firms to consider tracking agent actions and decisions and monitoring the access and data agents touch. Expect your own auditors to ask the same questions.

How to tell you have it

Choose one agent action from last week and try to produce, within an hour, the person it acted for, the decision that allowed it, and the policy in force at the time. Anything you can't produce is a gap an auditor will find first.

How Lumos handles it

MCP Governance logs every coding agent tool call with the tool, server, inputs, human identity, and policy decision, and never sends or stores prompts, model responses, or tool results. When our Access Request Agent works a Jira Service Management ticket, it records the originating actor, the service desk agent who assigned it, and the agent and its version, and every decision in Lumos access reviews is stored as audit evidence. ChargePoint already works this way for people's access, with approvals delegated to managers and Lumos audit logs that show the team what happened.

Add the acting person and the policy decision as required fields in every agent log you send to your SIEM, and reject any new agent that can't produce them. Those fields are what let you certify AI agent access in a form an auditor will accept.

7. Agentic AI compliance outpaces the frameworks auditors test against

Agentic AI compliance has run ahead of the control frameworks you're audited against, which were written before agents took on real work and don't yet tell you how agents fit. A systematic review by University of Illinois researchers, a preprint accepted for AIR-RES 2026, found no dedicated agentic AI governance framework outside Singapore's voluntary one. NIST lists single-agent and multi-agent use cases for its planned SP 800-53 control overlays but hasn't published them. The enterprise AI agent governance crosswalk maps today's AI frameworks clause by clause, and until those overlays arrive, fitting agents into them is your job.

Regulators are saying the same thing out loud. The UK Financial Conduct Authority's Mills Review, published in July 2026, says the Senior Managers Regime still applies as AI becomes more autonomous, but "firms and regulators will need to work through how it operates." It also says firms remain responsible for the services they provide, including where they use third-party models or agentic tools. The rules will arrive late and ask familiar questions: who had access, who approved it, and who reviewed it.

How to tell you have it

Ask your GRC lead which control in your current audit scope covers an agent's access. An answer of "the same as service accounts," with no agent-specific evidence behind it, is the gap.

How Lumos handles it

Lumos identity governance software builds the evidence as governance runs, with people, machines, and agents in one audit trail. Published Lumos access policies keep draft versions and a version history that shows an auditor which rule applied on a given day, and Albus captures the evidence behind each recommendation. Prosper centralized compliance for all its apps in one place and completed access reviews in record time with Lumos user access review software, and evidence kept that way is the easiest to extend when a framework adds agents.

Ask your auditor this quarter how they plan to test an agent's access, and bring the evidence you'd show for one agent today. Whatever they ask for is the evidence to start collecting now.

Every agentic AI governance challenge traces back to an access question

Every agentic AI governance challenge above comes down to a question about access, which means one access program can take on all seven. The table lines up each challenge with the question underneath it, the test to run this week, and how Lumos handles it.

‍

Start with authority and ownership, because an agent with no owner and no traceable authority can't be scoped, reviewed, or explained. Once those are in place, the AI agent governance best practices that keep agents on the governed path handle the speed of approvals and the side doors agents find on their own.

Run the seven tests this month, settle authority and ownership first, and take the other five in order of how many agents each one touches. The table is the slide your AI council asked for.

Answer the access questions before the next agent arrives

Go back to the sales assistant that emailed 400 customers from a vice president's account. The tests in this piece would have caught it three times: it ran on the VP's authority, no one owned it, and its log showed the VP sending the emails.

Your AI council will keep approving agents, and each one will act through access someone either decided on or didn't. Model governance decides what an agent says, and access governance decides what it can do, on a faster clock than most identity programs were built for.

Lumos approaches agentic AI security from the access layer, tying agent actions to the people behind them, holding coding agents to policy before each call, giving agents owners, and keeping one audit trail for people, machines, and agents. Book a demo to run the seven tests against your own apps.

‍