checklist

AI chatbot prompt injection response checklist for small teams

A practical response checklist for customer-facing AI chatbot prompt injection, covering triage, containment, evidence, customer impact, source cleanup, vendor questions, and monitoring.

Use this checklist when a customer-facing AI chatbot receives a prompt injection attempt, follows attacker instructions, reveals hidden instructions, exposes sensitive information, bypasses topic boundaries, takes the wrong action, or starts answering from untrusted content.

Prompt injection is not only a “bad prompt” problem. It is a production workflow problem. The response has to identify what the attacker tried, what the bot could access, what it revealed or changed, whether customers were affected, and which guardrail failed. Before keeping the chatbot live, run the AI Tool Risk Checker and attach the result to the response record.

Bottom line

Every customer-facing AI chatbot needs a prompt injection response checklist that defines:

1. What counts as direct or indirect prompt injection.
2. Which events require immediate containment.
3. Who reviews customer impact, sensitive data, and tool actions.
4. What evidence to preserve without spreading raw sensitive content.
5. How to pause a topic, source, connector, or bot path.
6. How to fix prompts, sources, retrieval rules, and action permissions.
7. When the bot can return to normal operation.

Use the Small Team AI Security Checklist for baseline approval, admin ownership, access control, and incident routing. This page focuses on prompt injection response after launch.

When to use this checklist

Scenario	Use this checklist?	Why
Customer tells the bot to ignore previous instructions	Yes	This is a direct injection attempt even if it fails.
Bot reveals hidden prompt, routing rules, internal policy snippets, or source IDs	Yes	System prompt leakage may indicate weak separation of controls.
Bot answers a prohibited billing, security, privacy, legal, or account question	Yes	Scope boundaries or handoff rules failed.
Bot uses text from a webpage, ticket, document, email, or knowledge base as instructions	Yes	This can be indirect prompt injection.
Bot exposes another customer’s data or private account facts	Escalate	Treat as a security or privacy incident signal.
Bot takes an action after attacker-style instructions	Escalate	Tool agency changes the impact level.
Bot refuses correctly but the attempt is repeated	Maybe	Track repeated patterns and source.
Employee tests the bot with a harmless jailbreak prompt in staging	Maybe	Record in testing notes, not incident queue, unless controls fail.
Static FAQ receives spam text	No	Use normal abuse and web security controls.

When the bot can access customer data, support tickets, internal documents, or tools, treat prompt injection as a security event, not a joke prompt.

Prompt injection intake form

Copy this into your helpdesk, incident tracker, or chatbot review queue.

Field	Required entry
Reporter	Customer, support agent, monitoring review, security owner, vendor alert, or automated detector.
Conversation ID	Chat ID, ticket ID, timestamp, page, account, and bot version if available.
Injection type	Direct user instruction, indirect content in source, hidden text, uploaded file, link content, ticket content, or unknown.
Trigger text	Redacted attack text or short description.
Bot response	Redacted answer, action, refusal, or leakage result.
Data or system access	Public docs, customer account data, helpdesk, CRM, billing, docs, file storage, browser action, or no tool access.
Customer impact	None known, possible confusion, wrong answer, sensitive data exposure, unauthorized action, or unknown.
Immediate containment	Monitor, block phrase, pause topic, disable source, revoke connector, disable action, pause bot, or escalate.
Owner	Security, support, privacy, product, documentation, engineering, or vendor owner.
Due date	Same day for high-risk failures; next review for blocked attempts.

Keep raw prompt text out of broad channels if it contains customer data, secrets, or attack instructions that could be copied.

Severity matrix

