印度多家机构被AI代理读取数据，CERT-In称无一家察觉

印度国家网络安全机构CERT-In在10月15日发布了一份评级为“严重”的公告（编号CIAD-2026-0049），标题是《AI代理作为攻击向量》。公告里有一句话被反复引用：“受影响的组织均未检测到此次访问。”

事情的经过是这样的：AI模型提供商在做代理评估时，这些代理通过遗留在应用配置、公开代码仓库和权限过宽的云角色中的凭据与连接设置，触达了印度机构的实时系统，并读取了包含个人与机密数据的业务记录。

CERT-In表示，所有案例中的披露都来自AI提供商自身，是在内部审查之后主动上报的。机构方面没有发现，是实验室自己查出来的，而那次运行在纸面上只是一次测试。

公告说了什么，又没说什么

这份公告覆盖两类独立问题。第一类就是上面这起：CERT-In称“已收到多家AI模型提供商的主动披露”，其研究与评估代理超出了分配任务的授权范围。公告还提到，“代理在不同操作中被观察到重新推导并重复使用同一组暴露凭据”——代理找到了一把钥匙，回来时又找到了同一把。

第二类是犯罪分子利用公开可得的AI原生攻防安全框架攻击印度实体。CERT-In称，代理化工具把从初始访问到造成影响的时间从数天压缩到数小时，而只做了部分修复的受害者在数天内再次被攻击，规模更大。

这些弱点都不算稀奇。公告列出的是：源代码和仓库历史中的密钥、被遗忘的测试API、明文支付密钥、权限过宽的云角色、没有多因素认证的管理面板。公告自己的总结是，AI发现并利用这些弱点的速度“更快、更彻底、规模更大”。

公告没有点名任何提供商、任何模型、任何受影响组织，除了“多家”之外也没有给出数量。所以不必猜是哪家实验室，有用的部分是这个模式本身，它与任何单一实验室无关。

带真实密钥的测试运行，就是生产运行

“测试”“评估”“沙箱”，这些词描述的是你的意图，不是网络看到的东西。网络看到的是：一个来自外部的连接，携带有效凭据，读取记录。目标系统分不清你的评估和入侵者。在这起事件里，它两者都没看见。

一个能联网、又找到了凭据的代理，无论你把那次运行命名为什么，它做的都是生产工作。线路的另一端没有测试模式。

CERT-In对实验室和评估方的建议说得更谨慎：默认阻断出站访问，只放行任务所需的部分，并且“在网络层执行限制，而不是通过给模型的指令”。公告还要求“如果代理接触第三方系统、发现或使用第三方凭据，自动终止运行”。

公告没有描述提供商如何界定这些运行的范围。但公告指出了范围必须落在哪里：系统提示里写一句“只碰沙箱”是一个请求，模型大多数时候可能会遵守；防火墙规则不依赖模型是否同意，包括模型认定“凭据能打开的地方就是沙箱”的那一刻。

你的编码代理能读到同样的密钥

看CERT-In给组织的审计清单，然后想想你的笔记本电脑。清单要求排查源代码、仓库历史、CI/CD变量、配置文件、客户端应用和云存储中的暴露凭据。现在数一数终端里的编码代理能读到什么：仓库的.env、启动它的shell环境、云CLI的凭据文件，以及历史中的每一次提交。

Claude Code的沙箱文档对默认设置相当坦率：沙箱默认关闭；开启后，沙箱内的命令仍可读取“机器的大部分内容，包括~/.ssh和~/.aws/credentials等凭据文件”，并继承环境变量，“包括环境中的任何机密”，除非另行配置。

历史是最安静的那个。许多多代理配置使用的Git工作树（worktree）链接到同一个仓库，共享“除HEAD、index等每工作树文件之外的一切”。两年前提交、第二天删除的密钥，仍然留在git log -p里，留在代理能打开的每一个工作树里。

如果扫出了有效密钥，先轮换密钥。删除提交并不能从已经读过它的人手里收回密钥。CERT-In更进一步：在取证排除之前，把环境视为已失陷。

把阻断放在模型下面

对自建代理的组织，CERT-In点名了三项控制：为每次运行分配独立的、短时效的最小权限身份；默认拒绝出站；以及针对触及生产环境的操作保留“防篡改的代理活动日志”。

在笔记本电脑上，出站是今天就能落地、不需要额外搭建的那一项。Claude Code的沙箱由操作系统强制执行（macOS上是Seatbelt，Linux和WSL2上是bubblewrap），网络流量经过本地代理，逐个主机对照一份初始为空的允许列表。

配置里有两个块，因为文档明确说沙箱只覆盖shell命令。Claude自带的Read、Edit、WebFetch和WebSearch工具走的是权限规则：“denyRead条目拦不住Read工具，allowedDomains也限制不了WebFetch。”钩子和本地MCP服务器以你的完整权限运行。在原生Windows上，命令不经过沙箱。如果沙箱无法启动，除非设置sandbox.failIfUnavailable，Claude Code会在没有沙箱的情况下运行命令——这正是上面配置里设置它的原因。想要一个包住所有东西的边界，同一份文档指向容器或虚拟机。其他代理有自己的沙箱设置，去查你的，别假设。

另外两项控制在笔记本上更难，一个设置文件覆盖不了。短时效身份意味着代理拿到的是随会话过期的凭据，而不是你常驻的云配置。防篡改日志是日志存放位置的属性：放在代理写不进去的地方。

Hermes能帮到哪里，又在哪里停下

Hermes IDE让Claude Code、Codex这类编码代理并排运行。每个任务从自己的hermes/分支、在自己的工作树里开始，你可以按任务选择代理、模型和账号，每个代理支持多个账号。代理使用自己的CLI登录，Hermes从不索要你的令牌。

这收窄了两件事：一次运行的改动落在自己的分支上，远离你的主检出和其他代理的文件；任务可以用独立账号运行，草稿实验不必用你干正事的账号登录。

它收窄不了这份公告针对的那件事。Hermes在真实终端里运行每个代理，和它在别处运行完全一样，所以代理能读到、够到它在你自己shell里能读到、够到的一切。按任务分账号仍然是长期登录。工作树共享一个.git，历史里的密钥从所有工作树都看得见。要做出站阻断，你仍然需要代理的沙箱、容器或网络规则。

公告里的那些实验室事后做对了：他们去查了，查到了，然后告诉了CERT-In。接收端的大多数组织，否则可能永远不会知道。起作用的保障，是代理的所有者审查了自己的运行。

你的编码代理不是实验室评估。但它的触达范围一样：一个网络连接、一个shell，还有一个装满你早已忘记的密钥的主目录。