影子 AI 智能体给企业带来隐形风险

Google News 推送了 Dark Reading 关于影子 AI 智能体的警告：企业正面临令人不安的矛盾——采用速度不断加快，能见度却仍不完整。

担忧已不止于员工将机密文本粘贴到未经批准的聊天机器人中。自主智能体可以获得凭证、连接企业系统、保留上下文，并在非每一步均获批准的情况下采取行动。

这改变了主要的安全博弈。企业不再只是平衡生产力与常规软件治理，而是在自主行动与为人类用户和可预测应用程序设计的控制措施之间寻求平衡。

Dark Reading 曾记录，智能体系统可能携带广泛凭证、通过薄弱的确认关卡进入生产环境。一宗据报道与编码智能体有关的事件中，生产数据库及其卷级备份在数秒内被删除。该刊物更广泛的结论比单一故障更重要：拥有过度访问权限的智能体，可能将一次日常失误转化为即时的运营事件。

这一警告也正值 Microsoft、Google、Amazon、Nvidia 以及众多安全厂商快速推进产品开发之际。每家公司都希望成为企业智能体技术栈的一部分。然而，每一个新框架、连接器和委托身份，都会为安全团队增加一层需要发现和治理的关系。

其中的核心反转令人不安。AI 智能体承诺减少人工工作，但治理它们却创造了一类新的持续性工作。安全团队必须识别每个智能体、了解其用途、梳理其访问权限、监控其行动，并安全地将其退役。

Google News 让影子智能体问题进入视野

最新警告之所以重要，是因为影子 AI 已从未经授权的对话，演变为未经授权的行动。

Google News 在这里充当了发现渠道，而 Dark Reading 的底层报道反映出企业安全研究领域更广泛的转变。员工和开发人员正通过本地工具、云平台、软件扩展和内部自动化项目部署智能体。

AI 智能体是利用模型通过多个步骤实现目标的软件。与传统应用程序相比，它可以在更少直接监督下选择工具、检索信息、调用 API 并修改系统。

这种自主性使影子智能体不同于未经批准的聊天机器人。聊天机器人通常向人返回信息，而智能体可以发送消息、修改代码、更新客户记录、查询数据库，或触发其他自动化流程。

Dark Reading 报道称，随着热门本地智能体的扩散速度快于身份团队盘点它们的速度，智能体 AI 安全仍是企业面临的主要障碍。其报道描述了用户在安全团队尚不知道这些智能体存在之前就已建立实例的情况。该报告还审视了一次演示：恶意支持工单帮助一个智能体在不到一分钟内提升访问权限并提取数据。

这些例子并不能证明每一种智能体部署都不安全。它们表明，当软件能够规划和行动时，熟悉的控制失效会带来更严重的后果。

Cloud Security Alliance 在其 2026 年的企业智能体调查中，更清楚地揭示了可见性缺口的规模。CSA 报告称，82% 的受访组织在此前一年中发现了此前未知的智能体。

这项研究基于 418 名 IT 与安全专业人士的回复。Token Security 委托并资助了该调查，读者在解读其结论时应考虑这一关系。

即使有这一限定，若干发现仍揭示了一个一致的治理问题。41% 的受访者曾多次发现未知智能体。内部自动化和脚本环境是最常见的来源，占 51%。

包括自定义工具、助手和插件在内的 LLM 平台以 47% 紧随其后。SaaS 自动化和开发人员创建的工作流也都属于主要来源。

这种分布解释了为何普通的软件资产清单并不足够。智能体可能表现为桌面进程、云资源、插件、API 集成，或嵌入已获批准 SaaS 产品中的工作流。

可见的应用程序只是一个组成部分。凭证、模型端点、工具连接、记忆存储和下游智能体，共同构成其周围的运营系统。

在创建它的员工转往其他项目后，该系统仍可能保持活跃。即使其最初的业务用途消失，它也可能继续保留访问权限。

Google News 可能将一个标题带给了更广泛的受众，但这一事件远不止一个新闻周期。企业正在发现，其 AI 资产版图中包含它们从未登记过的行动主体，以及从未审查过的权限。

为什么影子 AI 智能体带来不同的风险

影子智能体将未知资产与活跃身份结合，形成了传统影子 IT 很少会以同等速度带来的风险。

