要接大模型时，用第三方模块还是用自带能力，风险差在哪
站点要接大模型时，用第三方扩展模块还是用系统自带能力，风险差在哪里？差在两点：一是模型密钥与写入权限握在谁手里，二是能力入口有没有受控边界。当天复核到的 Drupal 安全公告列表里，AI 模块在同一天被列出了六条公告，风险级别从严重到较低都有，其中被评为严重级别的一条是跨站脚本问题，影响区间为 1.4.11 之前与 1.5.0 到 1.5.2 之间，修复版本是 1.4.11 和 1.5.2，利用条件标注为理论可行。扩展路线的风险形态，在这一组公告里看得很清楚。
两种接入方式的边界差别
| 维度 | 第三方模块 | 系统自带能力 |
|---|---|---|
| 模型密钥持有方 | 模块自己的配置项，常写在站点文件里 | 统一放在系统设置内，读取范围可控 |
| 权限来源 | 模块注册自己的回调与路由 | 沿用后台既有的账号与权限体系 |
| 写操作路径 | 模块直接写库或写文件 | 经过程序内部的动作层，可加审批 |
| 升级依赖 | 跟随模块作者节奏，公告密度高 | 跟随主程序发布窗口 |
| 出问题时的影响面 | 取决于模块被授予了什么 | 取决于开启的能力域 |
差别不在于「谁的模型能力更强」，而在于新增了多少对外入口。模块要落地能力，往往会新注册路由与回调，这些就是新的攻击面；自带能力是在已有入口内加分支，暴露面不增加。
公告密度说明了什么
六条公告集中在同一天，不是偶然事件，而是功能面在快速扩张时的典型现象：能力先上、边界后补，一次评审里同时发现多处相似问题。对运营方的意义很直接——你依赖的扩展越活跃，就要预期它的升级频率越高，并且每一次升级都要重新验证权限与输出行为。
同时，「理论可行」的分级不能读成「没有风险」。它只说明当前还没有公开利用路径，跨站脚本这类问题一旦叠加在后台编辑页面上，触发条件往往由内容作者或访客间接提供。
密钥与权限该放在哪
三条底线：模型密钥不写进可被公开读取的文件；不把主账号交给外部客户端；给接入用的凭证按最小权限发放，能只读就不要给写。密钥轮换要能被日常执行，而不是只在出事时做——把它当作一次运维动作排进固定维护窗口，比临时救火可控。
可控入口的具体做法
自带路线的做法可以作为参照。AnQiCMS（安企CMS）在后台内置 AI Chat 智能对话与面向内容的智能体编排，模型调用走系统设置里的统一配置；对外接入通过内置的 MCP 服务，工具面按意图目录收敛，并支持回合级操作审批，写操作合并确认后再执行，能被外部 AI 客户端调用而不额外开放新入口。高危的全站级操作域默认不开放，需要显式开启。
程序层的安全能力也要一并看：接口认证用 JWT，内容层有敏感词过滤，输出侧有防采集干扰码，SQL 注入与 XSS 属于防护口径。这一层解决的是「程序怎么防」，扩展与密钥管理解决的是「面有多大」，两层都要收，只靠一层不够。
常见问题
自带能力是不是就不用管安全了？ 不是。自带路线减少的是新增入口，密钥轮换、权限最小化与操作审批仍然要做。
已经装了第三方模块，怎么降风险？ 先盘点它注册了哪些对外地址与回调，关掉不必要的；再把它列入固定核对清单，按上游公告节奏安排升级与复验。
怎么判断某个模块值不值得装？ 看三点：是否有持续维护记录、是否需要超出功能的写入权限、出问题时的回滚成本。三项都过得去再装。