幽灵运维：未授权AI Agent正重塑企业风险格局

从影子IT到“幽灵运维”：未授权AI Agent正在企业内崛起

如果你在企业IT部门工作的时间足够长，你应该经历过不止一次似曾相识的场景：一项新技术出现，其传播速度远超政策制定速度，而第一次正式的管理讨论，往往发生在有人问出“这东西怎么会在我们的环境里？”之后。

本世纪初，是消费级云存储。接着是未经批准的合作应用、个人文件共享，以及“只需用你的工作邮箱登录”。我们将团队通过非官方渠道采用技术的行为称为“影子IT”（Shadow IT），这些行为通常初衷良好，但后果严重。

如今，同样的剧本正在重演，但风险要高得多，因为这项技术不仅仅是存储数据或发送信息——它在自主执行操作。

在许多客户环境中，我们发现有数十乃至数百个AI Agent在未经批准、未经过架构评审、甚至不清楚数据存储位置、凭证如何处理以及这些Agent与工具集成后能做什么的情况下被部署。某机构的网络脉动报告指出，29%的员工曾使用未经批准的AI Agent处理工作任务。同一份报告也指出了高端市场的快速采纳：80%的财富500强组织正在使用活跃的AI Agent。

因此，我们需要一个新术语，因为“影子AI”无法准确描述这些自主或半自主Agent运行任务、拉取数据、调用工具的操作现实。

我称之为“幽灵运维”（GhostOps）——指那些在企业内部悄然出现、执行工作、然后从视野中消失的未经授权的操作型AI Agent，只留下结果，有时甚至要等到应急响应团队介入，才能复盘到底发生了什么。

“幽灵运维”与“影子IT”有何不同

影子IT通常关乎生产力工具、存储和工作流加速。而幽灵运维关乎授权决策和授权执行。

一个AI Agent不仅仅是聊天界面。它具有三个改变风险方程式的核心属性：

1. 记忆：可以随时间保留上下文、文件、机密、提示和标识符。
2. 工具使用：能够调用API、运行脚本、与SaaS应用交互并自动化操作。
3. 自主性：能够串联步骤、重试、升级操作，并能并行运行，其速度往往远超人工监督。

当这三个属性在没有治理的情况下被引入时，你失去的不仅仅是可见性，而是对操作行为和问责制的控制。

技术扩散的实例：Clawd如何助长“幽灵运维”

一个实际的例子是Clawd，社区中通过像OpenClaw这样的项目以及使其能轻松连接到真实系统的“技能”和Agent工具生态系统而为人所知。其具体叙事不如其模式重要。它是开源的，设计巧妙，易于部署，并且通常始于某个开发者或高级用户想要消除日常工作中的摩擦。

开源并不意味着不安全，但它确实意味着你必须将供应链作为一等风险来处理，尤其是当该工具旨在与你的消息平台、开发者工作流和管理接口集成时。一个“乐于助人”的自动化脚本，如果能够创建拉取请求、访问代码仓库或调用命令行工具，那么如果不对其进行严格控制和审计，它就可能成为一个特权入口。

这引出一个治理团队必须面对的不安问题，尤其是对于免费开源的东西：它真的免费吗？

如果你没有支付金钱，那你可能正在用以下一种或多种东西支付：你的数据、你的元数据、你的行为信号、你未来的依赖性，或者你的注意力。

风险清单：到底哪里会出问题

以下是在经历“幽灵运维”无序扩张的客户环境中，我们反复梳理出的风险全景图。关键点不在于每个部署都会触发所有风险，而在于未经批准的部署让组织完全丧失了知晓存在哪些风险的能力。

• 数据驻留与数据主权 Agent通常会根据违反内部政策或法规要求的位置，路由处理提示词、文件、对话记录和向量化数据。团队常常无法回答：数据存储在哪里？存储多久？受哪个司法管辖区管辖？
• 凭证处理与密钥泄露 Agent需要访问工具、SaaS、代码仓库、邮件、工单系统，有时甚至是生产环境。我们经常发现，配置文件中、环境变量里、聊天记录里充斥着长期有效的API密钥、共享令牌、个人访问令牌和硬编码的机密信息。其结果是新型的凭证泄露：由Agent驱动、难以盘点，且通常对标准的身份与访问管理（IAM）治理不可见。
• 通过自动化实现权限提升 如果一个Agent能够“创建工单”，在集成配置不当的情况下，它通常也能“审批工作流”。当Agent能够调用管理员API时，它就可能成为一个非故意的操作员，其破坏半径等同于它所拥有的委托权限。
• 提示词注入与工具滥用 如果Agent摄入了不受信的内容（如邮件、网页、文档、工单评论），它可能被操纵，以不安全的方式调用工具。真正的风险不在于模型被“欺骗”，而在于Agent基于不可信输入在可信系统中执行了操作。
• 开源Agent生态系统的供应链风险 技能注册中心、插件市场和GitHub依赖项极大地扩展了依赖关系图。即使是知名的项目也可能因依赖项名混淆、维护者帐户被接管或恶意依赖项更新而受到攻击。
• 可审计性与不可否认性的丧失 许多Agent框架并非为企业级审计日志、基于角色的访问控制或职责分离而设计。当事件发生时，组织难以回答基本问题：谁发起的？它访问了什么？它修改了什么？证据在哪里？
• 监管风险、法律可发现性与知识产权泄露 敏感数据可能在未经批准的合同条款下被引入外部服务。输出内容可能包含专有上下文、客户数据或受监管信息。证据链可能碎片化地分布在个人设备、个人账户和第三方平台上。
• 成本与资源消耗风险 Agent的循环、重试和并行执行可能导致API调用、计算资源和日志记录方面产生意外的消耗。那个“免费”的概念验证项目，可能最终成为环境中成本最高的不受控工作负载。

