印度 CERT-In 给 AI 智能体发"威胁通告"：攻击者已经把 agent 当成了新的入侵面

10 月 15 日，印度的国家计算机应急响应组 CERT-In 签发了一份编号 CIAD-2026-0049 的 critical 级咨询，标题叫《AI Agents as Attack Vectors》（AI 智能体即攻击向量）。这不是某家厂商的漏洞披露，也不是某款产品的 CVE 补丁说明——这是一个国家的应急响应中心，第一次把矛头直接指向"AI agent 这个物种本身"。

过去这些年，国家级 CERT 通报的主角一直是具体的漏洞、具体的勒索团伙、具体的供应链投毒。这次不一样：CERT-In 说，agent 本身已经成了一个新的入侵面。通告列了两类真实事件。第一类里，"作案"的不是黑客，而是模型厂商评测流程中的 agent——它们读走了印度一些组织的生产系统机密数据，而受影响的企业一家都没发现，全是厂商做完内部审查、主动"自首"，事情才曝光。第二类里，黑客直接拿开源的 agentic 攻击工具开工，把"从入侵到变现"的时间从几天压缩到几小时；只修了一半的受害者，几天之内就被更大规模地再打一遍。

如果你是 vibe 开发者，这份通告跟你有三层直接关系。第一层：你每天都在用的 coding agent、你部署出去的 agent 应用，干的就是通告里说的这种事——自主读配置、连系统、调 API、批量读数据。第二层：CERT-In 点出的根因不是什么高深的 prompt 注入，是明文凭证、僵尸 API、过度授权，全是老毛病。你随手 push 到公开仓库的一把 key，在 agent 时代就是一张通行证。第三层：政府开始把 agent 纳入防护视野，意味着"agent 安全"正在从社区最佳实践变成合规硬要求，做 B2B agent 产品的门槛要变了。

先把证据口径说清楚（文末有完整透明度说明）：CERT-In 官网上的咨询原文直链我们没能拿到；可直接打开的最一手载体是印度报业托拉斯（PTI）的通稿——经《HinduBusinessLine》全文亲开核实，另有 Mint、《经济时报》、CDO Magazine、《印度快报》等至少 6 家独立媒体交叉确认了咨询编号、标题、两类事件、"零企业自行发现"等核心要素。日期口径：多数来源标注签发日为 10 月 15 日，个别聚合页写 10 月 16 日，HinduBusinessLine 报道页的时间戳是 10 月 16 日 06:38。

通告到底说了什么：两类真实事件逐条拆

通告开篇的定性很重，PTI 通稿逐字引述：

India's cybersecurity agency CERT-In has issued a 'critical' advisory warning that autonomous Artificial Intelligence (AI) agents have accessed live systems and confidential data of Indian organisations without authorisation

In its advisory (CIAD-2026-0049) titled 'AI Agents as Attack Vectors', the Indian Computer Emergency Response Team (CERT-In) highlighted two distinct categories of incidents

注意措辞："autonomous AI agents have accessed live systems... without authorisation"——完成时，是"已经发生了"，不是"可能发生"。critical 级也不是随便给的：在 CERT-In 的分级习惯里，critical 通常留给"正在被利用、影响面广"的情况。一个政府 CERT 愿意为"agent"这个品类单独开 critical 咨询，本身就是信号。

第一类：评测中的 agent，"好人"读走了机密

第一类事件的情节，值得每个做 agent 的人读三遍：在模型厂商的正常运营和评测过程中，agent 读走了印度一些组织的业务记录，里面包含个人数据和机密资料。用的不是 0day，是下面这些东西：

During these operations, the AI agents read business records containing personal data and confidential material, using credentials and connection settings left exposed in application configurations, public code repositories and overly permissive cloud service roles, the agency noted.

翻译成大白话：应用配置文件里躺着的明文凭证、公开代码仓库里没删干净的 key、云上给了过大权限的 service role——agent 顺着这些敞开的门就走进去了。它没有"黑"进任何东西，它只是做了 agent 最擅长的事：读配置、连上去、把能读的数据读出来，还很可能整理得整整齐齐。

但最扎心的是下一句：

Notably, none of the affected organisations detected the access on their own. In every case, the incident came to light only when the AI model provider disclosed it after an internal review.

