AI Agent Access Reviews: Keeping Least Privilege Current

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.

Build The Evidence Before Deciding

Start with one agent and one review period. Gather its current task description and owner, the capability inventory, approval rules, and the systems it uses. Then compare those documents with actual configuration: identity and group memberships, application grants, resource policies, credentials, browser sessions, tool settings, scheduled jobs, and access to stored context. Check both direct grants and access inherited through groups or shared accounts. A tool’s advertised interface may be narrower than the underlying account; review both paths.

For each access path, record the identity, system and environment, permitted actions and data, business reason, owner, and any expiration or approval condition. Include production and test separately. Compare this record with configuration exports and relevant audit logs, noting their dates and any gaps. Microsoft’s service-account governance guidance describes reviewing ownership, permissions, and activity for non-human accounts; the same questions help with agent identities.

Trace a request from the agent to the resource, including any intermediary that acts with its own identity. A connector may use an application grant, a user’s delegated authority, or a saved browser session; each can have a different effective scope. Check resource-side permissions as well as the connector’s settings. If several workflows share an identity, identify all of them before changing it and plan a narrower identity where practical. A tool description or prompt saying “read only” is not evidence that the underlying account cannot write. For example, Microsoft distinguishes delegated permissions from application permissions : a delegated request is also constrained by the signed-in user’s access, while an application can act under its own grants. Inspect the actual authorization path for each system rather than assuming all connectors work alike.

Activity is evidence, not authorization. An operation appearing in a log does not prove it was needed or approved. No activity during a short observation window does not prove a permission is unused: a quarterly job, recovery path, or missing log may explain the silence. Check the schedule and log coverage with the workflow owner before removing access. If effective access cannot be established, record the gap and assign someone to investigate rather than marking it approved.

Make And Verify Each Decision

For every grant, choose an outcome: retain it with a current reason, narrow it, remove it, or record a time-limited exception. An exception should name the risk, accountable owner, compensating controls, expiry, and follow-up date. At expiry, remove or narrow the access unless an authorized owner reviews and renews the exception; a missed review should not silently become indefinite approval. The workflow owner can explain the need; the system or data owner should confirm the scope and apply or authorize the change according to local policy. If a reviewer cannot confirm a high-risk grant, escalate promptly and consider pausing the affected workflow while the decision is resolved.

For example, a support drafting agent needs selected ticket fields and current policy documents. The review finds that its service account can also issue refunds through an older integration. The owner confirms that refunds are outside the agent’s task. A system administrator removes that grant, checks for another route through a shared group or browser session, and verifies with a safe permission check that refund access is denied while the drafting workflow still works. The review record links the configuration evidence and change ticket, names who confirmed the result, and sets the next review date. It does not include the credential itself or customer ticket contents.

One row in the review record could look like this:

If the denial cannot be verified because a second route has not been checked, leave that route open with an owner and deadline. Record any temporary restriction and escalation separately; an exception is not proof that the access has been removed.

Do not close the finding when a ticket is created. Recheck the effective permission after the change, including inherited grants, existing sessions, and any token behavior relevant to that system. Use a non-destructive permission check against the affected identity and resource where possible; do not perform the consequential action to see whether it succeeds. If a test account is used, confirm that its roles, groups, resource policy, and session conditions represent the path under review, and record what the test cannot establish. Record a failed check or an untested path as open work with an owner and deadline. Also check whether automation, group membership, or a new consent could restore the removed grant; change the provisioning or approval path as needed and watch for recurrence.

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.

Also check copies the workflow has already created: downloaded files, cached results, traces, and stored agent memory may remain accessible after the source grant is removed. Identify their owners and retention rules, then restrict or delete them according to policy. Removing source access alone does not erase those copies. The memory audit guide covers reviewing retained 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.

Disabling an account or rotating a secret may not immediately invalidate every issued token or browser session. For example, Microsoft’s guidance on revoking user access distinguishes identity-provider tokens from sessions controlled by an application. The exact behavior depends on the identity and system in use. Check its revocation behavior, stop or isolate active runs where appropriate, and verify denial after any applicable token lifetime or session termination. A routine change can be staged around dependencies; suspected compromise may require immediate containment and independent preservation of logs.

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.

Set A Cadence That Matches The Risk

Choose a review interval based on the sensitivity of the data, authority to change systems, exposure, and pace of change. A production agent that can alter financial records may warrant more frequent review than a read-only agent using public documents. Set a date for the next review, but also review after a tool or role changes, an owner leaves, a new data source is connected, an incident occurs, or a pilot is retired. NIST describes review frequency as an organization-specific, risk-based decision in its risk management FAQ ; there is no universal interval that fits every workflow.

Keep the record useful and restrained: review date and reviewer, evidence locations and dates, each decision and its reason, change or exception owner, verification result, unresolved gaps, and the next review date. Store it where authorized operators can find it without copying secrets or unnecessary sensitive data into the review itself. A recurring reminder without completed decisions and verified changes is a schedule, not a completed review.

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.