Security at Peach Pilot

Every connection is served over HTTPS with strict transport security, and all data is encrypted at rest with AES-256 — including automated backups. Database connections travel over TLS inside Google’s private network.

The most sensitive fields get a second, stronger layer. A client’s SSN, bank account, and routing number are individually encrypted with Google Cloud KMS before they ever reach the database:

• Encryption keys never materialize inside the application — every encrypt and decrypt is a discrete, audited call to the key service.
• No human has standing access to decrypt stored values. Exactly one identity — the application’s own runtime — can use the production key.
• Each encrypted value is cryptographically bound to the exact record and field it belongs to, so ciphertext can’t be replayed somewhere else.
• Fail-closed by design: if the key service is unavailable, nothing is written and nothing is returned. The system never silently degrades to weaker encryption.
• Keys rotate automatically, and older data stays decryptable across rotations.

Access is deny-by-default. A valid sign-in isn’t enough on its own — every user must also be explicitly provisioned with an active role.

• Sign-in is single sign-on only (OpenID Connect). There are no application passwords to phish, and no self-service signup.
• Roles are additive and database-enforced, checked both at the network edge and on every API route — failing closed to the login page.
• Revealing a stored banking value requires a discrete permission plus ownership of the record, and every reveal — and every denied attempt — is audited.
• Sessions are opaque tokens with hard and idle timeouts. Revoking a role invalidates every existing session on the next request.

Agents never handle raw banking details. The client receives a single-use, time-limited secure link by text and types their own information into a locked-down page on their own phone.

• Links expire on their own and are dead after one use; an expired link shows a neutral page that reveals nothing.
• The submission endpoint is rate-limited on multiple independent dimensions and responds identically whether a link is valid, invalid, or already used — there is no signal to probe.
• Every field is strictly validated — unexpected input is rejected, and banking numbers are checksum-verified before anything is stored.

The application stores only what it needs to produce a quote and originate a policy.

• Only the last four digits of SSN and account numbers are ever kept in cleartext, for display. The full values exist only as encrypted ciphertext.
• A scheduled purge permanently removes the sensitive values once their retention window passes — keeping the masked digits and the consent trail.
• ACH payment consent is captured as an immutable, append-only record: the exact disclosure text shown, when, and from where. It can’t be edited or deleted, meeting NACHA’s retention expectations.

A tamper-evident audit log records security-relevant events — sign-ins and failures, permission changes, admin actions, and every reveal of sensitive data — with who, what, and when.

• The audit log never contains client PII. A reveal event records the field name — never the value.
• Access decisions fail closed independently of logging — a logging failure can never grant access.
• Product analytics run fully masked: all inputs and text are hidden in session replays, and the sensitive screens aren’t captured at all. Server-side error reports carry route context only — never request bodies.
• Production is monitored with TLS-validated uptime checks and certificate-expiry alerting.

Right Quote runs on Google Kubernetes Engine in Google Cloud, with production designed around isolation and least privilege.

• The database has no public IP address — it is reachable only from inside the private network.
• Development and production are fully separate cloud projects with separate databases, secrets, and encryption keys. Development never touches production data.
• Workloads authenticate with short-lived cloud identities — there are no static credentials or database passwords baked into images. Secrets never live in source control, and CI scans to enforce it.
• Deploys are GitOps-only: production changes ship as reviewed, gated releases — nothing auto-deploys, and operators don’t run manual commands against production.
• Production runs multiple replicas across failure domains, so a node disruption doesn’t take the service down.

Every change runs through continuous integration: type checks, a 1,300+ case automated test suite, and guardrail checks that verify the security posture itself — headers, link expiry, rate limiting, purge behavior, and production safety gates.

• Database migrations are forward-only, tracked, and never edited once applied.
• Demo and QA code paths are hard-gated off in production by an environment check and a boot-time assertion that refuses to start if misconfigured.
• QA data tooling refuses to run against production, fail-closed.

• Automated daily database backups, with point-in-time recovery measured in seconds of data.
• Deletion protection on the production database.
• Documented, versioned runbooks for rollback, disaster recovery, and monitoring response — kept current with the deployment model.

Third-party services in the production data path, and exactly what each touches:

Development-only tooling never touches customer data.