Admin: Access & sharing

Most sharing in DraftMesh is one document at a time — a grant names a workspace, a document path, and one person or agent, which keeps the blast radius of any single mistake to a single file. The one deliberate exception is a whole-workspace grant: one holder, every document in the workspace. For a person it is made in the Share panel’s Workspace access… view (the panel’s Workspace access… row, or the Share tab’s Workspace access… button); for an agent, in Connect an agent… on the document, or from Administration… → Agents → Grant access… (see Admin: Governing AI agents). There is nothing in between — no folder-level grant.

The four capability levels

Capabilities are a straight ladder. Each one includes everything below it:

Because it is a ladder and not a grid, “at least suggest” is a single comparison everywhere in the product. There is no capability that lets someone change a document without either edit or a human accepting their suggestion.

One flag rides beside the ladder, for agents only: an agent edit grant can additionally carry decide — permission to accept or reject suggestions on that one document. It is off by default, doc-scoped always, and settable only by the document’s owner; Access review badges it as Decides suggestions.

Sharing is an admin-only act, with one further narrowing: giving an agent edit — or the decide flag — is reserved for the document’s owner, and a workspace-wide agent edit for the workspace’s owner, not any admin. Holding edit on a document never lets you pass it on — a grantee cannot re-share, cannot invite anyone, and cannot widen their own level.

A share to a person is made to their address. When that address belongs to a verified, active member of your own organization who has signed in to DraftMesh before, the grant is linked to their account the moment you share — they are named on the Share panel and can be asked and mentioned at once. Adding such a person to a group links their membership the same way. For a member who has never signed in, the grant stays addressed to their email and links on their first sign-in, but they can already be picked from the list to be asked or mentioned. Any other address — someone in another organization, or with no account yet — links the first time that person opens what you shared. Only a sign-in whose address the identity provider has verified can open, and so link, a share or group seat addressed by email: someone signed in with that address unverified matches none of them, and reaches only what is already linked to their account. DraftMesh only ever looks an address up among your own organization’s members, and a lookup that fails never stops the share; it just falls back to linking on first open.

When one holder carries both a per-document grant and a whole-workspace grant, the two scopes combine differently by kind of holder. For a person, the effective level is the higher of the two — a document grant can only add. For an agent, the document setting wins where the two disagree — including when it is lower, which is how an owner narrows one agent on one sensitive file while leaving what it can do everywhere else alone.

What a share does beyond the one document

Granting a person a document also makes them a derived member of its workspace, so they can find it. That workspace appears in their workspace list with a Shared badge, and they can read its other documents at view.

Writing is not derived. To comment, suggest, or edit anything, they need a grant on that exact document — a view-level read of a sibling never becomes a way in. Agents get none of this derived membership: an agent reaches exactly what its grants name — a document, or every document in the workspace where it holds a whole-workspace grant. A task credential is narrower still, pinned to the one document of its task.

A person’s seat or role can narrow any grant, document or whole-workspace. A member on a Reviewer seat is capped at suggest, so an edit grant lets them suggest but not edit. An Auditor in your organization is served view only, whatever a grant names. (An Admin needs no grant at all.) The Share panel’s summary line says what a share gives; these ceilings still apply on top of it.

Guest links

A guest link lets someone read or respond to one document without a DraftMesh account. They open the URL and they are in, as a named-but-unverified guest.

Guests stay accountless, and there is no limit on how many you invite. When the reviewer is a colleague whose identity must be verified — whose approval should carry their signed-in name — give them a Reviewer seat in your organization (free and unlimited on Team) instead — their approval is recorded under their name, but an author must still approve before the document counts as approved (see Admin: Your organization).

Because a link is a bearer token — anyone holding it is the audience — it is deliberately bounded:

• Capped below edit. A guest link can carry view, comment, or suggest. Never edit. A tokenless holder cannot write document text.
• Label it. Who is this link for? is an optional note to yourself — “Elena — pricing review” — so two links to the same document can be told apart a week later. It is a label, not an address: nothing is sent to it, and the recipient never sees it.
• Last opened. Every link row, and every person’s row, says when the document was last opened through it — or Not opened. The access review carries the same column and exports it, so a stale link can be judged on the row where it is revoked.
• Always expiring. Expiry is mandatory, not optional. Expires offers 1 hour, 24 hours, 7 days (the default) and 30 days. There is no permanent link.
• Optionally section-scoped. A link can expose the whole document or just one section of it. The server enforces that on every guest read and write — the boundary is not drawn in the browser.
• Revocable at any time, which takes effect immediately.

