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 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.

Use Settings → Organization · organization name → Workspaces to manage those assignments. Changing the organization selector changes the portfolio being administered; changing the workspace selector changes only the workspace-scoped settings below it.

Billing, usage, and audit administration are organization-scoped today and require an organization Owner or Admin. The shared catalog marks its billing-only workspace role as future, so it is not shown above as current access.

Ownership transfer is an explicit operation. An admin cannot silently acquire the owner's billing and deletion powers by editing their own role.

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.

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.

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.