checklist

AI chatbot permission drift review checklist for small teams

A practical review checklist for detecting and fixing AI chatbot permission drift across users, service accounts, connectors, source systems, tool actions, exports, and recovery controls.

Published: Aug 23, 2026 Last reviewed: Aug 23, 2026 Audience: Founders, support leads, product owners, engineering owners, security owners, privacy owners, and admins reviewing customer-facing AI chatbot permissions Risk: High Evidence: NIST AI RMF Core and Manage Playbook, FTC Safeguards Rule guidance, FTC vendor security guidance, OWASP LLM06:2025 Excessive Agency, and Cybergiz chatbot governance templates

Use this checklist to find permission drift in a customer-facing AI chatbot before a small configuration change becomes a data, account, or customer-impacting incident.

Bottom line

Permission drift means the effective access or action scope is broader, different, or less reviewable than the approved chatbot baseline. Compare the current route with a dated baseline across human users, administrators, service identities, connectors, source systems, browser or OAuth grants, tool actions, exports, and pause controls. Do not approve a route because its role label looks familiar; verify the actual scope and run a negative test.

Start with the AI Tool Risk Checker when the chatbot can reach customer data, internal sources, account records, or tools. Use the Small Team AI Security Checklist for baseline ownership, MFA, incident routing, and evidence storage. Pair this page with the AI chatbot access recertification checklist for person-by-person review and the AI chatbot service owner handover checklist when responsibility changes.

Do not paste passwords, API keys, private keys, raw customer records, unredacted transcripts, regulated files, private invoices, or dashboard URLs with tokens into the review record. Store protected evidence by reference.

When to use this checklist

Trigger	Review depth	Minimum response
New user, admin, group, contractor, or vendor joins	Focused	Compare effective access with the approved user scope.
Owner, team, or service account changes	Full	Reconcile access, connectors, actions, logs, and recovery.
New source, connector, OAuth grant, or browser extension is added	Full	Verify scope, identity, tenant boundary, expiry, and revocation.
New tool action or outbound integration is enabled	Full	Review downstream authorization, approval, logging, and rollback.
Vendor, model, or admin setting changes	Full	Confirm the vendor change did not expand the effective route.
Periodic review for a high-risk chatbot	Full	Rebuild the baseline and run negative tests.
An incident, near miss, or unexpected data result occurs	Incident-led	Contain first, then preserve minimum evidence and remediate.
Low-risk public FAQ with no private data or actions	Light	Record why a lighter review is appropriate.

Treat an unknown permission as a finding. If a high-impact permission cannot be verified or revoked, restrict or pause the affected path while the team investigates.

Permission drift intake form

Copy this form into a protected review ticket.

AI chatbot permission drift review

Chatbot and environment:
Review date:
Review owner:
Business owner:
Technical owner:
Security or privacy reviewer:
Baseline date and reference:
Current configuration reference:
Review trigger:

Approved use case:
Approved users and channels:
Approved data classes:
Approved source systems:
Approved connectors and scopes:
Approved tool actions:
Approved outbound destinations:
Approved pause and fallback path:

Current differences found:
Affected identity, source, connector, or action:
Customer or data impact:
Containment taken:
Negative test result:
Remediation owner:
Due date:
Decision:
Approver:
Next review date:

Use a protected record ID for customer impact, incident, exception, change, and access evidence. The public article should contain only the reusable form, not the completed review.

Permission inventory

Build the inventory from effective permissions, not only from the chatbot vendor’s feature list.

Inventory area	Capture	Review question
Human users	User, group, role, last-use signal, owner, and review date.	Does each person still need this access?
Administrators	Admin role, configuration rights, MFA, break-glass path, and audit access.	Can an admin change the route without independent review?
Service identities	Identity, workload, downstream role, owner, expiry, and rotation path.	Is the identity narrower than the workflow requires?
Vendors and contractors	Named account, support window, scope, sponsor, and expiry.	Is access need-to-know and time-bound?
Source systems	Tenant, table or field scope, folder, index, API role, and retrieval filter.	Could the bot read another team’s or customer’s data?
Connectors	OAuth grant, app, scopes, consent, user context, and revocation path.	Does the grant include write, delete, export, or send capability?
Tool actions	Action, arguments, target, approval step, rate limit, and rollback.	Can a model output trigger an irreversible action?
Destinations	Email, CRM, ticketing, webhook, queue, or export target.	Can content leave the approved boundary?
Recovery controls	Pause authority, fallback, restore path, and test date.	Can the team contain a risky permission quickly?

