Sharing and permissions

d5s uses layered access controls so organization administration, workspace roles, project visibility, and connector execution are not one broad permission.

Workspace roles

Organization owners and admins manage organization identity, members, invitations, groups, audit access, and ownership transfer. Workspace roles grant:

Workspace roles

Role	Main access
Owner	Full workspace control, including members, settings, capabilities, and deletion.
Admin	Manage workspace members, settings, skills, and connectors.
Member	Create and use workspace resources.
Viewer	Read-only workspace access.

An organization can contain multiple workspaces. Organization membership grants access to organization administration and discovery according to the organization role. Active organization Owners and Admins are also automatically Admins of every workspace in the organization, including workspaces created later. This access follows the organization role. It ends when the person becomes a plain member or leaves the organization. A removed Admin who rejoins by accepting a workspace invitation returns as a plain member. An organization Owner or Admin can promote them again. A workspace Owner who is also an organization Owner or Admin stays the workspace Owner. Plain organization membership does not grant access to workspace content. Organization Owners or Admins assign workspace access explicitly to an organization user or group. A group assignment expands to its current members, while retaining the group as the durable source of access.

The same account may hold memberships in organizations from different regions, but memberships and grants apply only in the region where they were made. Opening another region is navigation, not an access grant, and the region switcher does not disclose whether a person has organizations there.

Workspace Owners and Admins can also send workspace invitations, as can organization Owners and Admins. An accepted invitation grants only the selected role in the named workspace. It creates a plain organization membership for a new collaborator and never elevates an existing organization role. Pending invitations are scoped independently to each workspace, and personal workspaces do not accept invitations.

You can ask an agent in a workspace chat to help invite a colleague. Give it the colleague’s email address and, if needed, the workspace role. The agent prepares an invitation suggestion; it cannot send the invitation itself. Select Review invitation to check the workspace, address, role, and any seat terms. Only Send invitation sends it. You can dismiss the suggestion instead. The same invitation permissions and seat rules apply as when inviting from People. If sending fails or the invitation is created without an email, check People before trying again.

In a personal organization, the full member list is visible only to the organization owner; every other member sees only their own entry, and organization groups are visible only to the owner. Collaborators from one workspace are not discoverable by collaborators from another. Organization Owners and Admins use a workspace's Members tab to manage who can open it. The organization entry itself is also masked for everyone but the owner: in another member's organization list it appears as Shared workspaces, without the owner-derived organization name, link slug, or owner identity, while the workspaces they can open stay reachable. A personal organization also has exactly one organization manager: its owner. Collaborators join as plain members; admin invitations and admin promotions are rejected there, and a pre-existing admin invitation is accepted as a plain membership.

Open Settings → People for the organization roster and invitations. To invite someone to a workspace, open Settings from that workspace and confirm the organization before choosing People → Invite people. The action is available only when you can invite to that workspace. If it is missing after switching organizations or opening a saved settings link, return to the intended workspace and open Settings again. Organization Owners and Admins see pending organization-wide and workspace invitations, including when no workspace is selected. Workspace Owners and Admins see only invitations for the workspace from which they opened Settings. A workspace invitation still grants access only to its named workspace. The roster's Workspaces column names the workspaces each person belongs to. Organization Owners and Admins can select a workspace name to open that workspace's Members tab; other members see the names as text.

Workspace access is managed in one place, each workspace's Members tab. The organization's Workspaces list shows every workspace at a glance:

• Settings → Organization → Workspaces lists the portfolio as a table, and is one of the two places a new workspace starts; the other is the Create workspace plus button in the workspace switcher header while you are in that organization, or Create workspace in its Switch organization list while it has none. Creating a workspace requires the organization Owner or Admin role. A plain organization member can open the list to see only accessible workspaces, without the create action or the Access column. Changing the organization selector changes which portfolio you see. Each row shows the workspace name and address, its people and agents, and its owner; organization Owners and Admins also see an Access column with the direct grants and groups. The people and agent stacks show up to three faces each, name each face on hover, and list the names when selected; the count beside them includes the rest. A row for a workspace you are not a member of says Names hidden and does not open. The people count includes the organization's Owners and Admins. The direct count in the Access column does not include their automatic Organization admin access. Select a row to open that workspace's settings.
• Settings → Workspaces → workspace name → Members administers one workspace. It lists the people and groups who can open that workspace and shows how each of them got in; Direct, Local group, Ownership, SCIM, Invitation or Organization admin. Each person has one row. When an organization Owner or Admin also has another grant, the row shows the stronger one. An Owner or Admin grant, such as Ownership, replaces the Organization admin row; a weaker grant stays hidden while the person is an organization Owner or Admin. The Members count is the number of people with access, including people who get in through a group. An organization Owner or Admin can add, re-role, or revoke the grants that were made by hand; the owner's own row and any row marked as managed externally are read-only, so change an owner with a transfer and directory-managed access at its source. An Organization admin row is also read-only and shows Follows organization role. To remove it, change the person's organization role to Member or remove them from the organization. A group row names the group and, where the count is available, how many people it currently carries in. Organization Owners and Admins can open this section for every workspace in the organization.

