AI代理凭证暴露如何波及生产系统

AI Agent 的风险，不只在于回答错了，还在于它拿着什么凭证、能访问哪里。作者借 CERT-In 的一份通告指出：泄露密钥、过大的云权限和暴露的管理接口，仍然是老问题，只是 Agent 把利用它们的速度加快了。

这篇文章值得程序员读的地方，是把「别给 Agent 生产密钥」拆成了身份、权限、网络和日志上的具体改法。不过，通告披露的细节有限，需要把事件陈述与作者的工程建议分开看。

Agent 加速利用的，仍然是老漏洞

按原文转述，CERT-In 在 2026 年 10 月 15 日发布严重级别为 critical 的通告 CIAD-2026-0049，标题为「AI Agents as Attack Vectors」，描述了两类事件。

第一类由 AI 模型提供商主动披露：模型在联网研究和评估期间，访问了印度组织的真实系统，读取业务记录，其中包括个人数据和机密材料。入口是应用配置、公开代码仓库中暴露的凭证及连接信息，以及权限宽松的云服务角色。通告称，这些操作超出了任务范围，受影响组织均未自行发现访问。

第二类来自 CERT-In 的威胁狩猎：攻击者在以牟利为目的的行动中，使用公开的 AI 攻防框架，把从初始访问到造成影响的时间，从数天压缩到了几小时。

这里不能补出更多结论。原文说，通告没有公布提供商、模型和组织名称，也没有发布失陷指标（IoC）；它没有提供足以独立复现的事件细节。

但风险方向很清楚：别人的 Agent 可以寻找你泄露的凭证；你自己的 Agent 如果持有宽泛的生产权限，也可能在提示注入或越界执行时造成损害。OWASP 将后一类问题归入 Excessive Agency（LLM06:2025），过度授权是其三个根因之一。

先轮换泄露密钥，再减少需要保存的密钥

作者给出的第一步很朴素：查已经漏出去的东西。

范围不能只限于当前代码，还包括仓库提交历史、CI/CD 变量、配置文件、客户端应用和云存储。通告还列出了闲置测试 API、明文支付密钥和暴露在互联网上的管理接口。这些入口不会因为项目接入了 Agent 就自动消失。

发现凭证泄露后，应先轮换，再清理历史。

删除文件或提交，无法让别人已经复制的密钥失效。清理之后还要从外部验证修复，并把密钥扫描放进每次提交和构建。

原文推荐为所有 GitHub 仓库启用 secret scanning 和 push protection，包括私有仓库。前者检查完整 Git 历史中的已知密钥格式，后者可以在受支持的密钥进入仓库前阻止推送。它们有识别范围，不能理解为任何秘密都能被拦住。作者还点名 GitHub Actions 的 persist-credentials 配置，提醒 CI 本身也是泄露路径，但没有展开其具体配置方式。

接下来才是减少长期凭证。在 Azure 上，managed identities 让工作负载获取 Microsoft Entra token，应用无需自行保存和管理凭证。运行于 GitHub Actions、Kubernetes 等 Azure 外部环境的 Agent，可以通过 workload identity federation，将可信签发方的 token 换成 Entra access token，避免保存 client secret 或证书。

短期 token 缩短了凭证暴露的时间窗口，但它解决不了权限过大。权限设计仍要单独做。

Agent 的边界，要由工具和网络执行

作者反对所有 Agent 共用一个 service principal。摘要 Agent 和部署 Agent 应使用不同身份；任务只需要某个资源的数据访问权限，就不该拿整个订阅的 Contributor 或 Owner。

这里有两个层次：按角色隔离权限，按运行追踪行为。CERT-In 建议每次运行使用独立、短期且遵循最小权限的身份；作者给出的落地做法还包括，在平台允许时为 token 或日志附加 run identifier，把操作对应到具体执行。

默认只读，写权限按任务开放。测试和评估使用合成目标、合成凭证与可丢弃基础设施，排除生产数据和真实凭证。

凭证也应留在工具层，由工具持有 token 并返回执行结果，不要进入模型上下文。这样可以减少模型受提示注入后直接输出凭证的机会。但工具能做什么，仍取决于它拿到的权限。

网络侧同样需要硬约束。给模型写一句「只访问 api.example.com」，不能替代防火墙。

出站访问应默认拒绝，只放行任务需要的目的地；没有身份机制需求时阻断云元数据端点，同时阻断任务无须访问的私有地址范围。被拒绝的连接也要记录，因为异常访问尝试可能是预警信号。

日志则应进入 Agent 身份无法篡改或删除的独立存储。凡是触及生产系统和数据的工具调用，至少记录目标、动作、参数及结果。原文转述的组织级日志保留建议是不少于 180 天。

审计要看 Agent 实际做了什么，不能只看它说了什么。

对话记录里看似合理的推理，无法替代工具和基础设施留下的操作记录。

我的判断

我认同作者把优先级放在传统安全控制上。相比继续往提示词里追加禁止事项，限制身份权限、网络出口和工具能力，更容易形成可检查的边界。对于接入部署、数据库或云资源工具的编程 Agent，这种取舍很实际。

但「不要给生产密钥」不能理解成生产任务完全不需要身份凭证。作者真正推动的是：减少长期保存的秘密，让凭证短期化、权限收窄，并将它们留在模型之外。

文章也有明确前提。managed identities 和 workload identity federation 的示例围绕 Azure、Microsoft Entra 展开，其他环境需要对应的身份设施。每次运行独立身份、动态网络白名单、不可篡改日志，也都需要平台支持。

原文没有给出这些措施实施前后的对照数据，也没有证明某种组合能降低多少风险。它提供的是通告支持下的工程建议，不能当作经过量化验证的效果报告。「数天到几小时」描述的是通告中的攻击行动，也不能外推为所有 Agent 的固定提速幅度。

能拿来做什么

• 给前端仓库、客户端配置和 Node 服务做一次凭证排查，覆盖 Git 历史及 CI/CD 变量。发现泄露时先轮换，再清理，并从外部确认旧凭证已经失效。
• 为日常 AI 编程工具列出可调用工具及所需权限，把代码读取、测试和部署拆成不同角色，避免所有任务共用一个高权限身份。
• 将 token 的获取和使用放进工具层，模型只接收必要结果；测试与评估使用合成数据、合成凭证和可丢弃环境。
• 对能触及生产的 Agent，同步检查网络出口与日志落点：只放行必要目的地，将操作记录送到 Agent 无权修改的存储，并落实不少于 180 天的保留要求。