checklist

AI chatbot tool action approval checklist for small teams

A practical approval checklist for AI chatbots that can call tools, create tickets, update CRM records, send messages, issue refunds, change access, or trigger automations.

Use this checklist before a customer-facing AI chatbot can create tickets, update CRM fields, send emails, issue refunds, change plans, modify permissions, retrieve account data, open support cases, write to a database, call internal APIs, or trigger automations.

The risk changes when a chatbot moves from “answering” to “acting.” A wrong answer can confuse a customer. A wrong action can change money, access, records, messages, permissions, account status, or evidence. Before approving tool actions, run the AI Tool Risk Checker and keep the result with the action approval packet.

Bottom line

Do not give a chatbot broad action permissions because the workflow feels convenient. Each action needs a written approval record that defines:

1. What the bot can do.
2. Which user, account, and data boundaries apply.
3. Which actions require human review.
4. Which actions are read-only, draft-only, or write-capable.
5. Which downstream system permissions are actually granted.
6. How prompt injection, wrong answers, customer disputes, and tool failures are handled.
7. When the action should be paused, rolled back, or removed.

Use the Small Team AI Security Checklist for baseline tool approval, access control, logging, incident response, and owner review. This page focuses on chatbot tool actions.

When to use this checklist

Scenario	Use this checklist?	Why
Bot creates support tickets	Yes	Bad categorization can delay urgent issues or expose sensitive context.
Bot updates ticket priority, status, owner, or tags	Yes	Routing and service level decisions affect customers.
Bot drafts customer emails or chat replies	Yes	Drafts can still create unsupported promises if sent by agents.
Bot sends customer messages automatically	Escalate	External communication requires tight review and rollback paths.
Bot updates CRM, account notes, renewal risk, or churn status	Yes	Wrong records can affect sales, support, and account treatment.
Bot reads customer account data	Yes	Least-privilege data access and transcript handling matter.
Bot issues credits, refunds, cancellations, plan changes, or access changes	Escalate	Money and account actions need human approval by default.
Bot can call an internal API or automation platform	Escalate	Broad integrations can bypass normal application controls.
Bot only answers from public docs with no actions	No	Use chatbot launch, handoff, and answer correction templates instead.

Default rule: a customer-facing chatbot should start read-only or draft-only. Write actions need a stronger reason.

Action inventory template

Create one row for every chatbot action.

Field	Required entry
Action name	Plain-language action, such as create ticket, update CRM field, send reply, or fetch account plan.
System touched	Helpdesk, CRM, billing, identity, database, email, Slack, docs, or internal API.
Action type	Read, draft, write, send, delete, approve, escalate, or trigger automation.
Customer-visible?	Yes, no, or internal-only.
Data used	Public docs, ticket text, account metadata, billing data, CRM notes, files, transcript, or support history.
Permission granted	Exact role, scope, API permission, service account, or OAuth grant.
Human review	None, sample review, agent approve, owner approve, or security/privacy approve.
Rollback	How to undo, correct, cancel, delete, or compensate.
Owner	Business and technical owner.
Review date	Approval date and next review trigger.

If the owner cannot describe the action in one row, the action is too vague to approve.

Action risk matrix

Action	Starting approval level
Read public docs	Low, with source controls.
Read customer ticket metadata	Medium, with least-privilege access and transcript rules.
Draft ticket summary for human review	Medium, with correction workflow.
Create support ticket	Medium, with routing checks and abuse controls.
Update ticket priority, owner, or status	Medium-high, with service level review.
Update CRM notes, account health, or renewal fields	High, with customer success review.
Send customer message	High, human approval by default.
Issue refund, credit, cancellation, discount, or plan change	High, owner approval required.
Change user access, role, admin, or authentication setting	High, authenticated workflow and human approval required.
Delete data, close account, or modify evidence	High, privacy/security/business approval required.
Call open-ended internal API or automation runner	High, deny until scoped into narrow functions.

Small teams should avoid giving chatbots open-ended “do anything” tools. Narrow functions are easier to review and safer to revoke.

Permission boundary checklist

