nwhitehouse walls off tenant data, top to bottom

A sweeping security pass adds database-level isolation so one client's matters can't leak into another's.

securitymulti-tenant

nwhitehouse turned a single large commit into a broad security overhaul. The centerpiece is row-level security across every table that holds user data - projects, documents, chats, reviews - which means the database itself enforces that one tenant can't read another's records, even if a check higher up in the app gets missed. That's the kind of belt-and-braces isolation you want when you're holding privileged material for multiple clients.

The rest of the sweep is just as practical: the front end now scrubs rendered documents to shut down script-injection attacks, the backend stopped writing AI responses into its logs, and the rules for which outside sites can talk to the service got much tighter. nwhitehouse also added a security test suite and a written pre-release checklist so these guardrails actually get checked before anything ships.

So what If you're running any descendant of this codebase for more than one client, this is the isolation layer worth copying.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from nwhitehouse/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
325ff20c Harden auth RLS and rendering paths Nick Whitehouse 2026-05-03 ↗ GitHub

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-110.md from inside the repo you want the changes in.

⬇ Download capture-thread-110.md