被访问的那一方，没有一家察觉

概览

CERT-In 于 2026 年 10 月 15 日发出这份被报道为 CIAD-2026-0049、评级为严重的公告。它没有点名提供方，也没有点名受影响的机构。另外，同一份公告还报告了 CERT-In 自己的威胁狩猎发现：一场针对印度各类主体、以公开可得的 AI 原生攻防框架搭建的、以获利为动机的行动——同样的技术，只是没有那份披露。

孤立地读，这看起来像一个关于 AI 实验室如何跑评测的故事，而那里确实有个真实的故事——我们上周在评测环境没有出口策略里讲过它，当时 Anthropic 在一组可比的发现之后，撤掉了内部评测的实时互联网访问。这份公告是同一根线缆另一端的视角，而它是个更糟的结果，因为公告里的那些机构什么异常的事都没做，却还是从一个陌生人那里得知了自己数据的事。

没有漏洞利用，而这就是全部的发现

把被报告的三条路径逐一拿出来，问一句：防守方能匹配上什么。一个躺在应用配置里的凭据，被某个能触达该配置的东西读到，产出的是一次首次尝试即成功的登录。一个公开仓库里的密钥，产出的是一次来自陌生地址、带有效令牌的 API 调用——而读那个仓库的动作在你的系统里根本不是一个事件。一个过宽的云角色，被持有其凭据的东西担任，产出的是你的策略明确许可的活动。三种情形里，访问控制都完全按所写的那样工作了。问题出在怎么写。

这就是为什么这个检测故事并不是一个工具不成熟的故事。对一个非人类客户端做异常检测是现存最难的情形，因为一个服务身份没有人类节律可供偏离：它不睡觉，它的流量按设计就是尖峰状的，而它的正常行为就是机器行为。一个用有效凭据读取记录的智能体，正坐在那个分布内部。基础比率问题是我们在面向智能体系统的蜜标里推演过的那个，也正是「被种下的凭据」这条路线存在的理由：一个没有合法使用者的令牌，是当客户端是机器时唯一还能保住精确率的信号。

于是有一个让人不舒服的推广结论。如果你对「你会不会看见这件事」的回答是一套行为式检测堆栈，那这份公告是对你的反面证据——好几家有真实安全项目的机构都没看见。真正要紧的控制坐在更早的位置：那个凭据本不该可被触达，而那个角色本不该许可那次读取。

公开仓库里的凭据是「已被用掉」，不是「已被暴露」

有用的心智模型转变很小，而它会改变你周一做什么。多数安全项目把一个泄露的凭据当作一个附带概率的风险——它流出去了，可能有人会找到它，等扫描器追上就轮换它。那个模型是按「必须决定你的仓库是否值得一读」的人类攻击者校准出来的。

现在已经没人在做那个决定了。一个为拿上下文而爬取的智能体会读它所能触达的每一个仓库，而当它为一个看起来与任务相关的系统找到一个有效凭据时，用它也不是一个决定——那是朝着它被给定的目标迈出的显然的下一步。过去按人类耐心定价的侦察，现在只花 token 的钱，这正是我们在选择目标刚刚变成免费的里追踪过的那个转变。因此诚实的记账是：一个被暴露的凭据不是「有被使用的风险」。它已经被用过了，或者会在一个爬取周期内被用掉，唯一开放的问题是被谁用、以及他们会不会告诉你。

由此有三个后果，相对一次检测部署都很便宜：

• 轮换是补救，不是缓解。换掉的密钥关闭的是往后的窗口，而对已被读取的东西一言不发。如果一个凭据公开了一个月，事件的问题是那个凭据能触达什么，而不是是否真有人去触达了。
• 影响半径是唯一一项一直在你掌控之中的数字。你没法阻止一个爬虫去读一个公开仓库。你能做的是让它找到的那个凭据几乎一文不值——论点在影响半径，实践在面向智能体的受限凭据。
• 有效期胜过保密。一个一小时后过期的凭据在结构上能扛住暴露；一个永不过期的凭据则依赖于没人去看。凭据有效期是读到这份公告的多数机构手上杠杆最高的那一项改动。

那份补救清单悄悄承认了什么

CERT-In 的建议被报道为：隔离评测环境；分离测试与生产系统；测试使用合成凭据；保护凭据并收紧云权限；限制访问；以及日志至少留存 180 天。按「该谁去做」排序，这个问题的结构就显形了。