Check	Default rule
Is the downstream permission read-only when the bot only needs to read?	Use read-only scope.
Does the bot act as the current user or a shared service account?	Prefer user-scoped authorization where possible.
Can the bot access all customers or only the current account?	Limit to current authenticated customer context.
Can the bot update fields that affect billing, access, risk, or compliance?	Require human approval.
Can the bot delete or overwrite records?	Deny by default.
Can the bot send messages outside the workspace?	Require human approval and approved templates.
Can prompt text choose arbitrary API parameters?	Validate parameters server-side.
Can the bot chain actions across systems?	Require workflow approval for the chain, not only each step.
Can the bot action be replayed or repeated?	Add idempotency, rate limits, and duplicate checks.

The model should never be the authority that decides whether a user is allowed to act.

Human approval rules

Action category	Human approval rule
Low-risk read action	No approval after initial launch, but sample logs.
Draft summary or draft reply	Agent must approve before customer-visible use.
Ticket creation	Bot can create with clear label; support queue reviews.
Ticket priority or escalation	Human review for urgent, security, privacy, billing, outage, or complaint topics.
CRM update	Customer success or account owner approves sensitive fields.
Customer email or chat send	Human approval unless the message is a narrow approved receipt.
Refund, cancellation, discount, credit, or renewal action	Billing or account owner approves.
Role, permission, admin, SSO, or account access change	Authenticated admin workflow and human approval.
Data deletion, export, correction, or retention change	Privacy/security owner approval.
Internal API action with operational impact	Product or engineering owner approval.

Approvals should happen in the downstream system or workflow, not as a vague instruction in the prompt.

Tool call design rules

Design area	Rule
Function shape	Prefer small, specific functions over broad API wrappers.
Inputs	Use typed, validated parameters.
Identity	Use least-privilege, scoped identity.
Authorization	Check authorization server-side before action execution.
Confirmation	Require human confirmation for irreversible or customer-visible actions.
Logging	Log action, actor, source conversation, parameters, result, and reviewer.
Rate limits	Limit repeated actions and suspicious sessions.
Idempotency	Prevent duplicate tickets, messages, refunds, or updates.
Error handling	Fail closed and route to a human when context is missing.
Rollback	Define how to reverse or correct the action before launch.

A chatbot should request an action; the application should decide whether the action is allowed.

Customer-visible action rules

Customer-visible action	Required control
Confirmation message	Use approved wording and label AI-assisted action when appropriate.
Support ticket created	Show ticket ID, expected response path, and human contact option.
Email sent	Human approval unless it is a narrow receipt or status confirmation.
Account update requested	Require customer authentication and confirmation.
Billing change requested	Human/billing owner approval and audit trail.
Data deletion or export requested	Route to approved privacy workflow.
Escalation triggered	Tell customer what happens next and when.
Action denied	Give a safe explanation and human path.

If the customer can rely on the action, keep a reviewable record.

Abuse and prompt injection controls

Tool actions increase the impact of prompt injection.

Signal	Control
User instructs bot to ignore policy and perform an action	Refuse and route repeated attempts to review.
User asks bot to act on another customer’s account	Refuse and preserve minimal evidence.
Source content instructs bot to call a tool	Treat source text as untrusted data.
Bot receives conflicting instructions from ticket text	Follow policy and authenticated user context, not ticket content.
Session tries repeated refunds, tickets, messages, or access changes	Rate limit and require human review.
Bot proposes hidden API parameters	Validate against allowlisted schema.
Tool result includes sensitive data	Redact before display and restrict logs.
Action path is unclear	Fail closed and hand off.

Use the AI chatbot prompt injection response checklist if a tool action is triggered or attempted through injection.

Pre-launch test set

Test these before approving an action.

Test	Expected result
Happy path with valid authenticated customer	Action succeeds or creates human-reviewed draft.
Missing customer identity	Action denied or routed to human.
Another customer’s account ID	Action denied.
Prompt injection asking for action	Action denied and logged.
Malicious source text asks for action	Source is treated as data, not instruction.
Duplicate request	Duplicate blocked or idempotent.
High-risk topic such as billing, privacy, security, outage, or access	Human approval required.
Tool error or timeout	No partial action; handoff message shown.
Sensitive data in input or output	Redacted, escalated, or blocked according to policy.
Rollback drill	Team can undo or correct the action.

Do not launch write actions if only happy paths have been tested.

Approval record

Copy this into the chatbot approval packet.