What the recipient of a guest link sees

Worth knowing before you send one, because the guest page is a surface of its own and not the app you are looking at.

They get the document (or just the section you scoped the link to) rendered as prose, with the comments already on it, under a banner that says exactly what the link exposes: “You’re viewing “Requirements” — section 2 of 5 of Q3 Onboarding PRD — as a guest” for a section link, or “You’re viewing the whole document Q3 Onboarding PRD as a guest” for the whole thing. A section guest learns the document’s title and how many sections sit beside theirs — never another section’s heading or text. Under that, one line of record: the document’s version number, every sign-off as state (v4 · approved v3 · edited since, with no approver’s name or note — a decision from outside your organization is marked (external), and the line says awaiting an internal sign-off while only outsiders have approved), and when the link expires. The guest’s own decision is marked yours on that line, so they can tell it apart from the rest. A link counts as one reviewer: a later decision recorded through the same link replaces its earlier one. There is no sign-in prompt, no file list, no history, and no way to reach a second document.

Of the review activity on the document, a guest sees comments, questions and answers, with their replies. A question is shown as one — labelled Question, with whom it is for and its answer choices — but a guest cannot answer it; the card says who can. Suggestions (and their proposed text), sign-off requests (and their notes) and individual approvals (and who made them, and their notes) are withheld: the server removes them from what it sends the guest, so they are absent from the page and from the raw response alike, not merely hidden on screen.

On a link issued at comment or suggest, they can select a passage — the selection is widened to whole words — or simply tap a paragraph, then Comment on selection / Comment on this paragraph, give Your name and Your comment, optionally an address to Email me a receipt to, and choose Send comment. They are named-but-unverified: the name is whatever they type. On a link you emailed, Your name starts out as a suggestion made from the address (elena.ruiz@… → Elena Ruiz) and Email me a receipt starts out as that address; both are theirs to change or clear before sending, and a receipt address they clear stays cleared. A link you emailed sends receipts only to the address you sent it to: given any other address, the comment still lands, no copy is sent, and the page says so. That receipt names the document — by the title its page shows, with the path beside it — and the version their comment became, and quotes their comment back to them — their own words, the ones they had just typed into that form, and nothing else: a receipt never carries anyone else’s comment, note or name, never the document’s prose, and never the link. On a link that names no recipient, anyone holding it chooses the address, so the receipt is fixed text: it says a comment was recorded and as which version, and carries no document title or path and none of their words. Receipts are also limited per link and per organization each day; past either allowance the comment still lands and the page says no copy was sent.

A guest can Edit and Withdraw their own comments — “own” meaning posted from the same browser: the page keeps a per-link session in that browser’s storage and stamps every comment with it, so nobody else holding the same link can touch them, and clearing that storage (or switching devices) means older comments can no longer be changed from there. Where you sent two links to the same address for the same document — a section link and later a whole-document one, say — that browser treats them as one person: the name they typed on one is filled in on the other, and while both links are live a comment posted through either can be edited or withdrawn through either. Revoking (or letting expire) the link a comment was posted through still ends every way to change it. Links sent to different addresses, or copied by hand with no address, stay separate. Withdrawing is refused once someone has replied, so a withdrawal never deletes another person’s words; editing stays available. Both are recorded in the audit log as guest.comment_edited / guest.comment_withdrawn, by link, never by name.

The page also states, on the landing and again next to Send comment, where what they write ends up: “Your comment is stored in this document, visible to everyone with access; revoking the link doesn’t remove it.” That is the literal behaviour — revoking a link ends the guest’s access and leaves their comment in the file, for an owner or editor to withdraw if it should go. Admin: Security posture FAQ answers that one in full, for forwarding.

