Quarterly Permission Reviews for AI Agents: A Practical Checklist

A permission review for an AI agent is a scheduled check of every tool, account and approval right the agent holds, compared against the role it is supposed to play today. Run it once a quarter, remove or narrow whatever the role no longer needs, and record what changed and why. The aim is not perfect access on the first day but access that stays matched to the job as the job changes.

Key takeaways

• Review each agent against its written role, not against the access it was originally given.
• Check tools, accounts and approval rights separately, because each one drifts in a different way.
• Remove unused access first, narrow what remains, then re-test the agent's core tasks.
• Keep a short written record of every change so the next review starts from evidence.
• Route any new permission through the same change process you use for changes to behavior.

Why agent access drifts after launch

Agents rarely gain access in one decision. A tool is added for a pilot, a shared login is reused for a test, and an approver is added during an escalation and never removed. Each addition made sense at the time. After a few months the total no longer matches the role on paper, and nobody notices, because the agent still works.

The checklist below is written for the agents businesses run today. The same discipline matters more as agents become more capable, because a wider scope of action makes stale access more costly. A review that is easy to repeat is the most reliable way to keep scope honest.

This review belongs to the same operating routine as monitoring and incident response. If you already have a way to request and approve changes to a managed agent, permission changes should travel through it too.

What to write down before the first review

A review without a reference point is only an opinion about access. Before the first quarterly review, write a one-page role sheet for each agent that contains:

• The agent's purpose in one sentence, and the specific tasks it is allowed to perform.
• Every tool, data source and account it can reach, with a named owner for each.
• Every action that requires human approval, and the role of the person who approves it.
• The success criterion the agent is judged against, so you can tell whether it still needs the access it has.

Keep the role sheet short enough that someone can read it in a few minutes. If the sheet is longer than the agent's actual job, the scope is probably already too broad.

The quarterly checklist, step by step

Run the review in the same order each quarter so the results can be compared. The steps below assume one agent at a time.

• Export the current permission state: tools enabled, accounts connected, scopes granted and approval rights assigned.
• Compare each item against the role sheet and mark it keep, narrow or remove.
• Check usage logs for the whole period. Any tool, account or right unused for the entire quarter is a removal candidate unless there is a written reason, such as a yearly process that runs outside the quarter.
• Confirm that the agent uses its own identity, not a person's login or a credential shared with another system.
• Confirm that read and write rights are separated wherever the task only requires reading.
• Confirm that each approval right still belongs to someone who holds that responsibility today.
• Apply the removals and narrowings, and record each one with the reason and the person who approved it.
• Re-run the agent's core test tasks and check the success criterion against recent results.
• Write a short outcome note: what was kept, what was removed, and what remains open for the next review.

The outcome note is the artifact that matters most. It turns a routine check into a record that the next reviewer can trust.

Tools, accounts and approval rights need different questions

A tool is a capability the agent can invoke, such as searching a document store, creating a ticket or sending a message. The review question is whether the agent still needs that capability for its role, and whether the tool is limited to the records and actions the role requires. A tool that was added for a one-off migration usually should not survive into normal operations.

An account is the identity the agent uses to reach a system. Google's OAuth 2.0 documentation describes delegated authorization in which an application receives scoped, revocable tokens rather than the user's password. Apply the same logic to agents: each connected account should carry only the scopes its role needs, and it should be possible to revoke that access without disrupting unrelated work.

An approval right is the authority to say yes to an action the agent proposes. These rights go stale fastest, because people change roles and nobody updates the agent's configuration. OWASP's authorization guidance recommends denying access by default and enforcing checks on every request rather than assuming an earlier check still applies. In practice, confirm that each approver is a current holder of that responsibility and that the approval path still exists.

Illustrative scenario: a support agent that outgrew its role

Illustrative scenario, not a client case: a support triage agent was set up to read tickets and suggest priorities. During a busy period, its write access to the refund tool was switched on so it could process small refunds, and the change was never reversed. The agent also still used a login that had belonged to a former contractor.

The quarterly review found three problems. The refund write right had not been used in the entire quarter. The shared login was still in use for ticket reads. The refund approval had been routed to a team lead who had moved to another department. The team removed the refund write right, issued the agent its own credential with read-only ticket scope, assigned approval to the current owner of refunds, and re-ran the triage test set. The change record explained each step, so the next reviewer did not have to reconstruct the history.

Decide whether to remove, narrow or keep

Use this decision guide when a review item is unclear. It keeps the outcome consistent across reviewers.

• Remove when the access was granted for a task that has ended, or when no log shows use during the period.
• Narrow when the access is needed but broader than the role, such as write rights for a job that only reads.
• Keep when the access is used, limited to the role, and has a named owner who can explain it.
• Escalate when nobody can say why the access exists. Treat it as a removal candidate, give the owner a short window to answer, and remove it if no answer arrives.

The last rule is the one most teams skip. Access that nobody can explain is not a safe default, and keeping it because removal feels risky makes the next review harder.

How Be Human handles permission reviews

In managed operations, Be Human keeps each agent's role sheet, tool and account inventory and approval map as part of the operating record. Permission review is one of the recurring services in managed operations, alongside monitoring, integration maintenance and incident response. Changes to access follow the same request and approval path as other changes, and each review produces a written outcome that the client can read and keep. The same record makes the next quarter faster, because the reviewer starts from what changed rather than from memory.

Keeping the review useful over time

A permission review fails when it becomes a form that gets signed without being read. Keep the checklist short, name one owner for the review of each agent, and put the date of the next review on the same calendar as the agent's other operating tasks. The NIST AI Risk Management Framework treats governance and monitoring as continuing activities rather than one-time approvals, which is a useful way to think about access as well. If your company has not yet decided who owns these decisions, the guidance on lightweight AI governance for mid-sized firms is a practical place to start. If you are not yet sure which agent in your company deserves this review first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

How often should an AI agent's permissions be reviewed? Quarterly is a sound default for agents that touch customer data, money, or external systems. Agents with narrow, read-only scope can be reviewed less often, but they should still be checked whenever their role or connected systems change. Any new tool, account or approval right should trigger a review of that item at the time it is granted.

Who should approve the outcome of a permission review? The agent's business owner should approve the role sheet and any decision to keep broad access, because that person is accountable for the outcome. The technical owner should confirm that removals and scope changes were applied correctly. Keeping these two sign-offs separate prevents the person who wants the access from being the only person who judges it.

What if an agent stops working after access is removed? That is useful information, and it should be handled as a change request rather than a quiet restoration. Check whether the missing access was part of the role sheet, and if it was not, the removal was correct and the workflow needs redesign. If it was part of the role, restore the narrowest scope that works, record the reason, and note it for the next review.

Does a permission review replace security testing? No. A permission review checks whether access still matches the role, while security testing checks whether the agent can be manipulated into acting outside its role, for example through untrusted content in its inputs. Both are needed. The review reduces what an attacker or an error could reach, and testing shows whether the remaining controls hold under pressure.

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