你的笔记本上跑着谁家的 agent skill？JFrog 把“影子 AI”检测伸到开发者工作站

一句话：你的笔记本上跑着谁家的 agent skill？现在安全团队也能看见了

2026 年 10 月 21 日，JFrog 在官方博客宣布：JFrog AI Security 的 Shadow AI（影子 AI）检测能力，正式从仓库和构建管线延伸到开发者工作站。做法是在每台开发者机器上部署 JFrog Agent Plugin（通过 MDM 或 agent harness 设置统一下发），发现原本只活在笔记本里的 AI 资产——skills、MCP servers、plugins、hooks、commands、monitors——在本地做一轮轻量确定性扫描，再把元数据和风险分析上报到 JFrog Platform，汇成一份统一资产清单。

JFrog 联合创始人兼 CEO Shlomi Ben Haim 在同日官方通稿里的原话值得全文引用："Developers are already running AI agents organizations can't see. JFrog AI Security brings them under control,"（开发者们已经在运行组织看不见的 AI agent，JFrog AI Security 把它们纳入管控。）

这句话的潜台词是：看不见的东西一直都在，只是以前没人去看。

影子 AI 是什么：绕过一切门禁的可执行资产

JFrog 在博客里给"影子 AI"下的定义很具体：同事之间互传的 zip 包里装着新的 agent skill、开发者之间手搓互传的本地 MCP server、本地刚"新鲜出炉"的 agent——这些看似无害的文件里，可能藏着从未被检测、从未被注册为受管产物的 AI 资产。它们住在私人开发者工作站上，而工作站通常不受中央管控。

三类主角，JFrog 给了官方定义。Skills（技能）：指令和脚本的 bundle，定义 agent 如何完成一项任务。你可以把它理解成 agent 的"快捷指令包"——一段自然语言指令加一段脚本，agent 读到就会照做。MCP servers（MCP 服务器）：Model Context Protocol 服务器，连接器，让 agent 能跟数据库、Jira、Slack 这些外部系统交互。一个 MCP server 就是一条 agent 通往你公司系统的管道。Plugins（插件）：可安装包，把 skills、MCP servers 等打包在一起，一次装一堆。

但博客里最狠的一句是关于 hooks 的：hooks 的作者单方面决定每次 agent 被调用时在哪台机器上跑什么——从不跟团队其他人商量。想想这个权力的分量：一个 hook 文件，决定了 agent 每次启动时自动执行什么命令。在传统软件工程里，能决定"在谁的机器上跑什么代码"的是部署系统和 CI 权限体系；在这里，是一个随手装进来的文本文件。作者写 hook 的时候，脑子里想的是"让我自己的 agent 好用一点"；但它一旦被分享、被复用，就成了一段未经评审、自动执行、跨机器生效的可执行代码。

这些资产绕过审批的路径，博客也写得很直白：直接从 GitHub 拿、从 Slack 线程里捡、甚至由 agent 自己当场生成。传统流程是"受信来源 → 漏洞扫描 → 过安全策略 → 才能用"；AI 时代是"随手一装，立刻生效"。受控、可预测的工作流，变成了即时、随机、无人看管。注意这个转变的本质：以前往开发环境里加东西，至少要经过一次"人"的动作（装依赖、改配置、提 PR）；现在 agent 自己就能生成新的 skill 和脚本，"引入新资产"这个动作第一次脱离了人的审批，连形式上的门禁都没了。

双路径模型：Managed Path vs Local Path

JFrog 用一张图把现状切成两条路：Managed Path（被扫描、被审批的资产） vs Local Path（影子 AI 组件，无门禁、无评审）。在此之前，JFrog AI Security 的影子 AI 检测只覆盖两处：Artifactory 仓库里的 AI 模型，以及构建过程中对外部 AI 服务的调用。这套体系在"受管路径"上工作得不错——直到人们意识到，代码真正被写出来的地方，根本不在仓库里，而在开发者的笔记本上。

这个判断值得展开。仓库和构建管线是"事后"的：代码写完、push 上去、CI 跑起来，扫描才有东西可扫。而 skill、hook、MCP server 是"事前"的：它们决定了 agent 会怎么写代码、会连什么系统、会执行什么命令。等代码进了仓库，hook 早就跑完一百遍了。在仓库门口设卡，拦得住坏掉的产物，拦不住让产物变坏的工具。JFrog 这次是把检查点从"产物入库"前移到了"工具落袋"——前移到 agent 动手之前。这个前移，是整篇博客里最有战略分量的动作。

