Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-21 01:25:28 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #3855] [FEAT]: Workspace specific agent skills #2463

New Issue
Open
opened 2026-02-22 18:29:46 -05:00 by yindo · 7 comments
yindo commented 2026-02-22 18:29:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @stentorianjoe on GitHub (May 20, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3855

What would you like to see?

Expansion on #2970 (Workspace-assigned Custom Skills);

Current implementation requires the MCP tool flow to manage auth to the external service in the chat context using tool parameters, or via global env supplied in AnythingLLM config that authorizes all Agent enabled Threads across all Workspaces for each configured MCP server.

Design-Agnostic - MCP Client Session per Workspace/User/Thread rather than per Server, with associated management - possible stepping stone could be to limit available tools in a Workspace according to an 'Enabled Tools' dictionary filtered upon registration to the MCP servers.

Would further enable RBAC for different users to have access to different MCP servers/tools based on their AnythingLLM User and/or Workspace.

Originally created by @stentorianjoe on GitHub (May 20, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3855 ### What would you like to see? Expansion on #2970 (Workspace-assigned Custom Skills); Current implementation requires the MCP tool flow to manage auth to the external service in the chat context using tool parameters, or via global env supplied in AnythingLLM config that authorizes all Agent enabled Threads across all Workspaces for each configured MCP server. Design-Agnostic - MCP Client Session per Workspace/User/Thread rather than per Server, with associated management - possible stepping stone could be to limit available tools in a Workspace according to an 'Enabled Tools' dictionary filtered upon registration to the MCP servers. Would further enable RBAC for different users to have access to different MCP servers/tools based on their AnythingLLM User and/or Workspace.
yindo added the enhancementfeature request labels 2026-02-22 18:29:46 -05:00
yindo commented 2026-02-22 18:29:47 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (May 20, 2025):

https://github.com/Mintplex-Labs/anything-llm/issues/2970
and
https://github.com/Mintplex-Labs/anything-llm/pull/3799

Would cover the scope of this :+1

@timothycarambat commented on GitHub (May 20, 2025): https://github.com/Mintplex-Labs/anything-llm/issues/2970 and https://github.com/Mintplex-Labs/anything-llm/pull/3799 Would cover the scope of this :+1
yindo commented 2026-02-22 18:29:47 -05:00
Author
Owner
Copy Link
Copy Source

@stentorianjoe commented on GitHub (May 23, 2025):

https://github.com/Mintplex-Labs/anything-llm/issues/2970
and
https://github.com/Mintplex-Labs/anything-llm/pull/3799

Would cover the scope of this :+1

The end result seems similar, but because MCP clients need to manage unique streaming sessions (currently per-instance of AnythingLLM) it is unclear how this should be handled, and its implementation may be very different to those (adding a parameter to the request, spawning sessions based on thread or workspace).

Had a debate with myself whether to add it to #2970 but decided to separate concerns. How is this being done in #3799?

@stentorianjoe commented on GitHub (May 23, 2025): > https://github.com/Mintplex-Labs/anything-llm/issues/2970 > and > https://github.com/Mintplex-Labs/anything-llm/pull/3799 > > Would cover the scope of this :+1 The end result seems similar, but because MCP clients need to manage unique streaming sessions (currently per-instance of AnythingLLM) it is unclear how this should be handled, and its implementation may be very different to those (adding a parameter to the request, spawning sessions based on thread or workspace). Had a debate with myself whether to add it to #2970 but decided to separate concerns. How is this being done in #3799?
yindo commented 2026-02-22 18:29:47 -05:00
Author
Owner
Copy Link
Copy Source

@RobMaye commented on GitHub (Jun 6, 2025):

Would love to see this too.

@RobMaye commented on GitHub (Jun 6, 2025): Would love to see this too.
yindo commented 2026-02-22 18:29:47 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jun 6, 2025):

Since MCPs are just skills, this should be just any skills not just MCP. It winds up being the same thing but less specific and more useful

@timothycarambat commented on GitHub (Jun 6, 2025): Since MCPs are just skills, this should be just _any skills_ not just MCP. It winds up being the same thing but less specific and more useful
yindo commented 2026-02-22 18:29:47 -05:00
Author
Owner
Copy Link
Copy Source

@roller100 commented on GitHub (Jul 21, 2025):

MCP Workspace-Specific Authentication: RBAC Use Case Summary

Executive Summary

This document outlines a critical security requirement for Model Context Protocol (MCP) implementations in enterprise environments: workspace-specific agent skills with proper RBAC pass-through authentication. The current limitation where all workspaces share global MCP configurations creates significant security vulnerabilities and compliance risks that block enterprise adoption.

The Problem: Shared Credentials Across All Workspaces

Current AnythingLLM MCP Implementation

// Global configuration applies to ALL workspaces and users
{
  "mcpServers": {
    "neo4j-server": {
      "command": "neo4j-mcp-server",
      "env": {
        "NEO4J_URI": "bolt://neo4j.company.com:7687",
        "NEO4J_USERNAME": "admin",       // 🚨 EVERYONE GETS ADMIN ACCESS
        "NEO4J_PASSWORD": "admin-secret" // 🚨 SHARED CREDENTIALS
      }
    }
  }
}

Security Vulnerabilities

  • ❌ RBAC Bypass: All database-level access controls are rendered useless
  • ❌ Audit Trail Corruption: All actions appear as single shared user
  • ❌ Privilege Escalation: Read-only users gain admin access
  • ❌ Cross-Environment Access: Development users can access production data
  • ❌ Compliance Violations: GDPR, SOX, HIPAA access control requirements not met

Use Case: Neo4j Database with Proper RBAC

Scenario

Development team uses AnythingLLM with Neo4j MCP server to query knowledge graph database:

  • Alice (Data Analyst): Should have read-only access to customer and product data
  • Bob (Developer): Should have read-write access to development schema only
  • Charlie (Admin): Should have full administrative access

What Should Happen: Per-User Authentication

// Alice's workspace configuration
{
  "user": "alice@company.com",
  "workspace": "analytics",
  "mcpServers": {
    "neo4j-server": {
      "env": {
        "NEO4J_USERNAME": "alice",
        "NEO4J_PASSWORD": "alice-secret"
        // Alice's Neo4j role: READ-ONLY on customer, product nodes
      }
    }
  }
}

// Bob's workspace configuration  
{
  "user": "bob@company.com",
  "workspace": "development",
  "mcpServers": {
    "neo4j-server": {
      "env": {
        "NEO4J_USERNAME": "bob",
        "NEO4J_PASSWORD": "bob-secret"
        // Bob's Neo4j role: READ-WRITE on development schema only
      }
    }
  }
}

Database-Side RBAC (Already Configured)

-- Alice: Read-only analyst role
CREATE USER alice SET PASSWORD 'alice-secret';
GRANT ROLE analyst TO alice;  -- Can only READ customer, product data

-- Bob: Developer role  
CREATE USER bob SET PASSWORD 'bob-secret';
GRANT ROLE developer TO bob;  -- READ-WRITE on development schema only

-- Charlie: Admin role
CREATE USER charlie SET PASSWORD 'charlie-secret'; 
GRANT ROLE admin TO charlie;  -- Full access

Current State of MCP OAuth 2.1 Specification

What OAuth 2.1 DOES Provide

  • ✅ Standardized Authentication: OAuth flows for MCP servers
  • ✅ User-Specific Tokens: Individual access tokens per user
  • ✅ Scoped Access Control: OAuth scopes for permission boundaries
  • ✅ Secure Token Management: Proper storage and validation

What OAuth 2.1 DOESN'T Solve

  • ❌ Database MCP Servers: Most database MCP servers use native authentication (not OAuth)
  • ❌ Workspace Boundaries: No mechanism for client-side credential isolation
  • ❌ AnythingLLM Architecture: Still requires global MCP configuration

Key Insight

MCP OAuth 2.1 provides building blocks but doesn't solve the fundamental client-side workspace isolation problem.

Required Solution: GitHub Issue #3855

Feature Request: Workspace-Specific Agent Skills

GitHub Issue #3855 requests:

  1. MCP Client Sessions per Workspace: Instead of global MCP server configurations
  2. User/Workspace-Specific Tool Filtering: Different available tools per context
  3. RBAC Integration: Role-based access to different MCP servers/tools

Technical Implementation Needs

interface WorkspaceMCPConfig {
  workspaceId: string;
  userId: string;
  mcpServers: {
    [serverId: string]: {
      command: string;
      args: string[];
      env: Record<string, string>;  // User-specific credentials
      enabledTools?: string[];     // Workspace-specific tool filtering
    }
  };
}

Business Impact

Without This Feature

  • Enterprise Adoption: Restricted enterprise adoption as RBAC is vital
  • Security Audit Failures: Cannot demonstrate proper access controls to auditors or security teams
  • Compliance Risks: Regulatory violations (GDPR, SOX, HIPAA, BCBS239) due to improper access controls
  • Data Breach Exposure: Users accessing data beyond authorized scope, creating liability
  • Insurance/Legal Issues: Cyber insurance may not cover breaches due to inadequate access controls

With This Feature

  • ✅ Proper RBAC: Database-level permissions enforced
  • ✅ Audit Compliance: Individual user actions tracked
  • ✅ Enterprise Ready: Meets security requirements for deployment
  • ✅ Universal Application: Works with any RBAC-enabled system

Broader Applicability

This use case affects any MCP server connecting to systems with existing RBAC:

  • Databases: PostgreSQL, MySQL, MongoDB, Neo4j
  • APIs: REST/GraphQL APIs with role-based access
  • Cloud Services: AWS, Azure, GCP with IAM controls
  • Enterprise Systems: CRM, ERP, ITSM platforms

Recommendation

Priority: CRITICAL - This is a security requirement that blocks enterprise MCP adoption

Implementation Path:

  1. Short-term: Support per-workspace MCP configurations in AnythingLLM (addresses GitHub Issue #3855)
  2. Medium-term: Implement user-specific credential management and RBAC integration
  3. Long-term: Full RBAC integration with enterprise identity providers (Entra ID, LDAP, SAML)

Related Issues:

  • GitHub Issue #3855: Workspace-specific agent skills
  • This use case provides the concrete security rationale for why #3855 is not just a convenience feature but a critical security requirement

Conclusion

The workspace-specific agent skills feature (GitHub Issue #3855) is not just a convenience enhancement - it's a fundamental security requirement for enterprise MCP deployment. Without proper credential isolation and RBAC pass-through, MCP implementations cannot meet basic security and compliance standards required by regulated industries.

The Neo4j use case demonstrates this requirement clearly: database systems already have proper RBAC configured, but AnythingLLM's global MCP configuration bypasses these controls entirely, creating unacceptable security risks. This same pattern affects any system with existing RBAC - making AnythingLLM unsuitable for enterprise deployment until workspace-specific MCP configurations are implemented.

@roller100 commented on GitHub (Jul 21, 2025): # MCP Workspace-Specific Authentication: RBAC Use Case Summary ## Executive Summary This document outlines a critical security requirement for Model Context Protocol (MCP) implementations in enterprise environments: **workspace-specific agent skills with proper RBAC pass-through authentication**. The current limitation where all workspaces share global MCP configurations creates significant security vulnerabilities and compliance risks that block enterprise adoption. ## The Problem: Shared Credentials Across All Workspaces ### Current AnythingLLM MCP Implementation ```json // Global configuration applies to ALL workspaces and users { "mcpServers": { "neo4j-server": { "command": "neo4j-mcp-server", "env": { "NEO4J_URI": "bolt://neo4j.company.com:7687", "NEO4J_USERNAME": "admin", // 🚨 EVERYONE GETS ADMIN ACCESS "NEO4J_PASSWORD": "admin-secret" // 🚨 SHARED CREDENTIALS } } } } ``` ### Security Vulnerabilities - **❌ RBAC Bypass**: All database-level access controls are rendered useless - **❌ Audit Trail Corruption**: All actions appear as single shared user - **❌ Privilege Escalation**: Read-only users gain admin access - **❌ Cross-Environment Access**: Development users can access production data - **❌ Compliance Violations**: GDPR, SOX, HIPAA access control requirements not met ## Use Case: Neo4j Database with Proper RBAC ### Scenario Development team uses AnythingLLM with Neo4j MCP server to query knowledge graph database: - **Alice (Data Analyst)**: Should have read-only access to customer and product data - **Bob (Developer)**: Should have read-write access to development schema only - **Charlie (Admin)**: Should have full administrative access ### What Should Happen: Per-User Authentication ```json // Alice's workspace configuration { "user": "alice@company.com", "workspace": "analytics", "mcpServers": { "neo4j-server": { "env": { "NEO4J_USERNAME": "alice", "NEO4J_PASSWORD": "alice-secret" // Alice's Neo4j role: READ-ONLY on customer, product nodes } } } } // Bob's workspace configuration { "user": "bob@company.com", "workspace": "development", "mcpServers": { "neo4j-server": { "env": { "NEO4J_USERNAME": "bob", "NEO4J_PASSWORD": "bob-secret" // Bob's Neo4j role: READ-WRITE on development schema only } } } } ``` ### Database-Side RBAC (Already Configured) ```cypher -- Alice: Read-only analyst role CREATE USER alice SET PASSWORD 'alice-secret'; GRANT ROLE analyst TO alice; -- Can only READ customer, product data -- Bob: Developer role CREATE USER bob SET PASSWORD 'bob-secret'; GRANT ROLE developer TO bob; -- READ-WRITE on development schema only -- Charlie: Admin role CREATE USER charlie SET PASSWORD 'charlie-secret'; GRANT ROLE admin TO charlie; -- Full access ``` ## Current State of MCP OAuth 2.1 Specification ### What OAuth 2.1 DOES Provide - ✅ **Standardized Authentication**: OAuth flows for MCP servers - ✅ **User-Specific Tokens**: Individual access tokens per user - ✅ **Scoped Access Control**: OAuth scopes for permission boundaries - ✅ **Secure Token Management**: Proper storage and validation ### What OAuth 2.1 DOESN'T Solve - ❌ **Database MCP Servers**: Most database MCP servers use native authentication (not OAuth) - ❌ **Workspace Boundaries**: No mechanism for client-side credential isolation - ❌ **AnythingLLM Architecture**: Still requires global MCP configuration ### Key Insight **MCP OAuth 2.1 provides building blocks but doesn't solve the fundamental client-side workspace isolation problem.** ## Required Solution: GitHub Issue #3855 ### Feature Request: Workspace-Specific Agent Skills [GitHub Issue #3855](https://github.com/Mintplex-Labs/anything-llm/issues/3855) requests: 1. **MCP Client Sessions per Workspace**: Instead of global MCP server configurations 2. **User/Workspace-Specific Tool Filtering**: Different available tools per context 3. **RBAC Integration**: Role-based access to different MCP servers/tools ### Technical Implementation Needs ```typescript interface WorkspaceMCPConfig { workspaceId: string; userId: string; mcpServers: { [serverId: string]: { command: string; args: string[]; env: Record<string, string>; // User-specific credentials enabledTools?: string[]; // Workspace-specific tool filtering } }; } ``` ## Business Impact ### Without This Feature - **Enterprise Adoption**: Restricted enterprise adoption as RBAC is vital - **Security Audit Failures**: Cannot demonstrate proper access controls to auditors or security teams - **Compliance Risks**: Regulatory violations (GDPR, SOX, HIPAA, BCBS239) due to improper access controls - **Data Breach Exposure**: Users accessing data beyond authorized scope, creating liability - **Insurance/Legal Issues**: Cyber insurance may not cover breaches due to inadequate access controls ### With This Feature - **✅ Proper RBAC**: Database-level permissions enforced - **✅ Audit Compliance**: Individual user actions tracked - **✅ Enterprise Ready**: Meets security requirements for deployment - **✅ Universal Application**: Works with any RBAC-enabled system ## Broader Applicability This use case affects **any MCP server connecting to systems with existing RBAC**: - **Databases**: PostgreSQL, MySQL, MongoDB, Neo4j - **APIs**: REST/GraphQL APIs with role-based access - **Cloud Services**: AWS, Azure, GCP with IAM controls - **Enterprise Systems**: CRM, ERP, ITSM platforms ## Recommendation **Priority**: **CRITICAL** - This is a **security requirement** that blocks enterprise MCP adoption **Implementation Path**: 1. **Short-term**: Support per-workspace MCP configurations in AnythingLLM (addresses GitHub Issue #3855) 2. **Medium-term**: Implement user-specific credential management and RBAC integration 3. **Long-term**: Full RBAC integration with enterprise identity providers (Entra ID, LDAP, SAML) **Related Issues**: - GitHub Issue #3855: Workspace-specific agent skills - This use case provides the **concrete security rationale** for why #3855 is not just a convenience feature but a critical security requirement ## Conclusion The workspace-specific agent skills feature (GitHub Issue #3855) is not just a convenience enhancement - it's a **fundamental security requirement** for enterprise MCP deployment. Without proper credential isolation and RBAC pass-through, MCP implementations cannot meet basic security and compliance standards required by regulated industries. The Neo4j use case demonstrates this requirement clearly: database systems already have proper RBAC configured, but AnythingLLM's global MCP configuration bypasses these controls entirely, creating unacceptable security risks. This same pattern affects **any system with existing RBAC** - making AnythingLLM unsuitable for enterprise deployment until workspace-specific MCP configurations are implemented.
yindo commented 2026-02-22 18:29:47 -05:00
Author
Owner
Copy Link
Copy Source

@HanJammer commented on GitHub (Nov 10, 2025):

Absolutely agree.

That's one of the most important things to implement actually. Without it the multi-user mode is seriously impacted for anything but the most basic use cases with read-only tools.

@HanJammer commented on GitHub (Nov 10, 2025): Absolutely agree. That's one of the most important things to implement actually. Without it the multi-user mode is seriously impacted for anything but the most basic use cases with read-only tools.
yindo changed title from [FEAT]: Workspace specific agent skills to [GH-ISSUE #3855] [FEAT]: Workspace specific agent skills 2026-06-05 14:46:42 -04:00
yindo commented 2026-06-05 14:46:43 -04:00
Author
Owner
Copy Link
Copy Source

@miraculix95 commented on GitHub (May 18, 2026):

Adding a concrete production use-case + implementation thought to push this forward.

Use-Case

I'm running a multi-tenant RAG setup with a self-hosted vector database (pgvector) exposed via a custom MCP server. Each customer/workspace needs auth-scoped access to their own data only. Today this is blocked because:

  1. anythingllm_mcp_servers.json is loaded globally — every workspace sees the same MCP servers with the same env (auth tokens included)
  2. System prompts cannot enforce workspace isolation — prompt injection trivially makes the agent ignore "only use workspace X" instructions
  3. The only workaround is one AnythingLLM instance per customer (Docker replication, separate Caddy routes, separate auth setups) — which doesn't scale economically beyond a handful of customers

This is a real blocker for serious multi-tenant deployments — exactly the scenarios where AnythingLLM as a SaaS-style frontend would shine.

Suggested Implementation Direction

Following the design hint from the issue body, the minimal version could be:

  • Add allowed_mcp_servers (JSON array) to the workspace settings schema in Prisma
  • New API endpoint PUT /workspace/:slug/mcp-servers for admins to scope per workspace
  • New Frontend section in workspace settings: multi-select of available MCP servers
  • On agent invocation: filter the global mcpHypervisor.servers list by workspace.allowed_mcp_servers before passing to the agent runtime
  • Optional v2: same mechanism per-user for full RBAC (related to #2970)

Happy to test a PoC PR against production data if a maintainer wants to collaborate on the design. Without per-workspace MCP scoping, the "agent mode" feature is essentially restricted to single-tenant or fully-trusted-team scenarios — which is a shame given how much infrastructure AnythingLLM already provides for multi-workspace setups.

Also seeing recent Discord activity on this exact ask (May 2026) — the need is current, not dormant.

<!-- gh-comment-id:4478754738 --> @miraculix95 commented on GitHub (May 18, 2026): Adding a concrete production use-case + implementation thought to push this forward. ## Use-Case I'm running a multi-tenant RAG setup with a self-hosted vector database (pgvector) exposed via a custom MCP server. Each customer/workspace needs auth-scoped access to their own data only. Today this is blocked because: 1. `anythingllm_mcp_servers.json` is loaded globally — every workspace sees the same MCP servers with the same env (auth tokens included) 2. System prompts cannot enforce workspace isolation — prompt injection trivially makes the agent ignore "only use workspace X" instructions 3. The only workaround is **one AnythingLLM instance per customer** (Docker replication, separate Caddy routes, separate auth setups) — which doesn't scale economically beyond a handful of customers This is a real blocker for serious multi-tenant deployments — exactly the scenarios where AnythingLLM as a SaaS-style frontend would shine. ## Suggested Implementation Direction Following the design hint from the issue body, the minimal version could be: - Add `allowed_mcp_servers` (JSON array) to the workspace settings schema in Prisma - New API endpoint `PUT /workspace/:slug/mcp-servers` for admins to scope per workspace - New Frontend section in workspace settings: multi-select of available MCP servers - On agent invocation: filter the global `mcpHypervisor.servers` list by `workspace.allowed_mcp_servers` before passing to the agent runtime - Optional v2: same mechanism per-user for full RBAC (related to #2970) Happy to test a PoC PR against production data if a maintainer wants to collaborate on the design. Without per-workspace MCP scoping, the "agent mode" feature is essentially restricted to single-tenant or fully-trusted-team scenarios — which is a shame given how much infrastructure AnythingLLM already provides for multi-workspace setups. Also seeing recent Discord activity on this exact ask (May 2026) — the need is current, not dormant.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2463
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?