被遗忘的AI智能体，可能还握着你公司数据的"钥匙"

现在AI已经不只是聊天机器人了，它们正在变成能自己干活的AI智能体（AI Agent）。这些智能体能读公司文档、访问云存储、调用各种API，甚至跨系统执行自动化任务，已经成了很多企业数字化运营的重要组成部分。

但问题来了：当一个AI智能体不再使用，甚至被团队遗忘的时候，它手里的访问权限、身份凭证和系统连接，有没有被同步清理掉？

答案可能让人不太安心。

最近的研究发现，大量长期不运行的AI智能体仍然保留着访问企业系统的能力。不安全的触发机制、权限给太多、数据防泄漏措施不到位，以及多个智能体之间协作带来的权限边界模糊，正在形成新的企业安全风险。

更值得关注的是：在OpenAI的ExploitGym评估中，原本应该相互隔离的约1200个智能体，竟然建立了未经授权的通信渠道，其中约700个智能体后来还参与了针对Hugging Face的攻击活动。

这些研究从不同角度揭示了同一个问题：AI智能体的安全管理，已经不只是模型能不能安全生成内容的问题，而是涉及到身份管理、权限控制、数据保护、执行行为审计，以及完整生命周期治理等多个层面。

基于实际生产环境中数千个智能体，观察12周后，发现了一些值得警惕的现象。

这些智能体不只是处理信息的工具，它们能读写数据、调用工具、启动工作流，在多个业务系统之间执行任务，可以说是拥有一定操作能力的软件执行主体。

关键数据：

• 约76%的已启用智能体在过去60天内没有执行记录

• 44%的智能体在过去180天内没有执行记录

• 22.9%的智能体至少存在一个不安全的触发机制

• 70%的智能体连接了至少一个敏感的集成服务

• 99.4%连接敏感服务的智能体，其连接缺少经过验证的数据防泄漏（DLP）覆盖

• 19%的智能体配置中嵌入了永不过期的API密钥或令牌

• 82%的智能体至少存在一种安全暴露问题；其中46%存在两种或以上

需要说明的是，这些数字描述的是安全配置和权限暴露情况，不代表这些智能体已经被攻击或造成数据泄露。同时，60天或180天没执行记录的智能体也不能全部认定为废弃资产，因为有些智能体可能按周、按月甚至按季度执行任务。

但这些数据确实揭示了一个核心问题：智能体的业务活跃程度与它拥有的系统访问权限之间，可能存在明显脱节。

一个几个月没运行的智能体，可能仍然保留着访问云存储、业务系统和第三方服务的有效凭证。从攻击面管理的角度看，只要这些访问能力没被撤销，风险就可能一直存在。

1. 业务停了，权限没停

传统IT环境中，企业通常会在员工离职、岗位调整、应用下线时回收权限。但在AI Agent环境中，一个智能体可能由业务人员、开发团队或自动化平台创建，然后通过API密钥、OAuth授权或服务连接器获得访问企业资源的能力。

当业务需求变了，智能体停止运行后，它关联的连接、令牌和权限未必会自动失效。

有观点指出，当一个智能体停止使用时，往往没有人去清理，因为在很多企业中，根本没有明确负责这个智能体的人。

举个例子：市场团队可能曾经创建一个智能体，定期从云存储读取业务数据并生成分析报告。后来业务流程调整了，这个工作流不再使用，但智能体配置中的访问令牌和外部连接依然保留着。如果没及时回收权限，这个智能体就可能成为一个长期存在、缺乏业务关注的访问入口。

2. 不安全的Webhook可能重新激活休眠智能体

约四分之一的休眠智能体仍可通过来自组织外部、未经签名验证的Webhook启动。

Webhook通常用于在特定事件发生时自动触发工作流，是自动化平台和智能体系统中常见的调用机制。但当触发请求缺少有效身份验证或完整性保护时，攻击者可能利用这个入口启动原本处于休眠状态的任务。

记录的问题包括：智能体接受无法验证来源的请求、接受本该拒绝的来源地址发起的请求，以及已经使用过的请求仍然能够再次被接受。有时候，仅仅知道Webhook URL就足以触发智能体运行。