我们看到的真实世界案例

为了让这一点更具体，以下是企业客户中反复出现的几个例子（已对名称和细节进行泛化处理，但保留了技术机制）：

• 开发者生产力Agent：一个团队部署了一个Agent来管理拉取请求创建和代码审查摘要。它连接了源码控制平台、聊天工具和CI/CD流水线。Agent需要一个令牌，该令牌最终被授予了广泛的代码仓库权限，并以明文形式存储在构建服务器的一个配置文件中。至此，你就拥有了一个可以绕过你所有标准控制的凭证和访问通道。
• 财务报告Agent：一名分析师将一个Agent连接到电子表格、ERP导出接口和文档仓库，以自动化月度报告流程。Agent撰写的摘要包含了敏感的商业信息。随后，同一个Agent被用于另一个任务，无意中将机密内容粘贴到了一个外部提示词窗口中。
• “帮助台自动驾驶”：一个业务部门部署了一个Agent来起草工单回复。随后，它获得了工具访问权限，开始创建账户、重置密码、推送配置变更。如果没有健全的审批工作流，你就等于创造了一个无法被审计的、半自治的管理员。

治理再次试图追赶沉浸式技术

这是每一个重大技术变革周期中的反复上演的教训。治理通常是为那些拥有已知所有者、已知边界和已知变更控制的系统而构建的。

Agent打破了这些假设。它们易于搭建，可以在本地或云端运行，可以被封装进聊天工具，并能在团队间像病毒一样传播。部署的阻力极小，而治理的阻力极大。

答案不是“一刀切”地禁止。这种方法注定失败，因为生产力提升的差距太大，工作会转移到个人设备、个人账户和非托管网络上去。

答案是构建“护栏”，让组织能够以机器速度安全地运行。

有效的护栏：一套务实的企业级方法

我们通常将防护措施构建成两条互补的轨道：通过设计实现治理 和 通过证据实现检测。

轨道一：通过设计实现治理

这是专业服务价值所在，因为大多数组织需要的是一套结构化的能力提升方案，而不仅仅是一纸政策备忘录。一个基于专业服务的实用计划通常包括：

• Agent盘点与发现
• Agent部署的参考架构
• 身份、机密和访问权限加固
• 数据保护与策略执行
• 模型与Agent风险管理 目标很简单：让安全的路径成为最快的路径。

轨道二：通过证据实现检测

即使有强大的护栏，你仍然会面临“幽灵运维”。这就是为什么可观测性和检测必须是架构的一部分，而非事后补救。这可以利用某机构的安全信息与事件管理平台及更广泛的安全套件，在身份、端点、云资源和SaaS之间构建可见性、关联分析和响应工作流。一个可防御的方法通常包括：身份遥测、端点监控、云活动分析和数据移动检测，以便及早发现未经授权的Agent行为。

换句话说，治理降低可能性，而安全监测则减少影响和检测时间。

下一步行动：一份简明的高管议程

1. 假设“幽灵运维”已经存在于你的环境，然后去度量它。
2. 通过参考架构和快速审批，创建一条受官方批准的Agent使用通道。
3. 将Agent身份视为特权身份，并进行相应治理。
4. 对所有环节进行监测；如果无法记录日志，就无法信任。
5. 利用安全监测工具关联身份、端点和云信号。
6. 通过专业服务项目，发起一个由高管层赞助的专项治理计划。

影子IT是分散化采用的警示牌，而幽灵运维是分散化自主权的操作现实。

如果我们把护栏设置好，AI Agent将成为一种倍增优势。如果我们搞砸了，它们将成为我们部署过的最具可扩展性的风险——从一个“免费”工具开始，逐步蔓延。

别让“幽灵运维”危害你企业的安全态势。无论你需要保护现有的AI部署，还是从零开始构建一个稳健的治理框架，都需要立即行动起来，通过全面的托管安全服务以及专家级的咨询与专业网络安全服务，来获得可见性、降低风险，并确保你的组织能够安全地以机器速度运行。

参考文献与扩展阅读

• 某机构网络安全脉动AI安全报告
• 某机构安全博客，关于AI Agent、可观测性和治理的文章
• OpenClaw 项目代码仓库
• Clawd bot GitHub 集成概览
• 金融时报关于生成式AI中广告的讨论