如何发现企业中的影子 AI 代理

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

现在你的网络上正在运行着一些东西：你的 SIEM 不会记录它，你的 DLP 工具不会拦截它，你的资产清单从未编目过它。它不是恶意软件。它是被你自己的一位工程师安装的——很可能是一个高绩效者，很可能是出于好意，很可能是在 IT 还没来得及响应工单之前更快地解决了一个真实的问题。

它是一个 AI 代理。

更准确地说，它是一个影子 AI 代理：一个自主的、使用工具的、与外部通信的软件进程，在没有经过正式安全审查、没有策略批准、没有任何机制让安全团队观察它在做什么、接触什么数据、或代表你的组织做出什么决定的情况下被部署。

这不是一个假设性的威胁。在最近分享的一个现场演示中，TraceForce 的 CTO Varun Wadhwa 展示了这种场景在一个标准开发者笔记本电脑上的真实发生。一位工程师在 VS Code 开发容器中运行 Claude Code。该容器预先配置了用于 GitHub 和内存的 MCP（模型上下文协议）服务器，并通过公司托管的网关路由 LLM 调用。从该环境中每一个传统安全工具的角度来看，没有发生任何异常。一个开发者在使用他们的 IDE。容器只是一个容器。

但从代理安全平台的角度——TraceForce 的 Scout Lite 代理，在启动时自动安装到开发容器中——画面完全不同。有一个 AI 编程助手拥有对生产 GitHub 仓库的实时工具访问权限。有一个内存 MCP 在会话之间保留上下文。有出站 LLM 流量能够将知识产权、源代码、凭据或内部架构细节携带到外部推理端点。所有这些都对企业安全堆栈来说是不可见的。所有这些都运行在一个本应增加隔离的沙盒环境中。

那个差距——你的安全工具看到的和你的环境中实际执行之间的差距——就是影子 AI 代理问题。本文精确定义它，解释这些代理出现在哪里，剖析为什么传统工具会遗漏它们，梳理一个结构化的发现工作流程，并论证为什么清单不仅仅是第一步，而是代理 AI 安全的基础行为。

1、定义影子 AI 代理

"影子IT"这个术语已经存在了几十年，泛指员工在正式 IT 渠道之外采用的软件和服务。影子 AI 代理是一个特定的、危险性高得多的子类别，由三个属性区分，使其与未经授权的 SaaS 工具或个人云存储账户在本质上不同。

自主性。 影子 AI 代理不会等待人类点击按钮。一旦被调用——在许多架构中，一旦被调度或事件触发——它就独立执行多步任务链。它推理、规划、选择工具、调用 API、读写数据，并决定何时完成其目标。部署它的人类可能不会观察到任何个别操作；他们只看到结果。

工具访问。 现代 AI 代理不是聊天机器人。它们通过模型上下文协议（MCP）、LangChain 工具定义、OpenAI 函数调用或自定义框架运行，这些框架赋予它们读写文件、执行代码、查询数据库、调用内部 API、发布到外部服务以及生成子代理的能力。这些能力中的每一个都是一个潜在的数据泄露路径、横向移动向量或权限升级机会——取决于工具的范围和代理被指示做什么。

外部 LLM 依赖。 几乎所有当前的影子 AI 代理都将数据发送到外部推理端点——无论是 OpenAI 的 API、Anthropic 的 API、Google Gemini 还是第三方包装服务。这意味着通过未经授权的代理传递的每个提示、每个文档块、每个代码片段和每个系统消息都在离开企业边界。即使响应出现在本地屏幕上，推理也发生在组织不控制的数据中心中，按照法律团队可能从未针对该用例审查过的服务条款协议进行。

这三个属性共同创造了一个在质量上与以前的影子 IT 风险不同的实体。一个 Dropbox 账户泄露你放入其中的东西。一个影子 AI 代理泄露它决定放入其中的东西——自主地、持续地、隐性地。

出于工作安全定义的目的：影子 AI 代理是在企业环境中运行的任何自主的、由 LLM 驱动的、具有工具调用能力的进程，且未经正式 AI 治理流程的清单、审查和批准。

2、影子 AI 代理出现在哪里