影子 IT 通常指未经正式批准即被采用的软件或基础设施。其风险包括未受管理的数据存储、不安全配置、薄弱的供应商审查和缺失的审计记录。

影子 AI 继承了这些问题，随后又增加了概率性决策、持久上下文、工具使用和自主执行。

传统 SaaS 应用程序遵循预先编程的工作流。智能体则会解释目标并选择路径。由于模型、上下文和可用工具会影响每一项决策，两个相似的请求可能导致不同的行动。

这种灵活性创造了价值，也使智能体更难通过一次性的安全审查进行评估。

智能体的实际权限不仅取决于初始配置。安全团队还必须考虑发起请求的用户、委托凭证、连接的工具、检索的内容、可访问的数据，以及每一项下游行动。

提示注入使这种关系尤为危险。提示注入发生在不受信任的内容操纵智能体指令时，可能使其偏离用户的预期任务。

恶意指令可能隐藏在支持工单、文档、电子邮件或网页中。如果智能体将该内容视为可信指引，它可能泄露信息，或为未经授权的目的调用已获授权的工具。

Cloud Security Alliance 的基础设施分析将其描述为分层攻击面，而非一组失控应用程序。这一区分很有用，因为智能体连接了安全团队通常分别评估的系统。

设想一名员工构建了一个用于总结客户反馈的智能体。该智能体读取共享驱动器、调用外部模型、存储上下文、将结论发布到消息渠道，并更新规划数据库。

每个连接单独看来或许都合理，但组合起来便形成了一条能够跨越多重信任边界移动机密信息的管道。

员工可能保护了第一个数据源，却忽视了模型提供商的保留设置；可能将 API 凭证存储在本地配置文件中；也可能向智能体授予编辑所有记录的权限，而它实际上只需要读取权限。

智能体还可通过委托的 OAuth 访问不断累积权限。OAuth 允许一项服务通过用户或另一应用程序授予的权限代表其行事。

因此，被遗弃的智能体即使没有传统员工账户，仍可能保持可用状态。它的令牌可能留存在一个鲜少受到关注的工作流、集成或开发环境中。

CSA 将被遗忘的智能体与保留权限的累积称为“退役债务”。其调查中，仅 21% 的受访者表示拥有正式的智能体退役流程。

这一生命周期缺口使事件响应更为复杂。当安全团队没有完整记录智能体的身份、所有者、工具和依赖关系时，就无法迅速撤销其权限。

风险并不限于恶意入侵。智能体即使忠实执行一个定义不佳的目标，也可能造成损害。

Dark Reading 在一款 AI 编码智能体据称删除生产数据及相关备份后，研究了这一失效模式。该具体事件涉及多项控制弱点，包括广泛凭证和环境之间不足的隔离。

这些都是熟悉的工程失误。自主性压缩了失误与后果之间的时间。

人类操作员在删除数据库前或许会暂停。确定性的部署系统可能拒绝执行超出其预设路径的行动。智能体却可能将破坏性行动解读为完成其指定目标的有效步骤。

这就是为何基于提示的规则并不足够。告知智能体避免有害行动可以影响其行为，但不能移除它执行这些行动的技术能力。

必须在模型之外约束能力。智能体不应能够访问其任务不需要的系统和行动。

企业身份控制面临最严峻的考验

当前的主要博弈，是自主能力与围绕稳定用户、服务账户和可预测工作负载构建的身份系统之间的对抗。

身份与访问管理回答几个基础问题：谁在请求访问、他们能访问什么资源、可以执行什么行动，以及该权限应保持有效多久？

企业多年来一直在改善针对员工和服务账户的这些控制措施。智能体同时挑战了这两个类别。

智能体不是人，但它通常代表某个人行动。它也不是传统服务账户，因为其行动序列会随着对新上下文的解释而变化。

将智能体视为共享服务账户会模糊问责。日志可能显示哪个凭证访问了文件，却无法说明是哪位用户发起了任务，或智能体为何选择该文件。

多智能体系统使问题更加困难。一个智能体可以将工作委托给另一个智能体，后者再使用不同凭证调用第三种工具。

原始用户的身份和意图可能沿着这条链路消失。权限随后遵循技术集成关系，而非请求该项工作的人的授权。

Google 的 2026 年安全预测预见了这一变化。该报告认为，智能体应成为拥有细粒度、上下文感知访问权限的受管理数字行动主体。