Open Workspaces, choose a workspace, and use its available General, Members, Browser, Network, and Developers tabs. General is available to workspace members; Members requires an organization Owner or Admin, while Network and Developers require a workspace Owner or Admin. Developers contains API keys. Browser lists the workspace's browser profiles: workspace Owners and Admins manage them, and other members see each profile's status and the agents that can use it. Models is set once for the organization. On a narrow screen, the workspace selector and section dropdown appear in the page body. A plain organization member with only one accessible workspace opens its General page directly from the Workspaces shortcut.

If agents show Computer, workspace settings omit the separate Browser tab. Agents that still use saved browsers retain Manage saved browsers and their existing access rules. If Storage is available, workspace owners and admins can inspect computer storage usage there.

Changing a workspace display name is available to that workspace's Owner and Admin roles under Workspaces → workspace name → General → Workspace details. It does not change the slug or links. Organization Owners and Admins are Admins of every workspace, so they can also rename it here. Other members see the name and address as text, and General shows them no Danger zone. The organization's Workspaces page has no rename control.

Workspace deletion follows the workspace roles. A workspace Owner or Admin can review the content to be deleted and cancel a scheduled deletion during the 48-hour window. Only the current workspace Owner can request the email verification code and schedule deletion. Organization Owners and Admins can review and cancel as workspace Admins. They cannot schedule deletion unless they are the workspace Owner. Content can remain in the workspace when deletion is scheduled. Personal workspaces cannot be deleted.

Billing, usage, and audit administration are organization-scoped today and require an organization Owner or Admin. This includes submitting or retrieving an eligible consumer withdrawal for that organization's subscription. Team seat limits are separate from workspace access grants; inviting a collaborator to a personal organization's shared workspace does not turn that guest into a billable seat. For teams that purchase seats upfront, an invitation to the organization or one of its workspaces claims Team capacity, so it is refused once active members plus pending invitations fill the effective seat quantity. Increase capacity or withdraw a pending invitation before trying again. If your team uses seats on joining, a new seat requires an organization Owner or Admin to review and authorize its joining charge or free offer and its individual monthly price before sending. Workspace Owner or Admin access alone does not grant that billing authority. A pending authorized invitation carries no charge; acceptance adds any needed seat after payment succeeds or the authorized waiver applies. An expired free offer cannot become a paid seat without fresh authorization. Inviting somebody who is already an active member of that organization adds workspace access without claiming another seat. See Plans and credits.

Workspace usage statistics show administrative totals, not project or conversation content. Seeing a workspace in this view does not grant access to its work. Inspect run also requires current access to the source conversation; an unavailable record does not reveal private details.

Ownership transfer is an explicit operation. An admin cannot silently acquire the owner's billing and deletion powers by editing their own role. Transfer a single workspace from Settings → Workspaces → workspace name → General → Danger zone → Transfer ownership. The transfer requires an organization Owner or Admin, so the row appears only for them; a workspace's own Owner cannot transfer it without that organization role. You name the new owner and confirm before the workspace changes hands.

Project access

Projects and active agents inherit workspace access by default. Project sharing has two general-access modes:

• Everyone in workspace inherits access from workspace membership.
• Restricted relies on explicit grants while retaining the administrative access needed to operate the workspace safely.

Removing access to a source Project or chat prevents new reads from that source. It does not recall information already shared with another agent or chat. Access to that receiving chat still controls who can read its saved messages.

Explicit grants can target people or organization groups and use these resource roles:

Project roles

Role	Main access
Owner	Full resource control, including sharing and deletion.
Editor	Edit the resource and run agents with attached capabilities.
Viewer	Read-only resource access.

In a personal organization, any share manager who is not the personal-organization owner, including a workspace Owner or Admin or a project Owner, can grant project access only to people who already have access to that workspace and cannot target organization groups. The personal-organization owner can manage grants across the whole portfolio, including active organization members and groups.

Sharing is project-centered. Sessions, automations, dashboards, and an agent's conversation inherit through their owning project instead of keeping separate child sharing policies. When a project is archived or deleted, that affects the contained work as a unit.

Named agents and selective Project reads keep the current requester's permissions. A destination chat must also be permitted to show the selected context to its readers. Choosing an agent does not grant the requester the owner's permissions. Agents can exchange requests and results across Projects shared with the workspace. A request that includes Restricted context must respect access to that context in the receiving conversation. Moving a chat to another Project does not grant its new readers access to context from a former Restricted Project.

If access to required context is removed, an affected response can become unavailable in conversation history and Inspect run. A link from an agent's Home conversation still requires current access to the Project work.

Private agent setup

Agent drafts and setup history are visible only to the person preparing them. Draft agents do not appear in ordinary agent lists. Channel setup during drafting still requires the normal administrator permissions. After activation, ordinary agent access applies; setup history stays private to its creator.

Capability policy

Project access answers “may this person work here?” Capability policy answers “may a run perform this action?” They are both required.

• Workspace roles control who can manage connector credentials and install skills.
• Project Owner or Editor access controls who can attach approved capabilities and run the project.
• Connector activation selects which workspace credential the project may use.
• Tool policy decides whether the operation is allowed, asks for approval, or is denied.
• The external service applies its own account permissions last.

This means sharing a project does not expose raw credentials and does not turn a denied connector write into an allowed one. Workspace API keys also act within one workspace and remain tied to the current access of their creator.

Personal desktop folders

Local folder grants belong to the person who authorized them on a particular Mac. Sharing an agent does not share these grants. Choose Read only, Write only, or Both separately for each folder. Content read into a conversation follows that conversation's sharing permissions. See Local files.