How Do You Prevent Unauthorized AI Agent Access?

Your quarterly access review closed clean last month. This morning, a coding agent changed a production setting using an engineer's cloud credentials. A sales assistant exported a customer list under an OAuth consent a rep clicked last spring, and a pilot agent nobody remembers still holds a token to the data warehouse. Nothing blocked any of it, because every permission involved was real.

To prevent unauthorized AI agent access, give each agent grant an owner, a reason, and an end date, re-decide it in each access review, and enforce each decision at the source app and the agent's next tool call. The source app is whichever app issued the access, from your CRM to a cloud console. Unauthorized AI agent access is any access an agent holds or uses without a current decision by someone accountable for it. Because the permission itself is real, it slips past the checks you already run, so the work starts with decisions.

Each step below turns one of those missing decisions into a record you can check. Some decisions take minutes, like naming an owner, and some take a full review cycle to get right. The five steps run from the moment an agent arrives to the day its access expires, with a short checklist at the end to catch anything that slips through.

1. Assign an owner and a business justification to every AI agent

Every agent needs a named owner and a written business justification (the reason it needs what it holds) before it touches anything. Those two fields are the decision everything else checks against. The Cloud Security Alliance's July 2026 paper defining non-human identity makes the same call, telling teams to "assign human sponsors and oversight owners" to agent identities and to settle ownership at onboarding, before production.

Your auditors already work from this idea. CC6.2 of the AICPA's Trust Services Criteria expects you to register and authorize each user whose access you administer before issuing credentials, and to remove those credentials once access is no longer authorized. Treat each agent as one of those users, and any grant comes down to two questions. Is there a decision on record, and is it still current?

A usable justification is specific enough to test. "Helps the sales team" tells a reviewer nothing, while "drafts renewal emails from open CRM opportunities, read-only" shows which scope to approve and which to cut.

The Agent Ownership Finder in Lumos's Identity Agent Force catalogs agents and non-human identities and assigns each one a human owner, so new agents get an owner before they start work. For service accounts and other machine identities from AWS, Entra ID, and OpenAI, our Non-Human Identity Inventory (in beta) adds Owner and Business Justification fields you set once. Access reviews read from that same inventory, so the justification is already on record when the grant comes up for review.

Coding agents are the hardest to find, because engineers add tools on their own laptops. Lumos MCP Governance, now in beta, shows each MCP server and tool call those agents make as people work, approved or not, including locally added servers. Each call is recorded with the person behind it, the tool, the server, and the policy verdict, while prompts, model responses, and tool results are never sent or stored. Shadow AI agents in those clients surface with that person attached, so each one gets an owner and a justification or gets cut.

A consent screen is the quietest way an agent arrives with no decision. An AI agent OAuth grant that an employee clicked through carries real scopes and no owner, and it sits in your identity provider's connected-app list until someone looks. Agents also arrive through SaaS upgrades and local installs, which is why discovery is the first job in AI agent identity and access management.

Set one rule for the agents you find: if nobody claims one within two weeks of discovery, suspend its access. By the end of the month, pull each OAuth grant to an AI app and each agent in your call records, and give it an owner and a justification.

2. Audit the human access your AI agents inherit

Your AI agents inherit the human access of the people they run as. A coding agent on an engineer's credentials, or an assistant working in a rep's session, can use any grant that person ever collected, including ones granted for a project that ended two reorgs ago. So the fastest way to find undecided agent access is to read those people's full entitlement lists.

Each of those grants was decided for a person working at human speed, and none was decided for an agent that runs at machine speed. That's how a dormant admin right turns into AI agent privileged access without a single new approval. It's also the first thing AI agent identity governance has to account for.

That inheritance also explains why so few teams can say who approved what an agent does. In Delinea's 2026 identity security survey of 2,254 IT and security leaders, only 36% could always trace a sensitive AI access event back to a named human authorizer. An agent's access tends to trace back to a person's click or a person's role, and rarely to a decision about the agent itself. Your other non-human identities carry the same gap, since service accounts and API keys often outlive the people who created them.

Each grant on those entitlement lists needs one of two outcomes. Either the person still needs it, and someone decides whether their agents may use it too, or nobody needs it, and it comes off before an agent finds it. Expect the second group to be large, because people collect access over the years and rarely lose it. Trimming that excess comes first in how to secure AI agents, because a delegated agent can reach anything its person can.

In Lumos, the Entitlements tab on the identity view lists the active entitlements a person holds across connected apps, and Albus answers audit questions in plain language, such as "Who has dormant admin access?" With both in one place, a full audit becomes practical for the people whose agents carry real reach.

Tristan Cary, Senior Manager of IT at Roku, described answering "who has access to what" as nearly impossible before Lumos. Now Roku can see who uses which apps, at what tier, and whether each person's role justifies the access. Those three facts are the audit for any agent running on that person's access.

Before your next review cycle, run this audit for the 20 people with the most agent activity. The dormant admin rights and unjustified grants it turns up become the first line items in step 3.

3. Review every AI agent grant against its business justification

An access review prevents unauthorized access only when each grant gets decided again against the justification its owner wrote down. That's what certifying a grant should mean. Without that test, a reviewer approves whatever the agent already holds, including scope an attacker can ride.

Tenet Threat Labs demonstrated the cost in research presented at DEF CON in August 2026. In its test, a triage agent reviewing blocked web requests read a log entry an attacker had planted, dressed up as a scanner finding about a missing email security record. The agent held a read connection for analytics and a write-capable API connection in the same session, and it used the write connection to repoint the domain to the attacker's server before reporting the issue resolved. Tenet's verdict on the chain was that "every step was authorized."

