Keeping One Customer's Data Away From Another: Multi-Tenant Security in a Chatbot Platform

Most business software, including chatbot platforms, is multi-tenant: many customers share the same application and database, each in their own workspace. It is efficient and keeps prices low, but it carries one serious risk. If the software ever mixes up whose data is whose, one customer can see another's conversations, leads or documents. For a chatbot, that could mean your visitors' messages, your price list or your customer contact details appearing in someone else's dashboard, or someone else's private notes surfacing in your assistant's answers. Such failures are rarely dramatic hacks; they are usually small mistakes, like a missing ownership check on one endpoint. This guide explains in plain language how tenant isolation works, the classic mistakes known as IDOR and BOLA, the layers of protection a careful platform uses, how retrieval and secrets are kept apart, how such systems are tested and what questions to ask any vendor. It describes the approach Crescelo takes without claiming certifications it does not hold.

What multi-tenant means

Multi-tenant is perfectly safe when it is done carefully, and most modern software-as-a-service works this way. The care is in the details.

The core idea: every record belongs to a workspace

Every conversation, lead, document, assistant and setting carries the identifier of the workspace that owns it. Every request from a logged-in user carries the identity of their workspace, taken from the session, not from anything the user can type. Every read or write must check that the record's workspace matches the requester's. If any step forgets this check, that step is a hole.

IDOR and BOLA: the classic mistakes

IDOR stands for insecure direct object reference, and BOLA for broken object level authorisation. Both describe the same flaw: the server accepts an identifier from the request, such as an assistant number, and returns the record without checking that the requester is allowed to see it. An attacker, or a curious customer, simply changes the number in the address and receives someone else's data.

Sequential or guessable identifiers make this worse, though unguessable identifiers alone are not a defence: the check must exist regardless.

Layers of protection

1. Authenticate: know who is calling. Sessions are checked against the account's current state on every request, so removing a member ends their access immediately.
2. Take the workspace from the session, never from the request body.
3. Check ownership of the specific record before reading or changing it. In Crescelo, a guard verifies that an assistant belongs to the caller's workspace before any action on it.
4. Check the role: within the workspace, roles limit what each member can do; see securing your chatbot account.
5. Scope queries so the database only returns rows for the workspace.
6. Test that cross-workspace access is refused.

The platform owner's master-admin role is a deliberate exception, used for support and administration, and it should itself be protected with strong authentication and logging.

Isolating search and answers

Retrieval brings a special risk: the assistant must only find passages from the right workspace and, within it, from the right assistant. The search is filtered by assistant and workspace before ranking, not afterwards, so another customer's passage can never be a candidate for an answer. If it were filtered after ranking, a stray passage could leak into the context sent to the AI model. Embedding and re-embedding jobs follow the same rule.

Secrets and keys

• Each customer's AI provider key is stored encrypted and used only for that customer's requests; see how a key vault works.
• Keys are never sent to visitors' browsers.
• Public widget requests use tokens tied to a single conversation rather than credentials that unlock the workspace; see signed visitor tokens.
• Outbound webhooks are signed so the receiver can verify them.

Rate limits and abuse controls per tenant

Isolation is also about fairness. One customer's traffic spike or abuse must not degrade service for others. Per-assistant and per-visitor rate limits, session allowances by plan and spending guards protect the platform and each customer's budget.

How to test isolation

Crescelo's automated tests include cross-workspace and ownership checks for API routes, and they run before each release. Automated tests find many issues; independent security testing adds assurance, and we do not claim formal certifications.

Questions to ask your vendor

• How is my workspace's data separated from other customers'?
• Do you check ownership on every record access, and do you test for cross-tenant access?
• How is search isolated between customers?
• How are provider keys stored?
• Can support staff see my data, and is that access logged?
• Do you have a data processing agreement and a list of sub-processors?

Look for specific answers. See how your data is protected and the sub-processors page.

Common mistakes

• Trusting an id from the request without an ownership check.
• Filtering search results after ranking.
• Guessable ids with no authorisation.
• Shared credentials between tenants.
• No tests for cross-tenant access.
• Over-broad admin access.

What this means for you as a customer

• Use named accounts and the smallest suitable roles for your team, so your own workspace is protected from the inside.
• Turn on two-factor sign-in for owners and admins.
• Keep confidential material out of the knowledge base unless the assistant is meant to use it.
• Ask your vendor for a data processing agreement and a list of sub-processors, and keep copies.
• Tell the vendor at once if you ever see data that is not yours.

Isolation is the platform's responsibility, and good practice inside your workspace is yours. Together they keep customers' information where it belongs.

Frequently asked questions

See the data processing addendum, the human handover feature, the knowledge base feature, pricing and read how a chat widget is built.

Further reading

• OWASP Top 10 for Large Language Model Applications: The main security risks of AI assistants, including prompt injection.
• Google Search Central: creating helpful, people-first content: What Google looks for in useful pages.