When we shipped agent identities at Dock, we hit an immediate question: what does the agent have access to by default?
The literal answer is "nothing — explicit grants only." That's the safe default and we still ship it for write access. But for read access, the literal answer creates an annoying onboarding problem. The user adds Argus as their agent. Argus is in 0 workspaces. The user has to manually add Argus to every workspace they want it to help with. That's friction the user pays for setting up an agent — and the friction is high enough that some users abandon the agent before it does anything useful.
We needed a softer default for reads. The rule we landed on is signed-agent inheritance, and once we shipped it, the agent system felt correct in a way it hadn't before.
This piece is the rule, the boundary, and what it unlocks.
The rule
Any workspace the owner can see, the signed agent can see — within the agent's org.
That's it. Three properties:
- The agent has a stable owner. Argus is owned by Govind. Every agent has exactly one owner.
- The owner has an access list. Govind can see every workspace where he's a member, plus every public/org-visible workspace in his orgs.
- The agent inherits the owner's read access, but only to workspaces in the agent's org.
The rule is read-only by default. The agent can see everything its owner can see (within the agent's org). It cannot write anywhere unless explicitly granted editor or admin role on a specific workspace.
The boundary
The phrase "within the agent's org" is doing a lot of work. Without it, the rule would have a serious problem.
A human user can be a member of multiple orgs. Govind is in three: Vector Apps (his company), an external customer org where he's been invited, and a side-project org with friends. Each org has its own membership rules and its own data.
If Argus inherited Govind's full access list, Argus would have read access to all three orgs. Argus could read Vector Apps's strategic docs and the external customer's confidential notebook and the side project. From the customer's perspective, this is bad: they invited Govind, not Govind's agent. From the side-project friends' perspective, this is bad: they didn't sign up to share with someone's automated tool.
The fix is the org boundary. Argus is created in Vector Apps's org. Argus's org_id = vector_apps. The inheritance rule says "Argus inherits Govind's access to Vector Apps workspaces, full stop." Argus does not see the external customer org. Does not see the side-project org. Even though Govind can.
This is the difference between transitive trust (which spirals into surveillance) and bounded inheritance (which is the right shape for delegated agents).
Why this is a soft default and not a hard rule
The inheritance is a soft default for reads. The user can override it. If Govind wants Argus to not see a particular workspace in Vector Apps, he can revoke the inheritance for that workspace. Concretely: he can mark the workspace as private with explicit member lists that don't include Argus.
The override is the safety valve. The default makes onboarding painless; the override handles the cases where the default isn't right.
For writes, there is no inheritance. Every write requires Argus to be a member with editor or admin role on the specific workspace. The asymmetry is deliberate: reads are recoverable (the agent saw something it shouldn't have, you fix the access list), writes are not (the agent wrote something it shouldn't have, you have to undo it).
What this unlocks
A few things became possible once the rule was in place:
Agent onboarding shrank to one step. The user creates Argus. Argus is immediately useful — it can read the workspaces the user is in, search across them, suggest things, draft against existing material. The user doesn't have to add Argus to ten workspaces before the agent does anything.
Cross-workspace search worked. "Argus, find the launch brief from last quarter" — Argus searches across the user's Vector Apps workspaces and finds it. Without inheritance, the search would have to be scoped to the agent's explicit workspaces, which would always be a subset of the user's.
Multi-workspace tasks composed. "Argus, read the Q4 plan from the strategy workspace and draft tasks in the engineering workspace." Argus has read access to strategy (via inheritance) and write access to engineering (via explicit grant). The task composes cleanly.
The org boundary felt right. Customers in shared external orgs trust that their data isn't bleeding into the user's personal agents. The agent is a member of one org; the inheritance is bounded to that org.
The implementation shape
In the database, this is two queries that compose:
-- Workspaces the owner can see
SELECT workspace_id FROM workspace_member WHERE user_id = :owner_id
UNION
SELECT id FROM workspace WHERE org_id IN (
SELECT org_id FROM org_member WHERE user_id = :owner_id
) AND visibility IN ('org', 'public');
-- Filtered by the agent's org
... AND org_id = :agent_org_id
The function that lists workspaces accessible to an agent is the same function that lists workspaces accessible to a human, plus the org filter. We call it listAccessibleWorkspaceIds(principal) and it takes either a human or an agent — the difference is just whether to apply the agent-org filter.
Centralizing this in one function matters. We covered the principle in AI-agent-first primitives — building access in the substrate so every surface gets it. Inheritance has to be in the access function, or it'll drift across the dozen routes that need to enforce it.
What inheritance is not
A few things this rule deliberately doesn't do:
It doesn't transit through other principals. Argus inherits from Govind. It does not inherit from "anyone Govind can see," because that would let Argus read Mike's workspaces (Mike being a teammate Govind can see). The inheritance has exactly one hop: agent → owner. Not agent → owner → other people.
It doesn't escalate writes. No matter how confident the agent is, no matter how clearly the inherited reads suggest the agent should write somewhere, the agent doesn't get write access by inheritance. Write requires an explicit grant.
It doesn't survive a permission change. If Govind loses access to a Vector Apps workspace, Argus immediately loses access too. The inheritance is computed live, not snapshotted. There is no "Argus had access yesterday, has it today."
It doesn't apply to other agents. Argus inherits from Govind, not from Scout (another agent). Agent-to-agent inheritance would create chains that are hard to reason about. We keep it strictly agent → human.
Why this matters for trust
The agent inherits its owner's view because the owner is responsible for the agent. If the agent does something with an inherited read that the owner shouldn't have shared, the owner is on the hook — not the org, not the agent vendor, not the platform. The accountability follows the inheritance line.
This shapes how owners think about agent permissions. They are not granting "their company" access to their data; they are granting their personal automated tool access. The trust model is different from a generic API integration.
We've found this is the right model for individuals running their own agents. For org-wide agents (a "shared customer-success agent" used by everyone in the org), the model is different — they're owned by the org, not a person, and inheritance doesn't apply the same way. We don't ship those yet; when we do, the rule will be different.
The phrase that captures it
The shorthand we use internally: the agent sees what its owner can see, where the agent lives.
The owner is Govind. The agent lives in Vector Apps. So Argus sees Vector Apps workspaces Govind can see — the intersection of those two sets. Not more, not less.
Once you say it this way, the rule is obvious. Getting there required ruling out the wrong defaults: full inheritance (too leaky), zero inheritance (too painful), explicit-only (too brittle). The rule that survived all three is the one we ship.
Cross-links
- AI-agent-first primitives — the broader pattern of building access into the substrate.
- Why agents need their own identities — the prerequisite for agent membership.
- OAuth scopes for agents — how this composes with workspace-scoped grants.
FAQ
What is signed-agent inheritance?
A read-access rule: any workspace the owner can see, the signed agent can see — within the agent's org. The agent inherits the owner's view bounded by the org boundary. Writes are not inherited; they require explicit per-workspace grants.
Why is the org boundary necessary?
Without it, an agent would inherit access to every org its owner is a member of, including external customer orgs and side-project orgs. That breaks the trust model — a customer who invited Govind didn't invite Govind's automated tool. The org boundary keeps the inheritance scoped to the agent's home.
Why is read inherited but not write?
Reads are recoverable (you fix the access list and the agent stops seeing it); writes are not (the agent wrote something, you have to undo it). The asymmetry matches the cost of mistakes.
Can the user override the inheritance?
Yes. The user can mark specific workspaces as private with explicit member lists that exclude the agent, or revoke the agent's access to a specific workspace. The default is permissive for usability; the override is the safety valve.
Does inheritance work across agents?
No. Argus inherits from Govind, not from Scout. Agent-to-agent inheritance would create chains that are hard to reason about. The rule has exactly one hop: agent → owner.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Signed-agent inheritance",
"description": "One access rule that made the whole agent system feel correct: any workspace the owner can see, the signed agent can see, within the agent's org.",
"datePublished": "2026-04-26",
"author": { "@type": "Person", "name": "Govind" },
"publisher": { "@type": "Organization", "name": "Dock", "url": "https://trydock.ai" },
"image": "https://trydock.ai/blog-mockups/style-d-dreamscape/signed-agent-inheritance.webp",
"mainEntityOfPage": "https://trydock.ai/blog/signed-agent-inheritance"
}