AI knowledge base security: a RAG checklist for support bots

Adding product manuals, support policies, and frequently asked questions to an AI knowledge base can keep customer-service answers closer to the business. But “grounded in company documents” does not mean inherently safe. A bad document, stale permission, hidden instruction, or cross-customer retrieval can still produce an answer that should never appear.

The OWASP RAG Security Cheat Sheet maps Retrieval-Augmented Generation risks across ingestion, embeddings, retrieval, generation, output, and tool use. Its central lesson is that RAG can reduce guessing when business information is missing, but it redistributes risk across the entire data pipeline.

The checklist below is for operators, product owners, and engineering teams preparing a knowledge-base support bot. It can serve as a pre-release review or as a set of questions for a vendor.

1. Admit only traceable material into the knowledge base

A knowledge base is a content supply chain. If a shared drive, ticket attachment, web source, or synchronization connector is compromised, malicious content may later be retrieved and influence an answer.

At minimum, record:

• Who uploaded or synchronized each document.
• Which system it came from and when it entered the knowledge base.
• Who approved it for use in customer answers.
• Its current version, integrity hash, and last update.
• Which older versions were withdrawn or expired.

OWASP recommends hashing documents at ingestion and scanning for hidden instructions, invisible Unicode characters, and zero-width spaces. A file extension or MIME type describes format; it does not establish trust.

2. Treat retrieved material as data, not commands

A document can contain text such as “ignore all previous rules.” Even when that text comes from a PDF, web page, or internal document, it remains data to cite rather than an instruction that may change the bot's system behavior.

An implementation should clearly delimit retrieved content, limit the number and total size of chunks placed in context, and inspect them for common injection patterns before sending them to the model. The OWASP prompt injection prevention guide likewise recommends separating system instructions from external content instead of expecting the model to determine trust by itself.

For an operator, the practical version is simple: do not bulk-import scraped pages, user attachments, or unknown shared documents without review.

3. Preserve permissions on every knowledge chunk

When a document is split into retrieval chunks, its original permissions must not disappear. OWASP recommends attaching owner, role, tenant, and classification metadata to every chunk and checking authorization again for every retrieval.

This matters directly in customer support. A policy, internal case note, or private quotation for customer A must not appear in an answer to customer B merely because the text is semantically similar. Authorization must happen before content reaches the model; it cannot be delegated to the model's judgment.

Before launch, test whether:

• Customers, groups, or teams can retrieve one another's material.
• Old chunks become unavailable when source permissions change.
• Deleting a source also removes its vectors, cached answers, and derived indexes.

4. Make important answers traceable to a source

Without provenance, it is difficult to tell whether an answer came from an approved policy, an obsolete guide, or model completion. High-impact topics such as refunds, prices, account permissions, and service scope should retain the document name, version, update time, and relevant chunk record.

Ordinary users may not need every piece of internal metadata, but an administrator should be able to answer, “Which source produced this reply?” If sources conflict, are stale, or cannot be accessed, the bot should expose uncertainty and route the question for human confirmation.

5. Do not silently become a general chatbot when retrieval fails

If the knowledge base is unavailable, authorization fails, or no acceptable source is found, silently falling back to model knowledge is especially risky. The tone may remain the same, so the reader cannot tell that the answer is no longer constrained by company material.

A safer response explicitly says that no verifiable source was found, narrows what it will answer, or hands the case to a person. A secure system makes failure visible instead of disguising a failed control as a normal reply.

6. Authorize high-risk actions independently

A support bot may eventually connect to order, refund, account, or outbound-message tools. Retrieved content must not decide by itself whether those actions execute.

OWASP recommends independent tool permissions and allowlists, plus explicit user confirmation for payments, deletion, and external API calls. A model requesting a tool does not prove that the current user is authorized. A complete audit record should connect the user request, retrieved material, generated answer, and final tool invocation.

7. Test with real attack scenarios

Happy-path questions prove only that the bot can answer. They do not prove that knowledge boundaries work. Add at least these adversarial checks before launch:

1. Upload a test document containing hidden prompts or zero-width characters and verify that it is blocked or flagged.
2. Ask an unauthorized account about unique content in a restricted document and verify that nothing leaks.
3. Delete or revoke a source, then confirm that old chunks and cached answers no longer appear.
4. Simulate a retrieval timeout or authorization failure and confirm that the bot does not answer freely without warning.
5. Let a hostile document request a refund, deletion, or external service call and confirm that independent authorization and human confirmation still apply.

Record the input, retrieved sources, actual output, and any tool attempt so the same tests can run again after a model or index update.

Questions to ask when buying or configuring a knowledge-base bot

If the system is a managed product, convert the technical controls into direct procurement questions:

• Who can import documents, and are approval, version, and provenance records available?
• How is knowledge isolated between groups, teams, and customers?
• How quickly do index and cache entries follow source deletion or permission changes?
• Can administrators inspect answer sources, and what does a user see when retrieval fails?
• Which tools can the bot invoke, and do sensitive actions require confirmation?
• Are retrieval and action logs retained for incident investigation?

The same questions apply to knowledge-base support inside Telegram. YourCopilot is designed to answer private chats, groups, and Telegram Business messages from configured knowledge. This article is a general selection and security-review framework; it does not claim that the product currently implements every control in the OWASP checklist. Verify current capabilities in the product page, administration interface, privacy information, and release notes.

Sources

• OWASP Cheat Sheet Series, Retrieval-Augmented Generation (RAG) Security Cheat Sheet. The page does not state a fixed publication date; accessed September 24, 2026.
• OWASP Cheat Sheet Series, LLM Prompt Injection Prevention Cheat Sheet. The page does not state a fixed publication date; accessed September 24, 2026.