Add RLS to all content beyond user profiles
ryanmcdonough/mike
ryanmcdonough is hardening Mike's access controls so a signed-in user can only ever reach what's theirs.
This fork is about one worry: a logged-in user reaching material that belongs to someone else. Everything ryanmcdonough has done here points at it. One change closes a hole that let users attach chats to projects they were never given access to. The other pushes authorization down into the database itself, extending row-level security from user profiles to every content table, so one client's material can never surface in another's account.
The database-wide sweep didn't land. The proposal was closed on 2026-05-08 with no explanation left behind, which leaves the fork carrying the narrower chat-creation fix. There is no rebrand and no new feature work; if you tried it, it would look and behave like stock Mike, with stricter rules about who can touch what.
We have no signal on who ryanmcdonough is beyond the handle. But the choice of work is legible enough - confidentiality between clients, enforced at the deepest layer available. If access control in a legal AI assistant is the thing you'd check before deploying, the actual changes on GitHub are a short read.
What's in it
- Project access check on new chats Starting a chat attached to a project now requires real access to that project. Previously any signed-in user could quietly hook chats onto projects they couldn't see.
- Row-level security on all content (proposed, closed) A database-layer sweep to lock down every record rather than user profiles alone, so the database itself decides who sees what. Closed on 2026-05-08 without merging, reason unknown.
Direction
security
Activity
Add RLS to all content beyond user profiles
⛔ #2 Enhance chat creation endpoint to check project access using user email +8 2mo ago by
ryanmcdonough ↗ analysis ↗ GitHub Fix Issue #1
⛔ #2 Enhance chat creation endpoint to check project access using user email +8 2mo ago by
ryanmcdonough ↗ analysis ↗ GitHub Fix Issue #1
A logged-in user could start chats attached to projects they had no business touching - ryanmcdonough proposed slamming that door shut.
📝 ryanmcdonough closes a hole in who can touch your projects 1 commit 3mo ago securitymulti-tenant draft
An authenticated user could quietly attach chats to projects they were never allowed to see - ryanmcdonough shut that door.
📝 ryanmcdonough wants the database itself to decide who sees what 0 commits — securitymulti-tenant draft
A proposed hardening pass to lock down every record, not just user profiles, so one client's material can never surface in another's account.
📝 RLS sweep across all content tables - closed without merging 0 commits — securitymulti-tenant draft
ryanmcdonough opened a PR to extend row-level security beyond user profiles to every other content table in the schema. The intent was a database-layer authorization sweep rather than a targeted fix. The PR was closed on…
Threads of work (detailed view)
ryanmcdonough moves to plug a chat-creation loophole
A logged-in user could start chats attached to projects they had no business touching - ryanmcdonough proposed slamming that door shut.
ryanmcdonough closes a hole in who can touch your projects
An authenticated user could quietly attach chats to projects they were never allowed to see - ryanmcdonough shut that door.
POST /chat/create now checks project access before inserting
ryanmcdonough patches an authz hole in `POST /chat/create`: the endpoint previously accepted any `project_id` from the request body and inserted a chat row without verifying the caller had access to that project. Eight lines close it. Upstream willchen96/mike still has the gap.
ryanmcdonough wants the database itself to decide who sees what
A proposed hardening pass to lock down every record, not just user profiles, so one client's material can never surface in another's account.
RLS sweep across all content tables - closed without merging
ryanmcdonough opened a PR to extend row-level security beyond user profiles to every other content table in the schema. The intent was a database-layer authorization sweep rather than a targeted fix. The PR was closed on 2026-05-08 without merging, and no explanation was left.
Pull requests (detailed view)
⛔ Closed without merge (4)
by
ryanmcdonough · opened 3mo ago · closed 2mo ago by
ryanmcdonough · opened 3mo ago · closed 2mo ago by
ryanmcdonough · opened 3mo ago · closed 2mo ago by
ryanmcdonough · opened 3mo ago · closed 2mo ago