1. Isolation: is my knowledge base really mine?
Multi-tenant AI products usually filter by a tenant column in application code — one forgotten WHERE clause away from a leak. Flocci Chat enforces isolation in the database itself with PostgreSQL row-level security keyed on app.current_tenant_id: a query that forgets the tenant returns nothing rather than someone else's data. Widget traffic authenticates with a per-workspace key that can be rotated or revoked.
2. Scope: what actually gets indexed?
Three sources, all of them yours: the onboarding crawl of your public site, pages a visitor renders while the widget is present, and files or text you upload. Nothing else. The single most important control is data-passive-ingest="off" — one attribute on logged-in surfaces means private in-app screens are never learned, which is exactly how Flocci runs the widget inside its own authenticated products.
3. Prompt injection: can a page talk to the assistant?
If a chatbot pastes page content or host-app state into the prompt with the same trust as its own instructions, anyone who can publish content on your site — a review, a comment, a CMS entry — can rewrite the assistant's behaviour. Flocci Chat frames both page context and app context explicitly as untrusted reference data, with an instruction never to follow directives found inside them. That framing was tightened deliberately after review: page context previously entered at knowledge-base trust level, which is a real class of vulnerability rather than a theoretical one.
4. Live user data: what proves who the customer is?
Personalised support means proving identity, not trusting a claim. flocciChat.identify() takes an HMAC-SHA256 signature computed on your server with a secret only you hold; the signature covers the user id itself, so a visitor cannot re-identify as somebody else by editing a payload. Anything a verified session does through an agentic action is logged with the action, the round and the outcome. Live screen state pushed through the Context API is used for the current message only and is deliberately never persisted to any table.
5. Exit: can I get everything out, and can I delete it?
Export as JSON or CSV from the dashboard; destructive deletion for right-to-erasure requests is a supported operation, not a support ticket. Secrets you configure for connectors — bearer tokens, webhook credentials — are encrypted at rest with AES-256-GCM rather than stored in clear text.
6. Behaviour under stress
Security includes what happens when things break. Chat completions run on DeepSeek through a provider abstraction; embeddings are real or explicitly disabled, never faked, and the system reports which mode it is in on its health endpoint. When the billing service is unreachable the system fails open — visitors keep getting answered rather than being cut off by an outage on our side.
A checklist you can send to any vendor
- Is tenant isolation enforced in the database or only in application code?
- Exactly which pages and files enter the index, and how do I exclude a surface?
- Is page content treated as untrusted input in the prompt? Show me where.
- How is a logged-in user's identity verified — a signature, or a claim in a script?
- Can I export and hard-delete all data myself, without a support request?
- How are connector credentials encrypted at rest?
- What does the assistant do when the model provider or billing is down?