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. Inside a workspace, the generated role catalog grants:

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, but it 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 each region evaluates only its local memberships and workspace grants. 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.

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 — use a workspace's own Members section to see who can open that workspace. 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.

There are two places to manage those assignments, and they read and write the same grants:

• Settings → Organization · organization name → Workspaces administers the whole portfolio, 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 first workspace in its Switch organization list while it has none. Both require the organization Owner or Admin role, so a plain organization member sees neither. Changing the organization selector changes which portfolio you see. Each workspace card shows aggregate people and agent counts. When the administrator can also open that workspace, the card includes up to three named people and three named agents, using their workspace identities, with an additional-count badge for the rest. An organization Owner or Admin who is not a member of that workspace sees only the counts and a names-hidden notice; organization administration alone never reveals its roster.
• Settings → Workspace settings → 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 or Invitation. 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. A group row names the group and, where the count is available, how many people it currently carries in. This section is only reachable to an administrator who can already open the workspace — an organization Owner or Admin without a grant of their own uses the organization's Workspaces page.

The Workspace · workspace name heading in the sidebar, and the workspace switcher in the settings page body (top right on a wide screen, beneath the section tag on a narrow one), both select which workspace's General, Members, Models, Network, or API Keys sections you administer; choosing another from the organization Workspaces page opens that workspace's settings.

Changing a workspace display name is available to that workspace's Owner and Admin roles under Workspace settings → General → Workspace details. It does not change the slug or links. Organization Owners and Admins without a workspace grant can manage its portfolio access, but they cannot open this setting or rename the workspace.

Workspace deletion keeps the same explicit-access boundary. A workspace Owner or Admin can inspect the readiness blockers and can cancel a scheduled deletion. Only the current workspace Owner can request the email verification code and schedule deletion. An organization Owner or Admin without an explicit grant to that workspace cannot use those controls. 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 read organization-scoped ledger attribution and current workspace names, not project or conversation content. Seeing a workspace in that administrative breakdown does not grant the administrator access to work inside it. Inspect run rechecks both organization billing authority and the source conversation's current project and audience permissions; unavailable and unauthorized traces look the same.

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 → Workspace settings → General → Danger zone → Transfer workspace ownership, or from the Manage access dialog on the organization's Workspaces page. Both require an organization Owner or Admin — a workspace's own Owner cannot transfer it without that organization role — and both ask you to name the new owner and confirm before the workspace changes hands. Only the organization's Workspaces page is available to an administrator who cannot open the workspace themselves.

Project access

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.

Explicit grants can target people or organization groups and use the generated 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.

Private agent setup

Conversational creation drafts and their setup history are visible only to the person preparing the agent. A draft identity and its home project are excluded from ordinary agent and project listings. Channel setup during drafting remains subject to the channel’s normal administrator requirements. After activation, ordinary agent access applies; the original 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.