Glossary
The Dock vocabulary.
31 terms used across the product, docs, and blog. Each links into the post that goes deeper, where one exists.
A
- Agent identity
- A first-class user-record for an AI agent. Has its own API key, its own scopes, its own audit trail, and an owning human. Distinct from the human's identity — when the agent acts, the log says the AGENT acted, not the human.
- Why agents need identities →
- Audit log
- Per-workspace ledger of every state-changing action, with the actor named explicitly: agent principal id and owning user id together on the same row. The substrate of accountability when humans and agents share state, and the artifact a regulator, an auditor, or an incident review reaches for to answer the question "who actually did this, the human or their AI?".
- Audit and compliance for AI agents →Auditing agent behavior: a walkthrough →Principal →
- Attribution
- Naming the actor (human or agent) on every state-changing action. In Dock, attribution rides as a dual key (agent principal id + owning user id) on every audit row, so any question about "who did this, the human or their AI" is a query, not a forensic reconstruction.
- Audit log →Audit and compliance for AI agents →Principal →
C
- Cloud 2.0
- The era when humans and AI agents need one shared state, not separate tools trading messages. Articulated by Govind Kavaturi and Mike Molinet. Dock is the first cloud built for it: tables and docs humans and agents read and write together, with first-class agent identity and an audit that names every actor.
- The Cloud 2.0 thesis →
- Component kit
- Free, MIT-licensed UI components Dock ships under the name dock-ui. About 55 React components, copy-paste registry (no npm dependency, no semver), agent-native primitives included (orb, presence stack, comment thread that survives AI rewrites, severity-tinted inbox card). The open-source companion to the product.
- dock-ui home →Browse all 55 components →Why we open-sourced it →GitHub repo →
- Consent gate
- The pattern of refusing to execute a sensitive operation on the first call. The handler returns a confirm token; the agent surfaces it to its user; the user confirms; the agent retries with the token. Used for billing changes and any irreversible op.
- Two-key handshakes for irreversible ops →Consent gates for dangerous ops →
- Capability-based security
- An access-control model where authority is carried by unforgeable references (capabilities) that bundle designation with permission, rather than by ambient privileges granted to a named identity. Foundational to the agents-are-principals framing: an agent holds a narrow capability, not a borrowed human session.
- Agents are principals, not delegated tokens →Robust Composition (Mark Miller thesis) →Principal →
- Consent token
- Single-use, short-TTL token (60 s default) that authorizes one specific dangerous operation. Bound to `{principal, op, params}` so the second call cannot be replayed against a different op or swapped to different params. The mechanism behind the consent gate's two-call handshake.
- Consent gate →Two-key handshake →How to design a dangerous operation →
D
- Dangerous operation
- A short list of MCP tools that move money, widen access, or are irreversible. They never execute on the first call — they require the consent-gate handshake. Today: upgrade_plan, downgrade_plan.
- The dangerous-ops contract →
- Dual-keyed audit
- Audit-log shape where every privileged action carries BOTH the agent principal id and the owning user id. The dual key turns the auditor's question "human or AI, and who is accountable?" into a column on every row, rather than a forensic guess from a single `actor` field.
- Audit log →Audit and compliance for AI agents →Auditing agent behavior: a walkthrough →
F
- Fast-path
- An exception under the dangerous-ops contract: a specific operation that can skip the consent gate when a code-checkable condition holds (e.g., deleting a workspace within 30 s of creation). Documented exceptions, not agent-feels-confident carve-outs.
- Consent gate →Dangerous operation →The dangerous-ops contract →
G
- Grace window
- The overlap during a credential rotation when both the old and new keys are valid (default 15 minutes). Lets a running agent pick up the new key on its next natural credential read without a single failed request. Same pattern AWS IAM applies at hyperscale.
- Rotating agent credentials without downtime →AWS IAM key rotation →Agent lifecycle →
M
- MCP
- Model Context Protocol. The open standard that lets any client (Claude Code, Cursor, Vercel AI, your own SDK) call into a Dock workspace's tools. Dock's MCP server exposes 20 tools at /api/mcp.
- MCP server quickstart →
- MCP tool
- A single callable function exposed over the MCP server. Each tool has typed inputs, typed outputs, and a permission scope. Same allowlist for humans and agents — there is no agent-only or human-only surface.
- Magic link
- Passwordless sign-in flow: the user enters their email, the server emails a signed, single-use URL, clicking the link establishes the session. Dock's primary human auth, layered with invite-only sign-up gating via `canSignUp()` and org-invite tokens.
- Inside the magic-link gate →/docs/security →
- MCP server
- The server half of the Model Context Protocol: exposes a tool catalog to an MCP client (Claude Desktop, Cursor, ChatGPT, custom agents), negotiates capabilities, and executes tool calls under the client's authenticated session. Dock's MCP server runs at `/api/mcp` with ~57 tools.
- MCP →MCP tool →MCP specification →
O
- Org
- A team's container, holding members (humans), agents (scoped to that single org), workspaces, plan, and billing. Users can belong to multiple orgs and the sidebar spans all of them; agents are pinned to exactly one org via `Agent.orgId`, while access can still flow cross-org through signed-agent inheritance when the owning user is a member elsewhere.
- Org member →Signed-agent inheritance →/docs/guides/teams →
- Org member
- A human with an `OrgMember` row, gaining default editor access to every non-private workspace in the org without per-workspace invites. The org-level membership distinct from `WorkspaceMember`, which is per-workspace and supports finer-grained access including agents.
- Org →Workspace member →/docs/guides/teams →
- Owner
- Every signed agent has a required `ownerUserId` — the human accountable for that agent's actions. The accountability substrate that lets us bestow real permissions on non-humans without losing the audit trail.
- Owner cascade
- When a human's access to a workspace or org changes, every agent owned by that human follows in the same transaction. Atomic in the database so the manager UI never sees a window where the human has been revoked but the agent is still acting.
- Signed-agent inheritance →Agent lifecycle →The agent identity lifecycle, from creation to revocation →
P
- Public workspace
- A workspace with `visibility: "public"`. Anyone, signed in or not, can read it; the page is listed in the sitemap and crawlable by search engines and AI clients. The free, read-only tier of Dock and the substrate behind the public blog, docs, and changelog.
- Workspace visibility →Shared workspace →/docs/security →
R
- Row
- A single record inside a Dock table, with typed columns and one cell per column. The same row is visible to a human editing in the UI and to an agent calling `list_rows` or `update_row` over MCP, with every change attributed in the audit log under the actor (human or agent) that made it.
- Surface →MCP tool →Audit log →
S
- Signed agent
- An agent with a verified owner. The signed status is what lets the agent inherit its owner's workspace memberships within the same org. Unsigned agents cannot exist on Dock.
- Signed agent inheritance →
- Signed-agent inheritance
- The rule: any workspace the owning user can act on, the signed agent inherits within the agent's own org. Auto-enrolls on first write so attribution points at the agent, not the owner, from that point forward.
- Surface
- A tab inside a workspace: either a table (typed columns and rows) or a doc (TipTap rich text). One workspace can hold any combination, one or many of either kind, grown over time with `create_surface`. Same access rules, same audit log, same dual-keyed attribution across kinds, so an agent writing to a table row and a human editing a heading both flow through the same accountability gate.
- Row →Doc/Table surface →What is an AI workspace? →
- Shape cap
- Byte, depth, and node-count bound applied at write time on any TipTap doc body. The structural fence that keeps an agent loop from accidentally writing a 200-MB doc or a 10,000-level deep tree. Same limits apply to humans and agents because real prose never trips them.
- Shape caps on TipTap JSON →Doc/Table surface →TipTap →
T
- Theme
- One of four canvas + chrome palettes Dock ships: Light (soft blue-grey paper), Breeze (sky-to-paper gradient with glass surfaces), Dark (deep navy, calm at night), Graphite (greyscale chrome where agent presence is the only saturated color). Set with `data-theme="X"` on `<html>`. Every component in the kit reads from the theme variables.
- All four themes →Light · Sunday-morning theme →Breeze · sky on top, paper at the bottom →Dark · deep navy, calm at night →Graphite · greyscale chrome →
- Two-key handshake
- Slang for the consent-gate flow on a dangerous operation. Two API calls required to execute: the first mints a confirm token bound to `{principal, op, params}` and a short TTL; the second presents the token and executes. The 'two keys' are the agent and the human user, both required to authorize the call.
- Consent gate →Dangerous operation →Two-key handshakes for irreversible agent actions →
W
- Workspace member
- A human or agent with an explicit `WorkspaceMember` row on a single workspace. Used for private workspaces, to elevate or restrict a specific principal, or to grant access that the org-level membership wouldn't otherwise provide. Auto-enrolled for signed agents on first write so attribution points at the agent, not the owner, from that point on.
- Org member →Signed-agent inheritance →Signed agent →
- Workspace visibility
- One of `private`, `org`, `unlisted`, or `public`. Controls who can see the workspace. Org-visible workspaces are accessible to every OrgMember; unlisted are link-shareable but not search-indexed.
- Public workspace →Shared workspace →/docs/security →