第三方tool未鉴权（插件、MCP等）

[sleep430]

Description / 描述

目前 AstrBot 中第三方 LLM tools（例如插件 tools、MCP tools，以及类似 Handoff / 外部能力桥接类工具）在进入 LLM tool-calling 流程后，权限控制主要依赖工具或插件开发者自行实现。
也就是说只要用户想就能恶意让ai调用对安全造成影响的问题（例如：本地文件的修改）导致第三方工具是否安全，完全取决于插件作者是否主动实现鉴权。对于文件读写、命令执行、网页控制、定时任务、外部系统操作等高危工具来说，这存在一定安全风险。
当前 LLM tools 的来源比较多，包括但不限于：

• 插件注册的 tools；
• MCP server 提供的 tools；
• Handoff / 子 Agent 类工具；
• 部分内置或框架级 tools。

这些工具最终都会进入统一的 LLM tool 列表中，由模型在 tool-calling 阶段选择调用。
但目前权限判断并没有形成统一后端机制，而是更多依赖：

1. 插件开发者是否在 tool handler 内自行判断 event.is_admin()；
2. 工具本身是否额外声明限制；
3. 个别内置能力是否在执行前做了特殊判断。
   因此会出现一个结构性问题：

第三方 tool 没有统一鉴权，是否安全全看插件开发者写不写权限校验。
这不仅容易遗漏，也不方便普通用户或管理员在 WebUI 中直接管理工具权限。
希望 AstrBot 能在后端和 WebUI 提供统一的 LLM tool 权限管理能力。
建议目标：

1. 后端增加统一权限模型

为 LLM tool 提供统一权限级别，例如：

• member：所有用户可用；
• admin：仅 AstrBot 管理员可用；
• disabled：完全禁用，不向 LLM 暴露，也不可执行。

2. 请求阶段过滤 tool schema

在 LLM 请求发出前，根据当前会话用户权限过滤 tools：

• 普通用户不应看到 admin tools 的 schema；
• disabled tools 不应对任何用户可见；
• 这样可以减少 prompt injection 和 token 暴露风险。

3. 执行阶段二次兜底校验

即使请求阶段遗漏，或存在历史上下文残留 / 伪造 tool_call，也应在真正执行工具前再次检查权限：

• 普通用户调用 admin tool 时返回 permission denied；
• disabled tool 永远拒绝执行。

4. WebUI 提供可编辑权限页面

希望在 WebUI 的工具管理页面中可以看到并修改每个 LLM tool 的权限，例如：

• 工具名称；
• 工具来源（内置 / 插件 / MCP）；
• 当前权限；
• 稳定的 permission key；
• 可在页面上切换 member / admin / disabled。
  并且这些配置应持久化到配置文件中，重启后仍然生效。

Use Case / 使用场景

在管理员使用tools的时候通过而在普通用户时返回没有这个权限，即无法使用对于tools

Willing to Submit PR? / 是否愿意提交PR？

• Yes, I am willing to submit a PR. / 是的，我愿意提交 PR。

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct. /

[NayukiChiba]

我觉得可以，我们目前在管理工具中，有插件指令和函数工具两种查看，但是对函数工具部分目前还是只能查看参数和开关，可以加一个权限控制，是很好的想法

[sleep430]

我觉得可以，我们目前在管理工具中，有插件指令和函数工具两种查看，但是对函数工具部分目前还是只能查看参数和开关，可以加一个权限控制，是很好的想法

已提交功能pr（#8512）如果逻辑没有问题我将在高考结束后开始将代码完善