Krisp
How Krisp protects your conversations, AI keys, and customer data
A customer support platform holds your visitors’ conversations and your external API credentials. This page documents our exact security architecture: how workspaces are isolated, how secrets are sealed with AES-256-GCM, how webhooks are signed, and where your data lives.
- AES-256-GCM sealed secretsAI keys, bot tokens, and channel credentials are checked with their service before save, encrypted at rest, and never logged.
- RFC 6238 two-step sign-inAuthenticator app TOTP codes, single-use recovery codes, and remote device session revocation.
- Strict CSP & frame locksNo third-party scripts; widget framing is locked to your allowlisted domains via
frame-ancestors. - EU hosting & live backupsHosted in the European Union with continuous off-site database replication and 30-day snapshots.
What happens to customer messages, AI prompts, and order lookups
Every boundary between your website visitors, your team dashboard, your AI model provider, and your store backend is explicitly enforced.
-
1. Visitor & widget isolation
A visitor holds a token scoped only to their own conversation, and a link in an email carries a one-time code instead of that token. Internal team notes, operator accounts, AI token costs, and other visitors’ threads are stripped at the server boundary. Browser requests to the widget API from a website not listed in your workspace are refused, and the loader stays hidden anywhere else.
-
2. AI provider & training boundary
The built-in local AI engine runs in-process and sends nothing outside Krisp. When you use a hosted LLM or bring your own API key, only the active thread and the pieces of your knowledge matched to it are sent over HTTPS to that provider. Shared training is opt-in and strips emails, phone numbers, URLs, and long numbers.
-
3. Zero-copy order verification
Your order database is never copied into Krisp. When a customer requests order credentials in the chat, Krisp sends one HMAC-SHA256 signed HTTPS
POSTto your server for each purchase email they type, within the tries you allow. It refuses redirects, resolves your endpoint’s name at every call and connects only to the public addresses it checked, and keeps the signing secret encrypted. What your server returns is posted in the conversation and kept with it.
Twelve controls enforced across every workspace
Built into the core server—not bolted on as paid enterprise add-ons.
Scoped to your workspace
Every database query is scoped by the authenticated caller’s workspace_id. Requesting a conversation, contact, message or file that belongs to another workspace returns 404 Not Found rather than 403 Forbidden, leaking nothing about its existence.
Secrets sealed, never shown
AI API keys, Discord and Telegram bot tokens, Facebook Page tokens, Meta app secrets and WhatsApp access tokens are tested with their provider before saving, as are the server’s own Stripe, PayPal, OxaPay and SMTP credentials; webhook signing secrets are checked for their format. All are encrypted with AES-256-GCM, shown only as a masked hint afterwards, and never written to logs. The order lookup signing secret is sealed the same way and shown in full only to an owner or admin who reveals it, which the audit log records. The Crisp importer keeps no Crisp key at all: the key serves the run it was given for, and only the website ID and the token identifier (sealed) are kept to carry on.
Passwords, sessions & API keys
Passwords are hashed with scrypt; refused sign-ins take constant time whether or not the email exists. Browser sessions and scoped API keys (read / write) are random tokens stored only as peppered SHA-256 hashes. Changing a password revokes all other sessions, and a session ends 14 days after sign-in.
Two-step sign-in (TOTP)
Standard authenticator-app codes (RFC 6238) with 10 single-use recovery codes. Each TOTP code is accepted once and rate-limited to 6 tries per 15 minutes. Mandatory for platform administrators, who must re-verify within 12 hours to view and 30 minutes to modify platform settings - renaming or deleting a workspace that is not their own included.
Sandboxed media uploads
Only JPG/PNG images (up to 10 MB) and MP4/WebM videos (up to 50 MB) are accepted, verified from magic byte signatures rather than filenames. Attachments are served with X-Content-Type-Options: nosniff and a sandboxed CSP so uploaded files can never execute script.
Outbound SSRF protection
Every URL you configure—your order lookup endpoint, custom AI provider URL, or website pages crawled for AI training—must use public HTTPS in production. Loopback, link-local, and private RFC 1918 addresses are refused. In production, your order lookup endpoint and your own AI provider are resolved at every call and connected to only at the public addresses that were checked, as are the pictures and videos Messenger, Instagram and WhatsApp point to. Order lookups and AI calls never follow a redirect, a crawled page, sitemap or store catalogue may redirect at most three times with every hop’s addresses checked, and response bodies are byte-limited.
Strict browser & frame policy
Every response carries a strict Content-Security-Policy with script-src 'self' and zero external font or script dependencies. Dashboard pages can be framed only by Krisp itself (frame-ancestors 'self' and X-Frame-Options: SAMEORIGIN); the widget page allows framing only on the websites you list.
Cryptographically signed webhooks
Order lookup requests are signed with a per-workspace HMAC-SHA256 key and timestamped, so your server can refuse anything older than five minutes. Stripe webhooks are signature-verified and re-fetched with the server’s key; Resend inbound emails are verified via Svix and fetched from Resend’s API; Meta webhooks for Messenger, Instagram and WhatsApp verify X-Hub-Signature-256; a PayPal event counts only when PayPal’s own check confirms it, the payment is then fetched from PayPal, and it changes a plan only at that plan’s price, in its currency; OxaPay payments are confirmed with OxaPay before a plan changes.
Continuous off-site backups
The SQLite database streams its changes off the server every second to a separate EU storage provider, with a full snapshot each day kept for 30 days, so it can be restored to any moment in that window. On startup, the server checks its seal key before accepting traffic.
Links in emails work once
The link in a reply or transcript email carries a one-time code, never the visitor’s token. Only a hash of the code is kept, bound to that visitor and conversation; it works once, within seven days, and only for its own workspace. Opened in a browser with no conversation in that workspace, it ends every token the visitor had before and closes their open connections, so nobody who passed the link on can read along; a browser holding another visitor’s conversation keeps it, and the link stays unused.
Email to visitors, capped
Replies and transcripts go to visitors only on plans with the email channel, and are counted over the last 24 hours: 300 per workspace on Starter, 1,000 on Growth, 3,000 on Scale, and 10 to any one address from the whole server (50 for a conversation that address has answered by email). A transcript a visitor asks for is limited per visitor, per address and per workspace; an invitation is emailed again at most once in ten minutes and five times a day.
Limits on live connections
One network address may hold 50 live connections at once; the next is refused with 429, and the chat checks for new messages every few seconds until one is free. A connection that has not said who it is within 30 seconds is closed. New connections are rate-limited per address, and the server keeps a ceiling on all of them together.
Security controls reference
Summary of the cryptographic primitives, headers, and operational policies enforced in production.
| Domain | Implementation in Krisp | Where to manage / verify |
|---|---|---|
| Secret & token encryption | AES-256-GCM with random 96-bit IVs under a key derived from the server’s seal secret; verified at startup |
Settings → Integrations, Settings → Channels and Settings → Order lookup |
| Account authentication | scrypt password hashing, constant-time login response, HttpOnly; SameSite=Lax; Secure session cookies, CSRF guard |
Settings → Account |
| Two-factor authentication | RFC 6238 TOTP (SHA-1, 6 digits, 30 s step, single-use replay lock) + 10 single-use recovery codes |
Settings → Account → Two-step sign-in |
| API key security | Shown once at creation, stored as peppered SHA-256 hash, scoped to read and/or write; never accepted for billing, team, key, budget or settings changes, sending messages, or imports |
Settings → API keys |
| Audit trail | Append-only workspace audit log - no edits or deletions, removed only with the workspace - recording actor, IP address, action type, and target resource (secrets excluded) | Settings → Audit log |
| Order lookup signatures | X-Krisp-Signature: v1=<hex> computed with HMAC-SHA256 over <X-Krisp-Timestamp>.<raw_body> |
Settings → Order lookup & Docs |
| Hosted chat pages | X-Robots-Tag: noindex on /chat/<slug>, the widget frame and workspaces’ own chat domains; a “Report this page” link under every hosted chat page; a workspace named after a brand or one of Krisp’s own words gets a numbered address |
Settings → Setup |
| Hosting & data residency | European Union servers behind a CDN that hides origin IP, TLS everywhere, off-site EU backup replication (30-day retention) | Privacy policy |
Where things run, what is not built yet, and how to report an issue
We would rather state our boundaries plainly before you sign up than have you guess.
Where things run
Krisp runs on servers in the European Union behind a content delivery network with HTTPS everywhere, and replicates its database to a separate EU storage provider. External AI providers receive conversation text only when your workspace uses them; the built-in engine sends nothing outside Krisp.
What we do not have yet
There is no SAML/OIDC single sign-on (SSO) yet, no password reset by email, no malware scanning of uploaded files beyond strict magic-byte type verification and sandboxed headers, and no full-database encryption at rest beyond AES-256-GCM sealed credentials. This page updates as those ship.
Reporting a security issue
If you believe you have found a security vulnerability, contact us through the contact page or email hello@krisp.chat with “security” in the subject line. We investigate every report promptly and reply with what we did to fix it.
Related pages
Questions about security or compliance?
Ask us before you sign up—we read every message and answer directly.