Admin: Security posture FAQ

The questions admins actually get asked, answered against what DraftMesh does today — including where the answer is “not yet”.

Who can see this document?

Per document: open it and use its Share panel for the people granted on it and any guest links issued for it. An agent’s access is deliberately not there — it shows on the document’s Agents panel, and every grant of either kind appears in Access review.

Across the organization: ⚙ Settings → Administration… → Access review. Every grant and every guest link in every workspace, in one list, with a CSV export for the questionnaire.

Remember the two scopes a grant can have: one document, or the whole workspace — there is no folder level. A whole-workspace grant also reaches documents created later, so “who can see this document” includes the workspace-wide holders, not just the grants naming its path.

One kind of document deserves a second look. A Google reference (.gdoc, .gsheet, .gslides) shows, where Google is connected, a snapshot of the referenced Google document read with the connecting account’s Google access, and Google’s own sharing on the document does not narrow who sees that snapshot in DraftMesh. Today the snapshot exists only on the machine that connected Google, where there are no grants; for a reference held in a hosted account, “who can see this document” is the grant list as usual, and what they see is the reference’s own details and its link. See What is not here yet below and Admin: Access & sharing.

Who approved this version?

Approvals live in the document, as approval markers — who approved, and pinned to the exact content they approved, so an approval that predates a later edit is visibly not an approval of the current text. Open the document and look at its markers and history. A decision recorded from outside your organization — through a guest link, or by a member of another organization the document was shared with — is marked external on the document, and the document is not counted as approved until a member of your own organization has approved too.

There is also an org-wide record. Every sign-off requested and every approval recorded is written to the audit log as its own event, so “show me everything approved this quarter” is one screen: Administration… → Audit log → the Decisions preset, with a date range. Each row names the actor, the document, the version and content hash the marker pinned, and the decision itself — approved or changes requested — and Export CSV downloads exactly those rows, version binding included.

Three honest limits. The ledger records the decision as the marker recorded it — including who took it, which is the identity stamped on the marker rather than an independently verified signature. In practice that is the person who used the sign-off control; but anyone who can edit the document’s raw text can write an approval marker, so treat a decision row the way you treat the approval in the document itself. The document remains the primary artifact, and a decision taken outside DraftMesh is not in here. And these events are written by the hosted service: a workspace kept only on a local daemon still has every approval marker in the file, but writes no decision events — the organization’s audit log, and the console that reads it, are part of the hosted account.

How do I turn someone’s access off?

Access review → find their row → Revoke. It takes effect on the next request they make; there is no cache to wait out. The same button works for a guest link.

Ending their sessions is partly yours to do from here. Administration… → Overview → their row → Sessions lists every credential DraftMesh itself issued to them — device sign-ins, and any agent credentials bound to them — and each device row has a Revoke that signs that device out on its next request (a device that signs itself out asks to end its own row as it goes, so most rows you see are devices that did not). (An agent credential is listed there but revoked from Agents, which owns the whole cascade.) What that list does not hold is their browser sign-in: that is an account session kept by the sign-in provider, so there is still no “sign this person out everywhere” inside DraftMesh. Revoking their grants stops them reaching your documents; ending the browser session, or disabling the identity itself, is done in your identity provider.

Taking away their admin authority is separate, and immediate: Administration… → Overview → their row → Remove admin. The very next thing they ask DraftMesh for is answered as a member. DraftMesh will not let you remove the last admin — promote someone else first.

Removing a person from the organization altogether is not built yet. You can revoke every grant they hold and demote them; the account still lists them among the people it has observed.

Revoking an agent does more, and does it immediately — its credential is deleted, in-flight tasks are failed, and its standing subscriptions are switched off. Its document grants are left behind as inert rows for you to clean up.

What happens to a guest’s comment when their link is revoked?

The comment stays in the document. A guest comment is not held in a side store keyed to the link — it is written into the file as a marker, part of the document’s text like every other comment, so it survives the link that produced it. Revoking the link ends that guest’s access: they can no longer open the document, add anything, or edit or withdraw what they already wrote. It does not reach back into the file. If you want the comment gone, someone with edit on the document deletes the marker itself: there is no Delete comment button, so it is done in Code mode, where the annotation markers are visible in the raw markdown. That is a deliberate act by an owner or editor, recorded like any other edit and reversible from history. The audit rows about the guest (the link’s issue and revocation, guest.comment_created, guest.comment_edited, guest.comment_withdrawn) are kept with the rest of the ledger, which is retained indefinitely and cannot be set to expire — so removing the comment text does not remove the record that it existed. The guest page says this before anyone types: “Your comment is stored in this document, visible to everyone with access; revoking the link doesn’t remove it.” For how guest links are issued and what else the guest sees, see Admin: Access and sharing.

Where does SSO live?

