MuseLegal locks down who can see which matter

An access overhaul moves matter visibility from "the frontend hides it" to a hard rule the database itself enforces.

securitymulti-tenant

Until now, deciding which clients, attorneys, reviewers, or paralegals could see a given matter leaned on implicit ownership and the user interface simply not showing things. MuseLegal swapped that out for an explicit assignment table - every person tied to a matter is listed, with a role attached - and then taught both the application and the database to check that list before handing anything over.

The move matters because it's defense in depth. Documents, portal messages, tasks, intake submissions, and downloadable files are all gated by the same rule, and partners and admins keep their global view. Even if a request somehow skipped the server's check, the database itself would still refuse to return another matter's contents. MuseLegal notes no automated tests ran against the change, and the PR was merged within a minute - this is groundwork being laid quickly so later work can build on it.

So what Anyone evaluating client-portal forks for confidentiality risk should note this is the kind of authorization model that survives a frontend bug.

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 MuseLegal/AI-Legal-Platform, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
b0ce349f Add matter_participants-based portal access controls Griot Vault 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-290.md from inside the repo you want the changes in.

⬇ Download capture-thread-290.md