Security
The controls below are what we run today. Where something is on the roadmap rather than shipped, we say so. We don't claim certifications we don't hold.
Last updated: 2026-06-23.
All traffic to the API and dashboard is served over TLS. Data at rest — your datasets, run artifacts, and labels — is encrypted by the underlying storage layer.
Every dataset, run, and label is owned by a tenant and scoped by tenant on read. The two cookie-auth surfaces (customer dashboard and operator admin) use separate cookie names and signing salts on purpose — logging into one does not grant the other. The customer API is a third, independent surface authenticated by bearer token.
API keys are gn_live_-prefixed and stored hashed; lookups
use a constant-time compare. A bad or revoked key returns an
indistinguishable 401 so a probing attacker cannot tell which it is.
We never log keys or password hashes.
X-Content-Type-Options, X-Frame-Options:
DENY, and a referrer policy on every response.Security here is not only about keeping data out — it's about being able to prove a result. Every governed run seals and hashes its estimand, metric, gold snapshot, and model pins, and emits a reproducibility manifest. You can confirm a certified number was computed against the locked plan and recompute it yourself. The system is designed to decline to certify when the data can't support a trustworthy number rather than overclaim.
Today the service is hosted, with the isolation and deletion controls above; see data residency for specifics. A VPC / on-prem deployment — where you hold the data and the gold and we provide the estimator, so safety- or fraud-sensitive data never leaves your environment — is on the roadmap. Until it ships, residency is procedural (encrypted, isolated, deletable, pre-registered, reproducible), and we will say so plainly to any reviewer who asks.
If you believe you've found a security issue, email kodycoppock@gmail.com. We'll acknowledge and work with you on a fix.