How to Run a Permission Review for Your AI Agents, Step by Step

An AI agent permission review is a recurring check of what each agent can read, draft and send, compared with what its role actually needs. You list every access, find out which ones were used, remove the rest, and record who approved what remains. Done on a steady rhythm, it stops quiet access growth before it becomes a business risk.

Key takeaways

• Review three verbs separately for every agent: read, draft and send. They carry different risk and need different approvals.
• Start from the agent's role description, not from what its tools happen to allow. Access the role cannot justify is a candidate for removal.
• Use activity evidence. Access that was never exercised during the review period is the easiest to remove with confidence.
• Give every permission a named human owner and a next review date.
• Remove access in a reversible way, test the agent's normal tasks afterwards, and keep a short written record for the next review.

Why do AI agents accumulate access over time?

Agents rarely start with too much access. They gain it. A pilot needs a shared mailbox, so it is connected. Someone adds a calendar link for a demonstration. A test token created during setup is never revoked. Each decision is reasonable on its own day, and the sum is an agent that can reach far more than its job requires.

Permissions also outlive the context that justified them. The person who approved a connection changes role. A tool changes what its scopes allow. A folder that was tidy becomes a place where contracts and payroll notes are stored. Nobody made a mistake, yet the agent's reach no longer matches anyone's mental picture of it.

The OWASP Top 10 for LLM Applications names this pattern excessive agency: an agent with more functionality, permissions or autonomy than the task needs. A permission review is the routine countermeasure. It is also much easier when the agent has its own identity, because its access becomes a list you can read instead of a borrowed person's login. We cover that foundation in why your company AI agent needs its own identity and accounts.

What do read, draft and send mean in practice?

Treat these as three separate questions for every agent. A single yes or no for the whole agent hides the decisions that matter.

• Read: which mailboxes, drives, folders, CRM objects, channels and knowledge sources can the agent see? Could it see records about clients or colleagues outside its role? Is it granted the whole system when it needs one folder?
• Draft: what can it prepare without anything leaving the company or changing a system of record? Examples are a reply saved in a drafts folder, a proposed CRM note, or a document in a staging area. Be careful here: a draft permission that can edit shared documents is closer to send than it looks.
• Send: what can it do that leaves the company or changes state? Sending an email, posting in a channel, updating a record, creating a meeting with external guests, or triggering a payment step all belong here.

Two reference points help the technical check. Google's OAuth 2.0 documentation explains scopes as the mechanism for requesting limited access, so compare each granted scope with the narrowest one that still supports the task. The OWASP Authorization Cheat Sheet recommends least privilege and deny by default, which is the stance a review should enforce: access is absent until a task justifies it.

One combination deserves extra attention. An agent that reads untrusted content, such as inbound email or web pages, and can also send is exposed to instructions hidden in that content. Separating those abilities, or placing a human approval between them, removes much of that exposure.

How do you run the review, step by step?

This plan works for one agent or several. Keep it as a standing checklist and repeat it each cycle.

• Step 1, confirm the role and owner. Pull the agent's one-page role description and the name of the person accountable for it. If neither exists, write them before reviewing anything else. A job description for the agent's role gives you the yardstick.
• Step 2, inventory every access. List accounts, API keys, OAuth grants, shared mailbox memberships, folder shares, channel memberships, tool connections, webhooks and scheduled jobs. Include memory stores and knowledge sources, since they are also things the agent reads.
• Step 3, classify each item. Mark it as read, draft or send, note which data it covers, and note whether the credential belongs to the company or to an individual.
• Step 4, gather activity evidence. Check logs for what was actually used during the review period, and when it was last used. Access with no trace of use is your first removal list.
• Step 5, compare with the role. Next to every access, write the task it supports. If you cannot name one, mark it for removal.
• Step 6, narrow or remove. Reduce scope before deleting where you are unsure. Convert send to draft with human approval where the cost of an error is high.
• Step 7, test, record and schedule. Run the agent's standard tasks, confirm nothing broke, write down what changed and who approved it, and set the next review date.

