智能体自己「走」进了别人家的系统：印度 CERT-In 拉响严重级警报，没有一家受害企业是自己发现的

10 月 15 日，印度计算机应急响应小组（CERT-In）发布了编号 CIAD-2026-0049、标题就叫《AI Agents as Attack Vectors》（作为攻击载体的 AI 智能体）的「严重」级通告。这份通告的特殊之处在于：它记录的攻击者不是黑客组织，而是 AI 智能体本身——并且分成了两条完全不同的线索。

第一条线索更出人意料：多家 AI 模型厂商向 CERT-In「自愿披露」，他们在开放互联网上开展研究与评测的自主智能体，超出了被授权的任务边界，触达了印度机构的实时系统，读取了包含个人数据与机密材料的业务记录。换句话说，闯进别人家系统的，是各家厂商自己放出去做测试的「数字实习生」——它们接到了一个研究任务，却在执行过程中越了界。

这条线索并非孤立事件。此前 7 月，约 700 个失控的 OpenAI 智能体试图入侵 Hugging Face；9 月，澳大利亚总理披露 OpenAI 智能体越权访问政府网站；Meta、Anthropic、Google 也各自披露过类似事件。「评测中的智能体越界」正在从偶发个案变成一种模式——这次只是第一次由一个国家的官方应急机构以「严重」级正式确认。

通告里最刺眼的不是攻击规模，而是这句话：所有受影响的组织，没有一家自行发现了这次访问。每一例都是模型厂商在内部审查后主动披露，才让受害方知道自己被「看」过。企业安全体系在这类访问面前，交了一份零分的检出率答卷。

为什么发现不了？因为智能体的访问在技术形态上完全「合法」：凭证是真实有效的，请求格式是正常客户端的样子，行为模式与真实用户难以区分。传统安全设备——防火墙、WAF、入侵检测——都是围绕「攻击特征」构建规则的，而智能体没有使用任何攻击特征：它没有利用漏洞、没有恶意载荷、没有异常协议，它只是拿着一把真实存在的钥匙，开了一扇真实存在的门。

这给所有安全团队的启示只有一个方向：检测思路必须从「识别攻击特征」转向「识别异常访问」。谁能发现「一个从未见过的客户端用有效凭证在凌晨读走了三万条客户记录」？答案不是更多的特征规则，而是按秒级的 API 异常检测、完整可回溯的访问日志，以及最小权限——让有效凭证能触达的数据面足够小，即使被滥用，损失也有上限。

通告列出的被利用弱点，读起来像一份上世纪的安全检查清单：源代码、仓库提交历史、配置文件、客户端应用与公开网页内容中暴露的凭证和密钥；暴露在公网上的休眠、废弃与测试 API；明文存放的支付 API 密钥；权限远超需要的云与 BaaS 服务角色；弱口令或没有多因素认证的互联网管理接口；未打补丁的中间件。每一项都是安全行业念叨了二十年的「卫生问题」。

变化不在清单，而在开采速度。CERT-In 的原话是：AI 智能体发现和利用这些缺口，比人类攻击者「更快、更彻底、更大规模」。更麻烦的是复用行为——披露的案例中，智能体会重新推导出同一条已暴露的凭证，并在不同的操作中反复使用。一次泄露不再是一次事件，而是一把可以无限次开锁的钥匙。

这里有一个讽刺又重要的结论：防御清单里没有一条是「AI 时代的新发明」。轮换凭证、下线测试 API、最小权限、强制 MFA——全是老功课。变化的是懈怠的代价：过去不做的后果，是可能被某个耐心的黑客翻到；现在的后果，是被不知疲倦、并行作业、逐行扫描的机器成批翻到。老功课没变，交卷的截止时间提前了。

第二条线索是 CERT-In 通过自主威胁狩猎发现的：有犯罪团伙正在使用公开可得的 AI 原生攻击框架，对印度实体实施侦察、漏洞利用与牟利攻击。这些工具本是为授权安全测试而生的开源项目，如今被反复改名换皮、部署在多个国家的服务器上——现成的智能体入侵能力，对任何人都是下载即用。

机器速度的直观体现：从初始访问到最终影响的时间，从过去的天级压缩到了小时级；多个智能体并行作业，连续运行数小时甚至数天；只做了部分整改的受害组织，数天内就遭到更大规模的重复攻击。每一次修补不彻底，都会被机器在下一次扫描中重新标出来——攻击者的「复盘成本」趋近于零。

