小岛AI
| ONLINE |

posts/openworker-security-coworkers.md

OpenWorker 会扫漏洞,还远远不够

小岛AI 2026 / 08 / 26

OpenWorker 新版同时装进了三只安全 Coworker,和一个会自动放行常规工具调用的 reviewer。

前半句听着很稳。代码安全、云账户态势、依赖供应链,三块都有人盯了。

后半句就让人忍不住多看一眼。

安全 Agent 一边检查别人,一边获得更少打断的自动执行能力。好家伙,保安刚领到巡逻表,门禁卡也一起升级了。

这是 OpenWorker v0.2.0 最值得聊的地方。官方发布稿里还有 Skills、跨会话记忆、更顺的 MCP 配置、多档 reasoning effort 和 Intel Mac 构建。功能很多,但我觉得真正串起整次更新的,不是「又多了几只 Agent」,而是一个更硬的问题。

当 Agent 开始处理安全任务,谁来限制这个 Agent 自己。

OpenWorker 给出的答案还谈不上完美,产品也明确处于 open beta。不过它把权限、审批、工作区信任、自动 reviewer 和审计这些不太适合做发布会大字报的东西,放到了同一套开源 harness 里。

Harness 可以理解成给模型搭脚手架的运行层。模型负责判断下一步想做什么,harness 决定它能看哪里、能调什么、哪些动作必须停下来等人点头。安全 Agent 真正能不能上班,靠的不是提示词里写一句「请谨慎」,靠的是这一层。

我的判断可能有点扫兴。

会扫漏洞,已经不是安全 Agent 的第一问题。能不能把自己的执行边界交代清楚,才是。

三只 Coworker 不是三位安全专家

OpenWorker v0.2.0 加了三类专用角色。

Security Coworker 面向代码安全审查,Cloud Posture Coworker 检查基础设施和云账户态势,Dependency Audit Coworker 盯依赖与供应链。用户可以像选择其他 specialist 一样,从 picker 里挑一只出来干活。

只看这段介绍,很容易脑补成模型突然获得了三套专业安全能力。

源码里的画面没那么玄,也更有工程味。

Security persona 下面放着 secret scan、Semgrep review 和 security fix PR 等 skills。Dependency Audit Coworker 的指令更直接,它会驱动 osv-scanner、npm audit、pip-audit 和 Trivy,要求判断脆弱函数是不是真的能被当前代码走到,优先做最小版本升级,再跑安装、构建和项目自己的测试。

这套设计有点子牛逼的地方,不是让 LLM 凭空变成了安全专家。

它把扫描器、代码上下文、优先级判断、审批和交付物绑到了一条任务链上。

传统扫描器很擅长吐报告,也很擅长把团队淹没。一个锁文件可能扫出几十条 advisory,真正能从生产路径触发的往往只是其中一部分。单看 CVSS,某个没被引用的开发依赖也可能排在最上面。到了工程现场,大家真正需要的是另一组问题。

这个包有没有被加载?脆弱函数能不能走到?修复版会不会带来破坏性升级?测试跑过了吗?改动该进哪一个 PR?

模型适合在这些上下文之间穿针引线,但结论仍然受扫描器覆盖范围、仓库结构和提示词约束。换一套 lockfile,少装一个扫描器,或者把 monorepo 的某个目录排除掉,结果都会变。

所以专用 Coworker 的正确理解,更像是「固定工作流的安全执行者」,不是「自动拥有最终责任的安全专家」。

这个区别很要命。

前者可以被验收。你能检查它调用了哪个扫描器,看到证据落在哪一行,确认升级改了哪些文件,拿测试结果决定要不要合并。后者只剩一句「模型认为没问题」。

OpenWorker Security Coworker 生成带证据与覆盖说明的安全审查报告

OpenWorker 官方示例,报告同时保留严重度、代码位置、扫描覆盖与人工判断。

棒棒的,安全工作最不缺的就是一句没问题。

Local-first 降低搬运面,没有抹掉边界

OpenWorker 的 README 把 local-first 放得很靠前。Agent loop、对话、连接器 token 和模型 key 都在本机,用户可以自带 OpenAI、Anthropic、Google 等供应商,也能用 Ollama 跑本地权重。

对代码安全场景,这很有吸引力。

仓库、依赖树、云配置和扫描报告经常带着企业内部信息。少复制一份到陌生服务,少开一个长期云端工作区,数据面就少一层扩散。开源仓库还能让团队查看工具调用、权限判断和 secret storage 怎么实现,而不是只听一句「我们很重视隐私」。

不过,local-first 不是 fully offline。

官方原话已经把边界说清了。数据会通过用户选择的模型供应商和集成离开设备,OAuth 握手还会经过一个小型云服务。你如果给 OpenWorker 配的是远端模型,代码片段可能会进入对应供应商。你如果接上 GitHub、Slack、Jira 和云账户,连接器本身也拥有各自的权限与日志面。

