(
Rumbe AIRumbe AI
Tenant Isolation / Rumbe AI

Multi-Tenant Isolation

Every customer’s data, retrieval, credentials, settings, and audit records are bound to an organization identifier — and verified server-side on every protected operation.

What stays separated

Strict boundaries, end to end.

01Customer & agent identities
02Conversations & tickets
03Knowledge & vector collections
04Widget keys & domains
05Provider credentials
06Audit & activity logs

Organization-Level Data Boundaries

An organizationId or equivalent tenant identifier scopes records to the active customer. Authorization logic must verify that the authenticated user belongs to the tenant before returning or modifying a record.

  • Customer and agent identities
  • Conversations and messages
  • Tickets, queues, summaries, and sentiment
  • Knowledge articles and uploaded documents
  • Widget keys and allowed domains
  • LLM provider configuration and encrypted secrets
  • Billing entitlements and add-ons
  • Audit and activity records

Database-Level Enforcement

Application queries should include the active organization boundary by default. Sensitive operations require both role authorization and tenant ownership checks.

A secure implementation avoids accepting an organization identifier from an untrusted client as the sole basis for access. The tenant context should be derived from authenticated server-side state and verified on every protected operation.

Tenant-Isolated RAG

Rumbe’s vector retrieval layer uses organization-specific collections. Queries are sent only to the active tenant’s collection, reducing the risk that an answer could be grounded in another customer’s documents.

Your support AI only retrieves from your organization’s approved knowledge sources.

Tenant-Specific Configuration

  • AI provider and selected model
  • Prompt instructions and tone
  • Knowledge-base content
  • Hidden-from-source settings
  • Widget branding and domain allowlist
  • Agent limits and capacity
  • SSO configuration
  • Retention and operational policies

Multi-Brand and Agency Use Cases

Tenant separation is important for agencies, healthcare groups, enterprise divisions, franchise networks, and companies operating multiple brands. Each environment can maintain distinct agents, content, widget settings, and AI behavior without mixing knowledge or customer interactions.

Testing Isolation

A mature isolation program should include negative authorization tests, cross-tenant identifier manipulation tests, vector-collection boundary tests, cache-key review, export validation, attachment access testing, and administrator privilege review.

FAQ

Frequently asked questions

Can one Rumbe customer access another customer’s conversations?

The documented architecture uses organization-level boundaries intended to prevent cross-tenant access. This should be validated through deployment testing and security review.

Can the AI retrieve another tenant’s documents?

Rumbe’s RAG design uses tenant-specific vector collections and organization-scoped retrieval.

Is tenant isolation only applied to the database?

No. The mapped model extends to operational records, knowledge retrieval, settings, credentials, widgets, and audit logs.

Does a multi-brand company need separate tenants?

That depends on governance and data-separation requirements. Separate tenants can provide stronger operational and knowledge boundaries between brands or business units.

Evaluate Rumbe AI for your environment.

Vovance Inc. can discuss Rumbe AI’s architecture, available controls, deployment assumptions, and contractual options for your use case.

)