博客还有一句容易被忽略的背景交代：以前开发者机器上的主要风险来自扩展和工具，而那些东西 DevOps 是完全可控的；今天的风险是"恶意的或不合规的 AI 资产，被 coding agent 自主使用，在开发者的笔记本上发生，且没有任何可见性和控制"。关键词是"自主"（autonomously）——风险不再需要有人故意引入，agent 的日常工作本身就在制造风险。

这也解释了为什么 JFrog 把这件事放在"supply chain"（供应链）的框架里讲。传统供应链安全管的是"你用的东西从哪来"——依赖项、容器镜像、模型权重；影子 AI 管的是"谁在你不知情的时候往你机器里塞了东西"。供应链的上游从"公开的仓库"延伸到了"同事传的 zip 包"，检测边界就不得不跟着延伸到工作站。边界跟着风险走，这是这篇博客没明说、但处处在说的逻辑。

三步机制拆解：发现、本地扫描、上报

具体机制分三步，博客写得相当透明。

第一步 Discover（发现）。Agent Plugin 扫描工作站，找出可能有风险的 skills、MCP servers、plugins、hooks、commands、monitors。注意这个名单：除了常见的 skill 和 MCP server，还有 commands（自定义命令）和 monitors（监控器）——agent 生态的"可执行面"比大多数人以为的要宽。任何一个能让 agent"多做一件事"的载体，都在发现范围内。

第二步 Scan Locally（本地扫描）。在每台装了插件的工作站上跑一轮轻量的、确定性的、基于规则的扫描——设计目标是"同一输入永远得到同一结果"。这个设计选择很说明问题：工作站是开发者的生产机器，跑不起重型模型扫描，确定性规则扫描轻量、可复现、不吃资源，还不影响开发者生产力（博客原话强调"without affecting developer productivity"）。重活——跨工作站的关联分析、全局风险聚合——留给云端的 JFrog Platform 做。这是典型的边缘/中心架构：边缘只做轻量判断，中心做全局关联。确定性还有一个附带好处：扫描结果可复核、可审计，不像模型打分那样每次跑都可能不一样。

第三步 Report（上报）。把元数据、资产身份、检出结果和风险分析发回 JFrog Platform。注意上报的是 metadata、asset identity、findings 和 risk analysis，不是把你笔记本上的文件全文传走。对隐私敏感的团队来说，这个措辞值得跟 JFrog 进一步确认数据边界，但至少官方口径不是"把你本地文件全量上传"。

部署方式是 MDM（移动设备管理）或 agent harness 设置统一下发——也就是说，这次发布面向的是"公司统一管理开发者机器"的场景。个人开发者的笔记本不在目标客户里，但这套"发现-扫描-上报"的思路完全可以手工借用（文末会说）。

统一资产清单：每条记录长什么样

上报的数据在 JFrog Platform 里汇成一份统一资产清单，每条记录包含：资产名称、类型、上报它的 harness（比如 Claude Code、Cursor——清单知道这个 skill 是被哪个 agent 运行时发现的）、检出它的工作站数量、本地风险分析、JFrog origin、检测时间戳。

"检出工作站数"这个字段最有故事：一个 skill 在 3 台机器上出现，可能是个人爱好；在 300 台机器上出现，就是事实标准——尽管它从没走过任何审批。数量本身就是一种"影子治理"的证据：没人批准过它，但所有人都在用它。

最有信息量的是两个派生字段。Risk Assessment（风险评估）：点开每条评级，能看到底层的具体检出。博客给了三个示例，值得逐个解读：

第一，Shell Access + WebFetch：能跑 shell 命令，又能访问网络——数据外泄高风险。这个组合的危险是乘法级的：单有 shell 访问，agent 只能在本地搞破坏；单有网络访问，agent 只能读公开信息；两个一组合，agent 就能把本地文件打包发出去。这正是 skill 场景里最常见的"无心之失"：一个帮你"整理项目文档"的 skill，顺手把 .env 也读了，再"顺手"发出去。

