Flagship case · AI Product Risk & Safety

Redis P0 Before First Users

A pre-launch safety audit found a P0 token exposure in Redis before the product had its first users.

Disclosure

This is my own product. The case covers product-safety engineering; it makes no claim about clinical outcomes, certification, or client consulting work.

One-sentence outcome

Before first users, the safety audit found and removed a P0 Redis token exposure that would have turned read access to Redis into read access to active user conversations.

Context and stakes

The product handled highly sensitive therapy-style conversations, so a security flaw was not a generic backend nuisance; it would have crossed directly into user trust and public-safety risk.

Baseline and constraints

Row Level Security still worked correctly, which made the flaw harder to notice at a glance. The vulnerable move was ordinary engineering plumbing: storing Supabase bearer tokens next to long-lived session state for convenience.

Exact role

Founding AI Product Architect and owner of the product, responsible for the pre-launch audit, exploit reproduction, remediation design, and the deterministic gate that prevented the issue from returning.

Trigger to measured change

Trigger
A planned pre-launch security pass treated Redis contents as first-class evidence instead of assuming integration tests represented safety.
Constraint
The product needed reconnect-friendly long sessions without turning persistence convenience into credential persistence.
Decision
Reproduce the exploit, remove plaintext bearer tokens from Redis, keep them only in request or websocket memory, and add a deterministic Redis scan gate to CI.
Measured change
The observed result was a reproduced P0 finding, a concrete remediation, and a build-time check that now fails if token-shaped data returns to Redis.

Before first users, a Redis exposure of plaintext Supabase bearer tokens was reproduced and remediated with a deterministic scan.

This is self-owned product safety evidence only. Please do not imply clinical efficacy, certification, regulated approval, or client consulting proof from this record.

Context: NearbyTo.me product safety audit with sensitive user-conversation data at stake.
Timeframe: Pre-launch security pass recorded in the phase-0 ledger on 2026-09-02.
Baseline: Exploit path: read access to Redis could yield still-valid bearer tokens for active chats.
Role: Founding AI Product Architect and owner of the product, responsible for the pre-launch audit, exploit reproduction, remediation design, and the deterministic gate that prevented the issue from returning.
Source: Review the source record
Provenance: Source post, long-form product article, and master profile.
Confidence: A - first-party reproduction and remediation mechanics are explicit.
Disclosure: Named, self-owned product; no client attribution is implied.

Measured or observable result

Before first users, a Redis exposure of plaintext Supabase bearer tokens was reproduced and remediated with a deterministic scan. The build gate now fails if Redis holds token-shaped authentication material.

Attribution and caveat

This is self-owned product safety evidence only. Please do not imply clinical efficacy, certification, regulated approval, or client consulting proof from this record.

Retained capability

The retained capability is a cleaner session boundary: Redis keeps identifiers, timestamps, and counters, while live auth stays ephemeral and therefore easier to reason about.