01. The Real Threat Model
The failure modes that matter in practice are specific and recurring: a chatbot answering from documents the current user shouldn't see, a crafted instruction hidden inside retrieved content changing its behavior, or a confidently wrong answer being treated as a binding commitment by the person reading it.
02. Specific Risks
- Retrieval permission gaps — content scoped incorrectly so an authenticated user can retrieve information from a different account or role than their own.
- Prompt injection via retrieved content — crafted text inside a document or ticket designed to override the system's intended behavior once retrieved and included in context.
- Hallucinated commitments — a fluent, wrong answer about a policy, refund, or contract term that a customer reasonably treats as authoritative.
- Transcript data exposure — conversation logs storing more sensitive content than the retention and access policy accounts for.
03. Defenses That Work
- Scope retrieval to the authenticated identity's actual permissions at query time, not as a post-response filter.
- Treat all retrieved content and user input as untrusted, the same posture used for any external input to a production system.
- Require explicit confirmation, and human approval above a threshold, for any binding commitment or irreversible action.
- Apply the same data retention and access policy to transcripts as to the source systems they reference.
- Attach citations to every substantive answer, making it possible to verify what the answer was actually grounded in.
04. What to Ask a Vendor
- How is retrieval scoped to the current user's actual permissions?
- How is retrieved content treated, trusted or untrusted, when constructing a response?
- Which actions require explicit human approval regardless of answer confidence?
- What's the retention and access policy for conversation transcripts?
See our AI chatbot guide for how these controls fit into the wider retrieval and synthesis pipeline.
05. Frequently Asked
Can a chatbot be tricked into revealing information it shouldn't?
Yes, if retrieval isn't scoped to the authenticated user's actual permissions. The chatbot should only be able to retrieve content the logged-in identity is entitled to see, checked at retrieval time, not just filtered from the response afterward.
What is prompt injection through retrieved content?
If a document in the knowledge base contains text crafted to look like an instruction, a support ticket with embedded text saying 'ignore previous instructions', a chatbot that treats retrieved content as trusted can be manipulated into unintended behavior. Treating all retrieved content as untrusted input is the defense.
Can a chatbot make a binding commitment it shouldn't?
Not if designed correctly. Refund approvals, contract terms, and other binding commitments should require explicit confirmation and, for anything above a threshold, human approval, regardless of how confident the synthesized answer sounds.
Cloudz Computing scopes retrieval to authenticated permissions and treats every retrieved passage as untrusted input by default.
Explore the AI Chatbots solution →
Request a private consultation