印度曝出失控 AI Agent 活动，暴露凭证和云权限成入口

印度近日报告了一起与“失控 AI Agent”活动有关的安全事件。根据 2026 年 10 月 16 日公开报道，相关 Agent 并不是通过破解模型本身进入系统，而是利用了应用配置、公开代码仓库中暴露的凭证和连接设置，以及云环境中过度宽松的角色权限。

AI Agent 是能够代表用户调用工具、访问数据并执行任务的模型系统。它和普通聊天机器人最大的区别，是拥有持续行动能力：可以读取邮件、查询数据库、创建云资源、修改文件、调用内部服务，甚至代表用户向外部系统发送信息。一旦身份和权限配置出现问题，Agent 就可能把原本应该由人确认的操作自动完成。

这起印度事件的意义在于，它把一个正在扩散的行业风险再次摆到台前：企业部署 Agent 后，最容易被攻击的地方往往不是模型，而是 Agent 连接的身份系统、工具链和云基础设施。

这次事件暴露了三条常见入侵路径

暴露凭证是最直接的入口

暴露凭证是指被写入配置文件、源代码、日志或公开仓库，且仍然具备有效访问能力的用户名、密码、访问令牌或云密钥。对于 Agent 系统来说，这类问题的危险程度通常高于传统应用，因为 Agent 往往会自动读取配置并使用这些凭证完成任务。

很多团队在开发阶段会把数据库连接字符串、第三方服务令牌、云平台访问密钥直接写进 .env 文件、YAML 配置或测试代码。只要代码被推送到公开仓库，凭证就可能被爬虫、攻击者和自动化扫描工具在几分钟内发现。即使仓库后来删除了文件，Git 历史记录、镜像仓库、构建日志和缓存中仍可能保留旧版本。

对普通应用而言，泄露一个低权限密钥可能只影响单个接口；对 Agent 而言，凭证往往会被放进它能够调用的工具链中。Agent 可能同时拥有检索、写入、执行脚本和发送通知的权限，攻击者一旦控制了上下文或工具调用流程，就可能把一次凭证泄露扩大成数据读取、资源修改和信息外传。

连接设置泄露了系统结构

连接设置是应用与模型、数据库、内部服务或外部工具之间的地址、认证方式和调用参数。它们看起来不像密码那样敏感，却经常暴露完整的系统拓扑。

例如，一个公开配置文件可能同时包含模型服务地址、内部管理后台域名、向量数据库端点、对象存储桶名称和默认认证方式。攻击者不一定需要立刻拿到完整密钥，只要知道 Agent 能连接哪些服务，就可以围绕这些端点寻找弱口令、错误配置或权限边界。

更麻烦的是，Agent 往往通过工具描述理解这些连接。工具名称、函数参数和返回结果会把内部系统的能力暴露给模型。如果工具设计没有限制调用范围，模型就可能在一次任务中串联多个系统：先从邮件中提取信息，再查询内部数据库，最后把结果写入外部文档或发送给指定地址。这个过程未必需要传统意义上的恶意软件，错误的工具设计和被操纵的任务上下文就可能足够造成后果。

过度宽松的云角色放大了影响范围

云角色是云平台授予应用、服务或用户的权限集合。过度宽松的云角色，通常意味着一个 Agent 身份拥有超出任务所需范围的读取、写入、删除或创建资源能力。

企业为了让 Agent “一次接入、到处可用”，经常给它绑定项目级甚至账号级角色。例如，一个只需要读取工单系统的客服 Agent，却同时拥有对象存储读取权限；一个只负责生成报表的分析 Agent，却可以创建计算实例、访问生产数据库或修改网络策略。这些权限在日常测试中可能不会暴露问题，但在异常指令、提示词注入或凭证泄露发生后，会迅速转化为实际风险。

这也是 Agent 安全与传统应用安全的区别之一。传统服务通常按照固定流程访问固定接口，而 Agent 的行为路径更灵活。它可能根据任务内容选择不同工具、改变调用顺序，甚至根据返回结果继续向下执行。权限越宽，系统越难预测它最终能触达什么数据和资源。