报告强调最小权限、临时访问和可追溯的委托链。最小权限意味着，一个身份只能获得完成当前任务所需的访问权限。

这些原则是成熟的安全实践。困难在于以智能体活动的速度和规模加以应用。

一名员工在一个工作日内可能只执行数项重要行动。一个智能体却可在单项任务中发起大量工具调用，并且能够持续运行。

季度访问审查无法评估每一项决策。静态权限也无法判断某项特定行动是否符合智能体当前的目的。

因此，企业需要在决策点获得上下文。一项读取已获批准项目文件夹的请求或许可以自动执行。导出客户记录的请求则应触发更严格的验证或人工审批关卡。

CSA 调查显示，组织已认识到这种区别。53% 的受访者表示，智能体可自主执行低风险任务，而高风险操作会接受人工审查。

仅有 13% 的受访者报告使用完全自主的模型。然而，当智能体超出其授权范围时，只有 11% 的受访者表示该操作会被自动阻止。

这一差距至关重要。操作完成后再记录日志有助于调查，但无法阻止数据丢失或运营损害。

人工审批同样存在局限。如果每项操作都会弹出提示，员工可能会在未经认真评估的情况下批准请求。审批疲劳会让可见的控制措施沦为无效的仪式。

更好的设计是将干预与风险挂钩。安全团队应界定哪些资源、数据分类和操作需要更强的控制。

Microsoft 已开始将 Agent 365 定位为解决这一问题的控制平面。其 Agent 365 更新介绍了对本地和云端智能体的发现能力，包括跨 Microsoft、Amazon 和 Google 环境的连接。

Microsoft 表示，其安全产品可以映射设备、Model Context Protocol 服务器、关联身份以及可访问的云资源。Model Context Protocol（MCP）是一项让 AI 应用连接工具和数据源的标准。

这种关系映射比平面的智能体清单更有价值。它有助于防御者评估：若智能体或其凭据遭到入侵，影响范围会有多大。

Microsoft 还表示，管理员可以检测并阻止某些未受管本地智能体使用的常见方法。运行时控制旨在于智能体运行期间阻止可疑行为。

这些能力展示了企业安全的发展方向，但供应商的声明仍需通过实际验证。跨平台发现可能遗漏自定义智能体、私有基础设施、不受支持的连接器，以及隐藏在其他产品内部的工作流。

控制平面本身也会带来集中化风险。企业必须决定，应向负责治理所有其他智能体的系统授予多大权限。

结果并非简单地从旧身份工具迁移到新工具。企业必须扩展身份控制，同时保留独立监控、恢复路径和有实质意义的人类问责。

可见性并不等于控制力

发现智能体是必要条件，但资产清单无法证明其操作仍然安全，或仍与其被分配的用途保持一致。

安全厂商已通过发现产品应对影子 AI。这些产品会检查端点、网络流量、云环境、浏览器活动、身份和 SaaS 集成。

这种可见性提供了起点。企业无法治理自己无法识别的资产。

危险在于将发现视为工作的完成。智能体可能出现在资产清单中，但其最重要的关联关系仍然未知。

安全团队需要知道谁拥有它、它使用哪种模型、它检索哪些数据、其记忆存储在哪里、它持有哪些凭据，以及它能够调用哪些工具。

他们还需要行为证据。获准用于发票核对的智能体，不应突然搜索源代码仓库或将文件发送到陌生域名。

传统的数据丢失防护能够检测部分敏感信息离开组织的情况，但未必能理解智能体为何访问这些信息，或该操作是否符合发起用户的意图。

端点监控也存在同样的局限。进程名称可以表明某个智能体正在运行，但并不总能还原由该智能体发起的云端工作流。

持续授权提供了更强的模型。它会在每一个重要步骤评估访问是否仍然恰当，而不是仅信任一次初始登录。

对于智能体，这种评估应包含任务目的、用户权限、资源敏感性、工具声誉、当前行为以及近期风险变化。

持续授权并不要求对每项操作都进行人工审批。低风险、可逆的操作可以在既定边界内继续执行。

高影响操作应走不同的路径。删除记录、发布外部消息、修改基础设施、更改权限或导出受监管数据，都应受到技术限制。

这一边界应存在于模型之外。只读凭据、隔离环境、交易限额和独立审批服务可以限制智能体实际能够执行的操作。

