Review AI tool permissions against current need

Purpose and fit

Use this for an existing AI tool, connector or agent when its purpose, membership or integrations change, or when an agreed access review falls due. The focus is effective access in the deployed setup, including inherited grants and connected services. Written instructions about what an agent should do are useful context but do not show what the underlying account can actually reach or change.

Before you start

Use existing authorised admin exports, permission summaries or sanitised screenshots and the current business need. Never provide passwords, tokens or credentials. You do not need to create test data to draft this worksheet; actual access checks are a later authorised administrator activity.

If your available data uses different fields or terminology, adjust the prompt to match it. State the intended decision, audience and acceptance criteria; ask for essential missing information, and label any non-essential working assumptions. Do not fill factual gaps with invented information.

Required inputs

• A confirmed business purpose and current authorisation for the bounded workflow.
• An administrator-provided inventory of relevant accounts, roles, groups, connectors and grants; references only, with no passwords or tokens.
• Evidence of effective access, recent authorised use where available, and known retention or audit constraints.
• The authorised administrator, affected owners, a safe verification method and an agreed change process.

Practical workflow

1. Set the review scope: exact workspace, accounts, agent identities, integrations and environments. Identify the owners of service identities and distinguish them from individual user accounts.
2. Obtain current grants from authoritative administration views or approved exports. Trace inherited groups, connector scopes, nested tools and output-sharing permissions. Mark access that cannot be verified as unresolved.
3. Compare each grant with the current authorised task. Record the business need, objects affected and required operations separately, such as read, draft, send or delete. Do not treat prior availability or recent use as proof of current approval.
4. Propose the narrowest supported access that meets the need. Flag unused, excessive, expired or ownerless grants for review. Where the product cannot express a required restriction, record that limitation and seek an alternative controlled design.
5. Have the authorised owners approve any removal or adjustment through the existing process. Check dependent jobs and recovery options before the administrator makes changes. An urgent suspected exposure follows the established response route immediately.
6. Verify the resulting effective access using safe checks of permitted and prohibited operations. Confirm dependent workflows still function within scope. Record unresolved propagation, cached-session or in-flight-task questions and schedule the next review trigger.

Expected output

Expect a proposed access-review worksheet, questions and a safe verification plan. It cannot establish effective permissions, make changes or report completed checks.

An access-review worksheet and an evidenced completion record. Copy one row for each distinct grant:

Identity/owner: [ ]. System/environment: [ ]. Direct or inherited grant/source: [ ]. Effective objects/data scope: [ ]. Permitted operations: [ ]. Current business need: [ ]. Authorisation reference: [ ]. Review evidence/date: [ ]. Proposed action: [retain/narrow/remove/investigate]. Dependency/recovery considerations: [ ]. Required approver: [ ]. Administrator: [ ].

After authorised changes: Actual action/time: [ ]. Configuration evidence: [ ]. Allowed-action check/result: [ ]. Prohibited-action check/result: [ ]. Remaining uncertainty: [ ]. Next owner/review trigger: [ ].

Use synthetic or otherwise approved test objects. A prohibited-action check should safely confirm denial without attempting harmful activity or exposing real sensitive data.

Human checks

Administrators verify actual access rather than relying on generated summaries or role names. Process owners explain why retained privileges are needed. Security specialists review high-consequence exposure and any ambiguity about revocation. Preserve evidence according to existing rules, without copying credentials into the worksheet or an AI prompt.

Limitations

Product-specific permission models differ, and removing one grant may leave another access path. Session expiry and revocation behaviour require product-specific verification. This organisational checklist does not implement least privilege, certify security or authorise an administrator to change access.

Responsible use

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.