2026 年是 Agent 安全工程从被动修补转向主动防御的转折点,这件事在最近两个月的几个独立事件里被反复印证。6 月 20 日 Argus Security 在 Hacker News 发布《We post-trained a model that pen tests instead of refusing》,93 分上首页讨论 10 条——这家 YC W23 公司基于 Kimi K2.6 开
2026 年是 Agent 安全工程从被动修补转向主动防御的转折点,这件事在最近两个月的几个独立事件里被反复印证。6 月 20 日 Argus Security 在 Hacker News 发布《We post-trained a model that pen tests instead of refusing》,93 分上首页讨论 10 条——这家 YC W23 公司基于 Kimi K2.6 开源权重做 SFT 加 RL with verifiable rewards against actual exploit checks,专门训练了一个不会拒绝渗透测试任务的模型;9 月 10 日 Reware Labs 发布 Security Cards,4 分首页关注,在 BaxBench 上把 Claude Code Opus 4.7 的 insecure-and-correct 比例从 23.9% 压到 6.6%,相对降幅 72.3%,安全通过率提升 21.4%,功能正确率只掉 0.5%。同月 19 日,YC S26 的 OneCLI 在 Hacker News 发布《OSS sandboxed agent harness for teams》,88 分上首页讨论,把"Agent 不能拥有真实密钥"这件事做成了一套带 deterministic HITL approval 的开源 harness。这三件事合在一起,把一个长期被忽视但极其重要的趋势摆到了桌面上——Harness 不能再把 Agent 当成被动工具,而必须从设计阶段就假设 Agent 会主动发现并尝试利用漏洞,并针对这个行为做防御性工程。
## 一、AI Agent 不被要求也会主动挖漏洞
这件事在 Argus Security 的 HN 帖里被首次明确点出——AI 可以同时作为攻防两端的工具,最坏的结果是只有攻击者能用到这些能力。Argus 把这背后的逻辑讲得很清楚:Anthropic 和 OpenAI 的公开模型被显式 guard-railed 拒绝 offensive 任务,他们的 cyber 专版又只向 enterprise 开放,结果是 SME 和 midmarket 公司完全暴露在 major vulnerabilities 下。与此同时,大多数现有的 AI cyber 工具只是 wrapper,foundation model 的 guardrails 还在,继承的拒绝行为没法绕开。
为了解决这个 gap,Argus 在 Kimi K2.6 开源权重上做了 post-training——SFT 在 CTF writeups 上,RL 用 verifiable rewards against actual exploit checks。出来的模型有两个 mode:Security scan 是只读审计本地代码库,只报能精确到 file/line 的漏洞,不输出 vibe-based findings;Pen test 是主动对抗模式,在 sandboxed 环境里尝试攻破 live system,每个漏洞都用真实 exploit 验证,跑请求看响应,不给 confidence score。
Argus 给出的 demo 是 Bank of Anthos——Google 开源银行 app,故意做得脆弱,方便 clone 后自己跑 scan 验证。Argus 在 transfer path 上找到一个 integer overflow:amount 是 int,amount + fee 溢出为负数,balance check 通过,用户可以转走没有的钱。这是典型的"模型不问也会挖出来"的例子——代码表面上看起来正确,只有真实跑起来才会暴露漏洞边界。
这件事的工程价值在于它揭示了一个 Agent 平台设计者必须面对的现实:任何能读代码的工具,无论用户是否明确要求它做漏洞研究,它都会主动找漏洞。这意味着 Harness 在设计阶段就必须假设 Agent 有 pen-test 能力,而不是依赖 foundation model 的 guardrails 来"被动禁止"。一旦某个新版模型更新 guardrails 失效,或者 Harness 接入的某个第三方插件被供应链污染,Agent 就会主动去找漏洞,而这种主动行为的后果完全由 Harness 设计者承担。
## 二、Harness 必须从被动审计升级为主动防御
Argus 把 pen-test AI 做成了独立产品,这件事的企业落地意义在于它意味着 Harness 必须从被动审计(Agent 跑完任务后做合规检查)升级为主动防御(Harness 在 Agent 执行链路里持续监测异常行为)。这件事在 OneCLI 的设计里被体现得最完整。
OneCLI 是 YC S26 的开源(Apache-2.0 + small enterprise exception)sandboxed agent harness,核心架构是把 Agent 跑在一个 team 级别的 harness 里,所有 secrets 不直接交给 Agent,而是过一层 vault,gateway 在 Agent 想用 secret 时做 deterministic 审批。OneCLI 创始团队在 HN 帖里复述了驱动他们做这件事的契机——他们原来做 ChartDB,一个开源 DB 工具,OpenClaw 起来之后他们用它 orchestrate agents,发现一个核心问题:Agents 需要 credential 才能做真实工作,但给它们 secret 又不安全——Agent 会把 secret 写进 memory、本地文件、session 明文,而且很容易被 prompt injection 骗走。
这种"Agent 拥有 secret → Agent 被 prompt injection → secret 外泄"的链路在 Argus 这件事的语境下变得更危险——一旦 Agent 有能力主动找漏洞,它一旦拿到 secret 就可能用 secret 去横向移动,渗透到企业其他系统。OneCLI 的解法是让 Agent 从来不持有真实 secret,所有调用通过 vault gateway,每次调用走 deterministic HITL approval,这样即使 Agent 被攻破,attacker 也拿不到可复用的 secret,只能发起已经被审计过的动作。
具体到工程细节,OneCLI 提供了四件事。第一,sandboxed agent——带完整 OneCLI 能力(连接 GitHub/Gmail/Notion/Dropbox)的 Agent 一键启动。第二,deterministic human-in-the-loop approval——在聊天界面里就能完成审批,适合发邮件、删 Linear ticket 这种必须 100% 控制的场景。第三,team policy in one place——一个地方管理所有 Agent 的策略,在 workspace 内统一执行。第四,global connections——team 级别的共享 LLM keys 或 service accounts,个人 Agent 不持有。
OneCLI 的 agent engine 用的是 jcode,核心是 agent-loop,团队说它比之前方案体验更好、Agent 更聪明更快。整套系统跑在企业自己的 infra 上,fully open-source,几分钟可以自托管或上云。安全不是承诺,是企业可以自己 verify 的代码。
## 三、Security Cards:从 harness 内部给 Agent 补上安全知识
把主动防御这件事再往前推一步,Security Cards 给出了另一类解法——不修改 Harness,而是在 Agent 的知识库里塞入 library-specific 的安全指南,让 Agent 在写代码时自动应用。
Reware Labs 这家公司的实证数据非常硬核。他们用 BaxBench(ETH Zurich + LogicStar.ai + UC Berkeley + INSAIT 联合发布的 benchmark,392 个任务、28 个 backend 场景、14 个 framework、6 种语言)测了 Claude Code 在 Opus 4.7 和 Haiku 4.5 两个模型上的 insecure-and-correct 比例。Security Cards 加进去后,Opus 4.7 的 insecure-and-correct 从 23.9% 掉到 6.6%,相对降幅 72.3%;Haiku 4.5 从 35.6% 掉到 14.3%,相对降幅 59.8%。同时 secure pass@1 涨了 21.4%(Opus)和 27.5%(Haiku),functional pass@1 只掉了 0.5%(Opus)和 5.0%(Haiku)。
这套机制的工作原理是,Security Cards 为 80+ 主流 library 提供安全指引,每张 card 都有"Use when"段落告诉 Agent 何时该用、具体怎么做、安全编码模式是什么。Agent 通过 `npx skills add Reware-Labs/securitycards --skill securitycards -g` 安装 skill,写代码时自动获取相关 card 当 context。最关键的是,skill 不会访问用户代码本身——它只把相关的安全 guidance 注入 Agent context,代码仍然只在用户已经在用的 Agent 和环境里访问。
Security Cards 的工程价值在于它补的是 Agent 安全知识层——很多代码漏洞不是因为 Agent 没有 pen-test 能力,而是因为 Agent 在写代码时根本没有"这个 library 的安全用法"的精确知识。Security Cards 把这类知识显式化、结构化、可版本管理,直接降低 Agent 写 insecure 代码的概率。这种"防患于未然"的策略和 OneCLI 的"运行时拦截"策略形成互补——Security Cards 让 Agent 少写漏洞,OneCLI 让 Agent 即使写了漏洞也跑不到生产。
## 四、把三件事合起来:Harness 安全工程的新基线
把 Argus、OneCLI、Security Cards 三件事合起来看,可以非常清晰地看到一个 Harness 安全工程的新基线正在形成。
第一,Agent 必须被假设有 pen-test 能力。Argus 用实证数据说明任何能读代码的 Agent 都会主动找漏洞,Harness 在设计阶段就必须以这个假设为出发点。这意味着 Harness 不能依赖 foundation model 的 guardrails 来"被动禁止"Agent 找漏洞,因为 guardrails 随时可能因为模型更新或 prompt injection 而失效。Harness 必须从架构层面主动防御——OneCLI 的 vault + gateway + deterministic approval 就是这个思路的样板。
第二,Agent 必须不持有真实 secret。OneCLI 反复强调,任何 Agent 直接持有 secret 的 Harness 设计,都等于把 secret 暴露给 attacker。一旦 Agent 被 prompt injection 攻破,attacker 不只拿到 secret,还能用 secret 横向移动到企业其他系统。Harness 必须把 secret 隔离到 vault,gateway 在调用时做 deterministic approval,这样即使 Agent 被攻破,attacker 也只能发起已经被审计过的动作。
第三,Agent 必须有 library-specific 安全知识。Security Cards 给出实证——72.3% 相对降幅不靠改 Harness 架构,靠的是给 Agent 补齐 library-specific 安全知识。这类知识必须显式化、结构化、可版本管理,而不是依赖 Agent 在预训练数据里模糊学到的零碎记忆。企业落地时应该维护一份内部 Security Cards 仓库,把公司所有常用 library 的安全用法沉淀下来,作为 Harness 的标准输入。
第四,Agent 的安全性能必须可量化。Security Cards 用 BaxBench 给出 23.9% → 6.6% 这种精确数字,这种"可量化"是 Harness 安全工程的必要前提。企业落地时,必须选一个安全 benchmark(如 BaxBench、CyberGym、SWE-Bench Security 等)定期跑,把数字作为 Harness 升级或模型切换的硬指标。
第五,Harness 必须默认 sandboxed。OneCLI、machine0、E2B、Firecracker 这些产品的共同点是都默认 Agent 跑在 sandbox 里,任何一步操作都受 sandbox 边界约束。企业落地时,任何 Agent 平台都必须以 sandbox 为默认部署形态,而不是允许 Agent 在企业内网裸跑。
## 五、企业 Harness 对抗自发现漏洞的具体清单
把上面的五条基线映射回企业落地,会得到一份 Harness 对抗自发现漏洞的具体清单。
第一条,Harness 必须假设 Agent 具备 pen-test 能力并主动防御。任何 Agent 平台在架构设计阶段就必须假设 Agent 会主动尝试横向移动、读取敏感数据、调用未授权工具,不能用任何形式的"AI 安全"作为唯一防线。
第二条,Harness 必须把 secret 隔离到 vault,Agent 从来不持有真实 credential。Vault 通过 deterministic gateway 在 Agent 调用时做审批,审批流可审计、可重放、可回滚。
第三条,Harness 必须维护内部 Security Cards 知识库。把企业所有常用 library 的安全用法、internal API 的安全约束、合规要求的强制规则沉淀成结构化知识,作为 Agent context 的标准输入。
第四条,Harness 必须选安全 benchmark 做持续评估。BaxBench 是个起点,企业内部应该基于自己的代码库和合规要求定制 benchmark,定期跑出数字,作为 Harness 升级和模型切换的硬指标。
第五条,Harness 必须默认 sandboxed。任何 Agent 跑在 sandbox 里,sandbox 边界按"最小权限 + 一次性凭证 + 审计可观测"三件套配置,不允许 Agent 在企业内网裸跑。
把这五条放在一起,可以看出 Harness 安全工程正在从"被动合规检查"过渡到"主动对抗工程"。被动合规是 Agent 跑完任务后审计 CoT,主动对抗是 Harness 在 Agent 执行链路里持续监测异常行为、在 Agent 调用前做审批拦截、在 Agent 知识库里塞安全指南、在 Agent sandbox 边界做隔离。四层叠加,Harness 才能真正承担起生产环境 Agent 平台的安全责任。
回到一开始的问题——Argus、OneCLI、Security Cards 三件事合起来,把"AI Agent 即使没被要求也会主动挖漏洞"这个长期被忽视但极其重要的事实第一次用产品形态清楚地呈现出来。剩下的就是企业 IT 在落地 Harness 时把这五条基线都做对,把 Agent 安全工程从被动修补推进到主动防御。一年内,具备完整主动防御能力的 Harness 会成为企业 Agent 部署的入场券,没有这套能力的 Harness 会在第一个重大安全事故后退场。