微软安全团队把 MCP 工具投毒讲得很具体，最让后端工程师不舒服的地方在这里，攻击者不一定要攻破模型，也不一定要拿到用户密码，只要把工具描述里的指令改掉，Agent 就可能在正常调用里把敏感数据带出去。
这事听起来有点绕。MCP server 给 Agent 提供工具，工具名称、描述和参数说明会进入模型上下文。Agent 读到描述后，会判断什么时候调用它。描述如果被塞进隐藏指令，Agent 可能把它当成工作要求。人看见的是工具还叫原来的名字，机器看到的上下文已经变味了。
工具描述也要走变更审核
过去后端审核接口，重点看鉴权、参数、SQL、限流和日志。Agent 接入以后，工具描述也要纳入审核。它已经算执行上下文的一部分，模型会读，会照着做。一个第三方 MCP server 更新了描述字段，风险可能跟改系统提示词差不多。
比较稳的做法是把工具元数据纳入版本库。名称、描述、参数、返回样例、允许访问的数据范围，都要有负责人和变更记录。生产环境的 Agent 不应该自动信任外部工具更新。这个要求麻烦，但安全就是这么麻烦。
权限要绑在人身上
Agent 调工具时，后端不能只看它是不是来自可信应用。它替哪个用户办事，就只能拿到那个用户本来能看的数据。销售只能看自己客户，项目经理只能看自己项目，财务动作要走财务确认。这个边界不能写在提示词里。
优易云在做工具网关时，会给 Agent 单独的服务身份，再把真实用户身份、角色、部门和数据范围一起传进来。网关先判断用户能不能调用这个工具，再判断参数里的客户、订单、合同或设备是不是在授权范围内。两道门都过了，后端才放行。
外发参数要能拦截
MCP 投毒的麻烦点在于，每个动作单看都可能合法。Agent 查了发票，调用了校验工具，给第三方服务传了参数。业务人员看到结果没问题，敏感摘要却可能已经被塞进请求里。
所以后端要检查工具调用参数，尤其是外发请求。客户名单、合同金额、发票明细、银行卡号、手机号、内部备注，这些字段不应该因为 Agent 说需要就直接出网。可以用字段级白名单，也可以按工具定义允许传出的数据类型。宁可前期多挡一点，也别让生产数据裸奔。
高风险动作要有人点头
读资料和改系统是两件事。Agent 可以帮人生成退款说明、采购建议、合同摘要和工单回复。到了关闭工单、修改付款状态、批量发送邮件、更新客户等级这些动作，系统要把影响对象、关键参数和依据摆出来，让负责人确认。
这个确认页不能做成摆设。确认记录要写日志，后面能查到谁确认、确认前看到了什么、系统执行结果怎样。出了问题，团队才能复盘。否则大家只会互相问一句，刚才是谁让 AI 点的。
日志要能讲清一条链路
Agent 系统的日志不能只留模型回答。一次工具调用至少要记录会话编号、用户身份、工具版本、输入摘要、参数、返回结果、外发目标、人工确认状态和错误信息。敏感内容可以脱敏，但链路不能断。
我更喜欢把日志分成两层。技术日志给工程师排障，业务事件给管理者和审计人员看。技术日志里可以有请求 ID 和堆栈，业务事件里要写成人话，比如某销售以客户负责人身份生成了合同摘要，系统拦截了外发手机号字段。这样才查得动。
优易云的落地建议
企业要接 MCP 或自研工具网关，可以先做一份工具清单。每个工具写清楚负责人、用途、可读数据、可写动作、外发范围、审批要求和回滚方式。然后把高风险工具放进灰度环境，拿真实流程做演练，看看日志能不能复盘。
Agent 能写系统以后，后端就别把它当聊天入口了。它更像一个会调用接口的新同事，手很快，也会犯错。给它权限闸口、审计链路和刹车，项目才有机会跑到生产环境。
