Security

An account cannot be used until its email address is verified: a one-time code confirms email sign-up, and Google sign-in is accepted only when Google itself reports the address verified. Sessions are signed, HTTP-only cookies issued by our authentication provider behind a same-origin proxy; the app never exposes the signing secret to browser code, and the proxy forwards only the small set of requests it explicitly recognizes.

Every application table enforces row-level security that is both enabled and forced, so even a bug in application code cannot read or write another workspace’s rows — the database itself refuses it. The database roles the running application connects with hold only the narrow, reviewed privileges each path needs, not blanket table access.

Authorization is derived from your verified server-side session on every request. Cartographer never accepts a workspace, user, or organization identifier from the browser as proof of who you are — the server resolves that itself and checks membership again on every read.

Checkout and the billing portal are Stripe-hosted: card numbers are entered on Stripe’s own page and never reach our servers. The browser can only request a plan by its internal key — every Stripe and tenant identifier is derived and validated server-side.

Billing data is written through a separate, isolated database role that has no access to your measurement data, and access is granted only after a signed, verified payment event — completing Checkout by itself never grants access.

Every inbound webhook — Stripe billing events, Resend email events, and our authentication provider’s account events — is verified against its raw request body and signing secret before we trust anything in it. An unsigned or mismatched request is rejected before it touches application state.

A retained observation is a normalized record: a bounded excerpt of the answer, the source URLs it cited, the exact measured surface, a timestamp, and a hash reference to the underlying provider artifact. That hash is a cryptographic fingerprint of the reply — enough to re-check that a claimed result matches what was recorded, not a blockchain and not an independent verification of the answer itself. We store the normalized record and its hash, not the raw provider response.

This is not a compliance certification and we do not claim one. It describes the current implementation, which is still evolving, in plain terms rather than as an exhaustive audit.

If you believe you have found a vulnerability, email support@cartographer.tools and we will confirm receipt. Please give us a reasonable chance to fix an issue before disclosing it publicly, and do not access, alter, or retain data belonging to anyone else while investigating.