The inventory has one accountable owner and a current date.
Effective permissions are recorded separately from intended permissions.
Every connector and action has a scope, identity, owner, and revocation path.
The review includes temporary, vendor, guest, shared, and break-glass access.
Private evidence is referenced, not copied into the review record.

Approved baseline scope matrix

Write the baseline so a second reviewer can compare it without guessing.

Capability	Approved scope	Approved identity	Prohibited scope	Review date
Read public knowledge			Private source or unrelated tenant
Read internal source			Unrelated teams, customers, or sensitive fields
Read customer context			Cross-customer or full-account export
Create or update support record			Billing, deletion, or account changes
Delete or correct record			Bulk or unconfirmed deletion
Export or send content			Unapproved destination or raw data
Billing or account action			Action without confirmation and downstream policy
Admin configuration			Self-approval of high-impact changes
Pause or restart			Restart without evidence and owner approval

Use separate rows for read, create, update, delete, export, send, billing, and admin operations. A combined label such as “support access” hides the difference between safe lookup and destructive capability.

Drift source review

Drift source	What can change	Evidence to compare
Role or group change	New users, inherited access, removed restrictions, or stale membership.	Identity provider and application role records.
Service-account change	Broader downstream role, new environment, or missing owner.	IAM record, deployment configuration, and owner register.
OAuth re-consent	New scopes, changed user context, or a different app.	Grant history, scopes, consent record, and revocation test.
Source-system change	New folders, fields, tables, indexes, or tenant access.	Source ACL, retrieval filter, and sample query results.
Prompt or policy change	New instruction that routes data or actions differently.	Approved version diff and regression results.
Tool or extension update	New functions, arguments, destinations, or retry behavior.	Function inventory, release note, and action tests.
Vendor setting change	Retention, export, training, support, logging, or admin behavior.	Dated setting record and official vendor documentation.
Emergency change	Temporary grant, bypass, debug mode, or break-glass access.	Change record, expiry, and closure evidence.
Team or vendor turnover	Orphaned owner, contractor access, or unreviewed backup identity.	Handover, offboarding, and access recertification records.

Compare the current configuration with a dated approved baseline.
Check both planned changes and changes that happened outside the normal workflow.
Review effective inherited permissions, not just the direct grant.
Record who made the change, why, when, and what test followed it.
Expire temporary permissions instead of carrying them into the next review.

Identity and role review

Check	Pass condition	Drift finding
Primary owner	Named owner can approve, restrict, and pause the route.	Owner is missing, inactive, or read-only.
Backup owner	Backup can operate during absence and has tested access.	Backup is listed but cannot sign in or act.
Admins	Admins use named accounts, MFA, least privilege, and review dates.	Shared admin, stale role, or unreviewed break-glass access.
Support users	Support scope matches the customer workflow.	Support can view unrelated data or export raw content.
Contractors	Access has sponsor, purpose, window, and expiry.	Contractor access has no expiry or owner.
Service identities	Each identity has one workload and narrow downstream role.	Generic identity spans environments or systems.
Offboarding	Removed identities fail a negative access test.	Removal is assumed but not verified.

Check group nesting and inherited roles.
Check inactive users and identities with no recent approved use.
Confirm role changes trigger a fresh review rather than inheriting old approval.
Verify that the person who approves risk is not relying on the model to authorize itself.
Save a redacted access result and the negative test reference.

Connector and source scope review

