Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5704] Add pluggable pre-execution trust check for MCP/agent tool calls #5242

New Issue
Closed
opened 2026-06-05 14:52:52 -04:00 by yindo · 1 comment
yindo commented 2026-06-05 14:52:52 -04:00
Owner
Copy Link
Copy Source

Originally created by @vdineshk on GitHub (May 26, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5704

Problem

AnythingLLM can connect to MCP servers and invoke external tools on behalf of users. Today there is no built-in hook that lets administrators or plugin authors verify whether an MCP server is trustworthy before the agent dispatches a call to it.

This means:

  • A newly added MCP server is trusted implicitly the moment it appears in the configuration.
  • There is no middleware point where an external reputation or conformance check can run.
  • Administrators who manage multi-user workspaces have no programmatic way to gate tool execution based on third-party trust signals.

Proposal

Add a pluggable pre-execution middleware interface for agent tool calls:

// Conceptual interface
interface ToolExecutionGate {
  /** Return true to allow, false to block, or throw to abort with reason */
  shouldExecute(context: {
    toolName: string;
    serverUri: string;
    workspaceId: string;
    userId: string;
    parameters: Record<string, unknown>;
  }): Promise<boolean>;
}

Key design points:

  1. Hook runs before every MCP tool invocation — not after.
  2. Pluggable — users register their own gate via a workspace setting or plugin, not hard-coded to any single provider.
  3. Async-safe — the gate can call an external API (reputation service, policy engine, allowlist DB) without blocking the event loop.
  4. Fail-closed default — if the gate throws or times out, the tool call is denied.

Use cases

  • An enterprise admin blocks any MCP server not on a corporate allowlist.
  • A security plugin queries an external behavioral-scoring API and blocks servers whose trust score falls below a threshold.
  • A compliance workflow logs every tool invocation with its gate decision for audit purposes.

Alternatives considered

  • Static allowlist in config — already possible, but doesn't support dynamic or score-based decisions.
  • Post-execution audit only — too late to prevent data exfiltration or unwanted side-effects.

Happy to help draft a PR if this direction makes sense.

Originally created by @vdineshk on GitHub (May 26, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5704 ## Problem AnythingLLM can connect to MCP servers and invoke external tools on behalf of users. Today there is no built-in hook that lets administrators or plugin authors verify whether an MCP server is trustworthy *before* the agent dispatches a call to it. This means: - A newly added MCP server is trusted implicitly the moment it appears in the configuration. - There is no middleware point where an external reputation or conformance check can run. - Administrators who manage multi-user workspaces have no programmatic way to gate tool execution based on third-party trust signals. ## Proposal Add a **pluggable pre-execution middleware interface** for agent tool calls: ``` // Conceptual interface interface ToolExecutionGate { /** Return true to allow, false to block, or throw to abort with reason */ shouldExecute(context: { toolName: string; serverUri: string; workspaceId: string; userId: string; parameters: Record<string, unknown>; }): Promise<boolean>; } ``` Key design points: 1. **Hook runs before every MCP tool invocation** — not after. 2. **Pluggable** — users register their own gate via a workspace setting or plugin, not hard-coded to any single provider. 3. **Async-safe** — the gate can call an external API (reputation service, policy engine, allowlist DB) without blocking the event loop. 4. **Fail-closed default** — if the gate throws or times out, the tool call is denied. ## Use cases - An enterprise admin blocks any MCP server not on a corporate allowlist. - A security plugin queries an external behavioral-scoring API and blocks servers whose trust score falls below a threshold. - A compliance workflow logs every tool invocation with its gate decision for audit purposes. ## Alternatives considered - **Static allowlist in config** — already possible, but doesn't support dynamic or score-based decisions. - **Post-execution audit only** — too late to prevent data exfiltration or unwanted side-effects. Happy to help draft a PR if this direction makes sense.
yindo closed this issue 2026-06-05 14:52:52 -04:00
yindo commented 2026-06-05 14:52:53 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (May 27, 2026):

Thanks for the detailed proposal! After looking at this, I think the existing architecture already addresses the core concern:

  1. MCP server configuration is admin-only: only admins can add, toggle, or delete MCP servers. The act of adding a server is itself the trust decision.

  2. Tool-level filtering exists: admins can suppress specific tools they don't want exposed to users, giving granular control without needing external validation.

Given these controls, the proposed middleware would add a lot of complexity for a use case that most deployments don't have. If an admin doesn't trust an MCP server, they simply don't add it! If they trust the server but not certain tools, they suppress those tools.

I can see this being valuable for very large enterprise deployments with centralized security teams enforcing policy across many instances, but that feels like a niche enough case that it might be better suited as a custom fork or plugin rather than core functionality.

If there's a specific gap in the current admin controls that isn't being addressed, happy to discuss further, but I don't think we'll be implementing this as proposed. Thanks for understanding!

All that being said, I would think maybe the askForApproval on MCPs could be useful, but that is user-discretion - not admin since that happens right before tool invocation

<!-- gh-comment-id:4556314198 --> @timothycarambat commented on GitHub (May 27, 2026): Thanks for the detailed proposal! After looking at this, I think the existing architecture already addresses the core concern: 1. **MCP server configuration is admin-only**: only admins can add, toggle, or delete MCP servers. The act of adding a server is itself the trust decision. 2. **Tool-level filtering exists**: admins can suppress specific tools they don't want exposed to users, giving granular control without needing external validation. Given these controls, the proposed middleware would add a lot of complexity for a use case that most deployments don't have. If an admin doesn't trust an MCP server, they simply don't add it! If they trust the server but not certain tools, they suppress those tools. I can see this being valuable for very large enterprise deployments with centralized security teams enforcing policy across many instances, but that feels like a niche enough case that it might be better suited as a custom fork or plugin rather than core functionality. If there's a specific gap in the current admin controls that isn't being addressed, happy to discuss further, but I don't think we'll be implementing this as proposed. Thanks for understanding! All that being said, I would think maybe the `askForApproval` on MCPs could be useful, but that is user-discretion - not admin since that happens right before tool invocation
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
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#5242
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?