了解影子 AI 代理在哪里 proliferate 是发现它们的前提。它们不会随机出现。它们聚集在可预测的位置，由部署它们的人的激励和工作流程驱动。

2.1 开发者环境和 IDE 扩展

影子 AI 代理最常见的滋生地是开发者工作站。Claude Code、GitHub Copilot Workspace、Cursor 和 Codeium 等工具已经远超自动补全。它们现在作为完整的代理循环运行——读取仓库结构、规划实现步骤、编写和执行代码、运行测试并提交更改。其中许多工具支持 MCP 服务器或插件架构，将它们的触角延伸到部署流水线、工单系统和内部 wiki。

TraceForce 的演示精确地说明了这一点。一位在 VS Code 开发容器中运行 Claude Code 的开发者在没有任何恶意意图的情况下，创建了一个可以访问生产 GitHub 仓库的代理。开发容器模式——在希望标准化开发环境的企业中越来越标准——实际上使发现变得更复杂，因为它在主机端点监控工具和运行中的进程之间增加了一层虚拟化。

2.2 工作流自动化平台

n8n、Zapier 和 Make 等平台已经添加了原生 AI 代理节点，允许业务用户在不编写代码的情况下构建多步自动化工作流。一位营销分析师可能构建一个代理来监控 Slack 频道获取客户反馈，使用 LLM 进行总结，并将每周摘要发布到 Confluence 页面。一位销售运营经理可能构建一个代理来查询 Salesforce，使用 GPT-4o 起草后续邮件，并通过邮件客户端安排发送。

这些代理持续运行，通常在个人或不受管理的账户下配置的云基础设施上，而不是企业租户下。它们可以访问员工粘贴到平台中的任何凭据。它们在结构上对任何端点监控工具是不可见的，因为它们完全在端点之外运行。

2.3 数据科学团队部署的代理框架

基于 Python 的框架——LangChain、LlamaIndex、CrewAI、AutoGen、Haystack——已经大幅降低了构建自定义多代理系统的门槛。想要自动化模型评估、竞争情报合成或文档处理的数据科学团队可以在一个下午构建一个功能性的多代理流水线。这些流水线通常作为 cron 任务、Kubernetes pod 或 Lambda 函数运行——基础设施可能在个人或团队 AWS 账户下配置，而不是云安全态势管理工具监控的企业账户下。

这正是 MAESTRO 框架的第2层（数据运营）和第3层（代理框架）风险具体化的地方。一个从数据仓库读取、分块文档、嵌入它们并将其发送到外部向量数据库的代理正在执行一个持续的、自动化的数据泄露操作——即使构建它的人有完全合法的分析目标。

2.4 沙盒环境中的 MCP 服务器

TraceForce 的演示浮出了许多安全团队尚未吸收的重要信息：MCP 服务器以沙盒隔离本身无法解决的方式改变了沙盒环境的威胁面。

开发容器和沙盒 AI 工作空间的整个前提是隔离减少爆炸半径。如果代理行为不当，它在容器内部行为不当。但在该容器内配置的 MCP 服务器——用于 GitHub、用于内存、用于文件系统、用于 Web 浏览器——通过设计打破了隔离边界。这正是 MCP 服务器的目的：给代理触达外部系统的能力。沙盒包含的是进程，而不是效果。

当开发容器中的 GitHub MCP 服务器推送一个提交时，那个提交是真实的。当内存 MCP 持久化会话上下文时，那些数据存储在某个地方——可能完全在容器之外。沙盒模型假设隔离是安全原语。启用 MCP 的代理假设工具访问是功能原语。这些假设直接矛盾，大多数企业安全架构尚未解决这种矛盾。

2.5 笔记本电脑级代理编排器

一些员工在本地运行完整的代理编排堆栈。Ollama 结合本地 MCP 客户端，或通过自定义框架管理的云端连接代理，可以完全在开发者的笔记本电脑上创建复杂的代理流水线。这些进程产生很少甚至不产生 DLP 工具会标记的网络流量——LLM 调用看起来像是对已知 API 端点的 HTTPS 请求，在流量检查中与开发者查询文档无法区分。

3、为什么传统工具会遗漏影子 AI 代理