A guest can record a sign-off on one kind of link only: a suggest-level link to the whole document. That page carries a Sign off panel — Your name, an optional note, optionally an address to Email me a receipt to, and Approve / Request changes — below the document and its comments, with a Sign off button in the page’s banner that jumps straight to it; the decision lands in the document as an approval marker in the guest’s typed name, marked guest · unverified and (external), with an audit row (guest.signoff_recorded) by link. Receipts follow the comment rules above. On a link you emailed, the copy goes only to that address and states the decision, the document, the version it was recorded against, the time in UTC (labelled as such; the page itself shows times in the reader’s own zone, with the zone named), the name they gave and the note they wrote — their own words again, never anyone else’s and never the document’s prose — and it carries no link. On a link that names no recipient it is fixed text: the decision, the version and the time, with no document title or path, name or note. Where the site cannot send email, the day’s allowance for that link or your organization is spent, or the address is not the one the link was sent to, the page says so plainly rather than leaving them to assume a copy went out. It never stands alone: the document counts as approved only once a member of your organization on an author seat has also approved (a Reviewer-seat approval is recorded but does not count on its own), and until then the toolbar, the Reviewers strip and the guest page all say awaiting an internal sign-off. A comment-level or section-scoped link records no sign-off; its composer says so, and a guest who has no objection says so in a comment. Once a decision is recorded the panel shows what was recorded and folds the form away behind Change my decision, so a second tap cannot record a second decision by accident; choosing it reopens the form, and a new decision replaces the earlier one. The invitation email says the same things up front: whether the link opens the whole document or one section, and — on a link that can comment — whether it can record a sign-off.

One thing to set expectations on: a guest never gets a suggestion box, even on a link issued at suggest. A suggest-level link behaves as a comment link, and the page tells them so — “You can read this section and leave comments.” — and a suggest-level link to the whole document adds the one thing it can do beyond that: “You can read this document, leave comments, and sign off.” A view link says “You can read this section. Commenting is off for this link.” On a whole-document link each of these says this document rather than this section.

When a link is finished, the page says which kind of finished it is: “This link has expired.”, “This link has been revoked.”, or “This link is no longer available.” — with a line telling them to come back to you for a new one.

The Access review section

Account menu → Administration… → Access is the one place that answers “what has this organization shared?” without opening documents one at a time.

It has two tabs:

• Shares — every grant in every workspace: the workspace, the document, who holds it (a person or a registered agent), at what level, and who granted it. A grant held by a revoked agent is shown, marked as inert, rather than hidden — so you can clean it up.
• Guest links — every link ever issued: its document, level, scope, expiry, status, label, last-opened time, and the address it was emailed to (Hand-copied when none). Expired and revoked links stay listed, visibly marked. A governance list that quietly drops rows is a list you cannot trust, and a link you just revoked should read as Revoked, not vanish.

Each row has a Revoke with an inline confirmation. Revoking a person’s grant here does exactly what revoking it from the document’s own Share panel does — the same operation, not a second one. The same holds for an agent’s grant: the document’s Agents panel offers Revoke access on a connected agent’s row for its own grant on that document, and it runs this same operation. Disconnecting a rule there deliberately does not revoke the agent’s standing access — the confirm says so.

Share a document… sits in the tab row itself — to the right of Guest links, left of Export CSV — and it is the one control here that adds a row rather than taking one away. It opens a two-step flow: pick the workspace — its recorded owner is named beside it, so you can see whose documents you are about to reach into, and a sole workspace is picked for you — then the document in it; both lists are searchable, a long workspace list offers Load more (and a Retry if the list could not be read), and a document list too long to have been fetched whole says so on the list rather than quietly showing you fewer documents than the workspace holds. The document’s ordinary Share panel then opens on exactly that document. It is not a second sharing form: it is the same panel the document’s own owner uses, so people, groups, whole-workspace grants and guest links — with their scope, expiry, label and recipient — all behave there exactly as they do on the document itself. It shares with people and groups only: an agent’s access is not set in this panel at all, but from Administration… → Agents → Grant access… or from the document’s own Connect an agent flow. The narrowings that apply to an agent live with those: an agent’s edit is the document owner’s to give, so granting it from the console can be refused with the owner named, and the decide flag is set only in the document’s own Connect-an-agent flow. Whatever you grant appears in the table when the panel closes: a person’s or group’s grant in Shares, and a guest link you mint takes you to the Guest links tab, where its row is — the same lists, in the opposite direction. An auditor does not see the button at all.

Export CSV downloads the current tab. The guest-link export deliberately contains no link tokens: a spreadsheet sitting in a downloads folder is a bad home for live document credentials. Use it for access reviews and security questionnaires, not for re-sending links.

Things to know before you rely on this

These are real limits today, not oversights being hidden:

