1. Home
  2. Security

Security architecture

We hold your sessions. That is a serious thing to ask.

A session vault is a high‑value target by definition. This page explains exactly what we store, what we never store, and which parts you control. If anything here is unclear, that is a bug in this page. Tell us.

Passwords stored: never Encryption: per‑tenant keys Master key: your cloud
The core promise

Your password is never written down.

During capture, you type your password into the site’s own login page, in a browser, over the site’s own TLS. It travels from your keyboard to the site. It does not pass through our storage layer, and there is no code path that persists it.

What we keep is the result: the session the site issued after it was satisfied. That is a meaningful difference. A session can be revoked, scoped and expired. A password cannot.

If our database were copied in full, an attacker would get sealed ciphertext and no way to use it. The keys live in your cloud, not alongside the data.

Envelope encryption, bounded by your cloud Your cloud — Secret Manager / KMS (never inside the app) Master key wraps the per-tenant DEK DEK encrypts the session Session cookies + localStorage per origin
Each record is also bound to its tenant and session id (AAD), so ciphertext cannot be replayed in another tenant’s context.

What we hold

Sealed ciphertext: the session cookies and localStorage the site handed back, encrypted under your tenant key. Revocable, scoped, and built to expire.

What we never hold

Your password. It exists for a single moment, in your hands, during capture, and is never written to disk, never stored, never persisted.

Cryptography

Envelope encryption, one key per tenant

Two layers, so that key rotation does not mean re‑encrypting the world, and a compromise of one tenant does not touch another.

  1. Per‑tenant data encryption key

    Every tenant is provisioned with its own DEK. Session material (cookies including HttpOnly, and localStorage for every origin we can reach) is encrypted under that key before it is written.

  2. Master key held outside the application

    The DEK is itself wrapped by a master key that lives in your cloud secret manager or KMS. On Google Cloud that is Secret Manager; the value is fetched at boot and held in memory. It is never written to instance metadata, never baked into an image, and never committed.

  3. Authenticated additional data

    Each ciphertext is bound to its tenant and session identifier. Move a record from one tenant to another and decryption fails rather than silently succeeding, which closes a whole class of confused‑deputy bug.

  4. Rotation re‑seals, it does not invalidate

    Rotating a tenant key generates a new DEK, re‑seals every session under it, and leaves the tenant’s API key working. Rotation is an operation you can run on a Tuesday afternoon without a migration window.

Isolation

Every run gets a clean room

A run never inherits state from the previous one. Each execution creates a fresh browser context (no cookies, no storage, no history) and the session is injected immediately before the first navigation. When the run finishes, the context is destroyed.

Two runs using the same session run in separate contexts and cannot see each other. Two tenants are isolated at the encryption layer, so there is no shared key that could decrypt both.

What is recorded

Every privileged action writes an audit entry: what happened, to which object, by which actor. The log covers tenant provisioning, session capture, revocation, key rotation and every run. It is queryable through the API and visible in the console.

Revocation

A session can be revoked at any time from the console or the API. Revocation is immediate: subsequent runs refuse to start, and the sealed material is no longer available for injection.

One session, three clean rooms — none can see the others Sealed session Run 1 fresh context Run 2 fresh context Run 3 fresh context
Every run builds its own browser context with no cookies, no storage and no history. Parallel runs on the same session cannot contaminate each other.
Honest limitations

What we are not claiming

Overstating security posture is how trust gets lost later. Current status:

  • Not yet certified. We are not SOC 2 or ISO 27001 certified. We will say so plainly until we are.
  • Depend on your cloud for key custody. The strength of the master‑key boundary is the strength of your KMS configuration and IAM policy.
  • Sessions inherit the site’s own limits. If a portal grants a 30‑minute session, that is the ceiling; we detect expiry rather than prevent it.
  • Capture is a human moment. The integrity of a session depends on the person who captured it and the machine they captured it on.

Found a vulnerability? Write to security@prelogin.click. We will acknowledge within two business days and will not pursue you for a good‑faith report.

Want the architecture review before you commit?

We’ll walk your security team through the key model and the deployment topology.

Request a review