如果你今天运行一个企业安全项目，你有大量的工具投资。你可能拥有端点检测和响应、一个聚合来自几十个源日志的 SIEM、一个云安全态势管理平台、一个数据防泄漏解决方案、网络流量分析，可能还有一个 CASB。这些工具中没有一个是为了检测、清单或治理 AI 代理而设计的。以下是它们系统性失败的原因。

3.1 缺乏语义理解的进程级可见性

EDR 工具擅长检测异常进程行为——意外的父子关系、未签名的二进制文件、可疑的文件修改。但作为一个由 VS Code 扩展调用的 Python 进程运行的 AI 代理在进程级别并不是异常的。它是一个合法的解释器运行一个合法的脚本。EDR 看到 python3 agent_harness.py 并且没有理由标记它。它不理解这个进程正在自主查询 LLM、调用 GitHub API，并就提交什么代码做出决策。

3.2 网络工具缺乏 LLM 流量上下文

DLP 和网络检查工具寻找模式——出站流量中的 SSN、信用卡号、已知恶意软件签名。LLM API 调用是对 api.anthropic.com 或 api.openai.com 等端点的 HTTPS POST 请求。这些请求的内容——提示、上下文窗口、工具调用参数——是加密的。网络检查工具看到的是：*HTTPS POST 到 api.anthropic.com，一个小的加密负载，200 OK 响应。*它无法看到负载中包含专有客户合同、数据库架构或开发者输入到代理上下文中的内部架构图。

即使部署了 TLS 检查，LLM API 调用负载是结构化 JSON，不是 DLP 工具被训练标记的模式。提示"这是我们的 Q3 客户列表，帮我起草后续邮件"后跟客户数据的 CSV 转储不匹配任何 DLP 签名。它只是文本。

3.3 代理到 API 流量的 CASB 覆盖缺口

云访问安全代理（CASB）是为 SaaS 治理设计的——通过浏览器流量识别员工何时使用未经授权的云应用程序。AI 代理不使用浏览器。它们以编程方式调用 API，通常从后端基础设施或本地进程路由流量到浏览器代理之外。CASB 永远看不到这个流量。

即使 CASB 工具添加了 AI 特定策略，它们通常在应用层操作——阻止通过浏览器访问 ChatGPT——而不是大多数代理流量流过的 API 层。

3.4 容器和沙盒盲区

正如 TraceForce 演示直接展示的，开发容器是一个特定的盲区。安装在开发者笔记本电脑操作系统级别的端点监控工具通常无法观察在 Docker 容器内运行的进程。容器的进程命名空间与主机隔离。除非监控代理也安装在容器内——Scout Lite 会自动执行此操作——否则主机级 EDR 只看到 Docker 守护进程，看不到 Claude Code 进程，看不到 MCP 服务器，看不到工具调用。

这不是配置错误。这是容器隔离的预期行为。安全假设是容器本身就是一个信任边界。但当容器的明确目的是给 AI 代理触达外部系统的能力时，这个假设不成立。

3.5 缺乏代理制品的模式

传统安全工具有它们监控的东西的模式：进程、文件哈希、网络连接、用户认证事件、对已知服务的 API 调用。它们没有代理安全中重要概念的模式：哪些代理在运行、它们加载了什么 MCP 服务器、什么工具在范围内、它们的系统提示词说什么、什么数据通过了它们的上下文窗口、它们自主采取了什么行动。

这不是可以通过新签名或新 DLP 规则修补的差距。它需要一个根本不同的监控原语——一个以代理为观察单元而不是进程、文件或网络包的原语。

4、影子 AI 代理的发现工作流程

图3. 五阶段发现工作流程。每个阶段增加一个代理可见性维度；它们共同产生所有后续控制所依赖的代理物料清单。

鉴于传统工具系统性失败，企业需要一个专门的发现工作流程。以下五阶段方法借鉴了 MAESTRO 框架的分层威胁模型，并反映了 TraceForce 等平台出现的操作模式。

阶段1：具有代理感知的端点枚举

起点是端点，因为大多数影子 AI 代理始于本地安装。部署一个轻量级代理——类似于主机级的 Scout——专门枚举 AI 相关制品是第一步。这意味着清单化匹配已知代理框架的已安装包（langchain、crewai、autogen、anthropic、openai、litellm 及其变体）、具有代理能力的 IDE 扩展、本地 LLM 运行时如 Ollama，以及引用 MCP 服务器定义的配置文件。

