This page lists what Kelu does to protect your data and the settings you control.

​
Sign-in

  • Methods: email and password, Google, GitHub, or SSO with OIDC or SAML 2.0 on the Enterprise plan or a metered plan.
  • Require SSO turns off every other sign-in method for your verified domain. The workspace owner keeps password access.
  • Two-factor authentication: turn it on under Profile → Security → Two-Factor Authentication. It uses an authenticator app code, with backup codes.
  • Passwords are stored as bcrypt hashes, never in plain text.
  • reCAPTCHA v3, when enabled, protects sign-in, registration and password reset, and requests made with a public client key. The widget handles the token for you.

​
Keys

KeyWhereNotes
Public client key (kl_pk_…)Knowledge base → Integrations → Client KeysSafe in a web page. Set Allowed origins.
Secret client key pair (kl_ci_… / kl_cs_…)Same placeFor your server only. Skips the origin check and captcha.
Workspace API key (klk_…)Settings → API KeysCovers the whole workspace.
Secrets are shown once, when you create them. Kelu stores only a hash, so it cannot show them again.
1

Restrict public keys to your domains

Add your site under Allowed origins, for example https://docs.example.com. https://*.example.com covers subdomains. A key with no allowed origins works from any website.
2

Keep secret keys on your server

Never put kl_cs_… or klk_… keys in a browser or mobile app.
3

Revoke a leaked key

Revoke it under Client Keys, or delete it under API Keys. It stops working at once.
A client key allows 600 requests per minute unless you set a different Rate limit when you create it. Over the limit, requests get 429.

​
Control who sees what

  • Roles: owners and admins manage the workspace. Other members get access per knowledge base. See Roles & Permissions.
  • Internal knowledge bases have no public surface. No client key works with one, so only signed-in team members, and any chat bot connected to it, can ask it questions.
  • Restricted documents are hidden from public surfaces: the widget, public API, form deflector, helpdesk replies and public MCP. Team members in Ask still see them. Every document in an internal knowledge base is restricted. Visibility is set on the knowledge base, not on each source.
Slack and Teams bots can answer from restricted documents. Anyone in a channel where the bot is installed can see those answers, so connecting a bot to internal content shares it with that channel.

​
Your data

  • AI providers: to index your content and answer questions, Kelu sends your content and readers’ questions to its AI model providers. With Bring Your Own Model, answers run on your own provider account instead.
  • Personal data: turn on PII masking before you index tickets, chat history or uploads.
  • Retention: set a retention window or zero data retention.
  • Readers: the widget identifies a reader with a random ID stored in their browser. No name or email is needed to chat. Analytics store no reader IP addresses.
  • Stored credentials: keys and tokens you give Kelu for sources, bots, helpdesks and AI providers are never shown again after you save them. AI provider keys, source credentials, helpdesk credentials and an Intercom agent app’s token are also encrypted with AES-256-GCM.
  • Kelu staff access: when Kelu staff open a trace or sign in as a user to help you, the access is recorded in Kelu’s internal audit log.

​
Activity Log

Settings → Activity Log records sign-ins, registrations, password changes, member invites and removals, role changes, ownership transfers, workspace and knowledge base changes, and workspace API key changes. Owners and admins can read it.

​
Answer safety

  • Grounded answers: when your sources do not cover a question, the model gets no content and no citations, so it says it cannot answer instead of guessing.
  • Citations: each answer links to the documents it used.
  • Untrusted content: the model is told to treat instructions found inside your documents as content, not as commands.

​
Signed webhooks

Kelu checks the signature on every incoming webhook:
SourceCheck
GitHub source syncX-Hub-Signature-256 (HMAC-SHA256)
SlackSlack signing secret, requests older than 5 minutes refused
Microsoft TeamsBot Framework token
HelpdesksThe platform’s own signature (Zendesk, Intercom, Front), or an HMAC with a secret Kelu generates
SAML sign-inXML signature against your IdP certificate
Webhooks that Kelu sends you carry X-Kelu-Signature, an HMAC-SHA256 of the raw body, when you set a secret. The format differs by webhook:
  • The webhook on Integrations → Notifications and a knowledge base’s webhooks send the plain hex, with no prefix.
  • Workspace webhooks created through the API (/api/v1/workspaces/:id/webhooks) send sha256=<hex>.

​
Network

  • The crawler never fetches cloud metadata addresses.
  • A Bring Your Own Model address must use https and a public address.
  • If your site is behind a firewall, allow the crawler’s IP address shown under Settings → IP Whitelist.

​
Enterprise

The Enterprise plan adds OIDC and SAML SSO, a widget without Kelu branding, and a custom SLA. A metered plan gets the same. See Billing & Plans.