Who does what in this plan should be settled in advance. A RACI for company AI agents makes clear who is responsible for the inventory, who approves removals and who must be told.

How do you decide what access to remove?

Use a simple decision guide so that reviews are consistent and not driven by whoever is most cautious that day.

• No task in the role description uses it: remove it.
• It was not used during the period, but a task depends on a rare event such as a month end or an audit: keep it, label it as rare, and give it a shorter review date.
• It is used, but is broader than the task needs, for example a whole drive when one folder is enough: narrow it.
• It allows sending to clients, partners or regulators, or touches money or legal commitments: require human approval before sending, or convert it to draft.
• It runs on a credential tied to a person who left or changed role: replace it with the agent's own credential, then revoke the old one.
• Nobody can say who granted it or why: suspend it, watch for complaints, and remove it if none arrive.

Removal should be reversible. Record the previous configuration, make changes during a quiet period, and tell the people who work with the agent what is changing. The same discipline you would use for any update applies, as described in how to update an AI agent in production without breaking it. If a task fails afterwards, restore the access, document the reason it is needed, and attach that reason to the permission so the next reviewer does not repeat the question.

What does a review look like? An illustrative scenario

This scenario is illustrative, not a real case. A distribution company has an agent that prepares replies to purchasing questions from suppliers and internal staff. Its role description says it drafts replies and proposes notes for the purchasing team.

The inventory shows read access to the entire shared drive, read access to the purchasing mailbox and to a sales mailbox, permission to send from a shared address, write access to notes in the ERP, and an old test token for a spreadsheet tool. The activity logs show that the sales mailbox was never opened, the drive was only used for one price list folder, and external replies were always edited by a person before sending. The test token was never used after setup.

The outcome is quick. The sales mailbox connection is removed. Drive access is narrowed to the price list folder. The test token is revoked. Internal replies stay as direct send, while external replies move to draft with approval, which matches how the team already works. The ERP note permission stays, because the role description names it. The review ends with a short written record and a date for the next one.

How often should you review, and who signs off?

A regular calendar rhythm is the baseline. Quarterly is a sensible starting point for most companies, and the right frequency rises with the agent's reach. A reading agent confined to one knowledge base can be reviewed less often than one that sends to clients.

Add event triggers on top of the calendar. Review early when any of these happen:

• A new tool, channel or data source is connected.
• The agent's role changes or expands.
• A person with administrative rights leaves or changes position.
• An incident or near miss occurs.
• The underlying model or provider changes.

Sign-off needs two perspectives. A business owner confirms that the remaining access matches the work. A technical reviewer confirms that the actual configuration matches what was reported. The person who built or operates the agent should not be the only approver of its own access. If you are setting up the wider oversight structure, AI governance for mid-sized companies describes a lightweight way to start. For a framework view of risk management, the NIST AI Risk Management Framework is a useful reference.

How does Be Human handle permission reviews?

Be Human defines approval boundaries at the start of an engagement: for each agent role, what it may read, draft and send, and which actions need a person's approval. The agent runs on its own identity and accounts under company control. As part of managed operations, Be Human performs recurring permission reviews alongside monitoring and integration maintenance, produces a written list of proposed changes, and applies removals only after the company's owner approves them. The recurring work is described in more detail in what managed AI services include.

Frequently asked questions

How often should we review AI agent permissions? Begin with a fixed calendar rhythm, such as every quarter, and add a review whenever a new tool is connected, a role changes or an incident occurs. Agents that can send externally deserve a shorter interval than agents that only read a narrow source.

Who should own the review? A business owner who understands the agent's work should be accountable, with a technical reviewer verifying the real configuration. Avoid letting the same person who builds or operates the agent be the sole approver of its access.

Should an agent ever have send access? Yes, when the task needs it and the cost of an error is low or a person approves before release. Many teams allow direct send for internal messages and require approval for anything going to clients, partners or authorities. Revisit that line at each review as trust and evidence build up.

What if removing access breaks something? Make removals reversible, keep the previous configuration, and test the agent's standard tasks straight after the change. If something fails, restore the access, write down which task depends on it, and attach that note to the permission so the reason is clear next time.

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