An AI agent’s access rarely becomes wrong all at once. It drifts. A pilot becomes a standing workflow. A read-only tool gains a write mode. A knowledge source is expanded to include sensitive material. A reviewer leaves the team. A queue is retired. A credential remains active because no one wanted to break a run. The agent may still be doing useful work, but its permissions no longer match the work anyone would deliberately assign from scratch.
Access reviews are the maintenance rhythm that keeps least privilege current. They are different from initial permission design. AI Agent Permissions explains how to think about the ladder from reading to acting. AI Agent Identities explains why separate accounts, scoped credentials, attribution, and revocation matter. Access reviews ask whether those choices still fit the workflow after reality has changed.
This is unglamorous work, but it is central to trust. Agents sit between language and action. They may hold access to tools, files, records, browsers, APIs, queues, and memory. If no one periodically compares that access against the current job, the workflow becomes more powerful than its mandate.
Review The Work Before The Credential
The access review should begin with the work, not with a list of tokens. What is the agent currently expected to do? Which tasks are still active? Which tasks are paused, retired, or experimental? Which outputs are accepted by people or downstream systems? Which actions remain draft-only? Which actions can happen without human approval?
Once the work is clear, the credential review has a standard. A customer-support drafting agent may need read access to approved policy sources and selected ticket fields, but not payment tools. A coding agent may need repository read access, a sandboxed branch, and test commands, but not production deployment credentials. A scheduling assistant may need availability windows without private calendar notes. The exact answer depends on the workflow, but the reasoning begins with the current task shape.
AI Agent Capability Inventories are useful evidence here. An inventory says what the delegate can do. An access review checks whether each capability still has a reason to exist. If a capability cannot be tied to an active task, it should be removed, disabled, or moved behind a fresh approval.
Stale Access Is Often Social
Access drift often follows human drift. A workflow owner changes roles. A reviewer stops watching the queue. A team moves from one system to another. A temporary exception becomes part of habit. An agent continues to post in a channel that no longer has the right audience. A retired pilot still has a service account because the account name sounds harmless.
The review should therefore include ownership. Who is responsible for the agent’s access? Who approves changes? Who receives incidents? Who can revoke the credential quickly? Who understands the downstream consequence if the agent stops? If the answer is “everyone” or “the team,” the real answer may be nobody.
AI Agent Runbooks should name these owners in practical terms. A runbook that describes execution but not ownership leaves access review work floating outside the operating rhythm. The agent may have a clear task path and still lack a clear authority path.
Tool Modes Need Separate Review
Many tools have modes. Reading a record, drafting an update, submitting an update for approval, and writing directly to production may all be exposed through similar interfaces. A browser can inspect a page, fill a form, download a file, upload a file, or submit a consequential action. A repository tool can read files, create a branch, open a pull request, or merge. An access review that sees only the tool name may miss the real authority.
The review should inspect modes and defaults. If a tool added a state-changing operation after the original review, the agent’s access may now be too broad. If a browser session has a logged-in role with more authority than the workflow requires, the agent may be one click away from a side effect it should not control. If a tool uses natural-language instructions to separate read and write behavior, the boundary may be weaker than the risk deserves.
This is why AI Agent Tool Contracts should represent authority in the contract itself. Narrow tools are easier to review. A vague universal tool forces the access review to rely on prompt discipline and human memory. A precise tool can say what it will refuse, what it will log, and what approval it requires before action.
Data Access Should Follow Minimization
Agents often receive more data than they need because broad access is convenient. A support workflow gets full tickets when it needs only a selected field set. A research agent gets the whole drive when it needs approved source folders. A personal assistant gets entire calendar notes when it needs availability. A coding agent gets environment files that include secrets when it needs only source code.
An access review should ask whether the data surface can shrink. The question is not only whether the agent has behaved well so far. It is whether the current task requires the data it can see. If not, the access should be reduced, the tool should redact fields, or the workflow should require a case-specific approval before the agent reads sensitive material.
AI Agent Data Boundaries gives the deeper privacy discipline. Access review is one enforcement moment. It turns minimization from a principle into a recurring comparison between task need and available context.
Approval Paths Can Go Stale Too
Access is not only about credentials. It is also about who can approve the agent’s next step. A workflow may have started with a careful approval path, but the path can drift. The reviewer may no longer own the area. The approval may be too broad for the actions now exposed. The interface may not show enough evidence. The approval may not expire when the target state changes.
AI Agent Approval Scopes is the companion guide. During access review, approvals should be inspected as part of permission. An agent with no direct write access can still cause harm if reviewers are approving vague actions without seeing source evidence or consequence. Conversely, a well-scoped approval path may allow a workflow to keep narrower credentials because the agent can prepare work and ask at the right moment.
The review should also ask what happens when approval is denied. Does the agent stop, revise, escalate, or try a different route? A denied approval should not become pressure to find another tool with fewer gates.
Revocation Should Be Practiced Before It Is Urgent
Access reviews should confirm that credentials can actually be revoked. A team may believe an agent account can be disabled quickly, but discover during an incident that the credential is shared, undocumented, embedded in a job, or tied to another workflow. Revocation that has never been practiced is an assumption.
This does not require dramatic drills for every small tool. It does require knowing where credentials live, which systems depend on them, how to rotate them, how to stop active runs, and how to confirm the agent no longer has access. AI Agent Incident Response depends on that groundwork. When something goes wrong, the first question is often how to stop new action without destroying the evidence needed to understand what happened.
Revocation is also part of ordinary lifecycle work. AI Agent Decommissioning explains how to retire delegates without leaving accounts half alive. Access reviews catch smaller retirement opportunities before a full shutdown is needed.
Access Review Is A Trust Habit
The review should end with a visible result. Some access remains because it matches current work. Some access is removed because the task changed. Some access is narrowed to draft-only or read-only. Some access receives a new owner, stronger logging, or a clearer approval path. Some uncertainty remains and needs follow-up. The outcome should be recorded so the next review does not start from folklore.
Access reviews do not make agent systems safe by themselves. They make one important question harder to ignore: does this delegate still have only the authority its current work requires? The answer will change as workflows mature. That is the point. Least privilege is not a launch setting. It is a maintenance practice.