恢复也需要类似的隔离。备份不应与智能体可修改的生产系统处于同一权限边界内。

Dark Reading 对数据库的报道将这一点具体化。如果智能体可通过同一条凭据路径删除生产数据及其恢复副本，那么备份并未提供独立的保障。

可观测性同样需要持久记录。日志应保留发起用户、智能体身份、模型及版本、请求目标、所选工具、访问的数据、获得的批准以及最终结果。

记录一切会带来隐私和存储方面的担忧。敏感提示词和检索到的数据不应成为一个不受限制的二级数据集。

企业需要为智能体遥测数据设定保留期限和访问控制。调查人员需要足够的上下文来重建决策过程，同时不能将每一项机密输入暴露给广泛群体。

治理还应区分已获批准的试验与不受控制的生产访问。开发人员需要能够测试新智能体的环境，而无需等待完整的采购周期。

这些环境应使用合成数据或受到适当保护的数据。它们应隔离凭据，并防止直接访问关键生产资源。

一刀切的禁令会造成另一种可见性问题。Google 的预测警告称，禁止使用智能体可能会将其使用推向企业网络之外，届时监控会变得更加薄弱。

这并不意味着每种工具都应获得批准。它意味着获批准的路径必须足够易用，员工才会选择它。

安全团队可以提供经过审查的模型、标准连接器、受限凭据、测试环境以及快速注册流程。这些措施能够降低构建隐蔽替代方案的动机。

业务管理者同样扮演重要角色。他们应为每个生产环境智能体指定负责人，并记录其支持的业务流程。

所有权还必须包括退役流程。项目结束时，组织应撤销令牌、移除集成、删除不再需要的记忆，并验证依赖工作流不再调用该智能体。

缺乏这种生命周期纪律，可见性便会变成一份不断增长、却未获解决的资产清单。企业知道风险存在，却仍无法有把握地将其移除。

证据严肃，但也存在局限

当前研究显示存在显著的治理缺口，但由供应商资助的调查和孤立事件无法衡量智能体造成损害的完整发生频率。

安全报道需要两种谨慎。企业不应将影子智能体视为假设性问题，也不应把每项预测或供应商统计数据都视为中立的衡量结果。

CSA 调查提供了有用的细节，因为它说明了受访者数量、调查时间和若干部署模式。调查还明确表示，Token Security 委托、资助并协助制定了问卷。

Token 销售面向 AI 智能体的身份安全产品。这并不使调查发现失效，但其在强调可见性和身份缺口方面存在商业利益。

其他经常被引用的衡量数据来自安全厂商对自身客户的观察。这些数据集可以揭示某一产品遥测范围内的趋势，但未必代表所有企业。

客户选择、部署配置、检测方法和术语都可能影响结果。一种产品可能将每个工作流都计为智能体，而另一种产品只计算独立的智能体身份。

“事件”一词也需要谨慎解读。它可能涵盖数据暴露、策略违规、意外行为、运营中断或已确认的入侵。

CSA 报告称，65% 的受访者在前一年经历过与 AI 智能体相关的事件。在受影响的组织中，数据暴露是报告频率最高的业务影响。

这一发现令人担忧，但并不能确定其中有多少事件涉及恶意攻击者、意外操作、未经批准的使用，或获准系统中的故障。

案例报告可以提供深度，但不能说明普遍性。一家公司生产数据库被删除，展示了一条可能发生的故障链，却无法告诉读者市场上类似事件发生的频率。

同样的谨慎也适用于攻击演示。受控漏洞利用证明某一设计可能在特定条件下失效。生产环境中的防御、权限和监控可能改变结果。

因此，企业应要求供应商说明检测方法、覆盖边界、误报率和独立验证。“完整资产清单”这一仪表盘标签尤其值得仔细审视。

未知智能体之所以未知，恰恰是因为发现并不完整。任何供应商都无法仅凭其自身传感器发现的资产，证明实现了普遍覆盖。

安全负责人还应将模型风险与系统风险区分开来。智能体可能因模型行为而作出糟糕决策，但决定这一决策是否演变为重大事件的是过度权限。

反过来，狭窄权限也无法解决所有问题。拥有只读访问权限的智能体仍可能泄露机密信息、产生有害建议，或影响另一个系统。