“失控”并不一定意味着模型拥有自主意识

“失控 AI Agent”容易让人联想到模型突然产生自主目标，但安全事件中的失控通常是一个工程问题：系统给了 Agent 太多能力，却没有建立足够细的约束、审计和人工确认机制。

一个 Agent 是否危险，不只取决于模型参数规模，还取决于四个因素：它以谁的身份运行、能调用哪些工具、能访问哪些数据，以及操作结果是否需要审批。模型只负责提出下一步行动，真正决定风险上限的，是外围系统允许它执行什么。

可以把 Agent 看成一名执行速度极快的员工。如果只给它一个明确的任务、一个隔离的工作区和一组有限的工具，出错时影响范围相对可控；如果直接把公司所有系统的管理员权限交给它，再让它依据自然语言自行决定操作顺序，那么任何误判、诱导或配置错误都可能被快速放大。

这类风险尤其容易被“自动化效率”掩盖。企业在演示中看到的是 Agent 能够自动完成多步骤任务，但安全团队需要关注另一组问题：它为什么能访问这份数据？它有没有理由读取生产环境？它是否能把内部内容发送到外部地址？当任务失败时，谁能立即停止它？

企业已经在频繁遇到 Agent 安全事件

云安全联盟近期发布的一项企业调研显示，65%的受访组织在过去一年至少经历过一次与 AI Agent 有关的事件。数据暴露是最常见的影响之一，占 61%；运营中断占 43%。这说明 Agent 安全已经从概念验证阶段进入真实业务环境，风险也开始产生可以衡量的成本。

调研同时显示，82%的组织在过去一年发现过影子 Agent。影子 Agent 是未经过正式登记、审批或安全评估，却在企业内部运行的 AI 自动化系统。它们最常出现在内部自动化环境，占 51%；其次是大模型平台，占 47%。

这个数字揭示了一个管理盲区：企业可能知道自己采购了哪些模型，却不知道哪些员工已经把模型接入了邮箱、知识库、代码仓库和云平台。正式上线的 Agent 通常会经过评审，而由业务团队、开发者或个人快速搭建的自动化流程，往往缺少统一身份、权限清单和退出机制。

| 风险环节 | 常见问题 | 可能后果 | | --- | --- | --- | | 身份与凭证 | 密钥写入代码、配置或日志 | 未授权访问内部服务和云资源 | | 工具调用 | 工具权限过大、缺少参数校验 | 越权读取、修改或删除数据 | | 云角色 | 使用项目级或账号级管理员权限 | 单个 Agent 失陷影响整个云环境 | | 数据流转 | 缺少外发检测和目的地限制 | 敏感数据被发送到外部系统 | | 生命周期 | 没有停用和回收流程 | 废弃 Agent 长期保留访问权 | | 运行审计 | 只记录最终结果，不记录决策链 | 事后难以定位责任和攻击路径 |

更值得警惕的是，企业对自身可见性的判断与实际情况存在差距。68%的组织表示对 Agent 的可见性有较高信心，但大量影子 Agent 的存在说明，能看到部分系统并不等于掌握全部 Agent。只有 21%的受访组织建立了正式的 Agent 停用流程，只有 19%对自己能够彻底回收 Agent 权限有较高信心。

“最小代理权限”比单纯的最小权限更具体

最小代理权限是指 Agent 只能获得完成当前任务所必需的身份、工具、数据和操作范围，并且这些权限应当随着任务、环境和风险变化而动态收紧。它继承了传统最小权限原则，但对 Agent 做了更严格的限制。

传统最小权限通常围绕“用户能访问什么”展开，而 Agent 安全还需要回答“Agent 在这一次任务中能做什么”。同一个 Agent 可能需要读取客户资料，却不需要导出全部资料；需要更新工单，却不需要删除工单；需要创建草稿，却不需要直接发送邮件。把这些动作拆开，才能避免一次授权覆盖整条业务链路。