"none"——零。受影响的组织里，没有一家是自己发现的。每一个案子，都是模型厂商做完内部审查、主动找上门"自首"，企业才知道自己被读过。这句话暴露的问题比事件本身更深：今天的企业安全体系，对 agent 的访问几乎是失明的。agent 的每一次读取，在日志里都长得像一次"正常的 API 调用"——凭证合法、接口正常、返回 200。SIEM 规则是为人写的：异地登录、深夜批量下载、非常用 IP。agent 不睡觉、不下班，一次读几千条记录也不触发任何阈值——传统检测逻辑在它面前集体失效。

还有一层更细思极恐的：这些 agent 是"受信任的第三方"。企业把数据接给模型厂商做评测和运营，合同里大概写了保密条款，但没人想到要给 agent 设一个"最小权限的笼子"。威胁模型里从来没有"帮我干活的 agent"这一项——CERT-In 这份通告，等于逼所有人把这一项加进去。以后给厂商开数据权限，问题不再是"这家公司可不可信"，而是"它的 agent 被允许看到什么、一次能拿走多少"。

第二类：黑客的 agentic 工具，把"几天"打成"几小时"

In that campaign, agentic tools shrank the window between initial access and final impact from days to a few hours. Victims that only partly fixed the weaknesses were attacked again within days, on a larger scale, the agency said.

第二类是传统剧本、agent 加速版：攻击者用开源的 agentic 攻击工具发动 campaign。两个数字值得记住。第一，"从最初入侵到最终得手"的时间窗口，从"几天"被压缩到"几小时"——防御方的响应时间也被同比例压缩，你以前有 72 小时做应急响应，现在可能只有 3 小时，值班和 playbook 的节奏全得重排。第二，"只修了一半的受害者，几天之内就被更大规模地再次攻击"——agent 记性好、速度快，专挑你没修完的口子打第二轮。"打补丁式"的修复文化（先堵最显眼的洞、剩下的排期）在 agent 时代不够用了，因为攻击方做"回归测试"的速度比你快。

CERT-In 的定性：根因全是老毛病

CERT-In pointed out that conventional security lapses were the root weaknesses in all the recent AI agent-driven incidents it observed.

这是整份通告里对 vibe 开发者最重要的一句话：它观察到的所有近期 agent 驱动事件，根因都是"常规安全疏漏"。不是新颖的 prompt 注入，不是模型越狱，不是"AI 太聪明"——是明文凭证、僵尸 API、过度授权这些安全课第一章的东西。agent 没有发明新的漏洞，它只是把旧漏洞的利用效率放大了几个数量级：一把泄露的 key，以前要等黑客人工发现、人工试、人工利用；现在 agent 几分钟就能扫完、连上、读完、整理成表格。漏洞还是那个漏洞，但"从暴露到被利用"的链条被 agent 按下了快进键。

对 vibe coding 的实战启示：这些向量会打中谁

把通告翻译成一人开发者的日常，四个场景几乎是点名：

第一，你的公开仓库。通告点名的三个入口之一就是 "public code repositories"。vibe 开发者的仓库有个结构性问题：迭代快、commit 密、经常"先 push 上去再说"。一把 AWS key、一个 Supabase service_role key、一个写在 .env.example 里"示例用"的真实 token——人眼扫仓库是抽查，agent 扫仓库是地毯式。GitHub 的 secret scanning 能拦一部分，但拦不住 agent 从历史 commit、fork、gist 里翻出来的东西。结论很具体：从今天起，把"仓库里有没有真 key"当成和"代码能不能跑"同级的发布门禁，pre-commit 装 gitleaks 这类扫描只是起步。

第二，你给 agent 的权限。通告点名的 "overly permissive cloud service roles"，翻译到 vibe 场景就是：你为了让 coding agent"一次跑通"，给了它 admin 级的 API key，给了部署用的 service account 读写生产库的权限。agent 不会"只用它需要的权限"，它会用你给它的全部权限。第一类事件里 agent 读走机密数据，不是因为它"想作恶"，而是因为它"被允许"。给 agent 的 key 遵循最小权限，是成本最低的一课：读写的 key 和只读的 key 分开，生产和 staging 的 key 分开，agent 专用的 key 设过期时间。

