Krites

Privacy Policy

Last updated 21 September 2026

This describes what Krites does with your data during the unbilled pilot. It is not a DPA. It states what the system actually implements, and claims no certification we do not hold.

What this service does

Krites routes AI requests from your organization to third-party model providers, applies the policies your administrators configure, and reports what was spent.

Operating it necessarily means your prompts are transmitted to the model provider selected for each request. That is the product, and it is the most important thing to understand about it.

This page describes the unbilled pilot. It is not a data processing agreement, Standard Contractual Clauses, or a CCPA/GDPR controller–processor allocation. Those instruments have not been published and must come from counsel.

Model providers process your prompts

When someone in your organization sends a request, the prompt and the resulting response are transmitted to the provider chosen for that request. OpenRouter is the active routing path; it forwards each request to an underlying provider it selects, which currently may include DeepSeek among others. Direct Anthropic access is not part of the current pilot (it is enabled only when an Anthropic API key is configured for the deployment).

On every OpenRouter request we send provider.data_collection: "deny", which excludes endpoints that train on or retain your content. Where your enterprise enables Zero Data Retention, requests additionally carry zdr: true and fail closed if no compliant endpoint is available — the request is refused rather than routed somewhere non-compliant.

We enforce these settings server-side. A client cannot weaken them: a privacy block supplied in a request body is overwritten, never honoured.

We do not control, and do not claim to control, a provider's internal handling beyond the contractual and request-level settings described here.

Web search sends a query to Tavily

When external-data tools / web search are enabled for the enterprise and a search runs, a query derived from the user prompt is sent to Tavily (api.tavily.com). Ordinary chat turns that do not search do not send data to Tavily.

Provider Zero Data Retention does not cover Tavily. This is not Krites using prompts to train models. It does mean search text leaves Krites to a third party with its own retention — we do not claim zero retention at Tavily.

The full conversation is not sent; only the search query is. That query can include sensitive wording from the prompt.

What we store

Account and organization data: names, work email addresses, team membership, roles, and budget assignments. When enterprise SSO is configured, a WorkOS subject identifier is stored as an identity link so the same person is recognized on later sign-ins. Directory sync (SCIM) is not enabled. The unbilled pilot does not use a payment processor, so no card or bank details are collected.

Usage and cost metadata for every request: timestamp, model and provider selected, token counts, latency, estimated and actual cost, and the routing decision. These analytics and spend records store only a hash of the prompt, never the readable prompt or response text.

Readable chat content: for the chat surface, your messages, the model's responses, and any files you upload (and their extracted text) are stored in your organization's database so people in that organization can use their chat history. We do not use that content to train models. This readable content is subject to your enterprise retention window — default 365 days.

Audit events for administrative actions. These record what changed and who changed it, never credentials or message content.

Retention and deletion

Each enterprise has a content retention window — 365 days by default; an administrator may set 7, 30, 90 or 365 days, or explicitly choose to keep content indefinitely.

Readable chat content is subject to that window: chat messages and model responses, message embeddings, uploaded-file bytes and extracted text, and content-derived conversation titles (which are reset to a neutral placeholder so a deleted prompt cannot survive in a title).

Deletion of content older than the window runs when retention cleanup is enabled for the deployment. The scheduled sweeper is opt-in — it is not on by default — so this page does not guarantee that a live daily delete job is running.

Retention is scoped per enterprise: one organization's window never affects another's data.

Usage, cost, routing and security-audit metadata are retained beyond that window because they are the record of what was spent, how requests were routed, and what administrators did. Only readable content is in scope for retention cleanup, not these records.

Administrators may request deletion of their organization's data by contacting [email protected]. Deletion requests are honoured for the tenant that makes them.

Security practices we actually implement

Passwords are stored as scrypt hashes with a per-user salt; they are never recoverable, including by us.

Sessions use signed, HTTP-only, SameSite=strict cookies, and every state-changing request requires a matching CSRF token.

Authorization is enforced server-side on every request. Tenant scope is derived from the session, never from a URL, header or request body.

API keys for programmatic access are stored only as SHA-256 hashes, verified in constant time, and can be scoped, expired and revoked.

Traffic is served over HTTPS. Credentials, cookies and authorization headers are redacted before anything is logged.

We do not hold SOC 2, ISO 27001, HIPAA, PCI-DSS, or any other certification, and we do not claim to.

Contact

Privacy questions: [email protected]. That address is an operational mailbox until counsel names an official notice contact.

Security reports: [email protected].