Field	Entry
Bot name and location	Website, app, help center, portal, or agent console.
Action approved	Exact action name and downstream system.
Action type	Read, draft, write, send, delete, approve, or trigger.
Data scope	Which customer, account, ticket, source, and fields are accessible.
Permission scope	Exact OAuth, API, role, or service account permission.
Human review rule	None, sample, agent approve, owner approve, security/privacy approve.
Abuse controls	Rate limits, prompt injection refusal, source restrictions, duplicate checks.
Logging	Where action logs, reviewer, parameters, and result are stored.
Rollback	How to reverse, correct, notify, or compensate.
Test evidence	Test cases run and failures fixed.
Decision	Approve, approve with limits, hold, deny, or escalate.
Next review	Date and triggers for reapproval.

Keep this record redacted. It should point to controlled logs rather than duplicate customer data.

Monitoring checklist

Review these during pilot and monthly after stabilization.

Signal	Action
Actions taken without human review	Pause action and review approval rule.
Duplicate tickets, messages, refunds, or updates	Add idempotency and duplicate checks.
Wrong account or customer context	Escalate and review authorization boundary.
Prompt injection near tool use	Route to security review and add regression test.
Tool errors or timeouts	Fail closed and improve handoff.
Customers dispute bot-triggered action	Run correction workflow and review rollback.
Broad service account permissions	Replace with least-privilege scope.
Unused action remains enabled	Remove or disable.
Vendor or API permission changes	Reapprove affected actions.

An unused high-risk action is still an exposed action.

Metrics to track

Metric	Why it matters
Actions attempted	Shows tool exposure.
Actions completed	Shows usage and value.
Actions requiring human approval	Shows review workload.
Denied actions	Shows boundary and abuse signals.
Duplicate actions blocked	Shows idempotency value.
Rollbacks or corrections	Shows action quality.
Prompt injection attempts near actions	Shows security pressure.
Permission exceptions	Shows access drift.
Customer disputes tied to actions	Shows customer impact.
Time to pause action	Shows operational readiness.

Track action metrics separately from answer-quality metrics. A chatbot can answer well and still act dangerously.

Evidence checked

This checklist is aligned with:

1. NIST AI RMF Core, which emphasizes AI governance, lifecycle monitoring, roles, incident response, recovery, change management, and communication about errors.
2. NIST Generative AI Profile, which identifies generative AI risks and risk management actions for organizations deploying generative AI systems.
3. OWASP LLM06:2025 Excessive Agency, which highlights excessive functionality, excessive permissions, and excessive autonomy in LLM-based systems.
4. OWASP Agentic AI threats and mitigations, which provides a threat-model-based reference for agentic AI systems.
5. OWASP Top 10 for Agentic Applications 2026, which focuses on autonomous AI agents that plan, act, and make decisions across workflows.
6. CISA and partner guidance on deploying AI systems securely, which emphasizes protecting, detecting, and responding to malicious activity against AI systems, data, and services.
7. Cybergiz templates for chatbot launch review, knowledge base review, human handoff, answer correction, conversation log retention, prompt injection response, customer impact assessment, and incident response.

This page is practical operating guidance, not legal, procurement, privacy, compliance, audit, certification, or security assurance advice.

FAQ

Should a chatbot be allowed to send customer emails automatically?

Usually not at first. Start with draft-only replies and require human approval. Automatic sending should be limited to narrow receipts or status confirmations with approved wording and logging.

Is creating a support ticket a high-risk action?

It is usually medium risk, but it becomes high risk when routing affects outages, security, privacy, billing, access, legal, regulated data, or angry customer escalation.

Can prompt instructions protect dangerous actions?

No. Prompts help, but authorization and action controls need to live outside the model. Validate user identity, account scope, action parameters, and permissions server-side.

What is the safest first tool action?

A narrow read-only or draft-only action is safest. For example, create a draft ticket summary for human approval, not a customer-visible account update.

Should the bot use a shared service account?

Only when necessary, and only with least-privilege scopes. A shared high-privilege account makes it harder to enforce customer and user boundaries.

When should an action be paused?

Pause when the bot acts on the wrong account, repeats an action, receives prompt injection near tool use, triggers customer disputes, bypasses human review, or touches sensitive data unexpectedly.

Who owns chatbot tool action approval?

The business owner owns the workflow decision, but security, privacy, engineering, support, billing, and customer success may each own specific controls depending on the action.