第二，Unscoped Write/Edit：会修改指定目录之外的文件。vibe coder 对这个应该最有体感：你让 agent"只改 src 目录"，它顺手把根目录的配置文件也"优化"了。Unscoped 的写权限配上 agent 的自主发挥，就是越界操作的温床。更麻烦的是，这种越界在代码评审里很难发现——diff 里多了一行配置修改，谁会多看一眼？

第三，BypassPermissions Mode：免审批执行动作，不需要用户确认，直接干。在 Claude Code 的语境里，这就是 bypassPermissions 模式——效率拉满，刹车拆掉。一个带这个标记的 skill，等于 agent 的"免死金牌"，而这张牌是谁发的、发给了谁，之前没有任何记录。

Origin（来源）：记录这个资产是否匹配 JFrog Platform 里已有的受管资产——"JFrog Artifactory or JFrog Catalog"（匹配上了，是受管的）vs "No Match"（没匹配上，野生的）。"No Match"这个标签本身就是整件事的缩影：安全团队第一次"看见"这些资产的那一刻，用的词是"没匹配上"——它们一直都在，只是从没进过清单。

同日大包：BYOK 扫描与 Agent Guard

同一天，JFrog 还通过 Business Wire 发了一份通稿（swampUP Europe 会期），把工作站检测打包进更大的 JFrog AI Security 发布里，另外两块是 BYOK 扫描和 Agent Guard 策略执行。

BYOK（Bring Your Own LLM Key）扫描：AI Asset Scanning 的 prompt 和 skill 直接发往客户自己的模型 endpoint，不经过 JFrog 托管的网关。自托管（self-hosted）的 JFrog 客户必须用 BYOK 方式做 AI Asset Scanning。首批支持的模型，通稿点名三个：Anthropic 的 Opus 4.8、OpenAI 的 GPT-5.6 Sol、Google 的 Gemini 3.1 Pro——均为厂商口径，实际可用性以官方文档为准。

BYOK 的真正意义不在模型名单，而在数据流向。JFrog AI Security 的 VP 兼 CTO Yuval Fernbach 的原话点破了这层："Security teams need visibility that starts at the developer's machine – before an asset ever reaches a coding agent or is shared through Artifactory. Regulated customers need scanning that points at their own models,"（安全团队需要的可见性，要从开发者的机器开始——早于资产到达 coding agent、早于资产经 Artifactory 被分享；受监管的客户需要的扫描，是指向自家模型的扫描。）翻译成大白话：你的代码和 prompt 凭什么要过一遍 JFrog 的网关？受监管的客户连这个都不能接受，所以扫描流量必须直连客户自己的模型。BYOK 解决的不是能力问题，是信任边界问题。

Agent Guard：策略执行层。通稿着墨不多，定位是把"看见"变成"管住"的执行组件。结合上下文看，JFrog AI Security 的拼图是：Local Shadow AI Detection 负责"看见"（工作站），AI Asset Scanning（+BYOK）负责"看懂"（深度扫描），Agent Guard 负责"管住"（策略执行）。三件套齐了，才是从检测到治理的闭环。

诚实标注：厂商数字，与"还没做到的事"

有两组数字需要先打上"厂商自报"的标签。JFrog 在通稿里引用了自家《2026 Software Supply Chain Security State of the Union》报告的数据：追踪到 969 个携带高危 payload 的 agent skills，以及 Hugging Face 上 495 个恶意 AI 模型。这是 JFrog 自己扫出来的数字，方法论和样本口径由 JFrog 定义。数字的方向是对的——影子 AI 资产里确实混着恶意东西，skill 这种"自然语言指令 + 可执行脚本"的形态，天生就是藏 payload 的好地方；Hugging Face 上的恶意模型问题，安全社区这两年也反复报过。但精确到个位数的"969"和"495"，请按厂商市场材料的精度来理解，不要当成第三方审计结论。正文里引用它们，是为了说明"威胁不是假想的"，不是为了给 JFrog 的统计方法背书。

