Where Does Your Chatbot's Data Live? Privacy and Isolation, Explained
Every doc-trained chatbot asks you for the same thing: your content. Docs, help centers, PDFs — the material that makes the bot useful is also material you spent real effort producing, and sometimes material with real sensitivity (unreleased pricing, internal runbooks, customer-specific SOPs).
"The AI reads it" is not an answer to "where does it go". This post maps AskEmbed's data flow end to end: what is stored, where, who can reach it, and which switches you control.
The pipeline, physically
When you ingest a document, three things happen:
- The original file is stored in object storage (R2, Cloudflare's S3-compatible store), under a key scoped to your user and bot.
- Chunks — the passages the retriever searches — are extracted and persisted in the operational database alongside the document record.
- Embeddings — numeric representations of those chunks — are upserted into a vector index scoped to a namespace that is your bot's id.
Rendering an answer never sends your content to a general-purpose search index or a shared knowledge pool. Retrieval is a similarity query against your bot's namespace, and the model receives only the handful of passages that matched — the RAG pipeline we described earlier is per-bot by construction.
Isolation between bots
Every AskEmbed bot has its own vector namespace, its own document store, and its own widget credentials. Two bots under the same account cannot read each other's content: bot A's retrieval query physically cannot return bot B's vectors, because they live in different namespaces.
This matters most for teams running multiple bots with different audiences — a public-facing support bot and an internal enablement bot, say. The split is structural, not a filter the application remembers to apply.
Who can talk to your bot
Two doors, both controlled:
- The embed snippet carries a public bot id plus a per-bot public token. The token is what authenticates visitor chats — a random bot id alone cannot send messages.
- The domain allowlist (Business plan) pins which hostnames the widget will even boot on. With it set, your script pasted onto someone else's site — or a lookalike domain — gets refused before any chat happens. See widget customization for setup.
Anonymous visitors can chat; they cannot list your documents, read your source files, or query the vector index directly. The only content that ever leaves through the widget is what the pipeline composes into an answer.
What your visitors' data looks like
Questions and answers are stored as messages so the dashboard can show you what people asked and how answers were rated. Visitor identity is a random client-generated id (vis_…) — not an email, not a login, not a tracking cookie across sites. There is no cross-site identity: the id is scoped to your widget's origin in the visitor's browser.
Questions worth asking any vendor
AskEmbed's architecture answers these a certain way; other tools differ, and the differences matter:
- Is my content mixed with anyone else's? (Here: no — per-bot namespaces, per-account object keys.)
- Can my bot be embedded off my domains? (Domain allowlist on Business; public token required otherwise.)
- What identifies my visitors? (A random per-site id, nothing else.)
- Where does inference run? (Embeddings and answer generation run on the same Cloudflare edge platform that stores the data — your content is not shipped to a federated of third-party services at answer time.)
- What happens when I delete a document? (The document, its chunks, and its vectors are removed together — deletion is the rollback path for ingestion.)
If a vendor can't answer question 1 crisply, ask harder.
Hygiene on your side
The pipeline isolates bots from each other; it cannot isolate a bot from content you fed it that shouldn't be public. Two habits:
- Don't ingest internal-only material into a public bot. The bot answers from whatever is indexed — "internal" is not a concept retrieval understands. Use a second bot for internal content, and gate where it's embedded.
- De-index stale pages. Old pricing, deprecated features, last year's announcement — stale sources are a top cause of confidently wrong answers, and they linger in vector indexes precisely because nobody deletes them.
Security in a RAG system is mostly the discipline of the knowledge base. Keep it clean, keep it current, and the isolation machinery does the rest.