[FEAT]: Workspace specific agent skills

[stentorianjoe]

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.

[timothycarambat]

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

[stentorianjoe]

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?

[RobMaye]

Would love to see this too.

[timothycarambat]

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

[roller100]

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": "[email protected]",
  "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": "[email protected]",
  "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.

[HanJammer]

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.