How to Audit and Certify AI Agent Access Rights an Auditor Will Accept

The auditor's request list arrives with a line that wasn't there last year: every AI agent with access to in-scope applications, and evidence that its access was reviewed. Your access review closed in June. Nobody on your team can say whether the coding agents, the service desk agents that shipped with the ITSM upgrade, or the AI app half the sales team approved through OAuth were in it.

To audit and certify AI agent access rights, you first establish, without relying on the people who'll sign off, which agents exist, what each can reach, and what each has used. Then an accountable person keeps, narrows, or revokes each grant, and you prove the change took effect.

Auditors test every access certification against three core questions: whether the population was complete, whether reviewers could judge each grant, and whether the removals happened. AI agents break all three, because many never appear in your directory, their last-used timestamps can't show which grant they exercised, and their tokens can outlive a revoke. Closing those gaps takes seven steps, and each one comes with the evidence an auditor will ask for and a move you can make before your next campaign.

1. Prove your AI agent inventory is complete with a two-source check

Before anyone certifies a single agent, prove you've found all of them, because completeness is the first thing an auditor tests. For SOX audits of public companies, PCAOB AS 1105 spells it out: an auditor who relies on information you produced, such as the population behind an access review, has to test its accuracy and completeness or the controls that keep it that way. The standard also asks whether that information is precise and detailed enough for the audit.

An agent population pulled from your identity provider fails both tests. Many agents never pass through it, and a list that names agents without their grants can't support a single certification. Agents reach your apps through doors that skip the request queue, from MCP servers on engineers' laptops to personal OAuth consent. That's why discovery is the first job in AI agent access management and in any audit of it.

An AI agent access audit builds the population from independent sources. Each of the six below sees a different slice, and the last two are where you see agents act.

‍

Every agent should appear in at least two of these sources, once where it's registered and once where it acts. An agent that shows up only where it acts is unregistered. One that shows up only in a registry is dormant access or activity you aren't collecting yet, and both go on the findings list, with the dated reconciliation as the first exhibit in your AI agent audit.

Tool-call records are the source most programs lack for coding agents, which run on engineers' laptops where no directory sees them. In the coding agent clients it covers, Lumos MCP Governance records every MCP server and tool call as people work, including servers employees added locally, which no vendor API can enumerate. The Agent Ownership Finder in our Identity Agent Force catalogs agents and non-human identities and assigns each one a human owner, so a new agent gets an owner before it gets to work.

An agent with no owner can't be certified, so it goes straight to disable and stays out of the campaign until someone claims it. Run the two-source check for one in-scope application this week, and log any agent that appears in only one source as a finding.

2. Break each agent's access into grants a reviewer can decide

With a complete population in hand, certify each agent one grant at a time: which agent, which resource, what scope, and on whose authority. A yes on the whole agent approves all its connections at once.

Agent access comes in three kinds of line items: grants the agent holds itself, access it borrows from the person it runs for, and credentials held by the tools it calls. The first kind covers OAuth client scopes, service account roles, API keys, and connections. Which kind dominates depends on how the agent gets its identity, which is where AI agent identity governance starts. Review templates skip the third kind, yet an agent with narrow rights of its own can still reach whatever its tool's credential allows, so give that credential its own line item and owner.

Grants on old non-human apps have a famous precedent. In January 2024, Microsoft Threat Intelligence reported that Midnight Blizzard compromised a legacy test OAuth application that still had elevated access to Microsoft's corporate environment. The attackers then used it to grant OAuth apps they controlled the Exchange Online full_access_as_app role, which allows access to mailboxes. The dangerous access sat in a grant on an app built for testing, and agents get most of their access through exactly that kind of grant.

Some frameworks already demand a line-item view for machine accounts. PCI DSS v4.0.1 Requirement 7.2.5.1 calls for periodic reviews of all access by the accounts that applications and machines use, at a frequency your targeted risk analysis sets. Each review confirms the access still fits the function performed, fixes anything that doesn't, and records management's acknowledgment. Read "function" as the agent's stated purpose, and judge every grant against it.

Then route each line item to someone who doesn't benefit from it, the same separation-of-duties rule that runs through AI agent access control: nobody certifies access that works for them. The agent's owner attests to purpose and need, and the owner's manager or the app owner signs the certification. Borrowed access gets certified by the person's manager in that person's own review, with the agent's use shown alongside, and a tool's credential gets certified by the tool or app owner. That chain of names is what AI agent accountability looks like on paper.

Reviewers can only decide grants they can read. The Entitlement Analyst in the Identity Agent Force translates permissions into plain English, so approvers see what a grant allows before they decide. With Lumos, GitLab removed unneeded admin access and set up just-in-time access for critical entitlements, which is the grant-level decision in practice: the admin layer comes off, and the access people use stays.