One review question would have stopped it. Does triaging blocked requests need write access to DNS? The justification answers that in seconds, and the same test is how to limit AI agent access everywhere: approve only the scope the justification needs. Tenet's planted log entry is also why AI agent access security best practices treat any field an outsider can write as a possible instruction to the agent.

How do reviewers make that call across thousands of grants? In Lumos access reviews, the Access Review Agent runs the campaign end to end, certifies safe access on its own, and brings people only the items that need a human call. Albus, the AI behind Lumos's agentic AI security, captures the evidence behind each recommendation, such as peer usage and last-login timestamps, and in copilot mode surfaces its recommendations for a person's approval.

Netskope chose Lumos to tackle problems common to identity programs, click fatigue and rubber-stamped reviews among them. Lumos analytics flag anomalies and route prioritized items to owners, so reviewers spend their attention where the risk is. A reviewer who sees ten grants that matter decides each one, and one who sees ten thousand approves them all.

The full procedure, from building the population to the evidence an auditor accepts, is how you audit and certify AI agent access rights. In your next cycle, make "does the justification cover this scope?" the first question on each agent line item, and narrow or revoke anything it doesn't cover.

4. Enforce access review decisions at the source app and the tool call

An access review decision prevents nothing until it's enforced at the app that issued the access and at the agent's next tool call. This handoff is the part of how to prevent unauthorized AI agent access that's easiest to skip.

Decided access tends to stay live in three places. Removals wait on a ticket or a manual app, removals fail without anyone noticing, and some narrowing can't happen at the source at all, because an app may offer an integration read-write access or nothing. When the app can't grant less, the tool call is the only place left to enforce "reads yes, writes no," and the table shows what each decision changes in both places.

‍

The tool-call column applies wherever a check sits in the agent's path, which today mostly means coding agents and other MCP clients. For agents built into SaaS apps or running on OAuth grants, the source column is the whole job, so removal there has to be fast and verified.

Speed matters as much as completeness. Between the moment a reviewer clicks revoke and the moment the source confirms removal, the agent still holds the access, and a deny rule at the call can close that window the same day. Set a target, such as removal confirmed at the source within one business day, and track each miss.

Sun Country Airlines had on-premise apps in its SOX scope that don't sync with a cloud identity provider. Lumos pulled review data from Active Directory, Azure, and the apps themselves, and rejected access could be revoked automatically with evidence of removal in its reports. Lumos access reviews can now run removals on the same deprovisioning workflows offboarding uses, where manual steps become tasks and failed removals become error tasks you can fix one at a time or in bulk. Evidence attaches to the review by file, link, or ITSM ticket.

For coding agents, the tool call can hold the line while the source catches up. MCP Governance runs a hook before each tool call and returns allow or deny. Albus drafts the rule for your approval from a plain-language description, such as blocking production database writes for one team's coding agent. It ships set to Allow, so nothing is blocked until you add a policy, which means visibility comes first and prevention starts with your first deny rule.

Proving a revoke landed is its own discipline, and the checks for verifying each revocation at the source belong in your campaign record. From now on, confirm each revoke and narrow decision at the source within a day, and write a deny rule for any write scope the app couldn't cut.

5. Replace standing AI agent access with requests that expire

Standing agent access is how revoked access comes back, so replace it with requests that expire. Access you revoke this quarter can return next month through a fresh OAuth consent, a local server someone re-adds, or a standing grant from a helpful admin. Writing that rule into your AI agent access policies, with an expiry required on each grant, keeps it from depending on one reviewer's memory.

Make the request the only door. Each new agent need goes through a request that records an owner, a justification, an approver, and an expiry, and a revoked tool stays denied at the call until a request is approved. A deny that explains itself and points to the request keeps people from hunting for a broader token, which is why AI agent access control treats deny design as part of the decision. A change event reopens the decision too, whether the owner leaves or changes teams, the agent picks up a new scope or server, or the task ends, using the same triggers that drive AI agent lifecycle management.

That door has to be faster than the workaround. If getting an agent approved takes a week and clicking a consent screen takes a second, people will click. Pre-approve low-risk scopes so most requests clear in minutes, and save a person's approval for write access, sensitive data, and anything that can't be undone.

In Lumos, the Access Request Agent in the Identity Agent Force grants access for as long as it's needed and revokes it automatically. Pre-approval rules run on Lumos's conditions framework and can be managed through MCP, the API, or Terraform, so routine requests clear on rules a person approved. Approval by Entitlement Owner can route each permission to the person who owns it, so each grant starts with its decision and end date on record.

Set a default expiry on agent grants approved this quarter, and make re-approval the only way to extend one. After one cycle, the grants still standing are the ones someone chose to keep.

Check your AI agents for the five types of unauthorized access

Once the five steps are running, check your agents each quarter against the five types of unauthorized AI agent access. Each type is missing a different decision, and the table maps it to the step that closes it.

‍

Attackers work the same five gaps through injected instructions, poisoned tools, and stolen tokens, and the catalog of AI agent security vulnerabilities covers that side in depth. To run the check, sample ten agent grants and write down who decided each one. Each blank is a finding, and its row in the table tells you which step to revisit.

Make every AI agent's access someone's current decision

Agents gain access faster than any campaign can review it, and your permission checks can't see access nobody decided. You close that gap with decisions: owners and justifications on your agents this month, a review that tests each grant against its justification this cycle, and a deny rule for each decision the source app couldn't carry. That's how you prevent AI agent security breaches that start with access everyone assumed someone had approved.

Unauthorized agent access isn't a permission you missed, it's a decision nobody made. Your agents spend access your people already hold, and Lumos already governs that access across 300+ integrations, down to who holds each entitlement and whether they use it. On the same platform, each agent gets an owner and a justification, its grants go through the access reviews your people already run, and coding agents' tool calls get checked against your rules. Book a demo to see where undecided agent access hides in an environment like yours.

‍