It is configured in your WorkOS organization — but you no longer have to leave DraftMesh to see whether it is connected. DraftMesh authenticates people through WorkOS AuthKit and maps your WorkOS organization to your DraftMesh account. Which identity provider you use, which domains are allowed, whether SAML or OIDC, and who may authenticate at all are all configured there.

Administration… → Overview now carries a Single sign-on card listing each connection your organization has — its name, its provider, and its state in WorkOS’s own words (active, inactive, draft, validating) — so “is SSO on for us?” is answered on the screen you are already looking at. Manage in WorkOS opens your organization’s WorkOS Admin Portal in a new tab, which is where the configuration itself is changed. DraftMesh reads this; it does not own it. If DraftMesh cannot reach WorkOS the card says so rather than showing you an empty list — a blank card would read as “no SSO is configured”, and that is the one thing it must never say by accident.

DraftMesh also has one seat-management screen of its own — Administration… → Members, where an admin can invite someone by email at Member or Admin and withdraw a pending invitation. The invitation itself is issued and mailed through your identity provider; DraftMesh is asking it to seat someone, not keeping a user directory. Password policy, login methods, and who may authenticate at all remain the identity provider’s job by design, not gaps in a screen we forgot to build.

What is not here yet

Said plainly, because a prospect’s security team will ask:

• No SCIM or directory sync. DraftMesh does not read your WorkOS directory. It learns a person exists when that person first signs in, which is why the Overview’s member list is labelled as observed — it is a subset of your directory, not a roster. (The Single sign-on card reports your connections, which is a different thing: it says which identity provider signs people in, not who is in it.)
• No SSO configuration inside DraftMesh. The Single sign-on card shows what your organization has connected and links out to WorkOS’s Admin Portal; adding, editing or removing a connection happens there.
• No MFA policy inside DraftMesh. Multi-factor is enforced by your identity provider.
• No browser-session listing or revocation. Device and agent credentials are listed per member (Overview → Sessions) and a device can be revoked there. A browser sign-in is the identity provider’s session, and DraftMesh can neither list it nor end it.
• No configurable audit retention. The record is kept indefinitely and cannot be set to expire.
• No ownership-transfer screen. The account’s recorded owner is the billing and accountability contact and cannot be changed from inside DraftMesh. It confers no authority, so this is a bookkeeping limit rather than a lock-in: admin authority itself is freely granted and removed.
• Two roles. Admin and Member, flat — every admin equal, with no read-only or auditor tier and no way to give someone one section of the console. Groups exist (⚙ Settings → Groups…) but only as targets for document grants: a group carries no console authority, never signs in, and is never recorded as the author of anything.
• No member removal. You can revoke a person’s grants and their admin role; you cannot delete them from the organization in DraftMesh.
• A connector block reaches your own door only, and only for people with an account id. Blocking someone’s MCP connector stops it when it acts as your organization; it does not follow them into any other organization they belong to, and no other organization’s block reaches you. It covers members of your organization and people homed elsewhere who hold shares here (both are listed, with the control, under Overview). A person who has never signed in has no account id to record a block against — and cannot attach a connector either, so there is nothing to block until they do. To stop everything at once rather than one person, the organization-wide agent switch is the blunt instrument.
• No workspace removal on DraftMesh cloud. A workspace in a hosted account cannot be removed from the account’s list — the workspace picker says so in a line under the list, and offers no per-workspace removal control. Unregistering is a machine-side act today: it drops a folder from the local DraftMesh’s list and never deletes files.
• No per-reader check against Google on reference snapshots. Where a local DraftMesh has Google connected, the snapshot it shows for a .gdoc, .gsheet or .gslides reference is exported with the connecting account’s Google access, and whatever reads the reference through that DraftMesh — its card, search, an AI agent connected to it — sees the snapshot; DraftMesh does not ask Google whether that reader may open the document. Governing a reference is governing its snapshot (see Admin: Access & sharing). DraftMesh cloud has no Google connector, so a reference reached through a hosted account shows the reference’s own details and its link only.

How this page is kept true

Every “not yet” above names a gap that a shipped change can close. When one closes, this page changes in the same change — it is edited by whoever closes the issue, before the release, not discovered stale by the admin who quoted it to their security team. A gap list that is wrong in your favour today can be wrong against you tomorrow, and you cannot tell which from the page. If you find a line here that the console contradicts, that is a bug in DraftMesh: report it, and treat the console as the truth until it is fixed.

Where the rest is written down

Your engineering and security reviewers will want more depth than an in-app guide should carry. Two documents exist for them: an administrator guide covering the same ground with the API surface included, and a security overview written to be handed to a security team as-is — identity, authorization, tenancy, sharing, agent access, audit, encryption, the search index, transport, and backups, each stating today’s posture and its known limits. Neither is published here. The security overview page on this site summarises the posture; get in touch for the current copies.