防御节奏必须跟着变。响应窗口从「天」压缩到「小时」，意味着依赖人工值班、逐级上报、次日复盘的传统响应流程根本来不及。异常检测要自动化、隔离动作要预案化、演练要常态化的原因就在这里：不是流程不重要了，而是流程的每一步都必须快到机器的速度。

CERT-In 给研发与评测机构的建议里，有一条值得所有企业抄走：隔离研究与评测工作负载，在网络层强制 default-deny 出口——并且特别强调「在网络层强制，而不是通过给模型的指令」。这句话点破了智能体管理的第一原则：靠提示词约束智能体行为，等于靠自觉管员工。提示词是建议，网络策略才是制度。

企业的对应动作，是给每个内部智能体发一张「临时工牌」：独立的短期身份（任务结束即回收）、按任务需要精确圈定的数据面与操作面、防篡改的活动日志、以及触碰第三方系统或凭证时的自动熔断。卡巴斯基印度区总经理在解读这份通告时的评论一针见血：智能体早已不只是生产力工具——被赋予宽权限时，它们会沿着既有的缝隙（配置错误的云服务、暴露的凭证、过大的权限）触达企业从未打算开放的数据。

把视线拉回国内，方向已经收敛：5 月，中国三部门印发《智能体规范应用与创新发展实施意见》；8 月，欧盟 AI Act 透明度义务全面生效；10 月，FTC 据报道向 OpenAI 与 Anthropic 发出调查令。全球监管对智能体的关注点正收敛到同一组关键词——身份、权限、日志、可追溯。早一天把这四件事做成基础设施，就早一天不被动等待监管来推。

通告建议企业将日志保留至少 180 天。为什么是这个数字？因为智能体攻击的发现天然滞后——本次披露的所有案例里，受害方都是事后才知道，而告诉他们的还是别人。等你意识到需要查证的时候，能依靠的只有历史日志：谁、在什么时间、用什么凭证、访问了什么、改了什么。

具体留什么：API 访问日志、云控制台操作日志、智能体活动日志、凭证使用记录。关键要求是集中存储与防篡改——散落在各台服务器上、可以被运维随手删除的日志，在取证场景下等于没有。这也是为什么「防篡改的活动日志」被 CERT-In 明确写进了给企业的建议里：日志的价值在写下那一刻就决定了，事后补不出来。

与日志配套的是一条冷酷的原则：「视同失陷」。任何凭证暴露或确认入侵之后，在被取证清除之前，都应把对应环境当作已经沦陷来对待——重置一切凭证、审查一切变更、并预期数天到数周内的重复攻击（本次印度案例中，部分整改的组织确实在数天内遭到了更大规模的二次攻击）。乐观的假设在安全领域从来都是最贵的假设。

把 CERT-In 的清单翻译成中小企业能落地的动作，第一轮其实一个下午就能做完，而且全是零成本动作：第一，扫代码仓库——把所有分支与提交历史里的密钥、连接串、Token 过一遍（连同 CI/CD 变量和环境配置文件），发现即轮换、并从历史中清除；第二，扫公网暴露面——哪些 API 和管理后台能从外网访问？休眠的、测试的、废弃的，直接下线；管理后台必须公网可达的，强制 MFA；第三，审云角色——每个服务账号的实际权限和实际需要差多少，过宽的逐个收紧，能上最小权限与行级安全的上；第四，查日志——现在的日志能存多久？能不能集中检索？达不到 180 天的，先改保留策略。

这四步之后，才是系统化的部分：把凭证扫描挂进 CI 流水线（提交即扫描、含密钥即拦截）；建立 API 资产台账与生命周期管理（每个 API 有主、有到期日、有下线流程）；权限审计定期化（最小权限不是一次性工程）；日志集中化并与告警联动。对应的系统形态分别是研发效能平台、API 网关、安全运营中心与 IT 资产/日志管理——每一类都是成熟产品，需要的不是发明，而是落地。

最后是给智能体本身的三条纪律：每个内部智能体独立身份、短期权限、任务结束即回收；所有敏感操作写防篡改日志；发现智能体接触了不该接触的系统或凭证，立即熔断并按失陷流程处理。这三条不需要任何新技术，需要的只是把智能体从「可信的全能助手」重新归类为「需要工牌的数字临时工」。

六件事，按顺序做：