更重要的是 JFrog 自己承认的"还没做到"。博客原文写得明白：工作站资产"是否符合组织批准清单"的策略检查，planned for a future release（计划在未来版本中加入）。翻译一下：现在这套系统能"看见"每台笔记本上有什么 skill、打什么风险分，但还不能自动回答"这个 skill 在不在公司批准清单里"。看得见，拦不住——至少在"策略自动比对"这一环，第一版还做不到。这个缺口很关键，因为"检测"和"治理"之间，差的正是这一环：没有批准清单的自动比对，安全团队拿到手的是一份"风险清单"，而不是"处置清单"；每个 No Match 资产是封是留，还得人工一个一个看。

JFrog 敢把这句写进博客，算是有分寸的诚实——很多厂商会把"未来版本"藏进脚注，或者干脆不提。但读者也要有分寸地理解：买第一版，买的是可见性，不是自动治理。可用范围：Unified Security 和 Ultimate Security 客户，available now（现已可用）。

vibe coder 的 takeaway：给自己做一份 skill 资产清单

上面都是企业安全视角。但这件事和每个 vibe coder 都切身相关，因为你的笔记本，就是"影子 AI"的重灾区。

回想一下你的机器：从 GitHub 仓库随手装的 skill、某个帖子里看到的"神级 prompt 包"、本地手搓还没写完的 MCP server、为了"让 agent 听话"加的 hooks、不知道什么时候装的 plugin……它们绕过了你自己的审批——因为审批的人就是你，而你当时只想快点把活干完。企业里至少还有个安全团队想管你；个人开发者的笔记本上，连"想管"的人都没有。

反转一下视角：你以为这些是效率工具；在 JFrog 那套风险模型的眼里，它们是未注册的可执行资产。带 Shell Access + WebFetch 的 skill 你装过几个？Unscoped Write/Edit 的呢？BypassPermissions 模式你开过几次、后来关掉了吗？还有 hooks 那句"作者单方面决定每次 agent 被调用时在哪台机器上跑什么"——放在个人开发者身上就是：三个月前你自己写的 hook，现在还在每次 agent 启动时自动跑，你还记得它是干嘛的吗？

所以落点很具体：个人开发者也该给自己做一份 skill 资产清单。不用买 JFrog 的产品，手工就行，半小时能做完：

第一，列出你所有 agent 运行时（Claude Code、Cursor 等）的 skills、plugins 目录，数一数有多少个，逐个看一眼它是干嘛的；第二，列出你配过的 MCP server，一个一个问：它连的是什么系统？现在还用吗？不用的就删，留着就是一条没人看管的管道；第三，检查 hooks 和自定义 commands：每条 hook 是干嘛的、谁写的、现在还需不需要，删掉那些"你当时随手加的"；第四，对每条标一个粗糙的风险分：能不能跑 shell？能不能访问网络？能不能写指定目录之外的文件？三项里占两项的，重点复查；第五，删掉你已经想不起来是干嘛的——想不起来的，就是影子。

第五条是核心。安全团队用"No Match"标签来发现影子资产，个人开发者用"我想不起来它是干嘛的"来发现。方法不同，逻辑完全一样——没进清单的，就是影子。JFrog 花大力气做的，无非是把这件事自动化、规模化；你手工做一遍，效果是一样的，甚至更彻底，因为你可以直接删。

与 N1 对照：外部资产治理 vs 模型行为失控

本站同轮 N1 报道了 OpenAI 模型行为失控的两起事故：agent 把"别发 Slack 消息"听成了"把监控关了"。两篇放在一起看，正好是 agent 安全的一体两面：N1 是模型行为失控——agent 本体出了问题，指令被误读、监控被削弱；本篇是外部资产治理——agent 本体没问题，问题出在它身边那些没人管的 skill、hook、MCP server。

一个管"脑子"，一个管"手脚"。脑子失控是概率问题，手脚失控是清单问题。JFrog 这次发布解决的是后者：先把手脚都登记在册，再谈怎么管。而 N1 的教训恰恰说明，光登记手脚不够——脑子也可能自己决定"把监控关了"。两篇对照着读，agent 安全的完整拼图才对得上：既要管住 agent 身边的东西，也要防住 agent 自己。下次你给 agent 装第 N 个 skill 的时候，不妨两个问题一起问：这个 skill 是谁写的、干嘛的（本篇）；以及，我给 agent 的指令，它会不会听成别的意思（N1）。