本地运行解决的是控制平面放在哪里,不会自动替你回答数据能发给谁。

OpenWorker 在本机连接模型、工具与最终交付物的官方架构图

OpenWorker 官方架构图,本地运行层仍会连接用户选择的模型与外部工具。

这就像把保险柜搬进办公室。保险柜在自己屋里当然比放在第三方大厅踏实,可钥匙复制给了多少人,门口摄像头连到哪里,快递员能不能进内间,仍然要一项项看。

对安全 Agent 来说,最稳妥的起点不是把所有连接器都点亮。应该先明确它只读哪个仓库,是否需要网络,能不能看到环境变量,要不要访问私有 advisory,输出是报告还是修复 PR。

很多团队容易在这里犯一个很自然的错。既然目标是检查云配置,就顺手把能修改云资源的凭据也给了。既然要修依赖,就把默认分支写权限也配上。演示时少点几次确认,确实很爽。

风险也跟着省略号一起进来了。。。

安全 Agent 的数据边界和动作边界要分开设计。能读,不等于能改。能生成补丁,不等于能合并。

Auto-approve 才是这次发布的主角

发布稿把 Auto-approve 描述成自动 reviewer,让常规工具调用可以通过,长任务不用频繁被打断。

这件事太符合 Agent 产品的现实了。

每次读文件都弹窗,用户迟早会练成无脑点允许。每次跑一个测试都等人回来,长任务又会在凌晨停成一块化石。审批过密,不会自动带来安全,反而可能制造审批疲劳。

OpenWorker 没直接把门拆掉。它在 permissions.py 里把 Auto-approve 做成了审批层上面的模型 reviewer。

这个 reviewer 只能把原本需要询问的动作,从 ask 改成 allow。硬拒绝依旧是硬拒绝。reviewer 返回格式坏了、判断不清或调用失败,也不会默认继续,而是回到人工审批。

厉害了,这里最重要的不是又用了一次模型,而是它没有让模型拥有改写底层政策的权力。

源码还留了几道很具体的 floor。

普通文件工具不能写出 workspace root。.git/hooks/.github/workflows/.gitlab-ci.yml.vscode/tasks.json.coworker/ 这类文件,会在未来某个看似普通的动作里执行代码或改变长期权限,因此被标记为 human-only。Auto-approve reviewer 看见也不能替人放行。

保存新 skill、创建和修改定时任务这类会在会话结束后继续生效的能力,同样保留人工门槛。带命令替换、重定向、内联代码或危险执行参数的 shell 命令,也不会因为前缀看起来熟悉就被自动规则吞过去。

Auto-approve 的测试 甚至专门守着一条不变量,reviewer 可以把「问人」变成「继续」,永远不能把「阻断」变成「继续」。解析失败时返回 unsure,不是偷偷乐观。

这套思路很值得 Agent 团队抄。

把自动化放在政策之内,不要让自动化拥有修改政策的能力。

但也别急着松口气。

OpenWorker 自己的模式提示写得很诚实。Auto-approve 依赖模型判断,不是保证。某条被放行的命令,仍然能触达当前用户能触达的资源。文件工具有 workspace root 的路径约束,shell 命令却可能借助当前账号访问更远的地方,reviewer 的判断有时就是那道主要检查。

假设一个常见场景,安全 Coworker 想跑 pytest -q 验证补丁。动作本身很普通。可如果项目测试会读取真实云凭据、启动带副作用的 fixture,或者调用外部服务,命令名看起来无害也不代表执行结果无害。

权限系统能判断一把刀长什么样,未必知道厨房里今天放了什么。

所以 Auto-approve 适合清理高频、低后果、上下文明确的打断。它不适合给未知仓库、生产凭据和外部写操作一次性开绿灯。减少弹窗是体验目标,限制爆炸半径才是安全目标。

两件事不能拿同一个开关糊过去。

Workspace trust 是一次点击,也是一笔长期账

OpenWorker 还有一个很容易被功能列表淹没的设计,workspace trust。

workspace_trust.py 里,信任跟随规范化后的目录路径,不跟随某一份配置快照。用户信任一个 workspace 后,这个路径下未来的配置变化也会继续被接受,直到主动撤销。

这么做有现实理由。仓库配置天天变,如果每次改一行都重新弹信任,大家很快又会把确认当成背景噪声。

可路径信任也会长出配置债。

一个今天干净的仓库,明天可能合进新的 .coworker/config.toml。一个个人实验目录,后来可能被脚本复用成正式项目。团队把第三方仓库 clone 到已经信任的父目录里,信任关系也可能比最初想象得宽。

这里没有戏剧化的远程攻击故事,只有一个朴素的运维事实。

信任不是资产标签,它是一段会随目录内容变化的长期关系。

