Quarterly AI Agent Permission Review: Steps and Evidence

A quarterly AI agent access review is a short, repeatable check of three things for every agent: what it can reach today, who approved each permission, and what evidence shows the permission is still needed. Anything without a current owner, a recorded reason or recent use is narrowed or removed, and the result is written down. Done on a fixed calendar, the review takes hours rather than days and stops agents from collecting access nobody remembers granting.

Key takeaways

• Review one agent at a time, connection by connection, and compare against the previous quarter rather than starting from scratch.
• Every permission needs a named approver, a stated reason and a date it was last confirmed.
• Evidence beats memory: use settings exports, approval records and usage logs, not recollection.
• Default to removal. If nobody can justify a permission, take it away and let the owner ask for it back.
• Close the loop by recording decisions, verifying removals actually worked and setting the next review date.

Why do AI agents need a permission review at all?

Agents collect access the way a shared drawer collects cables. Someone connects a mailbox to test a draft, a shared folder for a one-off task, a customer system token during a busy week. The work gets done, the connection stays, and nobody writes down why.

When a person changes roles, HR or IT usually triggers an access change. An agent has no such moment. Its job may stay the same on paper while its reach grows, and it will never complain about access it does not use. That gap is where unnecessary risk sits: an agent able to send, edit or delete things it was never meant to touch. The OWASP Top 10 for LLM Applications names excessive agency as a risk category, and OWASP's authorization guidance recommends least privilege and denying access by default. A quarterly review is the practical habit that keeps those principles true after the first month.

The review is not an audit for its own sake. It answers a business question: if this agent made a mistake, or were manipulated by a malicious message, how much could it affect? Smaller reach means smaller consequences, and a clear record means faster decisions when something does go wrong.

What do you need in hand before the review starts?

Reviews go badly when the first hour is spent hunting for information. Prepare a pack for each agent before the meeting:

• An agent register entry: the role the agent performs, the business owner, the technical operator and the date of the last review.
• A connection list: every system, channel and tool the agent can reach, with the access level for each (read, draft, write, send, delete).
• Credentials and grants: tokens, service accounts and OAuth authorizations, with their scopes and expiry dates.
• Knowledge and memory sources: which document stores, folders or databases the agent can retrieve from.
• Approval records: the ticket, message or change request that granted each permission.
• Usage logs for the quarter: which permissions the agent actually exercised, and when it last did so.

A note on OAuth, since many agent connections rely on it. The grant is defined by scopes, and Google's OAuth 2.0 documentation describes scopes as the way an application asks for limited access to a user's data. What matters in the review is the scope list as it exists now at the provider, not the one you remember choosing during setup.

If this is your first review, our step-by-step guide to running a permission review covers the initial pass. This article focuses on the quarterly rhythm that follows.

What are the steps of a quarterly AI agent access review?

Use the same sequence every quarter so results are comparable. Take one agent at a time, with its business owner in the room.

• Step one, snapshot: export the current permission list before changing anything, so there is a fixed record of what existed on the day of the review.
• Step two, compare: set the snapshot beside last quarter's. Mark every addition, every change in access level and every item with no matching approval record.
• Step three, test against use: for each permission, check the logs. Was it used this quarter? Does the agent's role still require it? Note seasonal needs explicitly, such as a year-end process.
• Step four, confirm the approver: the named owner states keep, narrow or remove. If the approver has left or changed role, assign a current owner before deciding.
• Step five, apply and verify: make the change, then check that the agent can no longer perform the removed action and that its core work still functions.
• Step six, record and schedule: file the evidence pack, list any exceptions with expiry dates and set the next review date.

Keep the group small but not self-grading. The business owner for the agent's role decides, the technical operator prepares the evidence and applies changes, and someone from IT or security joins when the agent touches shared systems. If only the operators attend, the review becomes a person checking their own work. For a standing agent, a sponsor who reads the one-page summary afterwards is usually enough oversight.

What evidence should you keep for each permission?

Evidence lets a new colleague, an insurer or an auditor understand a decision without asking anyone to remember it. For each permission, keep five items:

