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 Share… in its ⋯ menu 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 tab in the Inspector, and every grant of either kind appears in Access review.

Across the organization: Account menu → Administration… → Access. 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. One caution about that view: the badge shows what the file says, and it cannot tell a decision DraftMesh recorded from one typed into the text, so where the assurance matters, read the row in the audit log rather than the badge. Open Knowledge Format verification labels marked From file are also editable source claims and do not authenticate a reviewer or replace a DraftMesh sign-off. 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 on an author seat has approved too; a Reviewer-seat approval is recorded but likewise waits for an author.

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 document, the version and content hash the marker pinned, the decision itself — approved or changes requested — and how far DraftMesh can vouch for it, and Export CSV downloads exactly those rows, version binding included.

What the ledger vouches for, and what it only reports. Anyone who can edit a document’s raw text can write an approval marker into it, so the ledger does not repeat the marker — it classifies it. DraftMesh vouches only for decisions it recorded itself: a row whose result reads verified:approved was made with the sign-off control on the hosted service, under the signed-in person’s identity, and pinned to the content they saw. A decision that reached the document as text — a save, a push from another device, an edit in Code mode — is accepted and shown like any other, and its row says what the record can establish: self_recorded when a signed-in person committed a decision in their own name over the content that was saved; unverified_stamp when the row names someone the save does not put behind it; unverified_pin when the person committed it themselves but pinned content that was not what was saved; and unverified_mutated when the identity on a decision already in the document was changed afterwards by a plain save — the original row stands, and this one says the decision now names someone else. On the hosted service, a decision a person saves as text (in Code mode, or through a whole-document save) now carries that person’s own name, whatever name was typed into it, and a save keeps the name on a decision already in the document rather than changing it. Text that arrives by a push from a device is not re-credited yet, so the classes above still apply to it in full. A decision a plain save rewrote under the same claimed identity (a verdict flipped, a request re-addressed) is classified like a new decision, with its target naming the save that replaced the earlier record. Unverified rows carry no actor in the ledger — the record does not know who decided — and every decision row names the claimed identity and the committing account in its target column, so any of them can be traced; the audit log screen prints that claimed identity in the actor column with an unverified stamp tag rather than leaving it blank, and the export carries it in the target column only. (A verified row can also show a blank actor when DraftMesh recorded the decision under an identity with no account row to name, such as a connector acting on someone’s behalf; the class still stands.) Even a verified row is a record kept by the service, not a signature by the approver’s own key.

Accepting a suggestion is recorded too. A suggestion accepted or rejected on the hosted service writes its own event (suggestion.accepted / suggestion.rejected) naming who decided — a person, an agent the document’s owner granted decide permission, or a member’s own connected assistant where that member switched on Agents connected to my account may accept and reject suggestions as me (the row is then marked as an assistant’s act under that member’s own account, and records that member as the account it acted on behalf of; a member’s personal API token decides under the same switch, and new personal API-token decision rows retain the credential ID and read API token on behalf of that member; connected-assistant decisions and older rows without credential evidence retain Assistant or API token on behalf of) — and, in its result and target, whose suggestion it was and of what kind, so an agent’s rewrite that a person accepted reads as exactly that rather than as a plain save. The author in the target is the marker’s own stamp (a person’s sign-in id, or an agent’s id), not the id the Members list shows. The Suggestions preset in the audit log is that list. It is recorded from the accept itself, never reconstructed from the document afterwards: a suggestion marker deleted by hand in Code mode is a save, not a decision, and writes no such row.

