Skip to content
Linx Narrativ Login

Legal & trust

  • Terms
  • Privacy
  • Security
  • Subprocessors

Security

How Narrativ protects customer data

Narrativ is a single application with a single database. It does not use passwords and stores a limited amount of personal data.

Hosting

Narrativ runs on Fly.io in Amsterdam, the Netherlands (EU/EEA), alongside its managed PostgreSQL database. All traffic is served over HTTPS. Database connections require TLS, and storage volumes are encrypted at rest.

Data storage

All records are stored in a single PostgreSQL database. Narrativ uses no data warehouse, no analytics store, and no copies of data in other services.

Authentication

Narrativ does not use passwords. Sign-in uses one-time email links that expire and can be used once. The server stores only a cryptographic hash of each link, so a database leak cannot be replayed as a login. Sessions are held in signed cookies. Single sign-on (OIDC, including Microsoft Entra and Okta) is planned, and per-company authentication policy is already part of the data model.

Tenant isolation

Each organisation's data is isolated. Every signed-in API route resolves the requesting user's session and checks ownership before returning a record. Interview-token requests are resolved server-side from the token alone, so a request body cannot address another organisation's data. A request for another organisation's data returns the same response as a request for a record that does not exist.

Audit trail

Security-relevant events are written to an internal audit log: sign-ins, administrative access, interview submissions and their origin, and reversals. Project records are not edited in place. Changes create new records that supersede earlier ones, so history is preserved and each fact can be traced to its source.

Reversibility

A processed interview can be reverted in a single database transaction, which removes everything that run wrote.

Single-use tokens for the AI lane

When an interview runs through an AI assistant, the assistant reads context and submits the transcript using single-use tokens. Tokens are stored as hashes, rate-limited, and retired once the transcript is processed. Stored transcripts are scrubbed of credential material before they are written.

Backups

The database is backed up automatically, with frequent incremental backups and periodic full backups, on a rolling retention window of approximately ten days. Restore procedures are tested.

Reporting a vulnerability

To report a security issue in Narrativ, contact our CTO at matias@linx.pm.

Version 0.3. Last updated 17 August 2026. This document will be updated as Narrativ develops. Questions: simon@linx.pm

Linx

Oslo, Norway
  • Home
  • Login