当 AI Agent 开始自我繁殖：影子 IT 的指数爆炸与一个开源检测器的诞生
想象你是某家金融公司的 CISO。去年你批准了 GitHub Copilot 的使用。今年初，工程师小张在他的 Windows 笔记本上装了 Claude Code——你没批准，但你不知道。
目录
当 AI Agent 开始自我繁殖：影子 IT 的指数爆炸与一个开源检测器的诞生
一个 CISO 的噩梦
想象你是某家金融公司的 CISO。去年你批准了 GitHub Copilot 的使用。今年初，工程师小张在他的 Windows 笔记本上装了 Claude Code——你没批准，但你不知道。
Claude Code 不只是个聊天框。它是一个能读写文件、执行命令、调用 API 的 agent。某天下午，小张让 Claude Code 帮他搭一个数据处理流水线。Claude Code 觉得需要三个 MCP server 来扩展自己的能力，于是自动 npx 安装了 mcp-server-filesystem、mcp-server-git，还写了一个自定义的 Python 脚本去调 OpenAI 的 API 做数据清洗。
这三个组件留在了小张的电脑上。其中那个 Python 脚本本身是 agentic 的——它会在每次运行时自己决定调几次 API、执行什么命令。小张把这个脚本加进了 Windows 任务计划程序，每小时跑一次。
一个月后，另一个工程师看到小张的脚本很好用，要了一份。又一个月后，那个自定义脚本已经被改了三个版本，其中一个版本会自动生成新的子脚本去处理新的数据源。
你的公司批准了一个工具。现在你的公司有九个未批准的 agentic 工件在跑，其中两个会自我繁殖。
这不是科幻。这是 2026 年 11 月论文《Detecting Shadow AI: Unsanctioned LLM Agents on Enterprise Endpoints》描绘的场景，作者 Jérémy Canale 和 Fabien Soulis 用一个简洁的数学模型证明：当 agentic 工件的繁殖速度超过组织淘汰它们的速度时，影子 IT 会指数爆炸。
三波浪潮：从影子 IT 到影子 AI 到影子 Agent
论文把企业里未经批准的技术分成三波：
第一波：经典影子 IT。 员工自己装个 Dropbox、用个人邮箱发工作文件、把 Excel 宏搞成一个小型 ERP。这波影子 IT 很老，增长很慢——因为每个工具都需要人去找到它、安装它、配置它。一个员工一个月最多搞一两件。CIO 们虽然低估了它的规模，但它至少是收敛的：采用率到顶了，存量也就到顶了。
第二波：影子 AI（对话式）。 ChatGPT 出来后，员工开始把公司代码粘到网页聊天框里。2024 年的数据触目惊心：75% 的知识工作者在工作中使用生成式 AI，78% 的 AI 用户自带 AI 工具上班，44% 承认违反公司 AI 政策使用，61% 会刻意隐瞒。IBM 的报告显示，五分之一的被入侵组织报告过涉及影子 AI 的数据泄露。
但这波还是可控的——因为对话式 AI 发生在浏览器里，网络层能看到。你可以在防火墙上封 ChatGPT 的域名。
第三波：影子 Agent。 这是论文的核心警告。Agent 不是聊天框，是会自己干活的软件。Claude Code、OpenAI Codex CLI、Cursor、各种 home-made 的 Python 脚本——它们在本地运行，用用户的权限执行命令，调用远程 LLM API。更关键的是，agent 会制造 agent：它们安装 MCP server、生成自动化脚本、留下配置文件，这些工件本身就是 agentic 的，会继续繁殖。
一个让人后背发凉的公式
论文给出了一个极其简洁的复利模型。设 \(A_t\) 是第 \(t\) 个月使用未批准 agent 的员工数，\(S_t\) 是未批准工具的存量。
经典影子 IT 的动力学：
其中 \(\kappa\) 是每个员工每月引入未批准工具的速率，\(\delta\) 是组织每月淘汰的比例。这个方程会收敛到 \(\kappa N / \delta\)（\(N\) 是总员工数）——增长有上限，因为工具不会自己制造工具。
Agentic 影子 IT 的动力学：
两个关键变化：
- \(\rho \gg \kappa\)：agent 用户制造工件的速率远高于普通员工（因为 agent 几乎免费就能造工具）
- \(\sigma\phi\)：存量中比例为 \(\phi\) 的工件是 agentic 的，它们以速率 \(\sigma\) 制造新工件
这个临界条件的直白翻译：当 agentic 工件的繁殖速度超过组织淘汰它们的速度时，影子 IT 指数爆炸。
论文强调这个模型不是用来测量的——它不声称知道 \(\sigma\) 或 \(\phi\) 的真实值。它的作用是指出哪些量重要。而最重要的洞察是：淘汰的前提是发现。你无法淘汰你不知道存在的东西。检测不是治理的充分条件，但是必要条件。
行为双胞胎：为什么检测 agent 这么难
好，你决定检测。你在每台 Windows 笔记本上装了个监控程序。你看到：
python.exe进程- 它有一个子进程
cmd.exe - 它通过 443 端口连了一个 TLS 加密的远程地址
- 连接保持了几分钟
可能是。但也可能是 npm install——它也是 python/node 进程，也会起子进程，也会通过 443 下载东西。也可能是 VS Code 的集成终端在跑构建脚本。也可能是管理员的自动化脚本。
论文提出了一个精妙的概念：行为双胞胎（behavioural twin）。对于每一个 agent，都存在一个行为上完全相同但不是 agent 的程序——同样的进程树、同样的连接模式、同样的 shell 调用，只是远程服务不是 LLM 而是普通的 API。
论文用数学证明了这一点。设 \(\beta(a)\) 是 agent \(a\) 的行为特征（进程结构、连接模式），\(\iota(a)\) 是身份特征（远程服务的身份）。行为双胞胎 \(b\) 满足 \(\beta(a) = \beta(b)\) 但 \(\iota(a) \neq \iota(b)\)。任何只依赖 \(\beta\) 的检测器 \(f\)，对 \(a\) 和 \(b\) 给出相同的判断——要么漏检 \(a\)，要么误报 \(b\)。
这个论证的力量在于它的平凡性：它说的不是某个检测器不够好，而是任何只看行为的检测器在原理上都无法区分 agent 和非 agent。
论文在实验中验证了这一点。两个简单的行为规则——"解释器 + 443 端口 + shell"和"任何进程 + 443 端口 + shell"——在 9 个良性工作负载中误报了 4 个，包括每一个行为双胞胎和一次普通的 npm install。
九类 Agent，六层足迹
为了系统性地理解检测问题，论文提出了一个分类法。
九类 Agent（C1-C9）：
| 类别 | 例子 | 特征 |
|---|---|---|
| C1 命令行编码 agent | Claude Code, Codex CLI, Aider | 原生可执行文件或 Node/Python 运行时 |
| C2 桌面 agent | Claude Desktop, ChatGPT 桌面版 | 打包应用（MSIX） |
| C3 AI 原生 IDE | Cursor, Windsurf | Electron 应用 |
| C4 IDE 扩展 | GitHub Copilot, Cline, Continue | IDE 扩展宿主 |
| C5 本地 LLM 运行时 | Ollama, LM Studio, llama.cpp | 本地端口，无外部连接 |
| C6 Agent 浏览器 | Perplexity Comet | 浏览器进程 |
| C7 框架/SDK | LangChain, CrewAI, AutoGen | Python/Node 解释器 |
| C8 自制 agent | 几十行调 API 的脚本 | 通用解释器，无稳定标识 |
| C9 Agent 基础设施 | MCP server, 自建网关 | 为其他 agent 服务 |
python.exe 加一个 20 行脚本，没有安装记录、没有签名、没有版本号——你怎么检测它？六层端点足迹（L1-L6）：
- L1 软件身份：镜像名、安装路径、版本资源、Authenticode 签名
- L2 运行时结构：命令行、父子进程、加载模块、环境变量
- L3 网络：已建立连接、远程服务身份、监听端口
- L4 安装：已安装程序记录、服务、IDE/浏览器扩展
- L5 配置：配置文件夹、API key 存储位置
- L6 执行历史：Prefetch、BAM（后台活动修饰符）、最近文件
Agent Detector：一个开源的 Windows 检测器
基于这个分析，论文发布了 Agent Detector——一个开源的 Windows 端点检测器（GitHub: jeremy1392/IntuneAgentDetector），用 Go 写成，通过 Microsoft Intune 部署。
核心设计原则：把行为锚定到身份。
行为本身不够，但行为 + 远程服务身份 + 配置 + 安装历史 + 执行记录的多信号相关，就能区分 agent 和它的行为双胞胎。
具体做法：
1. 网络归因：通过 Windows DNS 缓存把连接关联到具体 LLM 服务商（Anthropic、OpenAI 等）。维护一个 39 个工具签名 + 184 个 LLM 端点的目录，覆盖九大类（直连 API、聚合器、推理平台、网关、中继等）。
2. 配置指纹：检测 OPENAI_BASE_URL、ANTHROPIC_API_KEY 等环境变量，VS Code 扩展目录里的 AI 工具配置。
3. 执行历史：Prefetch 和 BAM 记录了最近运行过的程序，即使当前没运行也能发现。
4. MCP 识别：命令行中匹配 @modelcontextprotocol/、mcp-server-* 等模式。
关键设计决策：通知而非阻断。 Agent Detector 永远不会关闭、卸载或阻断任何东西。它弹出一个窗口，列出检测到的 AI 工具，要求用户勾选"我已阅读并理解 AI 使用政策"然后点击"我接受"。每次扫描都会弹，只要未批准的工具还在。这个窗口没有关闭按钮。
这个设计很聪明：它把治理从"猫鼠游戏"变成了"知情同意"。IT 部门知道谁在用什么，用户知道自己在被监控，但没有人被阻止工作。
数据说话
在受控基准测试中（12 个合成 agent + 3 个 AI 组件 + 9 个良性工作负载，每台机器重复 5 次）：
| 检测器 | 真阳性 | 假阴性 | 假阳性 | 精确率 | 召回率 | F1 |
|---|---|---|---|---|---|---|
| 签名检测器 D0 | 0 | 12 | 0 | N/A | 0.00 | N/A |
| 行为规则 D1（解释器+443+shell） | 9 | 3 | 4 | 0.69 | 0.75 | 0.72 |
| 行为规则 D2（任意进程+443+shell） | 10 | 2 | 4 | 0.71 | 0.83 | 0.77 |
| Agent Detector | 12 | 0 | 0 | 1.00 | 1.00 | 1.00 |
npm install。Agent Detector 通过身份相关实现了零误报、零漏检。但论文诚实地承认这些数字"比论文中任何其他数字都更奉承 Agent Detector"，原因有三：基准太小、行为双胞胎是构造的最坏情况、合成 agent 复现的是检测器观察到的足迹而非真实 agent 的全部多样性。
时间的牢笼
Agent Detector 最有趣的局限是时间性的。
DNS 缓存的时间窗口。 通过 DNS 缓存把连接归因到 LLM 服务商，只在缓存条目存活期间有效。对于使用 CDN 的服务商（OpenAI、Anthropic 都在 CDN 后面），缓存条目只活 1-5 分钟。一个 agent 如果保持一个连接一小时，你只在它的前几分钟能归因。每小时扫描一次大概率会错过它。
间歇性 agent。 一个启动-停止-启动的 agent，大约只有三分之一的扫描能抓到它。因为它运行时可能正好不在扫描窗口里。
扫描成本。 一次扫描约 154 毫秒，可以频繁跑。但连续监控（比如 ETW）成本更高，论文没有采用。
这个时间局限揭示了一个深层问题：agent 的检测本质上是一个时间博弈。 你不是在检测一个静态的文件，而是在捕捉一个动态的行为窗口。这和传统杀毒软件扫描文件的模型完全不同——文件一直在那里，但 agent 的网络足迹只在特定时刻可见。
工程洞察
这篇论文给 AI 从业者几个实操层面的启发：
1. Agent 的治理问题不是"允不允许"的问题，而是"看不看得见"的问题。 你可以制定最严格的 AI 政策，但如果你不知道谁在跑什么，政策就是一张纸。检测是治理的前置条件。
2. 行为检测有原理性天花板。 不是检测器不够好，而是任何只看进程树和连接模式的检测器都无法区分 agent 和它的行为双胞胎。身份信息（远程服务是谁）是不可省略的。
3. MCP server 是新的攻击面。 论文专门把 MCP server 列为 C9 类——它们是 agent 基础设施，本身可能 agentic，而且几乎不在任何清单上。一个被植入后门的 MCP server 可以影响所有调用它的 agent。
4. 目录维护是持续的工程。 184 个 LLM 端点条目需要每月更新——厂商加新 IP 段、改 CDN 配置、出新产品。论文坦言写论文期间就发现目录里缺了 Anthropic 的 IPv6 段。这和杀毒软件的签名库一样，是一个需要持续投入的工程。
5. 通知优于阻断。 Agent Detector 的设计哲学是"知情承认"而非"阻断"。这在企业环境中更现实——你阻断 Claude Code，工程师会用 Ollama 跑本地模型，你连网络层都看不到了。
个人思考
这篇论文让我想到一个更大的图景：我们正在进入一个 agent 会自我繁殖的世界，而我们的治理工具还停留在静态清单时代。
复利模型的核心洞察不是"影子 IT 会爆炸"——这个直觉大家都有。而是它给出了爆炸的临界条件：\(\sigma\phi > \delta\)。这意味着治理有两个杠杆：降低 agent 的自我繁殖速率（\(\sigma\phi\)），或提高淘汰速率（\(\delta\)）。而淘汰速率的上限是检测速率——你发现不了的东西，你淘汰不了。
这和生物入侵的模型惊人地相似。外来物种入侵的临界条件是繁殖速率超过捕食/自然死亡率。一旦越过临界点，种群指数增长，直到资源耗尽。Agent 在企业环境里也是一样——一旦 agentic 工件的繁殖超过 IT 部门的清理能力，未批准工具就会像入侵物种一样填满每一个可用的生态位。
行为双胞胎的论证则让我想到密码学中的"不可区分性"。一个完美的加密方案，密文和随机串不可区分；一个完美的 agent，行为和非 agent 程序不可区分。检测 agent 的难度，在原理上和区分加密流量与随机流量一样——你需要额外的信息（密钥/身份）才能做到。
最后，这篇论文最务实的贡献可能不是 Agent Detector 本身，而是它对"检测"这个动作的重新定义。在 agent 时代，检测不是一个一次性的动作（扫描文件签名），而是一个持续的过程（监控运行时行为 + 身份相关 + 时间窗口捕捉）。这需要一种全新的安全基础设施——不是杀毒软件的升级版，而是某种 agent 时代的 EDR。
开源代码
- Agent Detector: https://github.com/jeremy1392/IntuneAgentDetector
- Go 语言编写，通过 Microsoft Intune 部署
- 包含 39 个工具签名 + 184 个 LLM 端点的开放目录
- 支持 Windows 10 22H2 / Windows 11，需 Pro/Business/Enterprise 版本
论文链接
- arXiv: https://arxiv.org/abs/2611.12377
- HTML 版本: https://arxiv.org/html/2611.12377v1
- 作者: Jérémy Canale, Fabien Soulis
- 发布日期: 2026-11-09
*当 agent 开始制造 agent，治理的战场从"谁在用什么"变成了"什么在自我繁殖"。这篇论文给的不是答案，而是一个框架——复利模型告诉你什么时候该恐慌，行为双胞胎告诉你为什么检测难，Agent Detector 告诉你至少在 Windows 端点上能做什么。剩下的，是每个 CISO 需要自己回答的问题：你的组织，\(\sigma\phi\) 大于 \(\delta\) 了吗？*