Connector or source	Review fields	Stop condition
Knowledge base or wiki	Tenant, folders, fields, sync, freshness, and source owner.	Retrieval can cross an approved boundary.
CRM or helpdesk	Record types, customer scope, fields, write scope, and export path.	Full-customer or unrelated-team access is possible.
Email or calendar	User context, folders, message scope, send rights, and retention.	Read-only use includes send or delete scope.
Drive or file store	Shared drives, folders, inherited ACLs, and public links.	Bot can retrieve unapproved shared content.
Source control	Repository, branch, issue, secret boundary, and write rights.	Bot can access production secrets or merge without review.
Webhook or queue	Destination, payload, retry, duplicate handling, and owner.	Unknown results can repeat a side effect.
Browser or OAuth extension	Host permissions, connected apps, scope, and update path.	Host or OAuth scope exceeds the approved use case.

Confirm source access is enforced by the source system, not just by a prompt.
Test an allowed source and a denied source.
Test an allowed tenant and a neighboring or unrelated tenant.
Review connector scopes after any re-consent or vendor update.
Confirm revocation can be completed without waiting for the outgoing owner.

Tool action and downstream authorization review

OWASP LLM06:2025 calls out excessive functionality, permissions, and autonomy as causes of harmful actions. A permission review should therefore inspect the action contract and downstream authorization, not only the chatbot UI.

Action class	Minimum control	Evidence
Read	Narrow identity, fields, tenant, and user context.	Scope record and allowed/denied tests.
Create or update	Validated arguments, downstream policy, confirmation, and reconciliation.	Action result and approval record.
Delete	Exact target, explicit confirmation, recovery, and audit event.	Safe deletion test and recovery reference.
Export or send	Destination check, content review, user approval, and rate limit.	Approval and outbound event record.
Billing or account change	Independent approver, state transition rule, and rollback.	Test result and decision record.
Webhook or automation	Idempotency, retry limit, timeout, and unknown-result handling.	Failure and duplicate-action test.
Admin change	Separate requester and approver with audit trail.	Change record and post-change review.

Remove unused action functions from the extension or tool contract.
Use the minimum downstream role required by the approved route.
Enforce authorization in the downstream system.
Require human approval for high-impact or irreversible actions.
Log action, actor context, target class, result, and correlation reference.
Test a denied action, a malformed argument, an expired grant, and an unknown result.

Data boundary and export review

Data question	Current answer	Drift indicator
Which data classes can enter the route?		New sensitive class appears without approval.
Which source fields can be retrieved?		Field or table scope expands.
Can transcripts, files, or memories be exported?		Export becomes available to a broader role.
Can content reach a vendor, webhook, CRM, or email destination?		New destination or unreviewed subprocessor appears.
What are retention and deletion rules?		Setting changes without a review or customer notice check.
Can customers request deletion, export, correction, or opt-out?		Route promises a result it cannot perform.
Are logs protected and minimized?		Raw content is copied into broad logs or chat channels.

Compare current data paths with the approved customer and internal data boundary.
Check for raw transcript, attachment, or export copies outside the intended system.
Confirm deletion and export workflows still reach the correct owner.
Review retention and training or product-improvement settings where relevant.
Escalate unknown data movement before approving a broader permission.

Drift detection cadence

Use event-driven review for high-impact changes and a recurring review for the remaining baseline.

Review cadence	Scope	Output
Before change	New identity, source, connector, tool, destination, or data class.	Approved diff, test result, and rollback or pause plan.
Within one business day	Emergency grant, vendor incident, unexpected access, or suspicious action.	Containment, incident or exception record, and owner.
Weekly	High-impact tool actions, alerts, failed negative tests, and open remediation.	Findings and action tracker.
Monthly	Users, groups, admins, service accounts, connectors, sources, and settings.	Reconciled baseline and decision table.
Quarterly	Full chatbot route, customer impact, vendor changes, residual risk, and recovery.	Governance scorecard and next review.

Assign an owner and backup for each cadence.
Define what changes must block deployment or restart.
Link the review to the change, incident, exception, and handover records.
Set a review date on every accepted deviation.

NIST AI RMF treats risk work as continuous across the AI lifecycle and calls for periodic review, clear roles, inventory, monitoring, and documented accountability. Use the cadence that matches the route’s risk and resources, but do not let a recurring date replace event-driven review.