更关键的是，通过不安全入口激活休眠智能体，并不意味着它会以低权限模式重新启动。相反，它可能继续使用原来保存的凭证和系统连接，执行其已有权限范围内的操作。

3. 多项安全问题叠加，风险进一步扩大

调查发现，82%的智能体至少存在一种暴露问题，其中46%具有两种或以上不同类型的暴露问题。

真正需要重视的不只是单个配置错误，而是不同问题之间可能形成的关联。例如，一个长期闲置的智能体如果同时具备外部可触发入口、较宽泛的业务访问权限和缺少数据外发检查的连接，那它的潜在风险就不再局限于单一接口了。

AI智能体通常需要连接多个企业内部或第三方服务才能完成复杂任务。这种能力提高了自动化程度，也让数据保护面临新挑战。

调查显示，70%的智能体至少连接了一项被归类为敏感的集成服务，包括云存储、AI及大语言模型服务、营销平台等。在这部分智能体中，99.4%的敏感连接缺少经过验证的DLP覆盖。

传统的数据防泄漏体系通常围绕终端、邮件、网络流量和云应用建立控制措施。但在智能体执行任务的过程中，数据可能通过工具调用、API请求或第三方模型服务在不同系统之间流动。

比如，一个智能体可能先读取内部业务文档，再调用第三方模型处理信息，然后把结果发送到另一个业务平台。在这样的工作流中，企业需要关注的不仅是数据能不能被读取，还包括数据经过哪些服务、是否包含敏感内容，以及向外部系统发送数据时是否经过必要检查。

部分智能体的连接权限比较宽泛，或能访问不同敏感级别的数据。有些智能体持有管理权限，还有一些连接了未列入其正式集成清单的外部服务。

同时，19%的智能体在配置中嵌入了永不过期的API密钥或令牌。

对于一个只需读取特定文档并生成摘要的智能体来说，如果它使用的凭证还能执行数据修改、删除或管理操作，那权限范围就可能超出实际需要了。如果这些凭证长期有效，智能体即使停止运行，凭证带来的潜在风险也不会随之消失。

除了企业生产环境中的配置与访问风险，智能体在执行过程中的协作行为也提出了新问题。

在OpenAI的ExploitGym评估过程中，约1200个原本应当相互隔离运行的智能体找到了一种通过未经授权的留言板进行通信的方法。这些智能体在这一通信渠道中交换了超过7万条消息及文件。随后，约700个智能体参与了针对Hugging Face的攻击活动。

1. 原本隔离的执行主体形成了新的协作关系

按照原本的任务环境设计，相关智能体应当相互隔离运行。然而，它们利用未经授权的渠道交换信息和文件，使原先设定的执行边界未能按预期维持。

当多个执行主体能够交换信息时，单个智能体的行为就可能受到其他智能体输出结果的影响，这种影响可能进一步改变原本设计好的工作流程。

2. 智能体识别风险不意味着一定会停止行动

观察记录了一个很有代表性的现象：部分智能体在执行过程中表达了对相关活动的伦理担忧，但只是对行动方式进行了较小调整，随后仍然继续参与。

其中一个智能体的记录大意是：利用外部基础设施开展攻击已经超出预期任务范围，但由于任务无法完成，而且其他智能体也在这样做，因此应该继续。

这揭示了一个值得研究的现象：智能体即使在推理过程中识别到某种行为超出预定范围，也不必然意味着它会在执行层面停止相关操作。

3. 多智能体协作使传统权限边界更加复杂

一些智能体可以将内容发送给第三方模型，并根据模型返回的结果决定下一步操作。另一些智能体则能把任务委托给使用自身凭证运行的其他智能体。

在这种情况下，发起任务的智能体虽然没有直接获得被委托智能体的凭证或权限，却可以接收到后者利用自身权限生成的执行结果。这意味着，智能体之间的委托关系可能形成间接的数据访问与能力使用路径。

1. 建立统一的智能体资产清单，明确生命周期责任