这个阶段的目标不是检测恶意行为。它是普查：在询问它们是否被授权之前，构建环境中存在什么代理工具的完整地图。

阶段2：容器和沙盒枚举

阶段1枚举主机。阶段2进入容器内部。这需要容器原生监控方法——正是 Scout Lite 在 TraceForce 视频中演示的。当开发容器启动时，一个轻量级的发现进程应该在其中自动执行，枚举运行中的进程、加载的 MCP 服务器、活跃的 LLM 连接和配置的工具集。

这个阶段浮出另一类否则完全不可见的影子代理：在开发容器、Kubernetes pod、GitHub Codespaces 和云托管沙盒环境中运行的代理。TraceForce 演示的关键实现洞察是，通过 MDM 在容器启动时强制安装——而不是事后扫描——是唯一可靠的机制。在扫描执行之前已经运行并退出的代理已经消失了。从容器内部持续发现是维持当前状态感知的唯一方式。

阶段3：网络流量基线和 LLM API 指纹识别

虽然加密的 LLM 负载内容无法在没有 TLS 终止的情况下检查，但 LLM API 流量的模式具有高度特征性，可以进行基线化。LLM API 调用具有特征性的请求大小、响应节奏和端点指纹。一个定期向 api.anthropic.com、api.openai.com 或 generativelanguage.googleapis.com 发出 HTTPS 调用的进程几乎可以确定是 AI 代理或应用程序。将这些网络观察与阶段1和阶段2的进程清单相关联，就闭合了"什么在运行"和"什么在向外调用"之间的循环。

这个阶段还通过它们的出站流量签名浮出基于云的代理——n8n 实例、无服务器函数和自动化平台——即使进程本身不在受管理的端点上。

阶段4：身份和凭据关联

影子 AI 代理不在凭据真空中运作。它们使用 API 密钥、OAuth 令牌、服务账户凭据，有时使用存储在 .env 文件、密钥管理器或硬编码在脚本中的人类员工凭据。阶段4将阶段1至3的代理清单与组织的身份基础设施——密钥管理系统、OAuth 授权日志、API 密钥发放记录和服务账户清单——进行关联。

目标是回答：这个代理使用的是谁的凭据？如果一个代理以开发者的 GitHub 令牌运作，它在效果上就是那个开发者——但没有开发者的实时判断，并且可能在开发者转到不同角色或离开组织后很长时间仍在运行。影子代理中的孤立凭据是一个重大的持久性风险，身份团队经常遗漏这一点，正是因为他们不将代理进程视为凭据消费者类别。

阶段5：行为基线化和异常检测

前四个阶段产生一个静态清单：什么代理存在、它们有什么工具、它们使用谁的凭据。阶段5引入时间观察——观察代理随时间的行为以建立正常外观并检测偏差。

AI 代理的行为基线化与传统 UBA 有意义地不同，因为 LLM 驱动行为的变化性在设计上就很高。一个今天总结文档、明天开始查询它从未访问过的数据库的代理可能在遵循合法的新指令——或者可能遭受了提示注入。区分这些需要一个正常工具调用模式、正常数据访问范围和正常出站流量量的基线，然后对统计上显著的偏差进行告警。

这正是 Simon Willison 的"致命三要素"变得具有操作相关性的地方：一个结合了对私有数据的访问、对不可信内容的暴露以及与外部通信能力的代理，在他的框架中，是最高风险配置。CSA MAESTRO 框架通过其分层威胁模型得出了类似的结论——跨第2层（数据运营）和第7层（代理生态系统）且具有凭据工具访问权限的代理集中了相同的风险组合。阶段5应该相应地加权异常分数，将该组合视为优先调查目标，无论个别信号单独看起来是否良性。

5、为什么清单是代理 AI 安全的基础

每一个成熟的安全学科都始于清单。你无法修补你没有编目的东西。你无法治理你没有枚举的东西。你无法对涉及你不知道存在的资产的事件做出响应。这些原则对漏洞管理、云安全、端点保护和身份治理都是正确的。它们对代理 AI 也正确——而且利害关系要高得多。