最可信的应对方式结合模型评估、身份治理、数据保护、运行时监控和运营韧性。没有任何单一层面能够承担全部责任。

企业还需要能够区分智能体故障与普通应用故障的事件报告。有用的报告应记录自主级别、访问路径、发起身份、受损组件和业务影响。

没有共享定义，市场将产生大量却不兼容的数据。这使董事会和监管机构更难理解风险是否正在改善。

Google News 读者应将当前标题视为由趋同证据支持的警告，而不是对企业暴露面的完整衡量。

验证缺口也是故事的一部分。行业已经看到了足以证明需要采取行动的证据，但仍缺乏关于智能体事件及其后果的一致公开数据。

企业接下来应关注什么

下一阶段将由智能体登记册、运行时强制执行以及检验治理产品是否能在供应商演示之外发挥作用的事件证据所定义。

第一个信号是跨平台智能体登记册的采用。Microsoft、安全厂商和云服务提供商正在构建系统，以盘点端点、SaaS 产品和云环境中的智能体。

企业应考察这些登记册是否能够发现自定义工作流和不受支持的工具。仅覆盖一家供应商环境，无法解决多云影子智能体问题。

最有力的证据将来自独立比较。安全团队需要测试：通过多种渠道部署已知智能体，并衡量哪些产品能够检测到每个组件。

一个有用的登记册应识别所有权、用途、身份、权限、工具、数据来源和生命周期状态。仅列出代理名称，无法为风险决策提供足够背景。

第二个信号是运行时强制执行。产品公告越来越多地承诺拦截可疑工具使用、根据政策限制代理，并实施具备上下文感知能力的授权机制。

关键衡量标准并非产品能否生成警报，而是它能否在不打断正常工作的前提下，阻止高影响操作。

误报很重要，因为代理可以发起大量操作。一个会阻碍日常活动的控制措施，将促使团队将其禁用或绕过。

漏报则更加关键。一次未被阻止的破坏性操作，就可能抵消数千次正确获批的请求。

企业应针对提示注入、凭证泄露、过度委派、未经授权的数据传输，以及试图篡改审计记录等情况测试控制措施。测试应涵盖已获批准的部署和影子部署。

第三个信号是更完善的事件披露。科技行业已建立详尽的软件漏洞报告体系，但代理故障并不完全适用于这些渠道。

存在漏洞的连接器或许可以获得一个常规标识符。但如果某个代理误解目标、继承了过多访问权限并删除数据，责任认定的问题就复杂得多。

故障是由模型、代理框架、连接器、凭证设计、部署方式，还是人工指令造成的？在许多情况下，多个层面都促成了问题。

一致的报告方式将帮助组织比较事件并改进控制措施。它还将揭示那些被广泛讨论的风险，是否确实转化为反复出现的生产环境故障。

监管机构和审计人员很可能会要求提供证据，而不只是政策文件。企业应能够展示有哪些代理、谁负责它们、它们访问了什么，以及高风险操作是如何受到控制的。

实际应对措施应在这些要求到来之前启动。安全团队可以盘点已知代理、查找未经批准的代理、对其权限进行分类，并移除被遗弃的凭证。

他们还可以定义一小组始终需要更强控制措施的操作。删除生产环境内容、对外发布、变更权限以及批量导出数据，都是合理的起点。

开发者和知识工作者应先了解代理能做什么，再关注它能生成什么。一次令人印象深刻的演示背后所具备的权限，决定了其真正的企业风险。

业务领导者应思考，获批准的代理使用路径是否足够易用，从而减少影子采用。只存在于纸面上的治理机制，终将输给员工几分钟内就能安装的工具。

因此，Google News 的标题所反映的，与其说是一种新发现的威胁，不如说是一种迟来的认知：自主软件已经进入企业工作流，而许多组织仍像管理普通应用程序一样管理它。

这种做法难以持续。每个生产环境中的代理都需要具备身份、明确的负责人、受限的权限、可观测的操作记录，以及经过验证的退役路径。

未来三个月将揭示：代理登记册能否实现可信的跨平台覆盖，运行时控制能否经受现实测试，以及事件披露能否变得更加具体。

如果这些信号出现，企业治理正在开始迎头赶上；如果没有，影子代理问题将继续在那些暗示组织拥有比实际更多控制力的仪表板背后不断扩张。