Data Isolation
Converse is a multi-tenant platform where many organizations share the same infrastructure. This page explains how your data is kept completely separate from every other organization's data.
The isolation model
Every piece of data in Converse belongs to an organization. Isolation is enforced at multiple independent layers — each sufficient on its own to prevent cross-tenant access:
1. Storage layer
All data storage enforces organization-level access controls. Queries are filtered by your organization's unique identifier at the storage layer itself — not just in application code. This means that even if an application-level bug existed, the storage layer would independently return no data for cross-organization queries.
2. Application layer
Every API request is authenticated and the caller's organization is resolved from their token. This resolved organization identifier is applied to every data operation. User-supplied input cannot override or substitute the organization identifier.
3. Call pipeline layer
When a voice or text session starts, the pipeline loads only the agents, flows, knowledge, and tools belonging to that session's organization. No resource from another organization is ever accessible within a running session, regardless of configuration.
What is isolated per organization
Knowledge base isolation
Knowledge base documents have two levels of isolation:
- Organization-level: Documents and their search indexes belong to an organization. An agent from a different organization cannot search them under any circumstances.
- Agent-level: Within an organization, documents can be assigned to specific agents. An agent can only search documents explicitly assigned to it — not all documents in the organization. This prevents agents in the same workspace from accessing each other's knowledge bases.
The knowledge search system is designed so that an organization identifier is always required. Searches without a valid organization cannot return results — they are rejected, not silently filtered.
Tool and integration isolation
Custom tools, webhooks, and MCP server connections are scoped to an organization. Within an organization, tools can be further restricted to specific agents. During a live call, the pipeline loads only tools explicitly assigned to the calling agent within the current organization. Tool definitions from other organizations are never visible or executable.
Campaign contact isolation
Campaign contacts are particularly sensitive — they contain personal phone numbers, names, and custom data. The isolation guarantees:
- Every contact record is tied to a campaign, which belongs to an organization. All contact queries are scoped to the requesting organization.
- Attempting to access another organization's campaign returns a 404 — no information about whether the resource exists is revealed.
- The campaign execution engine always verifies organization ownership before dialing any contact. A misconfigured request cannot cause contacts from another organization to be called.
Credential security
Telephony provider credentials stored in channels are encrypted before being written to storage:
- Credentials are encrypted at rest using industry-standard symmetric encryption. The encryption key is stored separately from the data it protects.
- The plaintext credentials are never stored, logged, or returned in API responses.
- Decryption happens in memory only at the moment the credentials are needed for an outbound request.
Access control
All access to organization data requires an authenticated session. Authentication is token-based with short-lived signed tokens. Tokens are verified before any data operation. Team member roles further restrict what each user can see and do within their organization — see Team & Access for details.