Sharing & roles

Invite humans by email. Mint API keys for agents. Everyone lands in the same workspace with a specific role. Every action is attributed to the principal that made it.

Four roles

Inviting a human

Two ways depending on whether you want them in the whole team or just one workspace:

1. Workspace-only (this page). Open the workspace, click Share top-right, enter the email, pick a role, send. They get a magic-link email and land in this workspace. Use this for outside collaborators, including people who already have their own team in Dock. Their team isn’t merged with yours; they gain access to this one workspace at the role you pick.
2. Whole team. Open Settings → Users and use Invite user. They become an org member and get access to every shared workspace at once. See the Teams guide for the full flow, including open join links.

Their agents come with them.Whichever path you pick, the invitee’s signed agents inherit the same access at the same role, even when the invitee lives in a different team. Trusting a person means trusting their tools. You manage the person; they manage their fleet in their own team. If you remove them or downgrade their role, every agent they had auto-enrolled on this workspace follows in the same operation. See the Teams guide for the full inheritance + cascade rules.

Inviting an agent

Agents authenticate with Bearer tokens rather than magic links.

1. In the Share modal (or Settings → API keys), name the agent and pick a role + workspace scope.
2. Dock returns a one-time secret dk_.... Copy it, it won't be shown again.
3. Give the secret to the agent. Every request it makes carries Authorization: Bearer dk_....

Agents have their own identity in the audit log. Every row they create shows up as Argus added 3 rows, not API integration added 3 rows.

Key scopes

• Workspace-scoped (default): key works against one workspace. Revocation limited to that workspace.
• Org-scoped: key can see every workspace you own. Convenient for trusted meta-agents; avoid for third-party agents.

Revoking access

• Humans: Share modal → click Remove next to their name. They lose access immediately; their past writes stay attributed to them in the audit log.
• Agents: Settings → API keys → Revoke. The next request returns 401.

Visibility

Visibility controls who can read a workspace. Edit access is always gated on membership, this setting only widens reads. Pick per workspace in the Share modal; flip the default for new workspaces org-wide in Settings → Organization.

Critical rule: visibility never grants write access. Even on a public workspace, only explicit members with the right role can edit. If you want someone to edit, invite them, a link share is never a license to write.

Org-level default

One org-wide setting controls what new workspaces default to. Two values:

• Private, every new workspace starts locked down. You flip specific ones to shared when you want to.
• Shared within org, every new workspace is visible to all teammates by default. Best for small teams who want transparency and avoid "I can't see what others are working on" friction.

Change it in Settings → Organization → Default workspace visibility. The toggle only affects future workspaces; existing ones keep whatever you set them to.

Workspace links

Every workspace has a canonical URL: trydock.ai/{org}/{workspace}. What happens when you share it depends on the workspace's visibility:

• Private, a non-member who visits sees an invite screen. Nothing leaks.
• Shared within org, teammates see it directly; non- teammates hit the invite screen.
• Unlisted / Public, anyone with the URL reads the workspace. The dashboard URL redirects anonymous visitors to the public view at trydock.site/{org}/{workspace}. Share that URL directly when you want the clean read-only view (no sidebar, no editor chrome).

Public pages: the anonymous reader view

Flip a workspace to Public or Unlisted and Dock renders a read-only public page at trydock.site/{org}/{workspace}. No sidebar, no Activity or Share buttons, no last-edit floater. Just the workspace title + table or doc content + a top-bar Sign-in link + a “Made with Dock” footer.

Public vs. unlisted, for SEO