• Configuration proof: an export or readout of the permission as it exists in the connected system, including scope or role names.
• Approval record: a reference to the request or ticket, the approver's name and the date.
• Stated reason: one sentence linking the permission to a task in the agent's role.
• Usage proof: the most recent log entry showing the permission was exercised, or a note that there was none.
• Negative test: for anything removed or narrowed, a record that an attempt to perform the blocked action failed.

Two practical rules help. Store evidence where the next reviewer will find it, not in a personal inbox. And write approvals as dated decisions, because a verbal go-ahead cannot be checked three months later. When a permission was granted through a documented change request, most of this evidence already exists, and the review only confirms it is still true.

Logs deserve a short word. They only support the review if they record the agent's actions with enough detail to see which connection was used, and if they are kept at least as long as the review cycle. Check retention before the meeting, not during it.

How do you decide what to remove, narrow or keep?

Decide with the same rules every time so the review does not turn into a negotiation. Use this guide:

• Remove when nobody can name the reason, when the approver has left and no one has adopted the permission, or when there was no use this quarter and no known seasonal need.
• Narrow when the agent uses only part of the access: read instead of write, one folder instead of a whole drive, one channel instead of every channel.
• Time-box when access serves a project, a trial or an outside party, and give it an expiry date (see time-boxed rules for contractor access).
• Escalate when a permission lets the agent take an irreversible action, such as sending external messages, deleting records or moving funds, without a human approval step. Add the approval boundary before keeping it.
• Keep when reason, approver, use and test all check out. Record the confirmation date so the next review has a starting point.

Removal is cheap to reverse. If someone needs the access back, they ask, state the reason and get it approved again. Leaving unjustified access in place has no equivalent safety net. For actions that affect people outside the company or change records, confirm in the same sitting which settings the business owner should control, so the approval boundaries match the permissions that remain.

What does a review look like in practice?

Illustrative scenario: a services firm runs an agent that drafts replies to customer emails. At the quarterly review, the register shows four connections: a shared support mailbox (read and draft), the order system (read), a finance folder (read) and a team calendar (write).

The comparison with last quarter shows the finance folder has no approval record. The operator explains it was connected during setup to test a question about invoices. The logs show the agent has never retrieved anything from it. The calendar write was approved for a scheduling project that has ended, and the logs show no calendar activity since.

The business owner decides: remove the finance folder, remove calendar write, keep the mailbox and order system as they are. The operator applies the changes, then asks the agent a question that would require a finance document and confirms it cannot retrieve one. The evidence pack records the snapshot, the two removals, the negative test and the next review date. The whole exercise fits in a single short meeting because the preparation was done beforehand.

How does Be Human handle this in managed operations?

Be Human keeps a register of each agent it operates: its identity, channels, tools, permissions and approval boundaries. The permission review is part of the recurring work in managed operations. The operator prepares the snapshot, the comparison with the previous quarter and the usage evidence, and the client's business owner makes the keep, narrow or remove decision. Changes follow an approval path, removals are verified, and the record stays with the client so that control remains with the humans responsible for the agent.

Frequently asked questions

How often should we review AI agent access? Quarterly is a sensible baseline for agents in regular use. Also review when something changes: a person with approval authority leaves, a new tool is connected, the agent's role expands, or an incident occurs. A short trigger-based check between quarters keeps the calendar review from becoming a backlog.

Who should approve an agent's permissions? The business owner of the role the agent performs should approve, because they understand what the work requires and what a mistake would cost. The technical operator confirms what is feasible and applies the change, but should not be the only approver. Where the agent touches shared systems, the owner of those systems should also agree.

What if nobody can find who approved a permission? Treat it as unapproved. Narrow or remove it, then ask for a fresh approval through the normal change process, with a stated reason and date. Record the gap in the evidence pack, since missing approvals usually point to a process weakness worth fixing, such as connections made informally during setup.

Does the review need to cover model providers and data flows too? Yes, at a lighter level. Note which providers receive the agent's context, what retention settings apply and whether any of that changed since last quarter. Frameworks such as the NIST AI Risk Management Framework stress documented accountability and governance, and a dated review record is a simple way to show that for access decisions.

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