Prompt injection defenses for customer-facing bots

Customer-facing bots that read user text and call tools are exposed to prompt injection: hostile instructions embedded in messages, tickets, or retrieved documents. This guide is defensive only — how to reduce blast radius, not how to bypass systems.

Related: production system prompts, JSON schema outputs, AI coding assistant privacy.

Threat model (keep it boring)

Assume an attacker can:

• Type into your chat widget
• Plant text in CRM notes, emails, or web pages your RAG index will retrieve
• Ask the bot to exfiltrate data via tool calls or links

Assume they cannot:

• Directly read your server env (unless a tool exposes it — don’t)
• Bypass auth if tools check auth independently of the model

Hard boundaries that work

1. Separate trust domains in the prompt

Structure messages so developer/system rules are not concatenated naively with untrusted content. Common pattern:

• System: immutable policy + tool list
• Developer: product rules
• User: untrusted
• Tool/retrieval: untrusted, labeled as data

Instruct the model that untrusted segments are data, never instructions. This is not foolproof; it is one layer.

2. Least-privilege tools

• Default deny; allowlist tools per bot
• No “run arbitrary SQL” or “send email to arbitrary address” from the LLM alone
• Require human confirmation for irreversible actions (refunds, deletes, external posts)
• Pass server-side user id from session — never trust model-supplied identity

3. Isolate retrieval

• Strip or escape instruction-like patterns in ingested docs where feasible
• Store source URLs; show citations so users and ops can audit
• Prefer answer-from-CONTEXT with refusal when CONTEXT is insufficient

4. Constrain outputs

• Structured outputs with server-side schema validation
• Allowlisted link domains in replies when possible
• Block raw secrets patterns in egress (API keys, PATs) with a filter after the model

Monitoring & tests

• Red-team suite owned by you: known injection phrasings aimed at your tools (run internally; do not publish payloads here)
• Log tool-call args; alert on anomalous recipients, bulk export shapes, or policy refusals spikes
• Canary documents in the corpus that should never change bot policy if retrieved

Incident response sketch

1. Disable risky tools or switch to “FAQ only” mode
2. Rotate any credentials that could have been exposed via tool egress
3. Snapshot logs (prompt ids, tool traces) for review
4. Patch allowlists / prompt policy; add a regression test
5. Notify per your security policy if customer data may have left the boundary

What not to rely on alone

• A longer system prompt that says “never ignore these instructions”
• Security through obscure model names
• Client-side-only filters users can bypass

Defense in depth: authz outside the model, small tool surface, monitoring, and kill switches.

FAQ

Does using a “stronger” model fix injection?
No. Stronger models can be better and better at following malicious instructions in data. Controls beat model shopping.

Should marketing bots have tools at all?
Often FAQ + handoff beats a tool-rich agent for public widgets. Add tools only when product value clears the security cost.