Security

Protect the context, evidence, decisions, and approvals behind every execution-ready deliverable.

Posture

The commitments that hold from day one.

01. Workspace isolation: Your workspace and its data belong to your account. Protected resources follow explicit ownership boundaries. Database-level row-level security provides an additional authorisation boundary.
02. Your material stays yours: Files and source material are stored as project-owned data. Kryterea separates binary storage from application records and tracks the relationship between uploaded material and its project context.
03. Authentication: Kryterea uses Clerk for identity and authentication. This covers account creation, sign-in, verification, sessions, provider authentication, and recovery. Kryterea then maps the authenticated identity to its own account and ownership model.
04. Access control: Authentication tells us who you are. Authorisation determines what you can access. Kryterea uses authenticated identity, workspace ownership, project ownership, and object ownership as separate boundaries. Client-supplied account identifiers are not treated as authoritative.
05. Auditability: The platform includes auditability as a core concern. The product preserves artefact versions, provenance, evidence, decisions, evaluation, and validation as part of the preparation model.
06. Retention and deletion: You should be able to understand what Kryterea retains. Workspace data, project data, files, and derived records can be managed explicitly rather than treated as an opaque data pool.

How your data is separated.

Your work follows an explicit ownership chain: account, personal workspace, project, conversation, and work. Research, knowledge, evidence, artefacts, decisions, evaluation, and validation remain connected to their project context. Security is not only about protecting a database. It is also about knowing which piece of work belongs to whom.

User uploads follow a controlled path from upload to object storage, metadata, processing, and finally into project knowledge, research, or evidence. Binary files live in Cloudflare R2 rather than inside PostgreSQL. Processing runs through background infrastructure rather than being mixed into the primary application transaction.

Context should be deliberate.

Knowledge does not automatically become persistent simply because it appeared in a conversation. The workspace design explicitly distinguishes project knowledge from working context and requires an explicit action for material to become persistent project knowledge.

Your AI workspace should know what it is allowed to use, why it is available, and where that material belongs.

The architecture defined today.

These are the technologies and boundaries defined in the current platform architecture. They are product and architecture decisions, not claims about certifications we do not yet have.

Security is not a page we publish after the product is built. It is part of how the product is built.

Sample runEvidence trail

Current platform boundaries:

AuthenticationClerk (identity, sessions, provider auth, recovery).
Application authorisationKryterea ownership model (account, workspace, project, object).
Database securityPostgreSQL with row-level security (Neon).
File storageCloudflare R2 (binary objects separated from application data).
Background processingCloudflare Queues.
Durable workflowsCloudflare Workflows.
Typed application boundariesKysely and Zod.

What is not true yet

No external certification has been completed.

No external security certification has been completed. No external audit has been completed. We will not imply otherwise.

As Kryterea completes formal security reviews, this page will be updated with the specific audit, its scope, and its date. Trust should be earned before it is advertised.

Ask the hard questions early.

Have a security requirement we have not addressed? We would rather answer the difficult question now than make a broad promise later.

Questions welcome any time.

What we can state today.