For your ten highest-risk agents, write all their grants as separate rows before the campaign opens. Name a certifier on each row, and log any row nobody will sign as a finding.

3. Judge AI agent usage by tool calls in every access review

Once each grant is its own row, the reviewer needs evidence of use, and last login and peer comparison, the two signals human reviews lean on, tell you little about an agent. Both assume an identity that signs in as itself and sits in an org chart.

We see the gap from the other side, because we built an AI agent to review people's access. Two of the engines in Albus, our identity AI agent, run on exactly those signals in its first pass. One checks whether each person used a specific app or permission set in the last 90 days and pre-fills a remove decision for dormant access, and another compares people with peers grouped by department, title, and manager.

Point that logic at an agent and both signals fail. A credential's last-used time, where your platforms record one, can't tell you which grant the agent exercised, and an agent has no HR record to group it by.

The worse problem is that an agent can launder dormant access. Agents acting in someone's session often show up in an app's activity logs as that person, so once an agent exercises a person's forgotten admin role, a usage-based review sees the person using it and keeps the role. Many apps record the OAuth client or service account next to the user, though, and splitting usage by that field shows whose activity it was.

Every signal a human review leans on needs a replacement when the identity is an agent. Most of the replacements come from tool-call records and app audit logs.

‍

For coding agents, Lumos MCP Governance records the tool, the server, the inputs, the person behind each call, and the policy verdict. It never sends or stores prompts, model responses, or tool results, so the evidence describes the access without copying the data it touched. At Lumos, with fewer than 200 employees, we measured more than 450,000 agent actions in a single week, and nobody certifies actions at that volume, so certify grants, keep the calls as evidence, and let the auditor sample them.

The last table row is where reviews meet AI agent lifecycle management, since a new tool, a model swap, or a wider scope should trigger a fresh look at the grants it touches. Treat those changes as the agent's version of a mover event, and pull them into the next campaign automatically.

To audit AI agent activity before your next campaign, pull 90 days of activity for the agents in scope from tool-call records and app audit logs. Mark every grant nothing has used, and start your revocations there.

4. Certify AI agent access with four decisions backed by evidence

Give every reviewer four choices: keep, narrow, revoke, or escalate. Most agent grants worth keeping are worth keeping smaller, and a reviewer who can only approve or revoke will approve the oversized grant every time.

You've watched the failure this fixes. Hand a manager thousands of entitlement rows with no context, and the review collapses into what we've called "Select All > Approve". Agent grants make it worse, because the rows read like OAuth scopes and connection names most managers have never seen.

‍

The default does more work than the rubric. A grant nothing used in the window comes off unless its owner explains it, which flips the burden of proof that keeps dormant access alive. Agents that run quarterly or annual jobs are the usual exception, and the owner's explanation is where they belong.

Checkr already runs the same remove-unless-used rule for its people's app licenses: it used Lumos to analyze when each employee last used an app across dozens of integrations, and inactivity workflows reclaim the licenses nobody touches. We hold our own review agent to the same evidence standard in our agentic AI security work. Albus labels each recommendation Safe, Caution, or Risk with a plain-language explanation and captures the evidence behind it, such as peer usage data and last-login timestamps for people.

Cloudflare learned what the opposite default costs. After Okta's October 2023 compromise, Cloudflare failed to rotate one service token and three service accounts, out of thousands of leaked credentials, because, in its own words, "mistakenly it was believed they were unused." An attacker Cloudflare believes was a nation-state actor used them to get in that November and established persistent access to its Atlassian server on November 22. Access that's idle by assumption is still live access, so the evidence has to prove a grant is in use before it stays.

Put the four decisions and the default-to-revoke rule into your campaign instructions before the next cycle opens. Put the usage evidence on the review screen, so reviewers decide from it.

5. Make automated access reviews auditable when AI agents decide

This step flips the subject: the agent in question is the one doing the reviewing, and the auditor wants to know when its first pass can be trusted. The answer is when they can see the rule it followed and the evidence behind each recommendation. We ship an agent that does this work, so these are the conditions we'd want an auditor to test on ours.

Two pieces share that work in our user access review software. Albus scores each item Accept, Reject, or Review with an insight category, such as Inactive, Unusual Access, or Non Human for service accounts, and when AI insights are switched on, they appear in the Auditor Report. The Access Review Agent runs the campaign end to end, certifying safe access on its own and escalating only the items that need a human decision, and copilot mode holds every recommendation for a person.

Rules a person approved can carry most of the volume. Intercom moved to rule-based reviews with Lumos, so IT can handle 90% of reviews and escalate only true exceptions. Before that, owners had to review every user's access by hand, in what its story calls "a painful quarterly ritual."

Five conditions make an automated first pass hold up. Meet all five, and AI agent auditability stops being an argument with your auditor.