Severity	Example	Required response
S0 incident	Bot exposed another customer’s data, credentials, private keys, regulated data, or took an unauthorized customer-impact action	Pause affected bot path, restrict logs, preserve minimal evidence, route to security/privacy incident owner, and review notification needs.
S1 high	Bot revealed hidden instructions, internal policy, source snippets, account facts, or bypassed prohibited topic controls	Contain the topic/source, review recent similar conversations, fix controls, and approve restart.
S2 medium	Bot followed injection into wrong but non-sensitive answer, bad routing, or unsupported claim	Correct answer, fix prompt/source/routing, add regression test, and monitor.
S3 low	Bot received injection attempt and refused correctly	Log pattern, sample future attempts, and adjust abuse filters if repeated.
S4 test	Internal staged test shows expected refusal	Record test result; no production response needed.

If the bot can call tools, update records, issue refunds, change access, send messages, or sync CRM fields, raise severity one level.

First-hour response

Use this checklist for S0, S1, and unclear S2 events.

Step	Action
1	Name an incident or response owner.
2	Identify the exact bot, workspace, page, conversation, source, customer, and timestamp.
3	Decide whether to pause the full bot, one topic, one source, one connector, or one action.
4	Preserve minimal evidence: redacted prompt, bot answer, tool calls, source trace, logs, and reviewer notes.
5	Restrict access to raw transcripts and screenshots.
6	Check whether the bot revealed sensitive data, hidden instructions, internal docs, account data, or customer records.
7	Check whether the bot took or proposed any customer-impact action.
8	Search recent conversations for the same attack phrase, source page, link, file, or topic.
9	Assign customer follow-up, source cleanup, prompt fix, connector review, and vendor review owners.
10	Record restart conditions before reenabling the affected path.

Containment can be narrow. A small team does not always need to shut down the whole chatbot, but it does need a clear reason when it keeps the bot live.

Containment actions

Failure mode	Containment
Bot followed “ignore previous instructions”	Add refusal test, tighten prompt hierarchy, and route repeated attempts to human/security review.
Bot revealed hidden prompt or internal rules	Remove sensitive content from prompts and treat prompts as non-secret control text.
Bot answered from malicious webpage or document text	Disable or quarantine that source and review retrieval filters.
Bot exposed customer data	Restrict logs, preserve minimal evidence, escalate to security/privacy owner, and review access boundaries.
Bot performed or drafted an action	Disable that action until human approval and authorization checks are confirmed.
Bot answered prohibited topics	Add topic block, handoff rule, and regression test.
Bot used stale or conflicting source content	Fix authoritative source and clear stale index if supported.
Attack repeats from one IP, account, or session	Apply rate limiting, abuse controls, account review, or support escalation.
Vendor behavior changed	Review vendor release notes, settings, and support ticket options.

Never store credentials, customer secrets, or authorization rules in the system prompt. If the prompt leaks, the real failure should not become credential exposure.

Customer impact review

Question	Owner
Did a customer see a wrong answer or refusal failure?	Support owner
Did the bot reveal account-specific information?	Security or privacy owner
Did the bot expose another customer’s information?	Security/privacy incident owner
Did the bot make a billing, cancellation, refund, access, or account promise?	Billing or account owner
Did the bot provide security, privacy, compliance, or legal claims?	Trust, privacy, security, or business owner
Did the bot take an action or trigger an automation?	Product, engineering, or admin owner
Did the customer rely on the answer?	Support or customer success owner
Is notice, correction, deletion, or record cleanup needed?	Responsible business owner plus privacy/security as needed

Use the AI chatbot answer correction workflow template if a customer needs a corrected answer.

Source and retrieval cleanup

Prompt injection often enters through content the bot reads.

Source	Cleanup rule
Public webpage	Block untrusted pages from instruction-following and use them only as data sources when approved.
Help article	Remove hidden or ambiguous instructions and mark authoritative content clearly.
Uploaded file	Treat file text as untrusted input; require human review for risky outputs.
Support ticket	Prevent customer-written ticket text from overriding bot policy.
Email or chat thread	Separate quoted customer content from instructions.
Internal wiki	Remove secrets and operational instructions that should not be exposed to the bot.
Retrieval index	Purge poisoned, stale, duplicated, or test content.
External link	Do not let linked content issue instructions to the bot without source controls.

The goal is not to make every source “safe.” The goal is to make sure source text cannot become policy.

