Security

How isolation, encryption and the request path work

With enough detail to ask a pointed question about any of it. Last reviewed 2026-09-10.

Tenant isolation

Enforced by the database, not remembered by a query

Postgres row-level security is applied in the engine against a session context set once per request. A query that forgets its tenant filter returns nothing rather than everything.

  • No WHERE clause to forget
  • Another tenant's id returns a 404
  • Isolation happens first, not last
A query that forgets its tenant filter
  • Workspace Areturns nothing
  • Your workspacereturns your rows
  • Workspace Creturns nothing

Enforced in Postgres, not in application code

The request path

From a keystroke to a lead in Slack

  1. 01

    Step 1

    The visitor's browser

    The widget is served from the API's own origin, not from your site, so it cannot read your page's DOM, your cookies or your session. A compromised assistant cannot become a compromised website.
  2. 02

    Step 2

    The public endpoint

    Rate-limited per bot and protected by an adaptive challenge. A failed challenge returns a specific code the widget can act on, so recovery is a re-render rather than a dead end.
  3. 03

    Step 3

    The tenant context

    Before any query runs, the request establishes which workspace it belongs to and sets that as the database session's context. Everything after this point is constrained by it.
  4. 04

    Step 4

    Retrieval

    The question is embedded and matched against that workspace's indexed content only. The passages found are what the model is given — it is not asked to recall anything about your business.
  5. 05

    Step 5

    Generation

    The model receives the retrieved passages and the conversation turn. It does not receive your credentials, your other conversations, or anything belonging to another workspace.
  6. 06

    Step 6

    Actions

    A booking or a lead is carried out server-side using credentials decrypted with your workspace's own key, used for that call and not retained in memory beyond it.

Encryption

Three layers, each on top of the last

The per-workspace key has a separate index key beside it, because searchable and confidential encryption want different properties — one key for both lets the weaker set the strength.

  1. In transit

    TLS on every hop, with HSTS on the public surfaces.
  2. At rest

    Storage-layer encryption on the database and object storage.
  3. Per workspace

    Connected-account credentials sealed with your workspace's own data key.

Worth knowing

Where the boundaries are

Model providers see the retrieved passages

Answering means sending your content and the visitor's question to a model. Which providers, and what each receives, is on the subprocessors page.

A custom tool calls out from our network

URLs are validated and the resolved address pinned — but you are still letting a server call your endpoint, so scope the credential you give it.

Anything a visitor types is stored

Conversations are kept so you can read them and so analytics can find the gaps. Don't build an assistant that asks for card numbers or health data.

No third-party penetration test yet

Everything here is our own design and review. When an external test happens, its summary goes on the compliance page.

Questions or a finding: security@integrable.cloud · how to report

See what it drafts from your site. Free to start, no card, live in minutes.

Start free