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 Whole workspace section; for an agent, in Connect an agent… on the document (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.

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.

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.

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. There is no sign-in prompt, no file list, no history, and no way to reach a second document.

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. The receipt names the document and the version their comment became; it carries neither the comment’s text nor the link.

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. 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, Approve / Request changes — and 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. It never stands alone: the document counts as approved only once a member of your organization has also approved, 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.

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.” A view link says “You can read this section. Commenting is off for this link.”

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

⚙ Settings → Administration… → Access review 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.

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 (⚙ Settings → Groups…) 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. Adding someone to a group that already holds edit hands them edit everywhere the group reaches, which is why the Groups panel asks first. Grants are how a member reaches a document; an Admin needs none — admin authority carries edit on every document in the organization (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.
• 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 and agent credentials — are listed per member under Administration… → Overview → Sessions, and a device 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. So a revoke here is for a device its owner no longer has, did not sign out of, or signed out of while offline. A browser sign-in belongs to the identity provider and cannot be listed or ended from DraftMesh.