Who can see, ask and change a confidential contract.
Contracts are among the most sensitive files a company has, and an AI workspace adds a new kind of access: asking questions about a document. I designed Malakah's permission system, from organisation roles down to a single contract, so legal teams can share widely without losing track of who can do what.
- Problem
- Contracts were shared by email and WhatsApp, so every share made an uncontrolled copy. Moving them into one workspace solved that only if sharing inside it was safe and easy to understand.
- Insight
- Not everyone who needs a contract needs to change it. Business approvers needed answers from contracts, not editing rights.
- What I designed
- A four-level access model, a role picker that explains each role, sharing and invite flows with visible pending states, owner-aware views, and an audit trail on every signed contract.
- Key decision
- A third project role, Query: use the AI on a project's files without being able to edit or delete them.
- Outcome
- One permission model shipped across organisation, project, contract and signing, used by Malakah's 1,000+ legal professionals.
Every share was a copy nobody could take back
In 12 interviews and 6 contracts followed end to end, the same pattern showed up: drafts went back and forth by email, finance approved in WhatsApp, and 9 of 12 people had sent an outdated version at least once. Each of those messages was a copy of a confidential document that nobody could recall or audit.
Moving contracts into one workspace fixes the copies, but only if sharing inside it is at least as easy as forwarding an email, and much safer. Three groups touch every contract, and they need very different access:
The design goal: anyone can see, at a glance, who can see, ask about and change a document, and change that in two clicks.
Four levels, each answering one question
Rather than one long list of permissions, I split access into four levels. Each one answers a single question, in the place where people ask it.
Admin or Member.
Edit, Query or View.
Per person, per file.
With an audit trail.
A role for asking, not editing
The usual model has two roles: people who can change a document and people who can only read it. AI breaks that. Reading a 60-page supply agreement isn't what a finance approver wants; asking “what are our payment terms and penalties?” is. With only Edit and View, they'd either get edit rights they shouldn't have, or no way to ask.
Edit and View only. Fewer choices, a familiar pattern. But approvers end up with editing rights just to use the AI, which is exactly the over-sharing we were trying to remove.
Edit, Query and View. Query lets someone run questions across a project's files without changing structure or files. One more option to understand, so each role carries a one-line description in the picker.
| Role | Can do | Can't do |
|---|---|---|
| Edit | Manage the project, add and delete files, run queries | — |
| Query | Run and analyse questions with the AI, see the answers | Edit the project structure or files |
| View | Read project files and earlier queries | Make any changes |
The descriptions in the picker are written as what you can do, not as a role name to decode. Choosing a role means reading one sentence, not checking a help page.
Sharing that stays visible and reversible
01Share a single contract
- The access list sits inside the share window, so you never grant access without seeing who already has it.
- Every person has their own level and a remove button. Changing or revoking access is one click, in the same place it was granted.
02Manage a whole project
- Bulk selection for teams of 20+, with a running count of who has access.
- Pending invitations are shown, not hidden. An admin can see access that's been offered but not yet used, and cancel it.
03The interface reflects your access
- Ownership is labelled, not implied. An Owner badge on each card, and separate “My projects” and “Shared with me” views.
- Unavailable actions are removed, not disabled. A viewer never meets a button that fails, so the menu itself tells them what their access is.
Every signature leaves a record
Signing is where access matters most, because it involves people outside the company. Each contract sent for signature carries its participants, an expiry date and an audit trail, all from the same menu.
- Access for outside parties can expire, so a signing link doesn't stay open forever.
- The audit trail records every view and signature and exports as a certificate, which is what a legal team needs if a signature is ever disputed.
- Five shared statuses (Pending, Waiting on Others, Action Required, Expiring Soon, Completed) show everyone the same state.
How I'd know it's working
Good permissions are mostly invisible, so the signals are about mistakes and friction. These are the metrics I'd put in place.
What I took from this
AI creates new kinds of access. “Can ask about this” is different from “can read this” and “can change this”, and the permission model had to say so.
Describe the action, not the role. A one-line “what you can do” beat any role name, especially across two languages.
Show access where it's granted. Putting the access list inside the share window did more for safe sharing than a separate settings page would have.
Next, I'd add an access review. A single view per contract answering “who can see this, and since when?”, so admins can tidy access without opening every project.