Negative tests

Run safe tests that demonstrate an unapproved scope is denied. Do not use real customer data or destructive actions.

Test	Expected result	Evidence
Removed user attempts to access the chatbot	Access denied or routed to reauthorization.	Test ID and timestamp.
Expired OAuth grant is used	Request fails without silently using a broader identity.	Grant and error reference.
Unrelated tenant or customer is requested	No retrieval or action occurs.	Redacted output and log reference.
Restricted field is requested	Field is denied or masked.	Test result and policy reference.
Write or delete action is requested without approval	Action is blocked or held for human review.	Action log and approval state.
Connector is revoked	Calls fail safely and fallback is available.	Revocation and fallback test.
Service account loses required scope	Failure is visible and no privilege escalation occurs.	Error, alert, and remediation record.
Prompt asks the bot to bypass authorization	Downstream policy still denies the request.	Safe prompt test and event record.

Tests use synthetic records, test tenants, or harmless read-only examples.
Test results identify the permission boundary, not just the final answer.
Failed tests create a remediation, exception, incident, or pause decision.
Rerun failed tests after the fix and record the new evidence.

Drift severity matrix

Severity	Example	First response
Critical	Cross-customer read, unauthorized account or billing action, raw export, or private credential exposure.	Pause affected path, revoke scope, preserve minimum evidence, and start incident review.
High	Write/delete scope expanded, source tenant boundary unclear, or high-impact action bypasses approval.	Restrict capability, assign same-day owner, and retest before restore.
Medium	Stale user, unreviewed connector setting, missing expiry, or incomplete logging.	Fix within the review window and track compensating control.
Low	Metadata, owner label, or documentation mismatch with no effective access change.	Correct record and verify no hidden scope change.
Unknown	Team cannot determine effective permission or change history.	Treat as a control gap; limit or pause until evidence exists.

Severity should reflect possible impact and effective scope, not how difficult the fix looks. A small change to an account-action tool may be more urgent than a large documentation gap.

Remediation workflow

Contain the affected permission, connector, source, or action when impact could be high.
Identify the actual scope, identity, data path, and customer or internal impact.
Compare the current state with the last approved baseline.
Remove unnecessary functions and privileges before adding compensating controls.
Apply downstream authorization, human approval, rate limits, and logging where needed.
Run negative and positive tests with synthetic or harmless data.
Record evidence, owner, due date, residual risk, and the decision to restore, restrict, or retire.
Update the baseline and review calendar so the same drift is detectable next time.

Do not close a finding because the permission was changed in the console. Close it after the effective scope and the negative test show the intended boundary.

Drift decision table

Result	Use when	Required follow-up
No drift	Effective state matches approved baseline and tests pass.	Record evidence and next review.
Accept with condition	Difference is bounded, owned, and time-limited.	Add expiry, compensating control, and approver.
Restrict	A subset of source, user, channel, or action scope is not ready.	Reduce scope and retest before expansion.
Remediate before restore	Control failed but the route can remain paused or limited.	Complete fix, evidence, and independent review.
Pause	High-impact access is unknown, unauthorized, or not revocable.	Use fallback and incident or exception path.
Retire or replace	Repeated drift or vendor constraints prevent a safe boundary.	Run a controlled exit and continuity plan.

Do not use an unconditional approval for an unresolved high-impact difference. The decision should make the residual risk and the next action visible.

Review sign-off record

AI chatbot permission drift review record

Chatbot and environment:
Review date:
Baseline date:
Review owner:
Business owner:
Technical owner:
Security or privacy reviewer:

Identity and role result:
Source and connector result:
Tool action result:
Data and export result:
Monitoring and log result:
Negative test result:
Customer or internal impact:
Containment taken:
Open incidents:
Open exceptions:
Open remediation:
Residual risk:
Decision: no drift / accept with condition / restrict / remediate before restore / pause / retire or replace
Approver:
Evidence location:
Next review date:

Action tracker