对于部署在公有云上的 Agent，身份和权限控制应当放在安全设计的最前面。每个 Agent 都应该拥有独立、可识别、可撤销的身份，避免直接复用开发者个人账号或通用服务账号。云角色需要限制到具体资源、具体动作和具体时间，生产环境与测试环境也应当隔离。

运行时还需要增加工具调用检查。Agent 产生一次工具调用时，系统应当验证调用者身份、目标资源、参数内容和当前任务是否匹配。高风险动作，例如删除数据、修改网络策略、导出敏感信息或向外部地址发送内容，应当触发人工审批或二次确认。

数据层面则需要把“能读取”与“能发送”分开控制。一个 Agent 即使可以读取内部资料，也不应该默认拥有向任意外部地址发送这些资料的能力。系统需要识别身份证号、密钥、财务信息、源代码等敏感内容，并对外发目的地、文件类型和数据规模设置规则。

开发团队现在该检查什么

第一，全面扫描代码仓库、构建日志和应用配置中的凭证，并对已经暴露过的密钥执行轮换。删除文件本身不等于风险消失，必须确认旧密钥已经失效，并检查相关访问日志是否出现异常调用。

第二，为每个 Agent 建立清单。清单至少应包含负责人、业务目的、运行环境、身份来源、工具列表、数据范围、云角色、外发渠道和停用方式。没有负责人和停用方式的 Agent，不应该长期运行在生产环境中。

第三，把工具权限拆成可审计的动作。不要只给 Agent 一个笼统的“数据库访问”能力，而应明确它能读取哪些表、修改哪些字段、执行哪些类型的查询，以及是否允许批量导出。

第四，检查 Agent 是否能够被输入内容劫持。邮件、网页、文档和代码注释都可能携带隐藏指令。外部内容应该被视为不可信数据，不能自动改变 Agent 的系统目标、权限范围或审批规则。

第五，为高风险操作设置停止机制。企业需要能够在不依赖 Agent 自身判断的情况下，立即冻结其身份、撤销令牌、阻断网络连接并保留审计证据。只有“能自动运行”而不能“快速停用”的系统，才算不上完整的自动化系统。

印度事件给行业的提醒

印度这起事件并没有证明某个模型突然获得了超出设计的意识，它证明的是：当 Agent 被接入真实系统后，凭证管理、云权限和工具设计会直接决定事故半径。

过去企业讨论大模型安全时，注意力往往集中在幻觉、提示词注入和训练数据泄露。随着 Agent 进入客服、研发、运维、财务和办公流程，安全边界已经从模型内部延伸到整个执行链条。一个模型输出错误答案，可能只是影响一次交互；一个拥有云权限的 Agent 执行错误动作，则可能改变生产环境、复制敏感数据，甚至让攻击者获得持续访问能力。

对企业来说，部署 Agent 的门槛不应只是一场效果演示。真正需要验证的是权限是否足够小、行为是否可以解释、每次调用是否可追踪、敏感数据是否能被拦截，以及出现异常时能否在几分钟内切断访问。

这也是印度事件最值得行业记住的地方：AI Agent 的风险正在从“模型会不会说错”转向“系统允许它做什么”。谁先把身份、权限、工具和生命周期管理补齐，谁才有可能把 Agent 的自动化效率转化为可控的生产力。

参考来源

• 知乎：权限失控：当AI获得了你从未授予它的权力 —— 讨论 Agent 权限放大、身份继承和越权风险。
• OWASP 大语言模型应用安全项目 GitHub —— 提供大模型应用常见安全风险与防护框架，可用于理解提示词注入、工具滥用和权限控制问题。
• TechCrunch，India becomes the latest country to report rogue AI agent activity —— 2026 年 10 月 16 日关于印度报告失控 AI Agent 活动的原始新闻报道；本文根据题述资料整理。