1. A signed policy. The auto-certification policy is written, versioned, and approved by a named person, because that approval is the control an auditor tests.
2. A narrow scope. The agent auto-certifies only what the policy calls safe, such as birthright access and grants that are unchanged, in use, and low in sensitivity. Production writes and separation-of-duties conflicts always go to a person.
3. Evidence on the record. Each recommendation keeps the evidence behind it, and that evidence lands in the record the auditor sees.
4. A supervised first cycle. The first campaign runs in copilot mode, with people making the calls, so you can compare their calls with the agent's.
5. Ongoing sampling. A person samples auto-certified items every cycle after that.

Write the auto-certification policy down this month and get it signed before the agent applies it. If nobody will sign it, the agent shouldn't apply it.

6. Verify every AI agent access revocation at the app that issued it

Whether a person or an agent made the call, a certification campaign ends with a list of revocations, and an auditor will ask you to prove each one happened. For agents, that proof has to come from every app that issued the access, because a status in the review tool proves only that someone clicked.

The Salesloft Drift breach shows how many places one agent's access can live. Google Threat Intelligence Group reported that attackers used OAuth tokens stolen from Drift, an AI chat agent connected to customers' Salesforce instances, to pull data from those instances between August 8 and at least August 18, 2025. Salesloft and Salesforce revoked all active access and refresh tokens the Drift app held there on August 20.

Google's August 28 update added that tokens for a second integration, Drift Email, had been used to reach a very small number of Google Workspace accounts. It advised treating all tokens connected to Drift as potentially compromised. An agent's access is issued by the apps it connects to, so a revoke has to land, and be checked, in all of them.

"At the source" means something specific for each kind of agent access. Revoke an OAuth grant at the provider along with its refresh token, delete a service account key at the cloud provider, remove a server from the client's configuration, and rotate any credential a tool held. Then run two checks: re-pull the entitlement from the source after remediation, and look for activity after the revoke time in tool-call records and the app's audit log. Any action that lands after the revoke means the revocation failed.

When a reviewer rejects access in Lumos, the platform triggers deprovisioning, a role downgrade, or license removal in the downstream app and logs each action. At Sun Country Airlines, Lumos made rejected access revocable automatically and let the team attach evidence of removal to the review itself, and the airline completed its next required SOX review without delays. For coding agents, MCP Governance keeps a per-user history of the calls in the clients it covers, so any call after the revoke time stands out. For agents inside SaaS apps, run the same check against the app's audit log.

Re-pull this cycle's revocations at their source within a day, and file the before-and-after with the campaign record. A revocation you can't show at the source never happened, as far as your auditor is concerned.

7. Prepare AI agent access reviews for SOX and SOC 2 audit testing

Your SOX or SOC 2 auditor will test the review itself: whether it covered every agent, whether reviewers could spot a bad grant, and whether removals happened on time. Expect two more questions on top of those three core tests, about any access kept as an exception and any decision a rule or an agent made. The AI agent audit trail, the record of who authorized each agent and which actions it took, is evidence for those tests, but it can't show that the review itself was complete.

If you want to know how to audit and certify AI agent access rights in a way that survives fieldwork, start from those five tests and work backward. Auditing AI agents gets easier once you know, for each test, the evidence that passes and the way agent reviews usually fail.

‍

The evidence in that table belongs in the same identity governance software that holds your human access evidence, since that's the record auditors already trust. Lumos access reviews capture evidence at each step and produce one-click reports formatted for SOC 2, SOX, and ISO 27001. Code42 went from building reports for its auditors by hand to generating them with the click of a button, and a record assembled as the review runs is the one that survives sampling.

The audit profession is landing in the same place. An ISACA industry piece from September 2026 on auditing agentic AI workflows argues that agents need the same review process with added scope, including scope testing for agents that act on delegated authority. If you've adopted NIST SP 800-53, control AC-6(7) already asks you to review, at a frequency you set, the privileges of the roles or classes of users you define, to confirm the need still exists.

So name AI agents as a class in your control description, with a review frequency. If you leave them out, an AI agent security audit will find them for you.

Send your auditor the reconciliation and the four-decision rubric before fieldwork starts. Ask which agents they plan to sample, and pull those agents' records first.

AI agent access certification is a claim you'll have to prove

Agents change faster than any campaign, and your auditor will still test the campaign. Every certification you sign claims the list was complete, the grants were judged on evidence, and the removals landed, and agents give each of those claims a new way to fail.

Reconcile the population this week, run the four decisions this cycle, and verify the revokes within a day of the campaign closing. Do that, and the agent line on next year's request list takes an afternoon. An agent you can't prove you reviewed counts, to an auditor, as one you never reviewed.

Lumos runs the parts that don't scale by hand: MCP Governance records the coding agents and local MCP servers your directory never sees, the Identity Agent Force gives agents owners and runs reviews end to end, and Albus shows the evidence behind each recommendation. Book a demo to see your agent population reconciled before your next audit.