利害关系更高是出于一个特定的结构性原因：AI 代理具有能动性。一个配置错误的云存储桶就放在那里，被动地向任何发现它的人泄露数据。一个影子 AI 代理主动做出决策、采取行动、调用工具，并在外部系统中产生效果——持续地、自主地、以软件的速度。从"代理开始运行"到"代理造成安全事件"的窗口可以以秒来衡量。从"代理造成事件"到"安全团队发现代理存在"的窗口可以以月来衡量——如果没有专门的工具，发现可能根本不会发生。

清单通过将第二个窗口压缩到零来解决这一点。如果你在出问题之前就知道什么代理在运行，你可以在事件之前而不是作为回应来应用控制——基于意图的访问控制策略、工具范围限制、输出监控、速率限制、人在环检查点。从被动到主动的转变是区分治理代理 AI 的安全项目与那些只是希望自己不出现在下一个泄露报告中的安全项目的关键。

TraceForce 的演示使这变得具体。Varun 展示的可见性——Claude Code 被发现、GitHub 和内存 MCP 被枚举、所有范围限定到特定沙盒——不是代理 AI 安全的最终状态。它是其他一切的前提条件。从这个清单，企业可以问：这个代理是被授权的吗？它的 MCP 范围与策略一致吗？它使用的凭据仍然有效且范围适当吗？它是通过批准的 LLM 网关路由还是直接调用外部端点？它的行为是否偏离了既定基线？

没有清单，这些问题都无法被提出。MCP 白名单、LLM 网关路由、输出检查、IBAC 执行——所有这些控制都无法应用于你不知道存在的代理。

还有一个合规维度正在快速成熟。新兴的 AI 治理框架——欧盟 AI 法案、NIST AI RMF、ISO 42001 和 CSA 的 AI 安全指南——正在趋同于一个共同的期望：组织必须能够展示对其运营的 AI 系统的感知和控制能力。"我们不知道我们的员工在运行那个代理"不是一个合规姿态。它是对治理缺口的承认，监管机构和审计师将越来越将其视为控制失败。

与软件供应链安全的类比很有启发性。十年前，大多数企业对其软件中的开源组件没有系统性的可见性。2021年的 Log4Shell 漏洞暴露了这个盲点可能有多灾难性——组织甚至无法回答"我们使用 Log4j 吗？"更不用说"在哪里、什么版本？"回应是 SBOM：软件物料清单——强制的、系统性的软件组件清单作为供应链安全治理的基础。

我们正处于代理 AI 的等效拐点。"我们的环境中运行着什么 AI 代理？"这个问题在大多数企业今天是无法回答的。这个问题将被以越来越紧迫的方式提出——由董事会、监管机构、事件响应者和网络保险公司。代理物料清单还不是行业标准术语，但底层要求已经在治理框架和客户安全问卷中成形。现在构建发现能力的组织将在该要求具体化时拥有基础。没有这样做的组织将面临代理 AI 版本的 Log4Shell：一个普遍的、不可见的风险，他们无法界定范围、无法修补、无法解释。

6、结束语

影子 AI 代理不是未来风险。它们现在就存在，正在 proliferation，并在你的环境中运行——在开发容器中、在工作流自动化平台中、在数据科学流水线中、在受管笔记本电脑上的 IDE 扩展中。它们逃避你部署的每一个传统安全工具，因为那些工具是为一个软件按照被告知的方式、在被告知的时候、由正在观察的人类来执行的世界而构建的。

那个世界不再描述你的环境。

发现是使不可见变为可见的行为。它需要专门的工具——轻量级主机代理、容器原生监控、网络流量指纹识别、身份关联和行为基线化——系统地部署在每个代理 AI 可能运行的环境中。TraceForce 通过 MDM 在容器启动时强制安装 Scout Lite 的方法是这个的一个具体实例。它体现的原则——发现必须是持续的、自动的、并且原生于执行环境而不是从外部附加的——是每个企业安全团队需要内化的架构洞察。

获取清单。其他一切都依赖于它。

原文链接: How to Discover Shadow AI Agents in Your Enterprise

汇智网翻译整理，转载请标明出处