checklist
AI chatbot access recertification checklist for small teams
A practical access review checklist for customer-facing AI chatbots, covering users, admins, service accounts, connectors, temporary access, offboarding, evidence, negative tests, and approval decisions.
Use this checklist to verify that everyone and everything with access to an AI chatbot still needs the permissions it has.
The goal is not to export a directory and mark every row approved. The goal is to answer who can use, administer, connect, operate, or recover the chatbot; what data and actions each identity can reach; when the access was last justified; and what happens when the answer is no longer valid. Run the AI Tool Risk Checker before approving a material scope change.
Bottom line
Recertify chatbot access on a predictable cadence and after material changes. Review human users, administrators, service accounts, connector grants, tool-action identities, support access, guests, and break-glass accounts separately. A role that can read customer records, change prompts, export transcripts, or trigger downstream actions should not be approved merely because the person works on the project.
Use the Small Team AI Security Checklist for baseline ownership, MFA, incident routing, and evidence storage. Pair this page with the AI chatbot audit log review checklist to verify that the review can be reconstructed, and with the AI chatbot admin settings review checklist when a permission finding requires a console setting change.
When to use this checklist
| Situation | Review depth | Minimum action |
|---|---|---|
| Read-only internal chatbot | Users, groups, guests, and source scope. | Confirm least privilege and remove stale users. |
| Customer-facing support chatbot | Operators, admins, service identities, transcripts, and handoff tools. | Review access and test a removed identity. |
| Chatbot with account, ticket, order, or billing actions | All identities plus downstream permissions and approvals. | Reconcile action scope and require downstream authorization. |
| New model, vendor, connector, tool, or channel | Baseline and post-change comparison. | Recertify before launch and after the observation window. |
| Role, team, vendor, or contractor change | Affected identities and temporary access. | Review immediately instead of waiting for the normal cycle. |
| Incident, near miss, or unexplained export | Full access and evidence review. | Preserve evidence, contain risky access, and link the incident record. |
| Low-risk pilot | Pilot users, owner, admin, and service account. | Set an expiry date and verify automatic removal. |
Do not put customer transcripts, access tokens, credentials, employee directory exports, or private incident evidence into this public article or repository. Use redacted references and protected evidence storage.
Access recertification scope matrix
| Identity or access path | What to verify | Escalate when |
|---|---|---|
| Standard user | Role, team, use case, data scope, last use, and manager approval. | The use case is inactive or broader data is reachable than needed. |
| Support operator | Handoff, transcript, customer record, and correction permissions. | The operator can export or change data without a business need. |
| Workspace admin | SSO, billing, settings, source, connector, export, and audit permissions. | Admin access is shared, unassigned, or used for routine work. |
| Developer or engineer | Test environment, deployment, prompt, source, and tool permissions. | Development access reaches production customer data by default. |
| Service account | Owner, workload, secret rotation, scope, and downstream role. | No accountable owner or the identity has broad write access. |
| Connector grant | User or service identity, source, scopes, consent, and expiry. | A read-only use case has write, delete, or unrelated source access. |
| Tool-action identity | Action, argument boundary, approval, result, and downstream policy. | The model or extension is the only authorization layer. |
| Vendor or contractor | Contract need, named users, MFA, time window, and support path. | Access has no end date or the vendor can see unrelated data. |
| Guest or temporary user | Sponsor, reason, start date, expiry, and review owner. | The guest is active after the work or sponsor has left. |
| Break-glass account | Custodian, trigger, MFA, alert, use log, and recovery plan. | The account is used for convenience or its use is not reviewed. |
Treat unknown ownership or unknown scope as a finding. Do not silently convert an unverified row into an approval.
Review intake form
Copy this into the protected review record.
| Field | Entry |
|---|---|
| Review date and time | |
| Review owner | |
| Chatbot route and channel | |
| Business owner | |
| Technical owner | |
| Security or privacy reviewer | |
| Model and vendor | |
| Connected sources | |
| Tool actions and downstream systems | |
| Access systems reviewed | |
| Review period and last review | |
| Change or incident IDs in scope | |
| Evidence location | |
| Exception register reference | |
| Decision approver | |
| Next review date |
Set the review window and evidence source before looking at individual rows. Record exclusions and explain why they do not change the decision.
Identity inventory
Build one row per identity or access grant. Avoid treating a group as approved without checking the members and effective permissions.
| Identity | Type | Owner or sponsor | Role | Data scope | Action scope | Last used | Expires | Decision |
|---|---|---|---|---|---|---|---|---|
| User | ||||||||
| Admin | ||||||||
| Service account | ||||||||
| Connector grant | ||||||||
| Vendor or guest | ||||||||
| Break-glass |
- Include direct users, groups, nested groups, guests, vendors, service accounts, API clients, connector grants, and emergency identities.
- Record effective permissions rather than only the role name shown in the chatbot console.
- Record the source system that proves the identity is active and the system that proves the scope.
- Link the identity to a business owner and a technical owner.
- Mark unused, duplicate, orphaned, and shared identities for a decision instead of leaving them blank.
Permission decision rules
Use the narrowest decision that matches evidence. An approval should have a reason, an owner, a scope, and a next review date.
| Condition | Decision | Required follow-up |
|---|---|---|
| Active owner, approved use case, necessary scope, recent use | Approve | Record evidence and next review date. |
| Owner and use case are clear but access is broader than needed | Reduce | Remove unused scope and retest. |
| Temporary work remains active and has a valid sponsor | Extend with expiry | Set a fixed end date and re-review. |
| No recent use and no planned work | Remove | Revoke, confirm failure, and record the result. |
| Owner cannot explain the access | Suspend | Route to the business owner before restore. |
| High-impact action lacks independent authorization | Restrict | Add downstream policy or human approval. |
| Service account has no accountable owner | Disable or quarantine | Identify owner and rotate credentials before reuse. |
| Vendor access is required but contract or time window is missing | Hold | Resolve terms and access boundary before approval. |
| Break-glass use is unexplained | Investigate | Review alerts, evidence, and possible incident impact. |
Never approve a high-impact permission because it is difficult to remove. Make the access smaller, move authorization to the downstream system, or pause the action until the control is verifiable.
Human user and group review
- Export or inspect the current user and group assignments from the approved identity source.
- Expand nested groups and record effective chatbot roles.
- Confirm that each user has a current job responsibility tied to the chatbot workflow.
- Check whether a support role can view raw transcripts, customer records, exports, or sensitive attachments.
- Check whether a developer role can alter production prompts, sources, connectors, or tools.
- Separate routine use from administrative access and require stronger controls for the latter.
- Verify MFA and SSO requirements for every human identity that can reach sensitive data or settings.
- Review shared accounts and replace them with named identities where possible.
- Remove users who left the team, changed role, lost sponsorship, or no longer need the workflow.
- Record every exception, its approver, its expiry, and the compensating control.
Do not use last-login data as the only approval signal. A rarely used admin role can still be high impact, while a frequently used role can still be over-privileged.
Admin and service-account review
| Review item | Evidence to inspect | Pass condition |
|---|---|---|
| Admin role | Role assignment, named owner, MFA, and change history. | Admin access is named, necessary, and monitored. |
| Prompt or policy editor | Editor list, change approval, version history. | Only approved owners can change behavior. |
| Source manager | Source membership, indexing scope, and sync identity. | Source access matches the chatbot use case. |
| Connector manager | OAuth grant, scopes, consent, and revocation path. | Connector access is narrow and revocable. |
| Tool manager | Tool list, argument limits, downstream roles, and approvals. | High-impact actions have independent authorization. |
| Export or support role | Export events, transcript access, and retention rules. | Export is justified, logged, and limited. |
| Service account | Owner, workload, secret age, role, and rotation record. | No shared human use and no unnecessary write access. |
| Break-glass role | Trigger, custodian, alert, and post-use review. | Emergency access is rare, observable, and time-limited. |
- Use separate identities for administration, deployment, support, and automated workloads where practical.
- Rotate credentials after an owner leaves or a service-account purpose changes.
- Disable unused service accounts rather than leaving them as future convenience access.
- Test that a service account cannot access unrelated tenants, sources, or actions.
- Review whether logs contain secret material, raw tokens, or reusable credentials.
Connector and tool permission review
Review the downstream permission, not only the label shown in the chatbot interface.
| Capability | Minimum question | Unsafe result |
|---|---|---|
| Read source data | Which user or service identity reads which records? | Generic identity reads all customers or all files. |
| Search or retrieval | Which fields, tenants, and indexes are searchable? | Search crosses tenant or confidentiality boundaries. |
| Create or update | What object can be changed and who approves it? | The model can write without a downstream policy check. |
| Delete | Is deletion required, confirmed, and reversible? | Delete is bundled into a general-purpose extension. |
| Export or send | Where can data leave and who can approve it? | Any user can export or send raw customer data. |
| Webhook or queue | How are retries and duplicate actions reconciled? | Unknown result can trigger repeated side effects. |
| Admin setting change | Who can alter the connector, source, or action? | The same identity develops, approves, and deploys changes. |
- Compare each connector grant with the approved data classification and business use case.
- Remove unused scopes and extensions before reviewing new feature requests.
- Enforce authorization in the downstream system rather than relying on the model to decide.
- Require confirmation or human approval for high-impact actions.
- Record revocation evidence and verify the old grant fails after removal.
OWASP’s LLM06:2025 guidance describes excessive functionality, permissions, and autonomy as causes of excessive agency. It recommends minimizing extensions and permissions, using the user’s security context where appropriate, requiring approval for high-impact actions, and enforcing authorization in downstream systems.
Temporary, vendor, and break-glass access
| Access type | Required fields | Closure test |
|---|---|---|
| Contractor | Sponsor, contract need, named user, scope, start, and end date. | User cannot sign in or reach the approved source after expiry. |
| Vendor support | Ticket, support staff identity, window, approved evidence, and monitor. | Support grant is revoked and the ticket records the result. |
| Pilot user | Pilot scope, test purpose, data boundary, owner, and expiry. | Pilot identity and data grant expire automatically. |
| Emergency access | Trigger, custodian, exact role, alert, and incident link. | Access is removed and use is reviewed by an independent owner. |
| Break-glass account | Storage, MFA, recovery steps, and quarterly test owner. | Test proves the account works only when needed and is logged. |
- Give temporary access a fixed expiry before it is granted.
- Require a named sponsor who is different from the person receiving access.
- Alert when temporary access is close to expiry or cannot be revoked automatically.
- Review vendor support access after every support session.
- Preserve emergency-use evidence without copying private customer content into the review packet.
The FTC’s small-business guidance recommends need-to-know access and limiting vendor access to the time required for the work. Use that principle for chatbot support, pilots, contractors, and emergency access.
Offboarding and role-change checks
Run these checks whenever a user, vendor, service owner, or team changes. Do not wait for the monthly review.
- Disable the identity in the approved identity provider or source system.
- Remove direct chatbot roles and group memberships.
- Revoke connector grants, API clients, tokens, and active sessions owned by the identity.
- Remove prompt, source, tool, export, and billing permissions that came from the old role.
- Rotate secrets or service-account credentials when ownership is unclear.
- Check queued jobs, webhooks, scheduled tasks, and pending approvals owned by the identity.
- Review recent logs for unusual exports, actions, setting changes, or failed revocations.
- Confirm the identity cannot sign in or reach the old data and action scope.
- Record the timestamp, operator, systems checked, exceptions, and verification evidence.
Evidence packet
Keep a small protected evidence packet. It should prove the decision without exposing raw customer records or credentials.
| Evidence item | What it proves | Safe representation |
|---|---|---|
| Identity export or query result | Who had access during the review window. | Redacted names or internal record IDs. |
| Role and scope record | What each identity could do. | Role names, scope classes, and protected pointers. |
| Connector and tool inventory | Which downstream paths were available. | Tool IDs, scope labels, and system owner. |
| Last-use or action summary | Whether access was used and how. | Counts, dates, and event references. |
| Change history | Whether permissions changed during the period. | Change IDs and approvers. |
| Revocation result | Removed access actually stopped working. | Test timestamp, status, and operator. |
| Exception record | Why an unusual permission remains. | Reason, compensating control, owner, expiry. |
| Approval record | Who accepted residual risk. | Name or role, decision, date, and next review. |
The FTC Safeguards Rule guidance recommends periodically reviewing who has access to customer information and whether there is still a legitimate business need. Keep the review record tied to the access decision, not as a disconnected screenshot folder.
Negative tests
Every review should include at least one test that confirms revoked or reduced access fails safely.
| Test | Expected result | Evidence |
|---|---|---|
| Removed user signs in | Sign-in or chatbot access is denied. | Timestamp and protected test record. |
| Reduced connector scope requests an excluded record | Request is denied or returns only approved fields. | Redacted result and scope reference. |
| Removed tool action is requested | Action is unavailable and no downstream side effect occurs. | Tool response and downstream check. |
| Expired guest uses old link | Session or request is rejected. | Expiry and denial record. |
| Service account calls unrelated tenant | Downstream authorization denies the request. | Policy decision and trace ID. |
| Break-glass account is used outside trigger | Alert fires and the use enters investigation. | Alert and review record. |
Do not test against real customer records when a synthetic fixture or redacted test tenant is sufficient. If a negative test would create a side effect, use a safe dry run or a protected staging boundary.
Findings and decision table
| Finding | Decision |
|---|---|
| Identity, owner, scope, last-use evidence, and next review are complete | Approve and set the next date. |
| Access is needed but includes unused read or write scope | Reduce scope, retest, then approve. |
| User or service account has no accountable owner | Suspend until ownership is assigned. |
| Connector or tool access crosses the approved data boundary | Revoke or isolate and investigate affected activity. |
| High-impact action relies only on model instructions | Restrict action and add downstream authorization or approval. |
| Temporary or vendor access has no expiry | Remove access or create an approved time-bound exception. |
| Offboarding cannot prove revocation | Treat as a security finding and inspect recent activity. |
| Review evidence contains raw secrets or unnecessary customer data | Secure, redact, rotate, and record the evidence-handling issue. |
| Repeated access findings exceed the team’s risk tolerance | Pause, redesign, replace, or retire the chatbot route. |
Do not close a finding because an access export looks clean. Close it when the permission was changed, the negative test passed, and the evidence is stored with an owner and due date.
Recertification record
| Field | Entry |
|---|---|
| Review period | |
| Chatbot route and environment | |
| Identities and grants reviewed | |
| High-impact permissions reviewed | |
| Connectors and tools reviewed | |
| Temporary and vendor access result | |
| Offboarding and role-change result | |
| Negative tests completed | |
| Open findings | |
| Exceptions and expiry dates | |
| Final decision | Approve, reduce, suspend, pause, redesign, replace, or retire. |
| Residual risk approver | |
| Next review date |
Store the record with the identity source, role and scope evidence, connector inventory, negative-test results, exception register, and remediation tracker. Keep actual customer data, tokens, and employee directory exports in protected systems.
Remediation tracker
| Finding or improvement | Severity | Owner | Due date | Closure test | Evidence |
|---|---|---|---|---|---|
- Separate access cleanup, downstream policy, identity lifecycle, logging, and training actions.
- Give every action a due date and a closure test.
- Re-run the AI Tool Risk Checker when a fix changes data, connector, or action scope.
- Reopen a finding when the verification evidence does not match the original decision.
Final recertification checklist
- The review owner, route, environment, time window, and scope are recorded.
- Direct users, groups, guests, vendors, service accounts, connector grants, and break-glass identities were included.
- Effective permissions were checked rather than relying only on role labels.
- Data scope, action scope, source scope, export scope, and downstream authorization were reviewed.
- Admin, support, developer, service, vendor, and temporary access were reviewed separately.
- MFA, SSO, named ownership, credential rotation, and session controls were checked.
- Offboarding and recent role changes were reconciled.
- Expiry dates exist for temporary, pilot, vendor, and emergency access.
- At least one negative test proved that reduced or revoked access fails safely.
- Findings have severity, owner, due date, closure test, and evidence.
- Exceptions have an approver, compensating control, and expiry date.
- The final decision, residual risk approver, and next review date are recorded.
Metrics to track
- Percentage of chatbot identities with a named owner and current recertification.
- Percentage of high-impact actions with independent downstream authorization or human approval.
- Number of stale, duplicate, shared, orphaned, or over-privileged identities removed.
- Number of connector grants and tool scopes reduced during review.
- Percentage of temporary and vendor grants with automatic expiry.
- Time from role change or offboarding event to verified access removal.
- Negative-test pass rate for removed users, reduced scopes, expired guests, and disabled actions.
- Number of open, overdue, repeated, and reopened access findings.
- Percentage of access decisions linked to protected evidence and a next review date.
Evidence checked
- NIST AI RMF Core includes post-deployment monitoring, appeal and override, incident response, recovery, decommissioning, and change management outcomes.
- NIST AI RMF Playbook provides adaptable actions for managing AI risk instead of a one-size-fits-all control list.
- FTC Safeguards Rule: What Your Business Needs to Know discusses periodic access-control review, data inventory, service providers, security events, and control changes.
- FTC Cybersecurity for Small Business recommends need-to-know access, MFA, vendor controls, incident response, and regular review of security practices.
- OWASP LLM06:2025 Excessive Agency covers excessive functionality, permissions, autonomy, downstream authorization, least privilege, approval, and monitoring.
- Cybergiz internal templates for chatbot admin settings, audit logs, tool actions, offboarding, and incident response were checked for overlap and linked workflow boundaries.
FAQ
How often should a small team recertify chatbot access?
Use a monthly or quarterly cadence based on the route’s data and action impact. Run an immediate review after a role change, vendor change, connector change, model or prompt change, incident, near miss, or unexplained export. High-impact action routes need more frequent review than read-only internal assistants.
Is a last-login report enough to approve access?
No. Last use can show activity, but it does not prove that the identity still has a legitimate business need, the scope is correct, the owner is accountable, or downstream actions are independently authorized. Use last-use data as one input to the decision.
Should admins be included if they do not use the chatbot every day?
Yes. Administrative access can change prompts, sources, connectors, roles, exports, or tool actions even when it is rarely used. Review the admin role separately and keep routine work out of the highest-privilege account.
How should we review a connector used by many employees?
Review the grant and its effective downstream scopes, then inspect group membership, tenant boundaries, source fields, read or write actions, consent, expiry, and revocation. A shared connector is not automatically safe because each user appears to have a separate chatbot session.
What should we do with an orphaned service account?
Disable or quarantine it, preserve the relevant access and action evidence, identify the owner, rotate credentials if exposure is possible, and verify that no queued job or webhook still depends on it. Restore only after the workload and least-privilege scope are documented.
Do temporary vendor accounts need a full review?
They need a focused review that covers the sponsor, contract need, named user, data and action scope, MFA, start and expiry dates, monitoring, and revocation test. A smaller scope does not remove the need for an owner and closure evidence.
What is the most useful negative test?
Test the riskiest change made during the review: a removed user, reduced connector scope, disabled tool action, expired guest, or service account blocked from an unrelated tenant. The expected result is a safe denial with no unintended downstream side effect.
Where should the real access export be stored?
In the team’s protected evidence or governance system with need-to-know access, retention, and deletion rules. The public article should contain only the reusable form and decision logic, never real directory exports, tokens, transcripts, or customer records.