AI Agent Access Review: A Quarterly Permission Audit

An AI agent access review is a scheduled check that compares what each agent can reach (its tools, data scopes and approvers) with what its role requires today. Run it every quarter, record each decision, and remove any grant the role no longer justifies. The goal is not a perfect permission list on the first day but a repeatable habit that catches access granted for a pilot and never withdrawn.

Key takeaways

• Review every agent's tools, data scopes and approvers against its current job, not against the setup it had at launch.
• Use the written role statement as the standard. Anything the role does not need is a candidate for removal.
• Treat approvers as part of the access model. An approver who left the company or changed roles is a broken control.
• Keep a dated record of each decision so the next review starts from evidence instead of memory.
• Revoke unexplained access first and discuss it second. A narrower permission can be restored through a recorded request, but data that was exposed cannot be taken back.

Why agent permissions drift

Agents are usually connected in a hurry. A pilot needs read access to a shared folder, an integration needs a write token for the customer system, and an approver is named because someone was available that week. Nobody decides to keep those grants. They simply remain after the project changes shape, the staff around the agent change, and the original reason fades.

Authorization guidance such as the OWASP Authorization Cheat Sheet treats access as a decision that must be enforced and revisited over time, not a configuration you set once and forget. For agents, the drift is faster than for ordinary software accounts because an agent can act on many systems at once and its scope often grows through convenience: one more folder, one more channel, one more tool that was useful during testing.

What to inspect for each agent

An access review covers three layers. Each layer needs a different question.

• Tools: every action the agent can call, including reads, writes, sends, deletions and anything that touches money or customer records. The question is whether the role performs each action.
• Data scopes: the folders, tables, mailboxes, channels and memory stores the agent can read or write. The question is whether the task uses that data or only sits near it.
• Approvers: the people who must confirm specific actions. The question is whether each approver is still employed in that role, reachable, and given enough context to decide.

Memory deserves its own line in the review. If an agent keeps notes about customers, staff or past decisions, that store is a data scope like any database. Its contents should match the role, and its retention should be written down.

A quarterly audit in six steps

The method below takes one agent at a time. For a small number of agents, one owner and one operations reviewer can complete it in a focused session. Larger estates benefit from a shared checklist and a single review calendar.

• Inventory: list every active agent, its business owner, its written role statement, and the date of its last review.
• Export: pull the current grants from the systems themselves, including tool permissions, folder and table scopes, integration tokens and approver assignments. Do not rely on the setup notes.
• Compare: set each grant against the role statement and label it as needed, unclear or unused.
• Read the logs: for the review period, check which tools were called, how often, and which approval requests were sent and answered. Logs are the evidence that separates a grant that is used from one that only exists.
• Revoke and narrow: remove unused and unexplained grants first, then reduce the remaining scopes to the smallest set that still completes the task.
• Record and test: write down each decision, the reviewer, and the next review date. Run a test task to confirm the agent still works within the new limits.

The logs step depends on instrumentation. The OpenTelemetry observability primer explains how traces, metrics and logs let teams reconstruct what a system did and why. An access review uses the same kind of evidence: which action happened, through which tool, under whose approval.

How to decide what a role still needs

Most disagreements in a review come from grants that look harmless. A simple decision guide helps the owner and reviewer reach the same answer.

• If the action is named in the role statement and appears in the logs, keep it and note how often it is used.
• If the action is named in the role statement but absent from the logs, ask the owner whether the task still exists before removing it. Removal can wait one cycle if the task is seasonal or rare, but the question must be recorded.
• If the action is not in the role statement, remove it, even if it might be useful later. Future needs go through a new request.
• If the action writes, sends or deletes anything, confirm that the named approver is current, reachable and has the context to decide.
• If a grant cannot be explained by anyone, treat it as an incident to investigate, not as a configuration detail to tidy later.

The same logic supports staged trust. Broader authority should be granted only when the narrower version has a track record. The article on superintelligent agent authorization and trust tiers describes how to move an agent up one tier at a time, which pairs well with a quarterly review that can also move it down.

Approvers are part of the access model

An approval step that is always granted within seconds is not a control. In a review, look at how approvals actually behave. Who answers the requests, how long they take, whether they ever decline, and whether the approver sees the proposed action in enough detail to judge it. An approver who clicks through every request is effectively a grant with an extra step.

For each action that needs approval, the review should name a primary approver and a backup, and both should be people who hold the authority for that decision today. When a person leaves a role, their approvals should move with the responsibility, not remain attached to a former account. Deciding where an agent must stop and ask is covered in more depth in where your AI agent should stop and ask.

An illustrative review of a support agent

Illustrative scenario, not a client case: a support agent drafts replies to customer emails and can read a shared folder of recent orders. Its role statement says it prepares drafts for a person to send and proposes refunds for a manager to approve.

During the review, the team finds three problems. The agent can send replies directly, which the role does not require. It can read the full order archive, while the drafting task only needs the last few months. The refund approver is a manager who moved to another department earlier in the year, so refund requests were waiting on someone without the context to decide.

The team removes direct sending and keeps drafting. It narrows folder access to the recent window, moves refund approval to the current manager with a named backup, and writes the decision into the register. A test run confirms that drafts still reach the send queue and that refund proposals reach the right person. The next quarter's review then checks whether the narrower window ever blocked a legitimate task.

How Be Human handles access reviews in managed operations

Be Human designs each agent's role, memory, tools, permissions and approval boundaries during the first engagement, so the review has a written baseline to compare against. Managed operations can include recurring permission review as part of the service, with changes made through controlled improvements, recorded, and tested before they go live. If a review finds a grant that no one can explain, the same process used for incident response applies, and the business owner is asked to make the decision. The aim is that access always reflects a current role, and that each change leaves a trail someone can read later.

Keeping the review useful after the first quarter

A quarterly cycle is a sensible default, but it is not the only trigger. Run an extra review whenever an agent gets a new tool, a new data source, a new channel, or a new approver, and whenever a staff member who owned or approved an agent leaves. An incident also justifies a review of every grant the affected agent holds, not only the one involved.

The NIST AI Risk Management Framework frames this as ongoing governance: mapping the context, measuring the risk, managing the response and assigning responsibility. Access findings belong in the same register as other AI risks, with an owner, a status and a date. The approach described in a simple AI risk register works well for that purpose. Over several cycles, the review should get shorter, because the baseline becomes accurate and changes are smaller.

If you are not sure which agent or task should be reviewed first, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

How long does a first AI agent access review take? The length depends on how many agents exist and how well their logs are kept. For a single agent with an owner and usable logs, a focused working session is often enough to complete the six steps and record the decisions. Estates with many agents should plan the first cycle as a project with a shared checklist.

Who should run the review? The business owner of each agent should make the decisions about what the role needs, because they know the work. An operations or security reviewer should check the grants against the systems and the logs. The agent should never approve changes to its own permissions, and no one should be the only person who can both request and approve a grant.

Should we remove a permission the agent might need later? If the role does not need it today and the logs show no recent use, remove it and record the reason. Restoring a narrower permission through a documented request is normal and takes little time. Keeping unused access in place for convenience leaves the company exposed without any matching benefit.

What if our systems do not keep logs of tool calls and approvals? Then the first action is to enable logging for tool calls, data access and approval decisions before the next review. Without logs, the review can compare grants with the written role, but it cannot show what the agent actually did. Logs should be kept for a period that matches your audit needs and your privacy obligations.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.