13. Security & Privacy
Klariton is a multi-tenant AI product. Security depends on strict organization scoping, controlled publishing, safe public delivery, and careful handling of personal data before AI providers are called.
This chapter describes the product controls visible to customers. It is not a replacement for a legal Data Processing Agreement or security addendum.
Core Security Principles
Section titled “Core Security Principles”| Principle | How Klariton applies it |
|---|---|
| Organization isolation | Studio routes and APIs are scoped to the active organization. |
| Least privilege | Users have organization roles, and critical actions require elevated roles. |
| Published-only public data | Public delivery serves live touchpoint content, not drafts or rejected BIQs. |
| Source-grounded AI | BIQs carry confidence and source state. Unsupported answers can be blocked or warned. |
| Explicit chat activation | Chat Advisor activation is gated through the Trust Center. |
| Reviewable safety checks | SafeGuard and Test Center flag issues before or after go-live. |
Roles And Access
Section titled “Roles And Access”Klariton uses organization membership. A user can belong to multiple organizations, and the active organization determines which data is visible.
Typical roles:
| Role | Typical rights |
|---|---|
| Owner | Full organization control, billing, team management, and critical settings. |
| Admin | Operational administration and publishing, without all owner-only controls. |
| Member | Content work such as materials, BIQs, personas, and touchpoints. |
Best practice: Keep owner access limited. Use admin/member roles for day-to-day work.
Public Delivery
Section titled “Public Delivery”Public touchpoint delivery is intentionally narrower than Studio access:
- only live touchpoints are served,
- draft and rejected BIQs are not public,
- widget delivery uses organization slug and touchpoint slug,
- staging and production origins are controlled in organization settings,
- API keys for custom integrations must stay server-side.
If a touchpoint does not render, check the production domain, staging allowlist, and the generated embed snippet before changing content.
Personal Data And AI Calls
Section titled “Personal Data And AI Calls”Klariton includes a pseudonymization gateway for AI calls. It detects and replaces common personal-data patterns before sending prompts to external AI providers.
Examples include:
- email addresses,
- German phone-number patterns,
- names with title or salutation,
- addresses in common postal-code formats,
- German IBAN patterns,
- credit-card-like numbers in end-customer question paths.
Important limitation: This is heuristic protection, not a guarantee that every possible personal-data string is detected. Avoid uploading highly sensitive raw customer records unless they are necessary for the answer workflow.
Data Minimization
Section titled “Data Minimization”For end-customer questions and AI work, Klariton should prefer redacted or pseudonymized text for storage and embeddings. Operational logs should capture the type of sensitive field where possible rather than storing unnecessary cleartext.
Assumption: Exact retention periods and subprocessors depend on the production environment and customer agreement. Use the signed DPA and in-app settings as the legal source of truth.
Trust Center
Section titled “Trust Center”The Trust Center is the go-live gate for Chat Advisor. It requires:
- each mandatory notice to be confirmed individually,
- at least five preview self-test questions,
- explicit self-test confirmation,
- activation only when the gate passes,
- an acknowledgement history with user, timestamp, IP address, notice key, and notice version.
See Trust Center.
SafeGuard
Section titled “SafeGuard”SafeGuard checks published BIQs against material and Brand Voice rules. It does not silently rewrite content. It flags findings and lets owners/admins decide whether to re-review, mark false positive, or apply a corrected rewrite.
See SafeGuard.
Test Center
Section titled “Test Center”Test Center runs the real chat through typical questions, edge cases, and security attack patterns. It checks for grounded answers, fitting products, and no internal leakage.
See Test Center.
API Keys And Secrets
Section titled “API Keys And Secrets”API keys are managed under Settings -> API keys and are intended for server-side or build-time use. Do not place them in browser JavaScript.
Public read API keys currently use the read_published scope. If a key is no longer needed, revoke it and issue a new one.
Operational secrets such as worker secrets, AI provider credentials, Clerk keys, database URLs, and webhook secrets belong in the deployment environment, not in the repository or public docs.
Customer Checklist
Section titled “Customer Checklist”- Accept the DPA before production use.
- Restrict owners and admins.
- Configure production and staging domains.
- Keep API keys server-side.
- Review unsupported BIQs before publishing.
- Activate Chat Advisor only after Trust Center self-test.
- Run Test Center before go-live and after major material changes.
- Review SafeGuard findings regularly.