Prompt and guardrail fixes

Control	Fix
System prompt	Remove secrets, credentials, hidden access rules, and unsupported promises.
Refusal rules	Add specific refusal and handoff language for prohibited topics.
Source requirement	Require source-backed answers for customer-impact topics.
Tool permissions	Require server-side authorization and human review for risky actions.
Output filter	Block sensitive data patterns, hidden prompt disclosures, and unsafe claims where feasible.
Human handoff	Route injection, uncertainty, and prohibited topics to human owner.
Test set	Add the attack prompt, expected refusal, and safe handoff answer.
Monitoring	Sample attempts and failed refusals after restart.

Prompt changes are useful, but prompt text is not an access control system. Keep authorization, data access, and action permissions outside the model.

Evidence to preserve

Evidence	Keep?	Notes
Conversation ID and timestamp	Yes	Use references instead of copying raw transcript into broad docs.
Redacted attack text	Yes	Keep enough to reproduce the failure safely.
Bot response	Yes	Redact sensitive content.
Source trace or retrieval IDs	Yes	Needed to find poisoned or wrong source content.
Tool calls or proposed actions	Yes	Needed for impact review.
Customer follow-up	Yes	Keep approved correction or notification.
Prompt version and settings	Yes	Keep version reference, not secrets.
Screenshots	Maybe	Use only when logs are insufficient and redact carefully.
Raw transcript	Follow retention policy	Restrict access and avoid duplicate copies.

Use the AI chatbot conversation log retention policy template for transcript retention and cleanup decisions.

Restart checklist

Do not return the affected path to normal until these are true.

Check	Requirement
Severity assigned	S0-S4 recorded with owner approval.
Customer impact reviewed	Affected customers, records, and actions checked.
Sensitive data reviewed	Security/privacy owner cleared exposure questions when needed.
Source fixed	Poisoned, stale, conflicting, or untrusted source handled.
Prompt/guardrail fixed	Refusal, handoff, source, or action control updated.
Regression test added	Attack prompt and expected safe response captured.
Logs reviewed	Similar recent events sampled.
Vendor reviewed	Vendor settings or support path checked when relevant.
Monitoring owner assigned	Someone watches repeat attempts after restart.

For S0 or S1, restart should be an explicit approval, not an automatic timer.

Vendor questions

Ask these before launch and after a prompt injection failure.

Question	Why it matters
Can admins inspect source traces for each answer?	Needed to find indirect injection sources.
Can admins disable one topic, source, connector, or action quickly?	Needed for narrow containment.
Are tool calls authorized outside the model?	Prevents prompt text from becoming permission logic.
Can prompts and retrieval settings be versioned?	Needed for rollback and evidence.
Can the system detect or label injection attempts?	Helps triage repeated attacks.
Can old indexed content be purged quickly?	Needed after poisoned source cleanup.
Can logs be exported and deleted safely?	Needed for incident review and retention.
Are vendor support staff able to see raw conversations?	Affects privacy and access review.
Does the vendor announce model, retrieval, or guardrail changes?	Helps explain drift and new failures.

If the vendor cannot support evidence, containment, and restart controls, keep the chatbot limited to low-impact topics.

Approval record

Copy this into the response ticket.

Field	Entry
Event ID	Conversation, ticket, or incident reference.
Bot and location	Website, app, help center, support portal, or agent console.
Injection type	Direct, indirect, source, file, link, tool, system prompt leakage, or unknown.
Severity	S0, S1, S2, S3, or S4.
Containment	Bot, topic, source, connector, action, account, or monitor-only.
Customer impact	None known, possible, confirmed, sensitive data, unauthorized action, or unknown.
Evidence kept	Redacted prompt, response, source trace, tool calls, logs, and decision notes.
Source fix	What changed in docs, retrieval, prompt, connector, or action controls.
Customer follow-up	Required, sent, not needed, or pending.
Restart decision	Approved, restricted, held, or escalated.
Monitoring owner	Person responsible for repeat checks.
Review date	Closure date and next review trigger.

