MuseLegal locks down who can see which matter

The fork adds real access control to a platform that previously had none enforced at the data layer.

securitymulti-tenant

MuseLegal built a permission layer that decides, for every matter, who is allowed to look at it. Each person is assigned a role - client, attorney, reviewer, or paralegal - and the rules follow from there: clients see only their own matters, attorneys see the ones they're staffed on, reviewers and paralegals can see either, and partners and admins see everything.

The key move is where this lives. The checks sit in the database itself, so the protection applies to matters, documents, client messages, tasks, intake submissions, and downloadable files no matter which part of the app does the asking. The same rules are mirrored in the application code, and they fail closed - when something goes wrong, access is denied rather than granted. No tests shipped with it yet.

So what Anyone running a client portal on Mike should look here: this is the difference between hoping the front end hides the wrong matter and guaranteeing the database won't serve it.

View this fork on GitHub →

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

Commits in this thread

2 commits 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
62747299 Merge pull request #1 from MuseLegal/codex/revise-portal-permission-model-based-on-roles Griot Vault 2026-05-03 ↗ GitHub
Add many-to-many matter participant authorization model

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-98.md from inside the repo you want the changes in.

⬇ Download capture-thread-98.md