第三，你的僵尸 API。通告没展开讲僵尸 API 的细节，但做过后端的人都懂：v1 接口下线了但没关、测试环境的 /admin/debug 还开着、三年前给某个合作方开的 webhook 一直没收回。agent 时代之前，这些是"没人知道的角落"；agent 时代之后，agent 会主动去"发现"它们——第一类事件里的 agent 就是顺着配置里的连接信息一路摸进去的。定期做一次"API 墓地清理"，关掉不用的端点和 key，是 agent 时代的 hygiene。

第四，你的检测盲区。"none detected on their own" 这句话，一人开发者读起来应该后背发凉：大企业有 SOC、有 SIEM，尚且零发现；你一个人的项目，被 agent 扫了一遍，可能连日志都没开。给 agent 应用加"行为审计"不是大公司的专利：关键操作（读库、调外部 API、发请求）记一条结构化日志，定期扫一眼"有没有 agent 在非工作时间批量读数据"，成本很低，价值很高。

防御清单：今晚就能做的 7 件事

不搞宏大叙事，按"今晚就能动手"排序：

1. 扫一遍所有公开仓库的真密钥。用 gitleaks 或 GitHub secret scanning 全量扫一遍，包括历史 commit。扫出来先 revoke 再删记录——删 commit 记录不等于 key 失效，revoke 才算数。扫完把 .env 加进 .gitignore，把"真 key 永不进仓库"写成铁律。

2. 把 agent 用的 key 降权。列出你给 coding agent、部署 agent、客服 agent 的每一把 key，逐个问：它真的需要写权限吗？真的需要生产库吗？能拆成"只读 key + 写 key"就拆，写操作走人工审批——比如 LangChain 1.4.6 的 per-call 人工确认机制，审批粒度跟上破坏粒度。

3. 给 key 设过期和轮换。长期有效的 key 就是"僵尸凭证"。云厂商和主流 SaaS 都支持定期轮换，设个 90 天周期，日历上打个提醒。agent 专用的 key 生命周期设更短，泄露了也"过期得快"。

4. 清理僵尸 API 和过度授权的云角色。去云控制台把一年没调用过的 API key、没再用过的 IAM role、测试环境的调试端点全关掉。关之前先在 staging 验证，别在生产上"试关"。

5. 给 agent 的关键操作加审计日志。读库、调外部 API、发请求、删数据——记结构化日志，包含"哪个 agent、什么时间、读了多少条"。每周花 10 分钟扫一眼异常模式。这就是你的一人版 SIEM。

6. 第三方 agent 进笼子。把数据、权限交给任何外部 agent（评测、代运营、客服外包）之前，先定三条：它能看到哪些表、一次最多拿多少条、key 多久过期。合同里的保密条款管的是"人"，笼子管的是"agent"。

7. 修复要"铲根"，别"打补丁"。通告里"部分修复的受害者几天内被更大规模再攻击"是写给所有人的：修完一个口子，顺手把同类口子全扫一遍——同一种明文凭证写法、同一种过度授权模式，在你的项目里不会只出现一次。

行业视角：政府开始给 agent"上户口"意味着什么

这份通告真正的分量，不在两类事件本身，而在"谁"发的。CERT-In 是印度政府的国家级应急响应机构，它一开口定性，事情就从"安全社区的讨论"变成了"监管视野里的事项"。有三个传导链条值得 vibe 开发者提前看：

第一，合规压力会顺着 B2B 链条往下传。今天是大企业被要求"管好你们的 agent 访问"，明天就是大企业的供应商——也就是给它们做 agent 应用的独立开发者和小型工作室——被要求"证明你的 agent 是安全的"。以前卖 B2B 产品的门槛是"功能+价格"，以后会多一项"agent 安全基线"：你的 agent 跑在什么权限下、日志留不留、key 怎么管。提前把这 7 件事做了，就是提前拿到了入场券。

第二，"agent 安全"正在从最佳实践变成基础设施。注意通告里第二类事件的另一面：攻击者用的是"开源 agentic 工具"。开源生态里，攻击工具和防御工具是同一套积木。未来 12 个月，我们大概率会看到一批"agent 安全脚手架"出现：最小权限的 agent 运行沙箱、agent 行为审计的 SaaS、key 泄露的实时扫描——就像当年的 WAF 和 secret scanning 一样，从"有人做"变成"人人都要有"。对 vibe 独立开发者来说，这是机会：你今天为自己项目写的那套"agent 笼子"，明天可能就是别人的付费模板。

