Feature request: Team and organization support with access management

[moshtaghmaveddat]

Feature request: Team and organization support with access management

Summary

DeepSeek Harness is currently built around a single user on a single machine. I'd like to propose first-class support for using it in teams and organizations. That means people can work together in one deployment, share knowledge, files and skills, and have administrators control who can access what, including which models, tools and workspaces each user or group can use. The main building blocks would be:

• Organizations and users, with roles.
• Groups: sets of users who share resources, with access limited to members.
• Shareable workspaces and skills that can be private, shared with specific people or groups, or visible to the whole organization.
• Resource access control over models, MCP servers/tools and plugins.
• Permissions, admin controls and a monitoring panel across all of the above.

Background

Harness has no concept of multiple users working together. A workspace is a folder on one person's computer (picked with Choose workspace), so there is nothing to share. Nothing separates what different people on the same instance can see or use, and there is no way to give a team its own space for files, skills and context. Companies that want to adopt Harness need a way to manage this.

Proposal

1. Organizations, users and roles

• An organization contains users, groups, workspaces and skills.
• Organization-level roles (Owner, Admin, Member), plus workspace- and group-level roles (Admin, Editor, Viewer).
• Admins can invite, remove and manage users.

2. Groups

• A group is a set of users with shared resources: knowledge, files, skills, tool/plugin access, and credentials such as model keys.
• Only members and invited people can access what the group shares.
• Example: a company creates a Top Managers group containing the CEO, CFO and others. Strategy documents, financial data and the skills built on them are visible only to that group, plus anyone explicitly invited.
• A person may belong to several groups, and groups can be attached to workspaces and skills so access doesn't have to be set person by person.
• Group owners or org admins manage membership and invitations.

3. Shareable workspaces

• Users can create workspaces inside Harness, in addition to the existing option of attaching a local folder.
• Each workspace has a visibility setting:
  • Private: only the owner.
  • Shared: specific users and/or groups, each with a role.
  • Organization-wide: everyone in the organization.
• A workspace holds its own files, instructions, skills, knowledge sources and session history, all following the workspace's access rules.
• Ownership can be transferred, and a workspace can be archived or deleted by its owner or an org admin.

4. Shareable skills

• Skills get the same visibility levels as workspaces: private, shared with specific users or groups (with roles such as Viewer, Editor, Admin), or organization-wide.
• Users can publish a personal skill to a group or to the organization, and the owner or an admin can unpublish it.
• Admins can control who may create, edit or publish skills.

5. Access control for models, MCP servers/tools and plugins

• Admins can define which models each user or group may use. For example, a cheaper model for everyone and a stronger one only for specific groups.
• The same applies to MCP servers and individual MCP tools, and to plugins. Admins decide who can install, enable or use each one, and can maintain an approved list for the organization.
• Credentials (model API keys, MCP server secrets) can be held at the organization or group level, so members can use them without ever seeing the raw values.
• Optional limits per user or group: usage quotas, rate limits and spending caps.

6. Permissions for risky actions

• Permissions should cover at least: viewing and using a workspace, editing its files and config, running commands or tools, installing plugins, managing members, and changing visibility.
• Deny by default for risky capabilities (shell execution, filesystem access, network access), configurable per group or workspace. This relates to BUG: sandbox 内模型可通过 Web approval 回环通道自批准 `danger-full-access` #250 (the sandbox can self-approve danger-full-access), which shows why approvals should be tied to a permission model and not left to the session itself.

7. Admin controls and monitoring panel

• UI pages and dsh commands to manage users, groups, workspaces, skills and resource access.
• Policies as config (YAML/JSON) so they can be versioned and reviewed, which fits the existing profile concept (named compositions of bundles and plugins).
• A monitoring panel for admins showing:
  • Active users, sessions and agents running now.
  • Usage by user, group, workspace and model (tokens, cost, request counts).
  • Tool and MCP call activity, including denied or failed attempts.
  • An audit log of sign-ins, role and sharing changes, plugin or skill installs, and permission-sensitive actions, filterable and exportable (file or webhook).
  • Alerts when quotas are reached or unusual activity is detected.

[heiying0917]

关注

[forestwolf-ai]

关注

[l2999019]

关注