Three honest limits. Rows written before September 2026 carry a bare approved, changes requested or requested and were not verified; they keep that value forever, and nothing new is written in that shape. An approval recorded on a local DraftMesh and later pushed to the hosted account arrives unverified (unverified_stamp): a local identity is a name that machine asserts, not a signed-in account, so the hosted service cannot put anyone behind it — when the record matters, approve on the hosted service. 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. The document remains the primary artifact, and a decision taken outside DraftMesh is not in here.

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… → People → their row in Members (as observed) → Sessions opens a panel beside the list with every credential DraftMesh itself issued to them — device sign-ins, personal API tokens, and any agent credentials bound to them. Each device or API-token row has a Revoke that stops its next request (a device that signs itself out asks to end its own row as it goes, so most device rows you see 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. Deleting the person in WorkOS, or removing or deactivating their membership of your WorkOS organization, also ends the device sign-ins and personal API tokens DraftMesh issued them, but not at once: DraftMesh asks WorkOS whether the person still exists and is still an active member of your organization each time a device renews its sign-in, and about once an hour while a device or token is in use. A check WorkOS fails to answer lets the credential through until the next one. Disabling or deleting someone only in a single sign-on identity provider (Okta, Entra and the like) does not end these credentials: WorkOS goes on reporting the person and their membership as active unless that change reaches WorkOS itself, so their devices keep syncing and their API tokens keep working until they expire — use Remove or Suspend… here as well. For an immediate cut-off, also use Remove or Suspend… here, which take effect on the very next request.

Changing what authority they hold is separate, and immediate: Administration… → People → their row → the Role selector, set to Admin, Member or Auditor. The very next thing they ask DraftMesh for is answered at the new role. DraftMesh will not let you move the last admin off Admin — to Member or to Auditor — so promote someone else first.

Blocking their connector also blocks their personal API tokens when they act in your organization. The block is scoped to your organization; it does not follow them into another organization they belong to. The organization-wide agent-access switch closes both doors for everyone at once.

Suspending their access temporarily is Administration… → People → Suspend…, for both locally homed members and Organization members homed elsewhere. Their next request to this organization is refused: browser, device sync, API tokens, hosted assistants and tasks. Named shares in this organization stop admitting them even when they sign in without an organization; shares from other organizations remain available. Their role, groups, grants, work and seat stay. Reinstate restores access without confirmation. Suspension signs out their DraftMesh devices and revokes API tokens by default; they must sign in again and create new tokens after reinstatement. Unchecking Sign out their devices and revoke API tokens keeps credentials alive, so unexpired ones work again on reinstatement. DraftMesh refuses browser cookies here but does not end identity-provider browser sessions. Local work on disk continues; guest links they issued keep working. Optional reasons are visible to admins and auditors, alongside the date and acting admin; the audit ledger records the act and admin, not the free-text reason. Scheduled auto-reinstate and bulk suspension are not available.

Removing them from the organization altogether is Administration… → People → their row → Remove, confirmed in a dialog that names them. It takes effect on their next request, frees their seat, removes them from your WorkOS organization so they cannot sign back in to it, ends the device and agent credentials DraftMesh issued them, and takes them out of your groups. Remove… also reaches Organization members homed elsewhere, from their row in that table: it ends their membership and access here in the same way, including through named shares, but frees no seat — they never held one here — and leaves their own workspace and any other organization they belong to untouched. Standing agent rules they connected are paused at once; another admin can resume them once the person has access again. What it does not do matters as much. Their comments, suggestions and approvals stay in the documents, and the audit rows naming them stay in the ledger — attribution is historical, and a comment written by someone who has since left the organization was still written by them. Their document share rows remain, but no longer admit them to this organization, including when they sign in without an organization. Re-admission restores surviving grants. Revoking those inactive rows is cleanup, a separate, confirmed step — follow Revoke remaining shares in Access review under the report, or go to Administration… → Access, where Removed members’ shares lists each removed member with Revoke remaining shares. If DraftMesh cannot resolve their address, it revokes bound shares but warns that email-addressed shares may remain; retry after identity lookup recovers. A removed person cannot receive access here through a named share; use a guest link instead. Removing someone already suspended keeps their suspension on record; re-admission clears it. Guest links they issued are not affected. The account’s owner cannot be removed — transfer ownership first (below) — and neither can the last admin or you yourself; the console disables Remove on those rows and says why. And as with everything else here, their browser sign-in belongs to your identity provider.

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.

An agent’s task callback credential also checks the requesting person’s access on every request. If that person no longer holds the task’s original capability, loses document access, becomes an auditor, is suspended, or is removed from the organization, the task fails and the callback credential is deleted. The failure is recorded once against the task. Restoring the person’s access does not revive it; they must send a new request. This check does not change the agent’s separate standing grants.

Removing a member ends their personal API tokens along with their device and agent credentials.

Who owns the account, and can that change?

Yes — ownership transfers. The account’s recorded owner is the billing and accountability contact and must be a current admin; People marks their row Owner, and Administration… → Billing & plan names them (Current owner: …). To hand it on, an admin opens Billing & plan → Transfer ownership, chooses another current admin as New owner, then Transfer ownership… and confirms. Only current admins other than the owner are offered, so make someone an admin on People first. The previous owner keeps their admin role until it is changed separately; ownership itself confers no extra authority. The current owner cannot be demoted or removed until ownership is transferred. The transfer is recorded in the audit log (tenant.owner_transferred). An auditor sees who the owner is and no transfer control.

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 two seat-management screens of its own. Administration… → People → Invitations is where an admin invites someone by email at Member, Admin or Auditor on an Author seat or a free Reviewer seat and withdraws a pending invitation. Administration… → Billing & plan lets any admin choose New seat limit for a live subscription, never below the number of people already seated; the Stripe Customer Portal confirms the change, and the new limit arrives from Stripe and is recorded in the audit log. When the subscription carries an add-on item, the charge is previewed and confirmed in Billing & plan instead. A lower seat limit then takes effect immediately and credits the next invoice. Billing also offers cancellation. When a subscription ends, the organization is marked lapsed and new invitations pause immediately. Cloud changes continue during the grace period shown in Billing (30 days by default). At its exact deadline, cloud changes pause, including creating workspaces, editing documents, pushing sync changes, expanding sharing, and starting agent work. Reads, downloads, exports, sync pulls, and editing local copies remain available. Admins can still manage billing and reduce access. Resubscribe starts checkout again; cloud changes resume when the renewed plan is recorded. An Individual subscription has the same grace period and recovery access. A personal account without a paid plan can edit locally for free; creating or changing its cloud workspaces requires Individual. At the personal grace deadline, or without a plan, no new guest links can be issued, and guests can still read through existing links but not comment or sign off; revoking a link always works. This does not remove access granted by a paid organization to its workspaces. 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.

Billing & plan also lists the organization’s add-ons and the state of each: Included (every add-on on Enterprise; Reviewer seats on Team too), Active with a quantity once one is on the subscription, Paused when one is held but the current plan state grants nothing, offered to a Team organization with a subscription once the host has its price configured, and Announced otherwise. When the host offers the Governance pack, an admin uses Add… or Change… in Billing & plan → Add-ons, reviews Due now and the next invoice, and confirms. Additions are charged for the remaining billing period before they apply; decreases and removals credit the next invoice. During a trial, additions cost $0 now and are billed when the trial ends. If payment needs action, Stripe’s invoice page opens to finish it; the existing entitlement stays until payment succeeds. An add-on arranged by DraftMesh is changed through support@draftmesh.com. The Governance pack covers SIEM streaming, configurable audit retention and an audit export API; it is not yet sold, because those features are not yet built. Reviewer seats are not sold: they are free and unlimited on Team and included in Enterprise.

Agents are never seats. Each organization has a monthly pooled allowance of agent actions — an agent’s saves, suggestions, comments, questions and answers, decisions, task deliveries and subscription firings; reads are free, and a person’s own connected assistant is not metered. Overview’s Agent activity tile shows usage, admins are warned at 80%, and at the cap agent actions pause with a clear error until the month resets. Agent actions are not sold, so nothing is ever billed for agent activity; an organization that regularly needs more can ask support@draftmesh.com. The agents kill switch, revoking an agent, and cancelling its subscriptions or tasks always work, at the cap or not.

What can DraftMesh’s own operators see?

Request metadata and process health — never document content. The hosted service keeps a diagnostics record of every request it serves (the route, the timing, the status, a request id, and the organization and account it was served for) and a rolling record of its own process health (memory, event-loop delay, which background index builds are running). Those records carry no document text, no search queries and no tokens by design. Your organization’s admins and auditors can read the records that belong to your organization; any other member reads only the records of their own requests, and an AI agent or connector reads only the records of the requests it made itself (see Governing AI agents); a DraftMesh operator — a named person on the DraftMesh team, marked as such on their own account by the team’s operations tooling, not by any organization’s admin — can read the whole host’s records and health, across every organization the host serves, and the CPU profiles the process captures of itself when it stalls. That is what lets an incident be diagnosed from the record rather than reproduced. A copy of those records, together with the service’s edge request log (the method, the route with any document or file path, query string and link token cut off, the status, the size and the timing; no request or response headers), with the organization and account identifiers replaced by one-way hashes and with no address, device name or browser details, is kept for the standard retention period of a hosted monitoring service operated by Grafana Labs, where DraftMesh’s operators and DraftMesh’s own monitoring automation read it; Grafana Labs receives no document text, no document name from those request logs, no search query and no token. What you type into the support form is read by a person on the DraftMesh team, not by an automation. DraftMesh’s support-triage automation sees only the shape of the queue: each open report’s category, its age and one-way-hashed identifiers for the report and the organization or personal account it came from, never the subject or details you typed, your name, address or account, or a document. It sends that to a model provider to summarize the queue and never answers you on its own. Mail to support@draftmesh.com is handled the same way: the automation sees when each unread message arrived and whether it has an attachment, never the sender, the subject or the body, and a person reads and answers it. Letting the automation read report or mail text to sort it and draft replies is a separate decision DraftMesh has not made; it is off, and this page will say so before it changes. Alongside that, the service keeps a daily count, per organization, of which of six product doors were opened — the account menu, app settings, a Help topic, an Administration section, billing, and the support form — recorded as a date, the door, one word for the section or topic, and a number, and, in the same form, which answers were picked on the welcome tour’s three fixed-choice questions (what you will use DraftMesh for, who you work with, your role) and whether a tutorial was started, finished or skipped. No person, no time of day, no document, no path and nothing typed; there is no row to attribute, and no third-party analytics service is involved. It exists so we can tell whether these doors are findable and whom the product is reaching, and there is nothing in it to ask us for on a member’s behalf. DraftMesh also keeps an idempotent conversion row when the verified recipient of an emailed document or workspace invitation successfully reaches its authorized target after sign-in. The underlying invitation snapshot and join data expire 30 days after the invitation context expires. Your organization’s admin overview receives only aggregate totals split by new or existing account and document or workspace; it never receives the recipient address, target path, token, account id or private join id. A preview, a wrong-account sign-in and a sign-in refused at admission record no conversion. First touch remains separate: the first-party tag on the link someone first signed in from (www, guest, hn, ph, mcp-registry, skills or a partner tag) and that link’s utm_source and utm_campaign are stored once on their account and on the sign-in row, never overwritten, and never a document path, an address or anything typed. It is what the weekly sign-ups-by-source count reads, and no third-party analytics service is involved. Making or unmaking an operator writes an event (principal.host_operator_granted / principal.host_operator_revoked) in the audit log of the account that person is homed in — when that is your organization, your admins see it in Audit log; a person who signed up individually before being invited is homed in their own personal account, and that ledger has no console today. Every operator read is itself a request record naming the operator. The error reports a browser sends back to the service are throttled per account and per organization, may hold only a fixed share of the record, and carry identifiers only — never free text — so error reports cannot push the request records (or that operator read trail) out of the record, or write a sentence into it. The service’s public liveness check answers only that it is up and its API version; it does not name the deployed build. Operators hold no document access through this: reading a document is governed by grants, roles and the organization’s own controls exactly as for anyone else.

What is not here yet

• No scheduled auto-reinstate or bulk suspension. An admin reinstates one person at a time.
• No re-crediting of comments that arrive by device sync. A comment or decision a person saves as text on the hosted service is credited to them; one that arrives in a device’s synced files still shows the name written into it.

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

• No hosted data-residency choice. You cannot choose a storage region for your hosted account’s documents, history, search index or audit log. Running DraftMesh locally does not create a region choice for any data you sync to the hosted service.

• No multi-user self-hosted server edition. There is no installable multi-user server release. The available local DraftMesh runs on your own machine for one user; optional cloud sync and sharing use the hosted service operated by DraftMesh.

• No SCIM or directory sync. DraftMesh does not sync or store your WorkOS directory. When directory sync arrives it is an Enterprise capability: on Team, the console refuses its directory-sync setup with a message that names the Enterprise plan. (Single sign-on is not affected; it stays available on Team.) It records a person when that person first signs in, which is why the member list under People is labelled Members (as observed) — it is a subset of your directory, not a roster. There are two directory reads. One is at share time: when someone shares a document with an address, DraftMesh asks WorkOS whether that address is a verified, active member of your organization — filtered to your organization by WorkOS itself, never across organizations — so a colleague’s grant is linked to their account at once. That share-time read means whoever shares (today, an admin) learns whether an address they typed belongs to a member of your organization, and that member’s name, and anyone who can comment on the workspace sees that member’s name, never their address, in the list of people they can mention or ask; nothing is learned about any other organization, and no account is created for someone who has never signed in. The other is the credential re-check above: for a device sign-in or personal API token, DraftMesh asks WorkOS whether the person it belongs to still exists and is still an active member of your organization, and stores only the answer, briefly, in memory. (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 administration. Device, personal API-token, and agent credentials are listed per member (People → their row → Sessions); devices and API tokens can be revoked there. Browser sessions are not listed or revoked in that console. A successful browser Sign out blocks subsequent authenticated requests from copies of that session, including refreshed cookies. Requests and event streams already admitted may finish. If server sign-out fails, the page offers a retry. DraftMesh stores only a hashed session key and expiry through the bounded replay window (a 24-hour access-token ceiling plus clock-skew allowances); cleanup runs every minute and retries after database outages. No cookies or tokens are kept in that record.

• No configurable audit retention. The record is kept indefinitely and cannot be set to expire. When it arrives, it comes with the Governance pack on Team and is included in Enterprise.

• The audit log records identified refusals, not every refused request. A suspended member, a member of an organization that is not admitted, an agent or connector stopped by the organization-wide switch, and a blocked connector are each recorded when refused at the door, whether they come through the browser, the desktop app, a personal API token, a connector or a registered agent’s credential — once per five minutes per person and reason, however often the client retries. A request with no valid credential, a sign-in from an organization DraftMesh has no record of, and a rate-limit refusal are counted for DraftMesh’s operators, not written to your log.

• Audit rows are best-effort, except for exports. Most rows are written just after the act they record; if the ledger cannot be written at that moment the act still stands and the failure is counted, not retried. A CSV export of the audit log or the access review writes its row first and is refused if that row cannot be written.

• Append-only is not yet independent of the service’s own database account. The database refuses updates, deletes and truncation of the audit table, so nothing done through DraftMesh can alter a row. The guard belongs to the same database account the hosted service runs as, so a person with direct database access under that account could remove it; separating the account that writes rows from the account that owns the table is not done yet. There is no hash chain over the rows either.

• Three roles. Admin, Member and Auditor, flat — every admin equal. An auditor reads every document in the organization and the whole console, including both CSV exports, and can change nothing: no comments, suggestions, edits, approvals or sign-off requests, no sharing, no console action, no workspace created, renamed or linked, no group created or changed — including a group they created before the role. A grant cannot raise an auditor: a share addressed to one is inert, and is refused outright whenever DraftMesh recognises the address as belonging to an auditor here. The last admin cannot be made one. A seat class is not a role: a Reviewer is a member with a lower ceiling — no edit, save, accept or reject — and their approval is recorded and shown; a version is approved once an author approves it. There is still no way to give someone one section of the console. Groups exist (Account menu → 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. Once a group has been given access to a document or workspace, only an admin can change its membership, name or existence, so a member who created it cannot use it to share.

• 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. Under People, Members (as observed) (locally homed members), Organization members homed elsewhere (from the organization membership roster), and People with shares (from bound share grants) are separate views. An organization member can have no share; a person with a share need not be an organization member. Neither outside-person view is a complete list of every possible connector caller. If the organization roster is unavailable, the console says so rather than showing an empty list. 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. Where known, whether a member has let their own connected assistant accept and reject suggestions as them is shown beside them to read and not to set: it is the member’s own account setting, and neither you nor any other admin can switch it on or off — but you do not need to, because a connector block on that person and the organization-wide switch both sit above it and close the door whatever it says.

• No per-member control over whether an assistant may accept suggestions as that member. A member can switch on Agents connected to my account may accept and reject suggestions as me, which lets their own connected assistant close suggestions on documents they can already edit — recorded as the assistant acting on their behalf, never granting the assistant anything the member does not have. It is off until they turn it on, you can see who has, and it is not an admin setting: there is no control that turns it off for one person, and none that prevents a member turning it on. What you have instead is blunter and reaches further — block that person’s connector, or the organization-wide agent switch. Both close the door whatever the member’s setting says.

• No workspace removal on DraftMesh cloud. A workspace in a hosted account cannot be removed from the account’s list — the workspace switcher says so in a line under its list, and there is 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.

• A personal account has guest links, and no other organization surfaces. Signing in without an organization gives you a personal account. On the Individual plan you can issue guest links from a document’s Share panel: view, comment or suggest, never edit; the whole document or one section; lasting 1 hour to 30 days; revocable at once. The guest is named but unverified. Named sharing with verified identity, Shared with me, groups, agents as separate principals, the admin console, the audit log and SSO still belong to an organization. The controls for those do not fail quietly or blame your sign-in — each is refused with a sentence saying an organization is what is missing, not an error about who you are. Use Account menu → Create an organization… when you want to bring colleagues in.

• 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.

• The local MCP doors are kept, and it is the credential, not the door, that decides authority. The default local setup — npm i -g draftmesh && draftmesh setup — installs the DraftMesh CLI and skill and writes no MCP server entry. Two older local MCP doors are still open for assistants configured before that: the published draftmesh-mcp command, and the local DraftMesh’s own address for MCP clients. Neither is installed, configured or advertised by setup, and neither is deprecated. A current DraftMesh client takes a bounded assistant session whichever of the three it uses — everything an assistant does (reading, commenting, suggesting, saving) goes through the CLI’s document commands or an up-to-date draftmesh-mcp, and both trade the machine’s owner credential for a bounded session before their first call, refusing to run with owner authority against a local DraftMesh too old to issue one. The CLI’s owner commands are a separate matter and deliberately not scoped: draftmesh status, sync, doctor, stop, restart and the cloud sign-in trio act on the machine’s own credential, because they are the person’s commands about their machine, not an assistant’s about a document. What sits outside that boundary is anything still presenting the owner credential itself: an assistant configured before scoped sessions shipped, or any program on that machine addressing the local DraftMesh directly. Upgrading DraftMesh does not narrow such a client — the connector has to be updated too. For a review, the question to ask about a machine is which of those two a given assistant is, not which door it came through.

• This console has one lever over a DraftMesh on someone’s own machine, and it is all-or-nothing. That daemon signs in to your account as a device, and its row in that member’s Sessions panel (People → their row → Sessions) can be revoked: on its next request the machine stops reaching the account, so its workspaces stop syncing. Removing the member ends their device credentials too, by the same mechanism and less selectively. That is the whole of it. Nothing here reaches inside the machine — the connector block and the organization-wide agent switch act on your hosted door, and what a local assistant may do with the files on that disk is set by the per-workspace switches below, by whoever sits at that machine. Revoking the device does not stop an assistant working locally; it stops the results reaching you. Documents that only ever lived on that machine were never in the account to begin with, and narrowing what runs on it is a device-management question rather than a DraftMesh setting.

• A workspace shared with a person is reached from their computer through DraftMesh cloud, never copied onto it. A signed-in local DraftMesh lists the workspaces shared with its person and forwards an assistant’s document calls on them — read, search, map, remember, comment, suggest — to DraftMesh cloud over the computer’s own cloud session. The cloud decides each call by that person’s share grants, exactly as in the browser, and records every write as the assistant acting on the person’s behalf. For a current (scoped) local assistant the local session policy runs first: on a shared workspace both per-workspace switches below read as off, so it can neither save directly nor accept suggestions there, and such a call never leaves the computer. A client still presenting the machine’s owner credential (see above) skips that local step: its call is forwarded and decided by the person’s share grant on the cloud alone. No assistant receives the computer’s cloud credential. Workspace and account administration is never forwarded. Signing the computer out removes the rows.

• Scoped local assistants have two separate per-workspace content controls. An updated local connection receives a bounded, restart-cleared assistant session rather than the machine’s owner credential. It can read, comment and suggest. Agents may save directly in this workspace governs full document saves: it starts on for a local-only workspace and off for one bound to DraftMesh cloud. Agents may accept and reject suggestions in this workspace is separate and starts off. Both controls live in Settings → Workspace agents and are remembered on this machine. Neither permits approval or sign-off, rollback, sync or account changes, agent or sharing administration, or access to the owner credential. This is an API authority boundary, not operating-system isolation: another process running as the same user can still read daemon.json or edit workspace files directly. Older connectors that still send the owner credential predate the boundary and must be updated; upgrading only the daemon does not rewrite a running client.

• Retracted memory entries remain in history (there is no purge). Retracting an entry — the Retract control on the memory landing page, or deleting the entry’s file in the synced folder — takes it out of the map, search and recall at once, but history keeps it: every earlier version stays in the workspace’s history, as for any document.

• Read history is incomplete. Successful direct reads of Memory documents through hosted agent doors and API tokens are sampled at 10% as doc.read, including historical versions. Rows name the workspace, document and version plus the acting account or registered agent and its account/task context; they contain no document text. Maps, searches, lists, human browser reads, other workspace kinds, local reads and direct disk access are outside this record. Sampling and best-effort delivery mean a missing row proves nothing about whether a document was read. Memory writes and credential-tripwire refusals keep their existing audit rows.

• Portable Memory review evidence can be incomplete. OKF exports include current, proposed and archived documents. Hosted review metadata requires authenticated records matching the exact copied content; source text, author labels and pasted approval markers do not establish it. Missing, delayed or legacy evidence remains unknown. Local exports omit authenticated trust. Exported files are editable snapshots and do not retain tamper-proof assurance or track later access revocation; a recorded review is not a factual accuracy guarantee.

• Local credentials are not kept in the operating system’s keychain. A signed-in DraftMesh on someone’s computer stores its device sign-in and any Google connection encrypted under ~/.draftmesh, with the encryption key in a file in that same folder. DraftMesh keeps the folder readable by that user account only, but protection rests on the computer’s user accounts: a copy of the folder (a backup, a synced folder) or another program running as that user can use them until the device sign-in ends (at most 30 days) or is revoked. draftmesh doctor reports this posture on the machine.

• The local daemon does not mint personal API tokens. Its owner credential and restart-cleared scoped assistant sessions already cover local REST access, and any same-user process can read daemon.json; another long-lived secret would add no security boundary.

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.