Trust Center

Isolation between organizations (multi-tenancy)

Every data request is filtered by org_id at the SQL query level. Any cross-tenant leak found during internal audits was fixed together with a reproducible regression test that permanently closes that exact class of bug. For the evaluations table, Row-Level Security is additionally enabled at the database level (PostgreSQL RLS) — a second isolation layer independent of the application code: even a bug in an application SQL query would not bypass this barrier, provided the connection uses an unprivileged database role.

Role-based access control (RBAC)

Three access levels for team leads: tl, senior_tl, admin. A regular tl can additionally be restricted to specific teams/groups (seeing only their own groups' data, not the whole organization) — this restriction is actually enforced on every analytics query, not just as a UI filter. Editing evaluation prompts and managing knowledge-base sources (upload/delete/sync) is available only to the senior_tl/admin roles — not to any team lead.

Platform provider's access to client data

The provider's internal admin panel (for operational support and billing) is separate from the regular client login, protected by its own secret with rate-limited login attempts and a constant-time check (protection against timing attacks).

SSO / SAML

SAML SSO with mandatory prior user invitation — no auto-provisioning by the IdP, so a new account can't be created bypassing the org administrator's control. Built on a standard, widely used library (the cryptographic verification of the SAML response signature is performed by the library itself, not custom code). To be candid: before first use with a specific client IdP (Okta/Azure AD/Google Workspace) we run a joint test cycle — the integration has not been independently pre-tested against every possible IdP.

SCIM (automatic user management via Okta/Azure AD)

SCIM 2.0 provisioning for the user lifecycle — the IdP creates an account when the app is assigned to an employee and deactivates it when they leave or the assignment is removed, with no manual work in /settings. A separate Bearer token (not the same as the API key), generated and controlled by the org administrator. A new account created via SCIM always gets the least-privileged role — the administrator promotes it manually if needed. The scope is deliberately medium, not a full SCIM stack: the Users resource is supported (create/read/update/deactivate), without groups or bulk operations, which real IdPs don't require for basic provisioning anyway. Honestly: as with SAML, before first use with a specific client IdP we run a joint test cycle.

Encryption of sensitive data in the database

API keys and other secrets (helpdesk and AI-provider credentials) are stored in the database encrypted, not in plain text. In production mode, the application deliberately refuses to start if the encryption key is not configured — not a silent fallback to plain text, but a guaranteed stop.

Masking of personal and payment data before AI processing

The text of a customer ticket is checked for card numbers (using the Luhn checksum — filters out random numbers, keeps structured card numbers), CVV, phone numbers, passwords, and access tokens — and is masked BEFORE the text is sent to the AI provider (OpenAI/Anthropic/Gemini) for evaluation, draft-reply generation, or an automatic knowledge-base article.

Retention policy for conversation text

A self-serve toggle in settings: automatic purging of conversation text (not the evaluation itself — the score, criteria, and quality trends remain for long-term analytics) after a configured period. Disabled by default for every organization (requires explicit opt-in). The period cannot be shorter than the separately configured minimum retention period for the EU AI Act decision record — the system does not allow saving a configuration that would violate this requirement.

Automated backups

Daily database backup to S3-compatible storage with 14-day rotation. Once a month, an automated check confirms that the latest backup is actually restorable (not just that the file exists).

Choice of data storage region (data residency)

Supported for enterprise clients by agreement during onboarding (currently an operational process, not a self-serve toggle in the interface).

Audit log with SIEM export

All team-lead actions are logged with the specific user, time, and IP address attached. Programmatic export for integration with Splunk, Datadog, and similar systems is available via the API.

Protection against automated brute-forcing (rate limiting)

A baseline limit applies to every request at the application level, with separate, stricter limits on sensitive routes (login, registration, webhooks) — previously this protection covered only a few entry points, now it covers the entire application surface.

Content Security Policy and other security headers

CSP, X-Frame-Options (prevents embedding in an iframe), HSTS (enforces HTTPS), and X-Content-Type-Options are applied to every response.

CSRF protection (cross-site request forgery)

Enabled globally for all forms and state-changing requests, with a narrow, documented list of exceptions where authentication is already provided another way (externally signed system webhooks, IdP SAML callbacks).

Validation of uploaded files

Knowledge-base uploads are checked not only by file extension (which is easy to fake by renaming) but also by the actual content of the file's first bytes.

Protection against prompt injection

Ticket text is checked for attempts to manipulate the AI model's instructions (e.g., “ignore previous instructions”). Detected cases are not silently blocked — they are flagged for mandatory human (team lead) review instead of automatically accepting the evaluation result.

Traceability for the EU AI Act (Article 12/13)

A dedicated AI decision traceability dashboard — details of every AI evaluation, the prompt version, the model provider. Evaluating employee performance falls under the high-risk category in Annex III of the EU AI Act (“employment, workers management”) — this traceability isn't cosmetic, it's direct preparation for requirements that take effect in stages: transparency from August 2, 2026, full obligations for certain high-risk systems from December 2, 2027 (postponed by the “AI Omnibus”, May 2026).

Human oversight of AI actions (Article 14)

No AI action that changes data or affects people (coaching-session suggestions, AI copilot actions) is executed automatically — it is only proposed, and the actual record is made only after explicit confirmation by a team lead. The same principle applies to autonomous triggers and to the interactive copilot — no exceptions.

AI assistant with a limited set of actions

The built-in AI copilot operates through a fixed list of permitted operations. Read-only actions execute immediately; actions that change data are only proposed (see the human-oversight item above). No arbitrary code execution or SQL query access outside this list.

Does your own AI agent need to disclose itself to customers (Article 50)?

From August 2, 2026, the EU AI Act requires that AI communicating directly with people disclose that fact. This concerns YOUR AI agent (bot) if it replies to customers directly — not our platform itself (we only evaluate quality, we don't talk to your customers). If the “AI agent vs. human agents” comparison on the dashboard shows an active bot, check whether it clearly discloses that it is AI.

SOC 2 Type I

Planned. Not yet certified.

Regular dependency scanning for known vulnerabilities

The application's main dependencies are regularly scanned by an automated scanner for known CVEs. Discovered vulnerabilities are fixed by a version update once a compatible patch is available.

ML dependencies (knowledge-base processing)

Two dependencies used for knowledge base indexing had known CVEs. One (transformers, 4 CVEs) has been updated and fully resolved — verified with a clean pip-audit and real regression testing. The other (chromadb, 1 CVE) remains open: no vendor patch has been released yet, and the vulnerability only applies to ChromaDB's HTTP server with untrusted model code loading enabled — our configuration exclusively uses the embedded (in-process) mode with no HTTP server, and only a fixed, predefined model, so the vulnerable scenario does not apply here.

Horizontal scaling

The application's architecture supports running multiple replicas of the main service simultaneously behind a load balancer.