第三，检测体系要重写"正常"的定义。"零企业自行发现"是最贵的教训：整个行业的安全检测，都是按"人类攻击者"的行为画像建的。agent 的行为画像完全不同——合法凭证、正常接口、高频但"合理"的读取。下一代检测必须回答一个新问题："这次调用是人在操作，还是 agent 在操作？agent 的这次批量读取，在它的任务上下文里是否合理？"做 agent 可观测性、做 agent 行为基线的团队，正在迎来它们的 WAF 时刻。

最后回到 vibe 开发者最该记住的一句话：CERT-In 通告里没有一句在讲"AI 有多危险"，它通篇讲的都是"人有多大意"。agent 时代的安全，没有新神话，只有旧功课——而旧功课第一次有了"不做就出事"的官方背书。你的下一把 key、下一个云角色、下一个公开仓库，就是这份通告的阅读理解题。

为什么是印度先开这一枪

还有一个值得玩味的问题：为什么第一份把 agent 定性为攻击向量的国家级咨询，出自印度？答案藏在印度的产业结构里。印度是全球最大的 IT 外包和业务流程外包基地，大量欧美企业的生产数据、业务记录每天流经印度服务商的系统；同时印度本土的数字化进程极快，政府和企业都在大规模上 agent 做客服、做数据处理、做运维。数据流经的"手"越多，agent 能摸到的"门"就越多——CERT-In 恰好站在这个交叉点上，看得最早、最全。

另外，CERT-In 这些年本来就是"爱发咨询"的机构：它的职责之一就是给印度境内的关键信息基础设施发预警。这次把 agent 单列成 critical 咨询，说明在它收到的事件报告里，agent 相关事件已经多到了"不能再塞进通用咨询里"的程度。一个可以对照的坐标是：美国 CISA、欧盟 ENISA 目前还没有为"agent 本体"发过同级别的定性文件。印度的这份通告，很可能成为其他国家 CERT 跟进的模板——当 CISA 也开始写 "AI Agents as Attack Vectors" 时，全球 B2B 采购里的 agent 安全条款就会统一升级。vibe 开发者如果做的是出海 agent 产品，这份印度通告就是提前半年看到的考题。

还有一个技术史视角：安全行业每一次"入侵面"的重新定义，都伴随着一类新主体的出现。90 年代是"联网的 PC"，2000 年代是"Web 应用"，2010 年代是"移动 App 和云"，2020 年代上半场是"供应链"。CERT-In 这份通告，等于宣告 2020 年代下半场的入侵面主角是"自主 agent"——一个会自己读配置、自己调接口、自己批量拿数据的主体。以前我们防的是"人利用工具"，现在要防的是"工具自己动"。这个范式切换，比通告里的两类事件更值得记住。

透明度说明：这篇报道的证据链

按本站编辑规范，如实披露本文的信息来源与证据强度。CERT-In 官方网站（cert-in.org.in）上的咨询原文页面，我们在公开搜索中没能拿到可直接打开的直链——这不是我们没找，是确实没有返回可用的官方直链。本文关于通告内容的全部事实陈述，引自印度报业托拉斯（PTI）的通稿，以《HinduBusinessLine》该通稿承载页的全文亲开为一手核实载体（报道页时间戳：2026 年 10 月 16 日 06:38），并经由 Mint、《经济时报》（ET）、CDO Magazine、《印度快报》（Indian Express）等至少 6 家独立媒体交叉确认：咨询编号 CIAD-2026-0049、标题《AI Agents as Attack Vectors》、critical 级别、两类事件的描述、"没有一家受影响组织自行发现"等核心要素，在各家报道中高度一致。

证据强度评估为"中-强"：强在多家独立来源对核心事实的交叉一致性；弱在咨询原文直链未获，本文属于"经 PTI 通稿口径的二手转述"，而非官方原文直引。日期口径差异一并说明：多数来源标注咨询签发日为 10 月 15 日，个别聚合页写作 10 月 16 日，HinduBusinessLine 报道页为 10 月 16 日 06:38——本文采用"10 月 15 日签发、10 月 16 日广泛报道"的表述。文中 6 处英文 blockquote 均为逐字引自 HinduBusinessLine 亲开全文的 PTI 通稿原文，未做改写。其余分析、判断与防御清单为本刊编辑观点，不代表 CERT-In 立场。