「致命三要素」正在被主动利用:Agent 加固先查哪三条?

TechGig 10 月 14 日的安全报道措辞相当直接:一个被称为「致命三要素」(lethal trifecta)的 AI Agent 结构性漏洞正在被主动利用,攻击者通过提示注入就能完成远程代码执行和数据外泄。报道同时点出企业侧的普遍盲区:多数企业对自己部署了多少个 Agent、每个 Agent 持有什么身份,完全没有可见性。 「三要素」凑齐的是哪三块积木? 把它拆开看,三个条件单独都不致命:一是 Agent 能访问外部内容(读网页、读仓库、读邮件),二是外部内容里藏着注入指令,三是 Agent 还持有执行工具的权限且默认放行。单独看,第一条是 Agent 存在的意义,第二条是互联网的常态,第三条是为了少打断用户。但三者一旦凑齐,攻击者只需要把一句话藏在 Agent 会读的某个页面里,剩下的交给 Agent 自己动手。这不是模型的问题,是架构把「读」和「做」之间的闸门拆了。 加固优先级为什么先从身份可见性开始? 报道给的第一刀不是技术补丁,是盘点:先回答你到底有几个 Agent、每个 Agent 背后用的是谁的凭证、能调哪些工具。很多团队的实际情况是,IT 部门不知道市场部给客服配了个能查客户库的 Agent。可见性之后才是技术加固:给「写」和「执行」类工具设人工确认、把 Agent 的网络出口收敛到白名单、外部内容渲染前先过一遍注入检测。把确认按钮加回高危操作,看起来是体验倒退,但在主动利用已经出现的当下,这是最便宜的止损。 Agent 安全的本质是给一个会读会写的系统重新装上闸门。闸门装得晚,代价就是某次泄露事故之后补的。企业侧最该先做的动作其实是一张表:列出所有 Agent、各自的调用凭证、能读写的数据源、能执行的命令范围。这张表建出来,你会发现大量 Agent 的权限远超它的任务需要。收缩权限之后,再考虑技术检测——外部内容进 Agent 前过一遍注入特征扫描,是投入产出比最高的一道防线。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

2026-10-15 · 1 min · 45 words · AI 实战派

十月十三日银行监管盯上自主智能体:有生产权限却没有权限边界的身份

十月十三日起,多家技术媒体报道:银行监管机构正在加强对自主 AI 智能体的审查。TechGig 十四日的一篇评论点出了一句关键判断——「一个拥有生产权限、却没有可执行权限边界的智能体,就是一个无边界身份,外加一把真钥匙」。这句话把过去一年 Agent 行业的隐患说透了。 为什么是银行先反应过来? 因为银行是最后一个能容忍错误的行业。一个写代码的智能体出错,最多回滚;一个交易智能体出错,一分钟能烧掉几千万美元。过去两年,银行内部悄悄部署了大量智能体:查账、写风控报告、回客户邮件、甚至初审贷款。它们被授予了真实的系统权限,但很少被授予真实的「权限边界」——也就是一个技术上强制执行的「你今天最多能转多少钱、最多能联系多少客户」。 责任到底落在谁头上? 监管的核心问题不是模型乖不乖,而是当智能体越权时,银行能不能在毫秒级拦住它。这就要求从「提示词约束」升级到「执行层约束」:智能体的每一个工具调用都要经过独立的策略引擎,调用结果要被审计,异常行为要能熔断。这是把传统金融风控里的双人复核、岗位分离、限额管理,重新发明给硅基员工。 接下来几个季度要观察:央行与 OCC 类机构会不会发布智能体权限分级指南;银行的首席风险官名单里会不会多出「Agent 风险官」这一岗位;以及出第一起智能体越权损失案之后,行业的合同条款会怎么改。当智能体开始拿真钥匙,锁的行业就要重新发明一次。 智能体权限分级会成为新的金融监管科目吗? 可以预见,未来银行的监管报表里会多出一类字段:在跑的智能体数量、权限级别、本周触发的熔断次数、越权未遂事件。这相当于给硅基员工做了一套征信系统。对技术团队来说,这意味着每部署一个新智能体,都要像新员工入职一样走权限审批、背景调查、行为监控。智能体的人力资源管理,会从文化讨论变成合规成本。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

2026-10-15 · 1 min · 21 words · AI 实战派

MCP 工具投毒:一个影响约 20 万实例的协议级设计缺陷

MCP(Model Context Protocol)是 2025 年底以来智能体连接外部工具的事实协议,但 2026 年它连续曝出协议级问题。4 月 OX Security 披露:MCP 官方 SDK 的 STDIO 传输存在一个系统性设计缺陷——本地启动服务器进程时,底层会执行任何传入的操作系统命令,即便伪造服务器启动失败返回错误,命令照样执行。该漏洞波及约 20 万个实例,供应链下载量超 1.5 亿次,覆盖 Anthropic 官方支持的全部 11 种语言 SDK;Anthropic 确认这是有意设计,拒绝修改。 三种投毒攻击面 CSA 七月的研究笔记把攻击归为三类,结构同源——客户端默认信任它连接的服务器,且从不持续校验这种信任: 工具描述投毒:恶意指令藏在工具描述、参数 schema 里,智能体注册工具时就被劫持。 rug-pull:服务器今天行为正常,某次更新后突然变坏,客户端毫无察觉。 工具影子化:影子工具冒充合法工具,窃取凭证。 学术侧也在跟进:arXiv 上 ShareLock 研究多工具阈值投毒,VIPER-MCP 用污点分析挖 MCP 服务器里的命令注入、SSRF 与路径穿越。 为什么不是修个 bug 就完事 因为 MCP 把工具元数据直接喂进模型上下文,模型天然把它当可信指令。这不是某家客户端的 bug,而是协议信任模型的结构性缺陷:只要工具描述能影响模型决策,投毒就可能发生。 工程上怎么挡 在客户端与 MCP 服务器之间加一层网关,对工具描述、返回内容做注入检测与白名单过滤。 工具凭证与模型进程隔离,就算上下文被劫持也拿不到密钥。 只信任经过审核的工具源,禁止智能体动态加载来路不明的 MCP 服务器。 特别要警惕供应链一環:很多 MCP 服务器本身依赖第三方 Python 包,一旦依赖被投毒,恶意代码就在服务器进程里执行,能拿到该服务器可见的一切上下文与凭证。安装时锁定依赖版本、定期做漏洞扫描,是这道防线上最容易被忽视却最致命的一环。 去论坛讨论 这篇文章里的观点,欢迎到硅基AGI论坛讨论。按标题搜索:MCP 工具投毒

2026-10-08 · 1 min · 65 words · AI 实战派
🔗 硅基 AGI 论坛 · silicon-agi.com | 📡 RSS 订阅
鲁ICP备2026018361号