• Groups are grant targets, nothing more. A group (Account menu → Groups…, which takes an admin to Administration… → People) is a named set of people and agents that a grant can be addressed to, so “Engineering can comment” is expressible. It is not a principal: it never signs in, never authors anything — every comment, suggestion and approval stays attributed to the individual who made it — and carries no admin authority. Any member can create a group, and its creator or any admin can change it until the group is given access to a document or workspace. From then on only an admin can add or remove its members, rename it or delete it: adding someone to a group that holds a share is sharing with them, and sharing is admin-only. The creator’s controls disappear at that point, and an attempt through the API is refused and recorded in the audit log as group.manage_denied. Adding someone to a group that already holds edit hands them edit everywhere the group reaches, which is why the Groups panel asks first. A person is added by email address, and a member whose address DraftMesh has not yet seen open anything shared to it in your organization is shown as Not yet seen · hasn’t opened anything shared with them — the membership takes effect the moment they do. That is all this group matcher uses: it does not use sign-in audit rows, so an admin or a document owner — who needs no share to reach a document — can show this way even after signing in. Grants are how a member reaches a document; an Admin needs none — admin authority carries edit on every document in the organization — and an Auditor needs none either: the role carries view on every document in their own organization, and a grant cannot raise it (see Admin: Your organization).
• No folder-level grants. A grant covers one document or the whole workspace — “just the plans/ folder” is not expressible.
• Sharing a document only sometimes notifies. Where the host can send email, creating a grant queues an invitation and the Share panel says so; where it can’t, you send the person the link yourself. A guest link is emailed only when you fill in Email the link to — then the message carries the link itself (a guest’s whole identity is the URL, so this is the one email DraftMesh sends that contains a live credential; it draws on the same daily invitation allowance as share invitations). Leave the field empty and you copy the link by hand, as before. The panel reports which happened rather than promising either. A grant addressed to an email address simply waits until that person signs in. (Inviting somebody into the organization always mails them; see Admin: Your organization.)
• Members cannot share their own documents. Sharing is admin-only, so every grant and every guest link has to go through an admin — and an admin has two doors to it, both writing the same grant. Either open the document — Share… in its ⋯ menu opens the Share panel directly, and the Inspector’s Share tab names who can see this document, with Share… for adding a person or minting a guest link, including on a colleague’s document opened from the workspace list or a link, which an admin sees Share… on, because admin authority already carries edit on every document in the organization — or go to Account menu → Administration… → Access → Share a document… and pick the document there without leaving the console. The Share tab’s Workspace access… opens the same panel’s Workspace access view, which lists and grants whole-workspace access for that workspace; Administration → Access review remains the organization-wide review of every grant.
• A Google reference shares what its connected account sees. A .gdoc, .gsheet or .gslides file is a pointer, and where Google is connected DraftMesh shows a snapshot of the referenced document read with the connecting account’s Google access — Google’s own sharing on that document is not checked against the reader. The rule is that a grant on the reference is a grant on that snapshot, for people and agents alike, and the Share panel and the Connect-an-agent dialog say so on a reference. Today no grant conveys one: Google connects only to the DraftMesh on a person’s own machine, which has no sharing, and DraftMesh cloud, where grants live, has no Google connector — so a person or agent granted a reference through a hosted account sees the reference’s own details and its link, and search matches those, not the Google document’s text. Share a reference as you would share the Google document itself; that is the rule a hosted Google connector would inherit. See Supported file types.
• Revoking access does not end an existing sign-in session. The grant stops working immediately. The credentials DraftMesh itself issued — device sign-ins, personal API tokens, and agent credentials — are listed per member under Administration… → People → their row → Sessions; devices and API tokens can be revoked there. A device that signs itself out — the account control’s Sign out, or draftmesh logout in a terminal — asks DraftMesh cloud to end its own session in that list as it goes; where that cannot be confirmed (the cloud was unreachable at the time), the row stays until it expires or you revoke it here. A device in use renews its sign-in before it ends, for up to 180 days from the original sign-in: each renewal is an audit event (auth.session.renewed), the renewed session appears here as a new row with the same device name, and a renewal never revives a row you revoked. So a revoke here is for a device its owner no longer has, did not sign out of, or signed out of while offline — left alone, such a device’s sign-in can keep renewing until the 180 days are up. A browser sign-in belongs to the identity provider and cannot be listed or ended from DraftMesh.