Kaido

Legal · 03

Security

Last updated — July 2026

Customer conversations are some of the most sensitive data a business holds. Kaido was built with the controls below from the first commit — they are how the product works, not a compliance checkbox.

Isolation in the database

Every table is scoped to a workspace and enforced with row-level security — not application code.

Least privilege

Owner, admin, agent, viewer. Every server call re-checks the role; the browser is never trusted.

Signed everything

Channel webhooks are verified with timing-safe signatures over the raw body before parsing.

01

Principles

  • Security is enforced at the lowest layer that can enforce it — usually the database.
  • Client-side checks are UX, never the control.
  • Secrets live in a managed vault, never in code or the browser.
  • Every privileged action is validated, authorised, and logged.

02

Workspace isolation

Every record — conversation, message, contact, article, report — carries its workspace ID, and row-level security policies in the database restrict every read and write to members of that workspace. Even a bug in application code cannot leak one customer's data to another, because the database itself refuses the query.

03

Encryption

  • TLS 1.2+ for all traffic in transit, including webhooks and the chat widget.
  • AES-256 encryption at rest for the database, file storage and backups.
  • Passwords are salted and hashed (never stored, never readable). Invite and widget tokens are stored only as SHA-256 hashes.

04

Access control

  • Four roles — owner, admin, agent, viewer — checked server-side on every request.
  • Sign-in with email + password or Google; password reset flows never reveal whether an account exists.
  • Rate limiting on authentication, public endpoints and AI calls.
  • Workspace invitations expire, are single-use, and are stored hashed.

05

Webhooks & integrations

Inbound webhooks from WhatsApp, Meta, telephony and payments are verified with provider-specific signatures using constant-time comparison over the raw request body — before any parsing happens. Unsigned or mis-signed requests are rejected and logged. Outbound fetches (like knowledge-base imports) run behind an allowlist that blocks private networks, so the platform cannot be turned into a proxy into anyone's infrastructure.

06

AI guardrails

  • Customer messages and imported content are treated as untrusted data — they are fenced off from the AI's instructions, so a message cannot "reprogram" the assistant.
  • The AI's ability to act (close, assign, escalate) is limited to a fixed, validated set of commands — it cannot invent new capabilities.
  • Every AI action and message is attributed and auditable.
  • Workspace data never trains shared models.

07

Operations

  • Infrastructure as code; changes ship through review, type-checking, linting and tests.
  • Continuous dependency and secret scanning.
  • Backups with tested restores; 30-day recovery window after workspace deletion.
  • SOC 2 alignment and GDPR-ready data-processing terms; SSO/SCIM on the Scale plan.

08

Reporting a vulnerability

Found something? Tell us at hello@kaido.app with "SECURITY" in the subject. We acknowledge reports within 48 hours, keep you updated, and never take legal action against good-faith research. Please avoid accessing other people's data — a proof-of-concept against your own workspace is enough. See also our Privacy Policy and Terms.