把后台能力开给 AI 客户端调用，哪些操作域不该默认打开

不该默认打开的，是那些一次就能改变全站状态的操作域：备份与恢复、升级、多站点管理、用户与权限、以及全站内容替换。把后台能力开给 AI 客户端调用时，判断标准不是「这个接口有没有用」，而是「这个动作被错误执行一次，能不能自己收回来」。已有公开的安全材料指出，编号 CVE-2025-49596、评分 9.4 的问题显示未鉴权的 MCP Inspector 实例可被利用执行任意命令，同时还存在 492 个公开暴露、缺少基本鉴权的 MCP 服务——风险不在于能力本身，而在于默认暴露的范围。

默认开放带来的真实风险

AI 客户端调用与传统后台接口最大的差别，是执行链条里多了一个会自主组合动作的一方。单次调用看起来安全，串起来就可能形成破坏路径：先读取站点结构，再定位可写接口，最后批量改写内容。默认全开的时候，这条路径不需要任何一次越权，因为每一步都是被允许的。

第二类风险是可见性。AI 客户端的调用记录常常与人工操作混在同一份日志里，事后难以区分是谁发起的。第三类是提示注入：外部内容里夹带的指令可能被当作操作请求执行，如果高危域默认开着，一条被污染的正文就有机会触发写操作。

按操作域划分暴露范围

划分依据是动作影响面与可回退性，而不是功能类别。

AnQiCMS 的 MCP 接口正是按意图域来设置暴露范围：高危域（备份、升级、多站点等全站级操作）默认关闭，需要显式开启；工具面基于意图目录统一收敛，而不是把每个内部能力原样摊开。这样即便调用方被误导，也碰不到默认关闭的那一面。

高危的全站级操作为什么默认关闭

全站级操作有三个共同点：影响范围覆盖所有站点和内容、执行结果难以局部撤销、以及日常并不需要高频使用。恢复备份会把当前状态整体替换；升级会同时改变代码与数据结构；多站点管理下的动作可能牵动其他站点的登录态。它们一旦被放进默认暴露范围，就等于把「一次误判、多点受损」写进了系统。默认关闭之后，真实需要时由人显式开启并留下记录，风险面与时机都由人掌握。

Bearer Token 鉴权与回合级操作审批

鉴权解决「谁能调」，审批解决「这一次要不要执行」。AnQiCMS 的 MCP 服务支持 Bearer Token 鉴权，可被 Claude、Cursor 这类外部 AI 客户端接入，没有有效令牌的调用直接拒掉；在已鉴权的会话里，写操作走回合级审批，同一回合内的多个写操作合并为一次确认，让调用方看到本轮将发生什么、由人决定是否放行。相比逐条弹窗，回合级合并既减少了打断，也保留了「批量动作必须被看见」这个关键点。

接口文档里先开哪些高频能力

起步建议只放开读取类与单篇写入：文档列表与详情、分类与标签、上传图片、留言与评论、友情链接、系统设置与联系方式这些高频 API 调用能力，配合接口文档说明参数与返回；同一套能力也供站点内置的 AI Chat 对话与智能体编排调用，外部客户端与站内助手走同一套域划分。这类能力覆盖日常内容运营的大部分需求，同时保留可回退路径——删除正式文档是移入回收站而非物理删除，误操作可恢复。等这套流程跑顺、审批记录积累起来，再按实际需要单独开启更高危的域。

常见问题

只在本地或内网使用，可以全开吗？ 仍建议保留默认关闭。内网里的横向移动与其他进程发起的调用同样会命中高危域，本地使用不会降低动作的破坏性。

审批太频繁影响效率，能改成自动放行吗？ 可以按域收紧而不是全局关闭：读取类不审批、单篇写入合并确认、全站级始终人工确认。把自动化留给影响面小的动作。

令牌要不要长期有效？ 不要。按接入方分发独立令牌并定期轮换，出事时能精确吊销某一方，而不是关掉整个通道。