Difference or action	Severity	Owner	Due date	Evidence	Status
	Critical / High / Medium / Low				Open / In progress / Done
	Critical / High / Medium / Low				Open / In progress / Done
	Critical / High / Medium / Low				Open / In progress / Done

Each action has one accountable owner.
Critical and high findings have containment or a documented pause decision.
Actions changing scope are linked to a change record.
Exceptions have an expiry, approver, and review date.
Closure evidence includes a repeatable positive or negative test.

Final permission drift checklist

Metrics to track

Metric	Why it matters
Chatbot routes with a dated permission baseline	Shows whether effective scope can be compared.
Reviews completed on schedule	Shows whether drift is checked before it becomes normal.
Unknown permissions found	Shows where inventory or evidence is weak.
Connectors or actions restricted during review	Shows hidden excess capability.
Failed negative tests	Shows whether revocation and downstream controls work.
Mean time to contain high-risk drift	Shows practical response capacity.
Findings reopened after closure	Shows whether remediation actually held.
Temporary permissions past expiry	Shows whether exceptions become permanent.

Track results by chatbot route and capability. A low finding count can mean strong controls, or it can mean the team is not inspecting effective permissions.

Evidence checked

NIST AI RMF Core describes continuous lifecycle risk management, documented roles and responsibilities, AI system inventory, periodic review, monitoring, testing, incident response, recovery, and safe deactivation outcomes.
NIST AI RMF Manage Playbook provides guidance for prioritizing risk, documenting residual risk, monitoring third-party resources, and assigning responsibility to supersede, disengage, or deactivate systems.
FTC Safeguards Rule guidance describes covered financial institutions’ expectations around risk assessment, access review, data inventory, MFA, monitoring, service providers, change management, and incident response. The rule is not universal to every small business.
FTC vendor security guidance recommends written vendor expectations, verification, and updates as threats and vendor practices change.
OWASP LLM06:2025 Excessive Agency recommends minimizing extensions, functionality, permissions, and autonomy, enforcing downstream authorization, requiring human approval for high-impact actions, and logging and rate limiting activity.

These sources support the control principles. They do not certify a specific chatbot, vendor, or business as compliant.

FAQ

What is permission drift in an AI chatbot?

It is a mismatch between the approved permission baseline and the chatbot’s effective access or action scope. It can come from a group change, inherited role, OAuth re-consent, source ACL change, vendor setting, prompt or tool update, emergency grant, or an owner transition.

Is a role review enough to detect drift?

No. A role label may hide inherited groups, source-system permissions, OAuth scopes, service-account roles, or tool functions. Compare effective access and run safe allowed and denied tests.

How often should a small team review permissions?

Use event-driven review before material changes and after incidents, plus recurring review based on risk. High-impact chatbot routes generally need at least monthly access and connector review with a fuller quarterly governance review. Set the cadence the team can execute and document.

What should happen when the team cannot prove a permission is safe?

Treat it as unknown, not approved. Restrict or pause the affected source, connector, action, or user scope, preserve minimum evidence, assign an owner, and require a negative test before restoring it.

Does least privilege prevent prompt injection?

No. Least privilege limits impact; it does not remove the need for input handling, downstream authorization, monitoring, human approval, and incident response. A prompt must not be the only authorization layer.

Should the review include service accounts and vendor support users?

Yes. Service identities and vendor access can bypass normal employee review. Record owner, purpose, scope, user context, support window, expiry, and revocation evidence.

What if a new permission is needed for a useful feature?

Treat it as a change. Document the use case, data and action scope, identity, downstream control, customer impact, test set, pause path, approver, and expiry or next review before enabling it.

Does the FTC Safeguards Rule apply to every chatbot operator?

No. The FTC guide describes requirements for covered financial institutions under its jurisdiction. Other businesses can use its access, inventory, monitoring, vendor, and incident principles, but they must determine which legal, contractual, and sector requirements apply to them.

When is a drift finding closed?

After the effective scope matches the approved baseline or the documented decision, the fix has evidence, and a repeatable positive or negative test passes. A console screenshot without a test is not enough for a high-impact permission.