Security overview

#1Where your data lives

Everything vitrinka stores — databases, uploads, screenshots, recordings, backups, error reports, analytics — lives in the European Union: Hetzner data centres in Germany and Finland, and AWS's Frankfurt region for outbound email. No US cloud holds your stored content.

The scoped exception is AI processing you trigger: when your workspace runs an AI action, the request content goes to the model provider behind it — eve's providers on credits, or whichever provider you connected — for the duration of the call, as the privacy policy and the sub-processor register disclose. Your workspace content does not otherwise leave the EU; the services that do involve non-EU processing — payment handling, and the optional push, Telegram and GitHub integrations — are listed on the register with the safeguard covering each. Of those, two optional surfaces carry fragments of content: notification payloads (a title, a short body that can quote the item it notifies you about, and a link), and the GitHub integration when you file an issue from a board — the issue's title and text are derived from your annotation.

#2Tenant isolation

• Each workspace is its own SQLite database file and its own object-storage key prefix. Isolation is physical, not a WHERE clause — a query cannot cross tenants because there is no shared table to cross.
• A workspace token is rejected outside the workspace it was minted for, and a connected-app token reaches only the workspaces of its organisation that the granting user belongs to; user tokens are re-scoped per workspace and capped at the member role.
• Share links are served from a separate host (share.vitrinka.ai) that never accepts sessions or API tokens.

#3Encryption

• In transit: TLS everywhere, HSTS on the production hosts.
• At rest, per workspace: every workspace has its own AES-256-GCM data-encryption key. Files and the most sensitive database content (recorded-session events, annotation text, project memory, documents, frozen share snapshots) are encrypted with it before they reach disk or object storage — the storage provider only ever holds ciphertext, including the local read-through cache. Workspace keys are stored only in wrapped (encrypted) form under a separate key-encryption key, which can be rotated.
• At rest, below the application: the production data volume sits on LUKS2 full-disk encryption whose unlock is bound to our private network — a stolen disk cannot be opened outside it.
• Secrets: passwords are argon2id hashes; passkeys are public credentials; API tokens, connector tokens, session cookies and share-link secrets are stored as SHA-256 hashes; AI provider keys and share-link secrets are encrypted under a master key held only by the server process, bound to the record they belong to.
• This is verified, not aspirational: after the 2026 encryption migration we ran a fleet-wide verification across every stored object and row — zero unsealed items.

#4Deletion is cryptographic

Deleting a workspace destroys its data-encryption key and writes a tombstone that blocks a replacement key from being minted. From that moment everything sealed under it — live storage, caches, and every backup taken after the deletion — is unreadable at once; no key material survives to recover it. Backups taken before the deletion still carry the workspace's wrapped key until they rotate out (seven days of database snapshots), which is when the deletion is complete.

#5Identity and access

• Sign-in by password, passkey, GitHub, or enterprise SSO (OIDC). Organisations can force SSO for their members; per-connection, they can additionally require MFA, verified against the identity provider's authentication claims rather than taken on faith.
• Break-glass access for locked-out SSO organisations is passkey-first and always audited.
• Session lifetime and idle timeout are enforced server-side and configurable for enterprise deployments.
• Sign-in, sign-up, verification, reset, passkey and connector-authorisation attempts are rate limited; failed and denied attempts are logged.
• Production access is limited to the people who operate the service. We do not read workspace content as a matter of routine, and the per-workspace encryption means casual access to stored files yields ciphertext.

#6Agents and connected apps

• AI assistants connect through OAuth 2.1 with mandatory PKCE — public clients only, no client secrets to leak.
• Grants are scoped (read, or read + write), bound to one app and one user, and reach the workspaces of one organisation that user belongs to — the workspace picked at consent is the default — never with more than the user's own role; they are enforced on every call at three independent layers.
• Access tokens live one hour. Refresh tokens rotate on every use; a rotated token presented twice is treated as theft and the whole connection is revoked automatically. A grant is also revoked the moment the granting user's membership lapses.
• Users and workspace admins each have a live list of connections with one-click revocation.

#7Application security

• User-supplied HTML artifacts are served in a sandboxed browsing context under a restrictive content security policy, with an opaque origin.
• Security headers ship on every response: nosniff, referrer policy, permissions policy, frame-ancestors, and HSTS on every https host.
• Server-side fetches of user-influenced URLs run through an SSRF-guarded client that blocks private ranges and cloud metadata endpoints.
• The journey recorder redacts by default — authentication headers and known-sensitive fields are scrubbed in the browser and again on the server at ingest, so a modified client cannot bypass the policy. Field-level scrubbing covers JSON, form-encoded and multipart bodies; other body types get pattern-based scrubbing.
• Image and document decoding is limit-guarded against decompression bombs.

#8Audit trail

Security-relevant events — connector consents, revocations, denied attempts, break-glass use, key destruction — are recorded with timestamp, actor, IP address and user agent in an append-only log: database triggers reject any update or delete of an entry, and each entry commits in the same transaction as the action it records. The trail is kept for the life of the organisation.

#9Backups and recovery

• Continuous replication of the control and tenant databases to a separate object-storage location, with seven days of consistent snapshots. The replica is shipped over TLS to a bucket only the host can address, and the sealed content inside it — recorded-session events, annotation text, project memory, documents — stays ciphertext under the workspace keys.
• Independently, daily snapshots seal every database into one archive encrypted end-to-end under the same key hierarchy — that archive is ciphertext wherever it is stored, and restoring it only ever unpacks into an empty directory, never over live data.
• Blobs are ciphertext at rest and live in object storage, which is their durable copy; the database backups deliberately exclude them.

#10Incidents and disclosure

If we suffer a personal-data breach we notify the supervisory authority within 72 hours of becoming aware of it where GDPR requires it, and we inform affected workspace owners without undue delay, with what we know and what we are doing.

Found a vulnerability? Write to security@vitrinka.ai. We answer fast, we do not take legal action against good-faith research, and we credit reporters who want it. Please do not test against other tenants' data — ask and we will give you a workspace to attack.

#11What we do not have (yet)

• No SOC 2 or ISO 27001 certificate. We are a small team; the controls above are real and verifiable, but nobody has audited them for a badge yet. If your procurement needs the paperwork walked through, ask — we fill in security questionnaires quickly and honestly.
• Single-region operation. Production runs in one EU data centre with offsite backups, not multi-region failover. An SLA, where agreed, reflects that honestly.
• On the hosted service, the audit trail is append-only but not yet exportable to your SIEM. Self-hosted deployments can export it as signed, hash-chained batches to write-once storage; ask if hosted export gates you.

This section shrinks over time. The date at the top tells you which version you are reading.