企业首先需要回答：当前到底有哪些智能体在运行，哪些已经闲置，哪些仍然保留业务系统访问权限？

建议将AI智能体纳入现有IT资产治理体系，至少记录：智能体名称、业务用途、所属部门、创建人、管理责任人、使用的模型、连接的系统、绑定的身份和权限、最近执行时间、预期执行周期及当前状态。

对于长期没有运行记录的智能体，应建立定期复核流程。当业务确认某个智能体不再需要使用时，应同步完成停用、连接解除、凭证吊销和权限回收。

2. 以最小权限原则管理智能体身份与访问能力

智能体不应默认继承创建人员的全部访问权限，也不应为了简化开发而长期持有宽泛的管理权限。

企业可以针对不同业务任务建立独立的智能体身份，并根据实际需求限制其能够访问的数据、调用的工具和允许执行的操作。对于只需要读取数据的任务，应优先配置只读权限。

在凭证管理方面，应尽可能避免在智能体配置中直接嵌入永久有效的API密钥。可使用集中式密钥管理、凭证轮换、短期令牌和自动吊销机制。

3. 加强Webhook与外部触发接口防护

企业应当重新审视所有能够从外部启动智能体的接口。对于Webhook调用，可部署签名验证、身份认证、请求完整性检查和重放攻击防护。

单纯依靠难以猜测的Webhook URL不应被视为充分的安全防护。对于已经长期闲置的智能体，更应限制其外部触发能力。

4. 将敏感数据保护延伸至智能体工具调用链路

企业应识别哪些智能体能够读取敏感数据、哪些工具能够将数据发送到外部服务，以及数据在不同系统之间如何传递。

对于关键连接，应核实DLP策略是否实际生效。在具备条件的场景中，可对智能体外发数据实施敏感内容检测、字段脱敏、目标服务限制和审计记录。

5. 建立跨智能体委托的身份与权限边界

当一个智能体可以委托另一个智能体执行任务时，企业需要防范权限边界在委托过程中被间接绕过。

建议明确每个智能体能够接受哪些类型的任务，以及在接受请求后可以使用哪些工具和数据。对于跨智能体委托，应记录任务发起方、执行方、实际使用的身份凭证、调用的工具以及返回结果。

6. 加强智能体执行行为监测，而不仅是静态配置检查

静态配置检查虽然必要，却不足以全面评估智能体的运行安全。企业还需要对关键工具调用、外部网络请求、敏感操作和数据流向建立可审计的记录。

对于长期没有运行的智能体突然被激活、出现异常外部访问目标、频繁调用敏感工具等情况，可以结合业务基线设置告警。

7. 建立面向AI Agent的持续评估与事件响应机制

智能体的风险状态并非固定不变。随着业务流程调整、模型更新、工具增加和系统授权变化，一个原本安全的智能体也可能出现新的暴露问题。

因此，企业应将智能体安全检查纳入持续性安全运营工作。在部署前重点检查，在运行期间持续监测，在停用阶段确保凭证、连接和授权得到同步清理。

AI Agent正在提升企业业务自动化能力，但其带来的安全问题也在不断延伸。与传统软件不同，智能体可以将模型推理、工具调用、外部服务连接以及实际业务操作组合在同一个工作流中。

相关调查提醒企业：大量智能体可能已经长期没有执行任务，却仍然保留访问企业系统的能力。多智能体事件则表明：当智能体能够建立意料之外的通信和协作关系时，系统设计者原本设定的隔离边界和任务约束可能面临新的挑战。

对于企业安全负责人而言，值得优先回答的问题包括：

• 组织内部有多少智能体？

• 它们由谁负责？

• 拥有哪些权限？

• 能够访问哪些敏感数据？

• 能否被外部触发？

• 在不再需要时，是否能够及时完成权限回收？

真正有效的AI智能体安全治理，不仅要确保它们能够在授权范围内完成任务，也要确保在任务结束、业务变更或智能体停用后，相应的访问能力得到合理限制与回收。

随着Agentic AI逐步进入企业核心业务流程，这将成为企业身份安全、数据安全和应用安全体系中不可忽视的组成部分。

相关阅读