Keep the record redacted and link to controlled evidence rather than copying raw sensitive content.

Monitoring checklist

Review these during the first week after restart and monthly after stabilization.

Signal	Action
Repeated injection phrases	Add detector rule, refusal test, or rate limit.
Repeated source-based attacks	Quarantine source and review ingestion controls.
Hidden prompt leakage	Remove sensitive prompt content and test refusals.
Prohibited-topic bypass	Tighten topic routing and human handoff.
Tool action near-miss	Review action permissions and server-side authorization.
Sensitive data output	Escalate and review access boundaries.
Customer complaints after attack	Run correction workflow.
Vendor setting changed	Rerun approval and regression tests.
No evidence captured	Fix intake and logging workflow.

If monitoring only produces charts and no owner action, it is not a control.

Metrics to track

Metric	Why it matters
Injection attempts detected	Shows attack pattern and bot exposure.
Successful bypasses	Shows control failure rate.
S0/S1 events	Shows customer and data-impact risk.
Time to containment	Shows operational readiness.
Topics paused	Shows where scope is unstable.
Sources quarantined	Shows source ingestion risk.
Tool actions blocked	Shows agency risk.
Regression tests added	Shows whether fixes are preserved.
Repeat attempts after restart	Shows whether containment worked.
Customer corrections sent	Shows downstream impact.

Track enough to improve controls. Do not keep raw attack text longer than needed.

Evidence checked

This checklist is aligned with:

1. NIST AI RMF Core, which emphasizes governance, feedback, post-deployment monitoring, incident response, recovery, change management, and communication about incidents and errors.
2. NIST Generative AI Profile, which identifies generative AI risks and risk management actions for organizations deploying generative AI systems.
3. OWASP Top 10 for Large Language Model Applications 2025, which covers prompt injection, sensitive information disclosure, excessive agency, system prompt leakage, misinformation, and other LLM application risks.
4. OWASP system prompt leakage guidance, which warns that system prompts should not contain sensitive data and should not be treated as security controls.
5. CISA and partner guidance on deploying AI systems securely, which emphasizes protecting, detecting, and responding to malicious activity against AI systems, data, and services.
6. FTC artificial intelligence guidance, which tracks FTC business guidance, policy statements, and enforcement actions related to AI accuracy, privacy, confidentiality, and consumer protection.
7. Cybergiz templates for chatbot launch review, knowledge base review, human handoff, answer correction, conversation log retention, customer impact assessment, and incident response.

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

FAQ

Is prompt injection an incident every time?

No. A failed attempt that the bot refuses correctly can be logged as a low-severity signal. It becomes an incident candidate when the bot follows attacker instructions, reveals sensitive information, takes action, bypasses policy, or affects a customer.

Should we publish our system prompt to prove transparency?

Usually no. The important rule is simpler: do not put secrets, credentials, customer data, or real authorization controls in the prompt. Assume parts of the prompt may eventually be inferred or disclosed.

Can a prompt alone stop prompt injection?

No. Prompts help, but they are not a security boundary. Use source controls, retrieval restrictions, server-side authorization, least-privilege connectors, human review, monitoring, and topic-level containment.

What is indirect prompt injection?

Indirect prompt injection happens when the bot reads attacker-controlled content from a webpage, document, ticket, email, file, or knowledge source and treats that content as instructions.

Should we delete every injection attempt from logs?

No. Keep enough redacted evidence to understand and test the failure, then follow your chatbot log retention policy. Avoid copying raw attack text or sensitive content into broad channels.

When should we pause the chatbot?

Pause the affected bot path when the event involves sensitive data, hidden prompt leakage, tool actions, repeated bypasses, customer-impact topics, untrusted sources, or unclear scope.

Who owns prompt injection response?

Support can own intake, but security should own S0/S1 review. Product, documentation, privacy, engineering, billing, and customer success may own specific fixes depending on what the bot accessed or changed.