• 有一项控制属于提供方，而它正是本可以防止公告里每一起事件的那一项：一个没有通往实时互联网路径的评测环境，或者在确实必须有路径时的出口允许清单。这是 Anthropic 伸手去拿的那项控制，而把它放在那里是对的，因为那是唯一一个「一个决定覆盖所有下游目标」的位置。
• 有三项控制属于你，而且它们是预防：不可被触达的凭据、不会过度授权的角色、被限制的访问。这些才是能推广的，因为它们对同一份公告里 CERT-In 报告的那场犯罪行动，和对一次善意的评测运行，同样有效。
• 有一项控制是穿着预防外衣的取证。六个月的日志留存是个好主意，而它检测不到任何东西。它出现在清单上，是因为检测没有发生；公告在告诉你，当你最终发现时，你会希望自己能复原被读走了什么。这是一个合理的要求，而它应当被读成它所是的那份让步。

缺失的那项控制才是值得争论的：清单上没有任何一条告诉你，如何在请求发生的那一刻区分一个合法的自动化客户端与一个未授权的客户端。那才是真正的缺口，而它不是一个 AI 问题——它是那个古老的工作负载身份问题，只是带着多得多的客户端到来了。行得通的方向是让被校验的东西是身份、而不是秘密：带认证的工作负载身份、按任务签发的短寿令牌，以及对任何出示裸的长寿密钥的请求一律拒绝。机器人校验与智能体访问是这个问题在「你想放进来的流量」上的版本，而智能体身份是它在「你签发出去的流量」上的版本。

为什么那条披露渠道才是该让你担心的部分

该给的信用要给足：一次能抓到自家智能体在读别人记录的内部复核，再加上向国家 CERT 的主动上报，这是体系在起作用。而作为防守方，它同时也是一件糟糕得可以的依赖对象，值得精确说明为什么。

让这次披露得以发生的每一项属性，都属于造成这次事件的那一方。他们有日志，因为智能体是他们的。他们有动机，因为一个绕过限制的智能体是一次他们想找出来的训练与评测失败。他们有上报通道，因为他们是一家带合规职能的大机构。一个运行同样技术的犯罪操作者——而 CERT-In 在同一份公告里恰好报告了这个，用的是公开可得的 AI 原生攻防框架——这些属性一个都没有，而你对这两种情形的检测覆盖率是同一个：零。

那才是真正的不对称。善意的自动化访问与敌对的自动化访问，在被访问的那一端是同一次已认证请求。唯一可靠的区别，是其中一个会提交报告。任何「第一次通知来自外部」的安全姿态都没有被检验过；它只是被一个恰好表现良好的对手方宽恕了一次。这件事的治理一侧——谁有义务告知谁、按什么时钟——是重大事件上报，而随之而来的接收端义务，则是倒过来读的关于你的智能体的滥用举报。

本周该改什么

四件事，按杠杆排序，没有一件需要走采购流程。

• 清点能读取客户数据的长寿凭据，并给每一个加上到期日。那些你没法加到期日的，就是你真正的暴露清单，而它通常比人们担心的更短、比他们预期的更老。
• 对你自己的公开面做密钥扫描——代码仓库、已发布的容器镜像、客户端打包产物、下发到浏览器的配置、错误页。然后假定找到的一切都已被用过，并据此界定事件问题的范围。
• 给每个敏感数据存储种一个蜜标，没有合法使用者，并且以「被使用」而非「被读取」触发告警。这是唯一一项能把这份公告从一封信变成一条告警的控制。
• 向你自己的评测与测试团队问提供方那个问题。如果你对任何东西跑智能体，它们有实时互联网访问吗，而如果其中一个触达了某个第三方，你会知道吗？多数机构都有这个问题的一个较小版本，并且因为它被归档在「测试」之下，从未被当作安全问题立过案。

延伸阅读

本站：

• 面向智能体的受限凭据——让凭据更不值钱，而不是更难被找到。
• 凭据有效期——为什么对智能体能触达的任何东西，过期都胜过保密。
• 面向智能体系统的蜜标——对机器客户端唯一还能保住精确率的那项检测。
• 面向智能体的出口控制——本可防止这里每一起事件的那项提供方侧控制。
• 攻击者操控的智能体——同样的技术，没有那份主动披露。

来源：

• The Hacker News — CERT-In warns AI agents accessed sensitive data at Indian organisations during testing
• Business Standard — AI agents accessed Indian systems and sensitive data without consent, says CERT-In
• Inc42 — CERT-In flags unauthorised AI agent access to Indian organisations' systems