Security & privacy.

A plain-English summary for IT reviewers, program officers, and legal teams. Written to be checked, not to impress — where the honest answer is “not yet,” we say “not yet.”

Start here

Most of your participants never give us any data.

Participants do not create an account, and they do not install anything. A participant clicks a link, opens a browser, types a display name, and they are in the room. That is the entire join flow.

At join we create a lightweight guest record containing a display name and a system-generated ID — nothing else. Email is null. Full name is null. There is no password, no profile, no verification step, and no invitation to make an account later. If a participant types “Sam,” what we hold about Sam is the word “Sam.”

Two optional extras, both off unless the participant chooses them. “Remember me” stores a token in their own browser so a returning participant keeps their name and preferences. LinkedIn sharing is opt-in, per person, per space. Decline either and we hold nothing.

For most IT reviews this is the answer to the question actually being asked. The people your program serves are not becoming users of a software product. They are joining a room.

Hosts and facilitators — the people who create and run spaces — do hold accounts, with a name and an email address. That population is small and known to you.

Send this to your IT reviewer

The same content as a PDF you can attach to a proposal, a procurement pack, or a vendor review. Same source, same wording.

Download the PDF

Data handling

What we store, where, and for how long

Where

All persistent data is hosted in the United States: application data in a PostgreSQL database, and session media and artifacts in DigitalOcean Spaces object storage in DigitalOcean’s New York (NYC3) region. Real-time audio and video are routed by LiveKit Cloud and are not stored except through the recording feature described below.

Region selection

Not available today. Storage region is a single global setting, not a per-customer option. If regional data residency is a requirement for your programme, raise it during procurement — we will give you a straight answer on timing rather than a checkbox we cannot honour.

What we store

Account records for hosts; guest records (display name and ID) for participants; the contents of boards and spaces your teams create; messages sent in a space’s chat; and — only when a host explicitly starts them — session recordings, transcripts, and AI summaries. Kolab does not currently have direct messages: chat happens in the space, in front of the people in it.

Retention

We do not currently apply an automatic retention period. Recordings, transcripts, and summaries are retained until deleted. Configurable per-space retention with automatic expiry is scoped work, not a shipped feature, and we would rather tell you that than describe a cleanup process we do not run.

Deletion on request

An account owner can request deletion of any recording, transcript, or summary, or of all data associated with their account, and we will carry it out. Today this is performed by our team on request rather than through a self-service button. Ask and we will confirm in writing when it is done.

Consent

Recording and transcription

Nothing is captured unless a host deliberately starts it. When capture is running:

  • Every participant sees an in-session disclosure. A status indicator labelled ● REC (recording) or ● TXN (transcribing) appears for everyone in the room for as long as capture is active. It is a labelled indicator, not a subtle dot, and it is announced to screen readers the moment capture begins.
  • The recorded participant must actively consent. Kolab’s recording follows one participant’s perspective. That person receives a prompt that cannot be dismissed by clicking away or pressing Escape — they choose Allow or Not right now. It names the host who asked and lists exactly what will and will not be captured.
  • What is never captured: chat, agenda and session notes, and conversations with Kola, our AI assistant. A recording is produced by a separate recording client that renders only the canvas and the video — not the chat panel, not the message previews that appear when a new message arrives, and not any other interface chrome — so chat cannot appear in the output even if a participant has it open on their own screen.
  • Side conversations are excluded by default. Transcription captures main-room audio only; it pauses automatically during spatial audio, zoned conversations, and breakouts. A host can turn on side-conversation capture, but it is off by default and stays off unless someone deliberately changes it.

Encryption

In transit and at rest

In transit. The application is served over TLS 1.3. Real-time audio and video use WebRTC’s SRTP with DTLS-SRTP key exchange. Connections to our object storage use TLS.

At rest. Object storage is encrypted with 256-bit AES full-disk encryption by our storage provider. Our real-time media provider encrypts its persistent stores with AES-256.

Sub-processors

Who else touches the data

ProviderWhat they doWhat they receiveRegion
DigitalOceanHosting, database, object storageAll stored dataUS (NYC3)
LiveKitReal-time media routing, recording, speech-to-textLive media; recording pipelineUS
Deepgram (via LiveKit)Speech-to-text for transcripts and captionsSession audioUS
AnthropicAI summaries and the Kola assistantTranscript text; assistant conversationsUS
GoogleGenerated graphic-recap images (facilitator-triggered)Summary text as an image promptUS
DeepL / Google TranslateChat translation, per-user opt-inChat message textUS/EU
FilestackFile and image uploads to boardsUploaded filesUS
PostmarkTransactional email to account holdersHost email addressesUS
StripePaymentsBilling data only — never session contentUS
PostHogProduct analyticsUsage events and web telemetryUS

Deepgram is reached through LiveKit’s inference platform rather than under a direct contract with us, so LiveKit’s commitments are the operative ones — which is why we cite them below rather than Deepgram’s own terms.

Your participants’ speech is not used to train AI models

Kolab does not train models on participant audio, transcripts, or summaries, and our processing sub-processors are contractually prohibited from doing so.

Two links a reviewer can check without asking us for anything:

“LiveKit contractually requires each Inference Sub-processor used through LiveKit Inference not to retain, log, train on, fine-tune on, or otherwise use Inference Data for model improvement.” The same page names Deepgram as an inference sub-processor. livekit.com/legal/sub-processors
“Anthropic may not train models on Customer Content from Services.” Anthropic Commercial Terms §B — anthropic.com/legal/commercial-terms

Kolab itself operates no machine-learning training pipeline of any kind. We have never trained a model, and we do not export session content anywhere that one could be trained.

AI is a per-space switch

AI features are controlled per space by the facilitator. When Kola is off for a space, no session content from that space is sent to an AI provider. A programme that would rather not involve an AI sub-processor at all can run with AI disabled and lose nothing but the AI features.

Access

Who can see your recordings

Access to recordings and transcripts requires Host or Facilitator access to the specific space they belong to. There is no staff or administrator override in the product. Our internal admin role covers billing and usage telemetry — it grants no access to session content, and the AI and agent interfaces are scoped by the same permission checks as the application itself.

A small number of named engineers hold production infrastructure credentials, as at any hosted service. That access exists for operations and incident response, not content review.

We do not currently keep an access log for recordings and transcripts. An audit trail visible to hosts is planned. We would rather tell you it is planned than call our analytics data an audit log.

Security contact

Will Chester — will@getkolab.ai

Report a suspected vulnerability, ask a question this page does not answer, or request a deletion to that address. We aim to acknowledge security reports within two business days.

On request, not on this page: data processing agreements, completed vendor security questionnaires, sub-processor change notifications, and programme-specific data handling commitments. We do not yet offer a Kolab data processing agreement of our own — our infrastructure providers maintain their own transfer mechanisms, and LiveKit and DigitalOcean are certified under the EU–U.S. Data Privacy Framework with Standard Contractual Clauses available — so if your review requires a DPA with us directly, raise it early and we will work through it with you.

Last updated 20 August 2026. Writing a proposal? The matching language blocks live on the proposals page.

Get started

Experience the difference

Try Kolab free for 14 days or book a personalized demo.

Kolab classroom
Kolab live workspace
Kolab playful space