• Public, indexable. The page ships <meta name="robots" content="index,follow">, plus a canonical /p/*URL, JSON-LD structured data (Article for doc-mode, Dataset for table-mode), and a per-workspace OG image. Also appears in Dock's /sitemap.xml so Google can discover it without you linking to it.
• Unlisted, anyone with the link reads it, but search engines don't. The page ships <meta name="robots" content="noindex,nofollow"> and is omitted from the sitemap. Good for client deliverables, investor decks, private sharing where a search-indexed footprint is unwanted.

White-labeling (Pro + Scale)

Settings → Organization → Public page branding controls the chrome visitors see:

• Hide the “Made with Dock” footer (Pro, $19/mo or Scale, $49/mo). Flip it off, the badge disappears from every public page on this org.
• Custom logo (Scale, $49/mo). Upload an SVG or PNG, it replaces the Dock mark in the top-left on every public workspace page AND the per-workspace OG image that social unfurls use. 2 MB cap. Rendered at 24px height; aspect ratio preserved.
• Website URL (Scale). Where the custom logo links to. Opens in a new tab.

Downgrades are non-destructive: your uploaded logo + preferences stay on your org row. Public pages revert to the Dock brand until you upgrade again, at which point your setup restores as-is.

Frequently asked questions

How do I share a workspace with my AI agent?

Open the workspace, click Share, mint a `dk_` API key scoped to that workspace, paste it into the agent's MCP config (or pass via `Authorization: Bearer dk_...` for REST). Or, if your agent is signed and owned by you, it auto-inherits any workspace you have access to. Learn more →

How do I invite a teammate to a Dock workspace?

Click Share in the workspace top-right, type their email, pick a role (Owner / Editor / Commenter / Viewer), send. They land via magic-link sign-in and the invite auto-accepts. To add someone to your whole org instead of one workspace, use Settings → Users. Learn more →

How do I make a workspace org-wide visible in Dock?

Settings → Visibility → `org`. Every member of your owning org gets virtual editor access without needing a per-workspace invite. The default for new workspaces in multi-member orgs is `org`; solo orgs default to `private`.

How do I give my agent read-only access to a workspace?

When minting the `dk_` key, pick the `Viewer` role. The agent can call `list_workspaces`, `get_workspace`, `list_rows`, `get_doc` but every write returns 403. To downgrade an existing agent, edit its WorkspaceMember row in the workspace's Members panel.

How do I remove a teammate from a Dock workspace?

Open the workspace's Members panel, click the kebab on their row, choose Remove. Their access drops immediately. If they have signed agents on the same workspace, those agents are atomically removed too via the cascade in `PATCH/DELETE /api/workspaces/[slug]/members/[memberId]`.

What is the difference between Owner, Editor, Commenter, and Viewer in Dock?

Owner can do anything including transfer ownership and delete. Editor can read + write rows + docs + invite members. Commenter can read + leave comments but cannot edit rows or docs. Viewer is read-only. Same role grid for humans and agents. Learn more →

Can I share a Dock workspace publicly so anyone can read it?

Yes. Settings → Visibility → `public` makes it readable by anyone (no sign-in) and listed on your org's public-workspace surface. `unlisted` is the same readability without listing. Writes still require explicit membership regardless of visibility.

How do agents get access to a workspace I share with their owner?

Automatically, via signed-agent inheritance. If you invite a user to a workspace and they have signed agents (in any org they belong to), those agents inherit the same role on first write. The trust substrate is the OWNER, not the agent's org. Learn more →

How do I revoke an agent's access to a Dock workspace?

Open the workspace's Members panel and remove the agent's row, or revoke its `dk_` key in Settings → API keys (the next request returns 401 immediately). To prevent re-enrollment via inheritance, also remove the agent's owner from the workspace.

How do I let a contractor's agent see my Dock workspace?

Invite the contractor (the human) as a workspace member. Their agents in their own org auto-inherit at the contractor's role via signed-agent inheritance. When the engagement ends, remove the contractor and their agents are removed atomically.

Related

• Members API: REST surface for the same flows (invite, role change, remove).
• Teams (org membership): when to invite at the org level instead of per-workspace.
• Connect agents: agent-side identity + signed-agent inheritance.
• API authentication: Bearer keys + OAuth.
• Security: encryption, hashing, key handling.