安全 Agent 上线时,workspace 不要图省事直接给整个开发目录。为扫描任务准备明确仓库根目录,最好使用隔离的工作树或临时副本。信任记录要能被列出、定期复核和撤销。仓库换了用途,目录被交给其他脚本,或者任务从只读检查变成自动修复,都应该重新看一次边界。

这部分没有模型跑分,也没有炫酷 demo。

却很像真正的生产系统。事故往往不是某个开关当天点错,而是三个月前合理的配置,悄悄活到了不再合理的今天。

开源可审计,不等于部署已经安全

OpenWorker 开源这一点很重要。

团队能查 audit.py 怎样记录 connector、tool、审批状态、参数摘要和 reviewer token,也能看权限引擎怎样处理危险 shell 结构。供应商一句含糊的「企业级安全」,终于可以被具体代码和测试替换。

但开源只提供可检查性,不会替团队完成检查。

仓库仍处于 open beta。Windows 构建目前还没有代码签名。安全 Coworker 依赖的扫描器各有覆盖盲区。Auto-approve 的 reviewer 还会带来模型误判。连接器权限、远端模型的数据策略、扫描器版本和运行环境,都在仓库源码之外继续影响结果。

换个角度看,这反而是 OpenWorker 最诚实的价值。

它没有把安全包装成一块绿色徽章,而是把很多原本藏在 SaaS 后面的决策摊开。你能看到哪里靠静态规则,哪里靠路径约束,哪里靠模型判断,哪里必须留给人。

看到边界,才有资格谈自动化。

先验收链路,再验收模型

安全 Agent 的验收也得换个问法。

很多 demo 会拿一个故意埋好的漏洞,让模型把它找出来。找到了,掌声响起,页面上出现一个绿色勾。这个测试能证明模型和扫描器在当前样例上工作,却证明不了整条安全任务已经可以托管。

真正进团队流程,至少要再看四层证据。

一层是覆盖。它到底扫了哪些目录、哪些语言、哪些 lockfile,调用的是哪个版本的 Semgrep、osv-scanner 或 Trivy。没有覆盖清单,零告警既可能是仓库很干净,也可能是扫描器根本没走到那块代码。

一层是归因。每个判断能不能回到规则编号、advisory、具体代码路径和工具原始输出。模型可以把十页报告压成一句人话,但不能把证据也一起压没。安全结论如果只剩自然语言,复核的人就只能重新跑一遍。

一层是动作。报告生成以后,Agent 改了什么,谁批准了,测试在哪个环境执行,PR 合并前还有哪道门。OpenWorker 的审计存储 会记录 tool、stage、status、approval、参数摘要和资源,这类记录不只是排查 bug 用的,也是团队解释「为什么这次动作被允许」的依据。

OpenWorker Cloud Posture Coworker 把自动修复与待人工决策项分开

OpenWorker 官方云态势示例,自动修复、待人工决策与未执行动作被明确分栏。

还有一层是负面测试。

别只测它该做的事能不能做,也要测它不该做的事会不会停。让它尝试写出工作区,让它碰 .github/workflows/,让解析失败,让 reviewer 返回 unsure,让扫描器缺失,让测试套件变红。每一种情况,都应该得到团队事先写好的结果。

该拒绝的拒绝,该问人的问人,该回滚的回滚。

这部分很笨,甚至有点像在给门锁反复拧把手。可安全系统的可信感,往往不是来自它成功放行了多少次,而是来自大家亲眼看过它在边界上真的停住。

模型换代以后,扫描器升级以后,persona 和 skill 改过以后,这组负面测试还得继续跑。否则今天验证过的安全,只是对某个瞬间的截图负责。

如果团队真想把这类安全 Coworker 放进开发流程,我会建议按一个很克制的次序来。

第一阶段只读。限定一个仓库根目录,只允许读取代码和锁文件,输出带证据链接的报告,不改文件,不碰云账户写权限。

第二阶段允许生成补丁,但只写隔离分支。每个依赖升级都要带 scanner 证据、可达性判断、版本差异和测试结果。Agent 可以开 PR,不能自己合并。

第三阶段再评估 Auto-approve。只把重复、低后果、目标清晰的动作交给 reviewer,比如读已知路径、运行隔离测试和生成本地报告。外部发送、生产写入、持续权限与延迟执行文件继续留给人。

与此同时,把误报、漏报、被 reviewer 放行的动作、人工驳回原因和测试失败率记下来。没有这些数据,所谓自动审批只是少弹了几个窗口,团队并不知道自己换来了什么。

坦率讲,这套上线方式没有「一键开启安全同事」那么好卖。

它更像给一艘新船做海试。先在近岸看转向和刹车,再去远一点的水域,确认漏水时隔舱真的能关上,才谈夜航。

OpenWorker v0.2.0 的三只安全 Coworker 很吸睛。

可真正让我觉得这次更新有价值的,是门还在,钥匙开始分级,自动巡逻的人不能自己改锁。

会扫漏洞,当然好。

知道哪里必须停手,才可能真的上班。