Get startedCLIAPIMCPWebDesktopAgentsSupportBillingChangelog
Agents · Concepts

Signed-agent inheritance

Every Agent has a required ownerUserId. That link is the accountability substrate: any workspace the owner has membership on, the signed agent inherits at the owner's role. Cross-org included.

Why

Without inheritance, every agent would need its own explicit WorkspaceMember row on every workspace it touches. For an agent serving its owner across 50 workspaces, that's 50 admin operations. Inheritance means: trust the owner, the agent's access follows.

Inversely, when the owner loses access (removed from workspace, removed from org), every agent owned by that user loses access at the same instant, atomic cascade.

Discovery

At LIST time, the agent sees every workspace its owner has access to. No auto-enrollment yet, the agent hasn't written. You can call GET /api/workspaces as the agent and see the full union.

Auto-enrollment on first write

On the agent's FIRST write to a workspace it doesn't already have a membership on:

  1. The system checks: does the agent's owner have access here?
  2. If yes: a WorkspaceMember row is created for the agent with the same role as the owner's effective role (inherited from owner's WorkspaceMember row OR org membership).
  3. The write proceeds.
  4. From that point, attribution points at the AGENT, not the owner. The agent is now a real member.

Cross-org IS the design

If Govind invites Mike (a member of OrgB) to a workspace in Govind's org, Mike's agents in OrgB inherit access to that workspace at Mike's role. The trust substrate is the OWNER, not the agent'sorgId.

Govind extended trust to Mike. Trusting Mike means trusting Mike's tools, which Mike, not Govind, manages. Govind manages Mike: remove Mike, the agents follow.

Inheritance also covers /api/me/sidebar. A signed agent can read and write its OWNER's sidebar sections + workspace assignments, the same way it reads and writes the owner's rows, doc bodies, and members.

Sidebar is a per-user resource (one sidebar per user per org), so the inheritance rule narrows slightly:

  • The agent's orgIdmust match the requested org. An agent in OrgA can only act on its owner's OrgA sidebar, never OrgB's, even if the same human owns agents in both orgs.
  • The OWNER must be an OrgMemberof the requested org. The trust substrate is the owner's membership; if the owner has no access, the agent doesn't either.
  • No consent-token gate. Sidebar mutations don't move money, don't permanently change org state, and don't affect other users, they're reversible by another PUT or a UI drag. Same threshold as rows and doc writes.

This brings sidebar in line with the rest of the surface area. Pre-2026-05-02 the route hard-rejected agent principals, sidebar was the lone holdout in the inheritance contract.

What inheritance does NOT span

Inheritance covers explicit WorkspaceMember rows held by the owner. It does NOT extend org-visibility (the "virtual editor" access on visibility: org workspaces) cross-org.

An agent in OrgA doesn't get virtual editor on OrgB workspaces just because its owner happens to be in both. Cross-org access only flows through explicit WorkspaceMember rows.

Cascade contract

When a user is removed from a workspace OR has their role changed, the cascade in PATCH/DELETE /api/workspaces/[slug]/members/[memberId] updates every agent owned by that user on the same workspace. Atomic in a transaction so the manager UI never sees a window where the user's access has been revoked but the agents linger.

Same for org-level removal: every agent owned by the removed user loses access to every workspace in the org where they were enrolled via inheritance.

How to audit

  • GET /api/workspaces/:slug/members shows every member, including auto-enrolled agents, with the owner attribution visible.
  • The events log shows member.auto_enrolled when an agent gets implicitly added.
  • Every write attributes to the agent's id, with the owner's id available in the event payload for downstream analysis.

Frequently asked questions

What is signed-agent inheritance in Dock?
An agent (a `signed agent` with a required `ownerUserId`) automatically inherits access to every workspace its owner has direct access to. Saves you from minting per-workspace API keys for every agent on every workspace; trust flows from the owner outward.
How does my AI agent get access to workspaces I am a member of?
On the agent's first read or write attempt against your workspace, Dock auto-enrolls the agent at your role (`auto-enrollment on first write`). Subsequent reads/writes attribute to the agent (not you), so the audit trail stays clean.
Can my Dock agent inherit access to workspaces in another org?
Yes. Cross-org is the design. If you're invited to OrgB's workspace, your signed agents in OrgA inherit at your role. The trust substrate is the OWNER, not the agent's `Agent.orgId`. Org-visibility (`visibility: org`) is the one exception; it stays single-org.
What happens to my agent's workspace access when I'm removed from a Dock workspace?
Atomic cascade. The PATCH/DELETE at `/api/workspaces/:slug/members/:memberId` updates every agent owned by you on that workspace in the same transaction. The manager UI never sees a window where you've lost access but your agents still have it.
What is auto-enrollment on first write in Dock?
When a signed agent first writes to a workspace it has inherited access to, Dock creates an explicit `WorkspaceMember` row for the agent at the owner's role. From that point on, attribution stamps the agent (not the owner), and the agent's row in the workspace's Members panel is editable.
Can I disable cross-org agent inheritance for my Dock org?
Yes. Settings → Org → toggle `autoInheritAgents = false`. Existing inherited rows stay; new inheritances stop. Use this for high-security orgs that want explicit per-workspace agent membership only.
How does signed-agent inheritance interact with workspace visibility?
Inheritance follows OWNER's explicit `WorkspaceMember` rows, not org-membership virtual access. So an agent doesn't auto-inherit workspaces its owner only sees via `visibility: org`; the owner needs an explicit membership row for the agent to inherit. Public/unlisted workspaces fall to virtual viewer reads only. Learn more →
If I downgrade a teammate to viewer in Dock, do their AI agents downgrade too?
Yes, atomically. The PATCH at `/api/workspaces/:slug/members/:memberId` cascades the role change to every agent owned by that user on that workspace. Inheritance always tracks the owner's current role; demoting the owner demotes the agent in the same transaction.
What is the cascade rule for Dock agent inheritance?
Owner removed from a workspace → all owned agents removed from that workspace, in one transaction. Owner role changed → all owned agents' roles changed in the same transaction. Auto-enrolled agent rows are durable for exactly as long as the owner row that begat them.
Can I prevent inheritance for a specific Dock agent?
Two options: (1) Toggle the org-level `autoInheritAgents = false` (broadest), (2) Mint a per-workspace `dk_` key for the agent and explicitly add it as a member of only the workspaces you want it to access. The explicit member row wins over inheritance.
Can my Dock agent organize my sidebar, create sections and pin workspaces?
Yes. `/api/me/sidebar` honours signed-agent inheritance, so your agent reads and writes your sidebar the same way it does your rows, doc bodies, and members. The agent must be in the same org as the sidebar (sidebars are per-user-per-org), and your `OrgMember` row gates the operation. No consent token required; sidebar mutations are reversible. Learn more →
Why was my agent getting 403 on /api/me/sidebar before May 2 2026?
Pre-2026-05-02 the route hard-rejected every agent principal, sidebar was the lone holdout in Dock's signed-agent inheritance contract (every other resource already honoured it). The fix resolves agent principals to their `ownerUserId` and gates by the owner's `OrgMember` row, matching the rest of the surface area.
Updated