An AI agent access review is a periodic, structured procedure that verifies whether every agent's granted access still matches its actual, observed usage, whether its credentials remain current, and whether the owner recorded for it is still accurate — closing gaps left by scope that outlived its original justification. Unlike a one-time onboarding approval, an access review looks backward at what an agent has actually done since the last review, not just at what it was approved to do at the start.

Why Granted Access Drifts from Actual Need

Access grants are almost always set at the point of maximum uncertainty — when an agent is first being built and its exact usage pattern is still speculative. Teams reasonably request slightly more scope than they are certain they need, to avoid coming back for an amendment mid-build. Once the agent is live and its real usage pattern stabilizes, that early over-grant rarely gets revisited unless something forces the question. Add team reorganizations, agents that get repurposed for a different task than they were originally built for, and owners who leave without a handoff, and the gap between granted and actual access widens continuously without any single event marking the change. An access review is the mechanism that catches that drift on a schedule, rather than only when an incident forces an ad hoc audit.

The Procedure

1. Pull the current inventory. Owner: platform engineering. Start from the agent inventory — every registered agent, its owner, and its granted connections. If the inventory is incomplete, the review's first job is closing that gap before anything else, because an access review of agents you know about tells you nothing about the ones you do not. Evidence: an inventory export timestamped at the start of the review.

2. Pull observed usage per agent. Owner: platform engineering. For each agent, pull what it actually called over the review period — which connections, how often, at what volume. This is the comparison baseline for step 3, and it depends entirely on the audit trail being complete and queryable. Evidence: a usage summary per agent for the review window.

3. Compare granted scope to observed usage. Owner: the agent's designated business owner, with platform engineering support. For every granted connection, ask whether it was used at all during the period, and if used, whether the actual calls stayed within a sensible pattern for the agent's purpose. An unused grant is a candidate for removal; a grant used in an unexpected way is a candidate for investigation before removal or renewal. See the threat model for over-broad MCP tool scope for what unused or excess scope actually exposes you to. Evidence: a scope-versus-usage table per agent, with a disposition for every line.

4. Verify credential currency. Owner: platform engineering. Check credential age against rotation policy for every agent in scope. An agent with a credential well past its rotation window is a finding regardless of whether its access scope is otherwise appropriate. Evidence: a credential age report.

5. Verify owner accuracy. Owner: whoever manages team rosters, cross-checked against the inventory. Confirm the recorded owner for each agent is still the correct accountable person, not someone who has changed roles or left the organization. An agent with a stale owner is an agent nobody is actually watching. Evidence: a confirmed or corrected owner field per agent.

6. Record findings and assign remediation. Owner: the review lead. Every finding from steps 3–5 gets a named owner and a deadline, recorded at the time of the review, not deferred to a follow-up meeting that may or may not happen. A finding without an assigned owner and date is not a finding — it is a note that will be forgotten. Evidence: a remediation tracker entry per finding.

7. Sign off. Owner: the agent's business owner, or a designated approver for agents without an active owner. A named person attests that the review was completed and the findings are accurate, for every agent — not a single blanket sign-off for the whole batch. Evidence: a per-agent attestation record, dated and attributed.

8. Close the loop on the prior review's findings. Owner: review lead. Before the review is considered complete, verify that findings from the previous cycle were actually remediated, not just recorded. An access review program that only ever opens new findings and never confirms closure of old ones is not actually reducing risk over time.

Where This Fails in Practice

The review becomes a rubber stamp. The single most common failure is an approver reconfirming access without looking at usage evidence — clicking "approved" on every line because reviewing actual call logs per agent takes real time and the review has a deadline. A review with no usage comparison step is not a review; it is a formality that produces a false sense of assurance.

Findings have no deadline. A finding recorded as "excess access, should be reviewed" with no owner and no date effectively never gets fixed. The fix has to be structural: the review template itself should not allow a finding to be recorded without both fields populated.

The review period is too long relative to how fast agents change. An annual review misses months of drift in a fleet where agents are onboarded and modified continuously. Matching review frequency to the actual rate of change in the fleet — more frequent for high-risk agents, less frequent for stable, low-risk ones — is more effective than a single fixed cadence applied uniformly. A trust score trend can help flag which agents need an off-cycle review before their scheduled date arrives.

Ownership gaps are discovered too late. If owner verification (step 5) is skipped or treated as a formality, an agent can go through an entire review cycle with a stale owner nobody notices, meaning the "review" happened but no one with real accountability actually looked at it.

Reviewing MCP Tool Scope Specifically

Agents connected to MCP servers add a layer the general procedure above should call out explicitly: tool-level scope within a single connection. An agent might have a connection to an MCP server that is, at the connection level, entirely appropriate — but the specific tools it was granted within that server can still be broader than what it uses. Scoping MCP tool permissions narrowly at the individual tool level, not just at the server-connection level, is what an access review needs to check for agents with MCP integrations. Reviewing only the connection and ignoring the tool-level grant inside it misses a large share of realistic over-provisioning, because a single MCP server connection can expose dozens of individual tools, only a handful of which any given agent actually calls.

Preparing for the Review Before It Starts

A review runs faster and produces better findings when the inputs are ready before the review session itself begins, rather than assembled live. Two preparation steps make the biggest difference: confirming that the audit trail for the review period is complete and has no gaps (a missing week of logs makes usage comparison unreliable for every agent, not just the ones that happen to fall in the gap), and pre-generating the scope-versus-usage comparison for every agent so the review session is spent on judgment calls rather than data assembly. Teams that treat the review meeting itself as the place where data gets pulled for the first time consistently run out of time before reaching the agents that need the most scrutiny.

Common Questions

How often should an access review run? There is no single correct interval, but the review frequency should track how quickly an agent's fleet changes and how sensitive its access is. High-risk agents — those with write access to financial systems or customer data — warrant a shorter cycle than stable, low-risk, read-only agents. A single fixed interval applied uniformly across a fleet with very different risk profiles under-reviews the agents that matter most and over-reviews the ones that do not.

What is the difference between an access review and an audit? An access review is an internal, operational practice aimed at catching drift and closing gaps before they become a problem. An audit is typically an external or formal internal verification that a control — including the access review process itself — is operating as described. A well-run access review program is what makes an audit straightforward, because the evidence artefacts the audit asks for already exist from the regular review cycle rather than needing to be assembled specially.

Should decommissioned agents be included in the review? Yes, but with a different check. A decommissioned agent should be verified as actually having no live credentials and no active connections, not simply marked inactive in the inventory while a forgotten credential remains valid. Confirming decommissioning is complete — not just recorded — is a distinct and easy-to-skip check that belongs in every review cycle.

What Good Looks Like

  • Every agent's review includes an actual usage comparison, not just a scope reconfirmation.
  • Every finding has a named owner and a deadline recorded at the time it is identified.
  • Prior-cycle findings are verified closed before the current cycle is considered complete.
  • Review frequency scales with risk tier and rate of change, not a single calendar cadence for every agent.
  • A completed review produces a per-agent, signed-off record that can be handed to an auditor without reconstruction — including for agents whose identity is federated through enterprise SSO and SCIM provisioning rather than issued directly.