Verica is now open. Start free →

// Trust Center

Security by architecture, not by policy.

How Verica protects your prompts, datasets, and provider keys. This page describes what the platform does today — kept honest and in sync with the code, not with aspirations. Written for the people evaluating us: engineering leads, security reviewers, and procurement.

At a glance

Provider API keys (BYOK)

Protection at rest
Encrypted — AES-256-GCM, with the data key wrapped by RSA-OAEP (3072-bit).
Isolation
Per workspace (RLS)
If the web tier were breached
Keys stay encrypted: the web tier holds only the public key and cannot decrypt them.

Prompts & datasets

Protection at rest
Stored as database data, protected by tenant isolation.
Isolation
Per workspace (RLS), enforced in the database
If the web tier were breached
Readable only within the breached session's own workspace.

Production traces (observability)

Protection at rest
Content encrypted — the same AES-256-GCM + RSA-OAEP envelope as credentials, with PII redacted before sealing.
Isolation
Per workspace (RLS)
If the web tier were breached
Content stays encrypted: the web tier can seal trace content but cannot open it.

Secrets & connection strings

Protection at rest
Server-side environment variables only.
Isolation
Per service (web vs. worker)
If the web tier were breached
Never shipped to the browser; the decryption key is not even present in the web service.

The internet-facing application physically cannot read your model provider keys. That property is enforced by the architecture — not by policy.

01Credential protection (BYOK)

When you add an OpenAI, Anthropic, Google, or OpenAI-compatible API key, it is sealed with envelope encryption before it ever touches the database: a fresh 256-bit data key encrypts your key with AES-256-GCM, and that data key is then wrapped with RSA-OAEP (SHA-256, 3072-bit) using a public key.

The RSA keypair is deliberately split across services — that split is the important part:

internet-facing Web app public key only

Can seal new credentials, but has no way to open them.

database Postgres ciphertext only

Stores the ciphertext, the nonce and auth tag, the wrapped data key, and a display fingerprint (sk-…AB12).

no inbound traffic Worker private key

Decrypts a credential only at the moment it makes a provider call.

  • Your plaintext key is never stored and never logged; only a non-sensitive fingerprint is shown in the UI.
  • The production web service refuses to boot if the private key is ever found in its environment.
  • Provider error messages are scrubbed of key-shaped strings before they are persisted.

02 Tenant isolation

Verica is multi-tenant, and isolation is enforced at the database layer — not just in application code:

  • Every tenant table has PostgreSQL Row-Level Security with FORCE ROW LEVEL SECURITY, keyed on the current workspace. A query with no workspace context sees zero rows and writes are rejected — it fails closed.
  • The application connects as a non-superuser role that cannot bypass RLS. Schema migrations use a separate, higher-privilege role the application never uses at runtime.
  • On top of RLS, every data-access path is also scoped to the caller's workspace in code, and background jobs carry and enforce their workspace identity — defense in depth.

03 Your data and your models

  • What we store: your prompts, datasets (golden sets), evaluation results, the production traces you choose to send (content redacted and encrypted — see below), and the encrypted provider credentials you choose to add.
  • Where model calls go: to your provider, using your key. Verica is the orchestration layer — we never proxy your traffic through a shared key.
  • Your prompts and outputs are never used to train any model.
  • In transit: traffic to the app and calls to model providers travel over HTTPS/TLS.

04 Production traces (observability)

If you send production traces (via the SDKs, OTLP, the proxy, or n8n), the sensitive content is protected end to end:

  • The trace receiver authenticates with ingest-scoped API tokens, stored only as a SHA-256 hash — never the secret. The raw payload is sealed with the public key before it is queued: it never sits in the queue in cleartext.
  • The worker redacts PII (emails, phone numbers, credit-card numbers) before anything is persisted; content is never stored un-redacted.
  • The input, output, and span cells are encrypted with the same asymmetric envelope as credentials: the web tier can seal them but cannot open them. To display a trace, the UI asks the worker over an internal channel — the private key never reaches the internet-facing service.
  • Only operational metadata stays in cleartext (model, provider, tokens, cost, latency, tags), plus short pre-redacted previews that power lists and search without decrypting anything.
  • Retention is enforced automatically: a scheduled sweep purges trace bodies and run outputs older than your plan's retention window; pinned traces are exempt.

05 Authentication & access

  • Sign-in is email one-time-code (OTP) — there are no passwords to phish, reuse, or leak. Sessions are signed server-side.
  • Each user belongs to a workspace via an explicit membership with a role (admin / editor / viewer); role and workspace are resolved on every request.
  • All secrets live as server-side environment variables; the only value exposed to the browser is the app's public URL. Each service validates its environment at boot and fails fast on misconfiguration — including a guard that worker-only secrets must never appear in the web tier.

06 Subprocessors

These are the vendors that process data on behalf of Verica today. We update this list when we add or change a vendor.

  • Railway (US) — cloud hosting and managed infrastructure, including the database and this website.
  • Cloudflare R2 (US) — storage for dataset images and for off-platform database backups; backups are AES-256 encrypted before upload.
  • Google Analytics (US) — traffic analytics for the verica.app marketing site; not used inside the application.
  • Calendly (US) — demo and session scheduling, only if you choose to book one.
  • Model providers (OpenAI, Anthropic, Google, or other compatible providers) — receive the evaluation inputs and outputs you run, via your own key (BYOK); you choose which ones to connect.

07 Data location, backups & incidents

  • Data is hosted on Railway, a managed cloud platform, in the US West region (California, United States). We do not offer regional data-residency options yet.
  • Backups run in three layers: continuous point-in-time recovery (PITR) on the database, allowing restores to any moment within a window of roughly one month; daily scheduled volume backups on the hosting platform; and a weekly full backup, encrypted with AES-256 before it leaves our infrastructure, stored in independent object storage (Cloudflare R2, United States) and retained for 90 days.
  • The weekly off-platform copy is deliberately independent: it survives an account-level failure of the hosting platform, and its decryption key is held separately from both platforms. Restore drills are exercised quarterly: in the latest (August 2026), a full dump was decrypted, integrity-checked, and restored in seconds at current data volume.
  • Recovery objectives at current scale: near-zero data loss (RPO) via PITR while the platform is available, and at most seven days if only the off-platform copy survives; recovery time (RTO) of hours for a full platform rebuild.
  • If a security incident materially affects your data, we will notify you without undue delay, consistent with applicable law, and share what we know as we investigate.

08 What we don't claim (yet)

We'd rather you learn this here than in a follow-up call:

  • Prompt and dataset contents are not encrypted at the column level (production trace content is — see above). They are protected by tenant isolation and by the at-rest encryption of the managed database and disks — application-level encryption of content with customer-managed keys is on the roadmap, not shipped.
  • At-rest disk and volume encryption is provided by the managed hosting platform; it is not something Verica implements itself.
  • We are not yet SOC 2 or ISO 27001 certified, and we do not run a formal bug-bounty program. We are happy to walk a security reviewer through the architecture directly.

09 Responsible disclosure

If you believe you have found a security issue, email [email protected] with details and steps to reproduce. Please do not file public issues for suspected vulnerabilities, and give us a reasonable window to respond before any disclosure. We will acknowledge your report and keep you updated on the fix.