造应用的人换了，Agent 安全评测的假设没换：这周三份新证据把口径推向防御侧

我这两天在翻三条互不相干的信号流，翻到最后发现它们撞在同一个词上：Agent 安全评测。

第一条来自 GitHub：十月上旬新建的仓库里，一批小项目在做同一件事——把 Agent 干过什么、哪些字段是它拿默认值填的，变成人能看见的东西。第二条来自 arXiv：十月十二日与十三日，连续四篇论文在问同一个问题，我们用什么口径判断一个 Agent 靠不靠谱。第三条来自行业：十月十三日，Pluto Security 带着四千两百万美元融资走出隐身模式，创始人留下一句话——"我们正在从用户行为转向 Agent 行为"。

三条线彼此不认识，指向的却是同一个错位：造应用的人换了一大批，兜底的口径还停在原来那批人身上。我会按 Agent 安全评测的四格错位把证据摊开，讲清它具体错在哪几格，再给一份我自己改过两版、可直接抄走的检查点清单。所有数字都标出处与口径，单源转述处我会明说未验证。

一、造应用的人换了：Agent 安全评测的前提假设被抽掉了

两小时进企业，财务部门排第一

先把一个事实钉住。传统应用安全模型有一个从不言明的前提：写这个应用的人是工程师，他懂鉴权、懂数据分级、知道什么不能放公网。这个前提在 2026 年已经不成立了。

TechCrunch 在二〇二六年十月十三日的报道里，Pluto Security 的 CEO 兼联合创始人 Shahar Bahat 给了一个我很在意的数字：一个新发布的 AI 工具，平均在发布后两小时内就会出现在客户的环境里。更关键的是风险分布——她公司在其客户群里检测到的风险中，约百分之六十来自非开发者用 vibe-coding 做出来的工具；财务部门是这类风险的最大来源，其次是市场和法务，开发者排第四。

我读到"开发者排第四"时停了一下。它把安全团队的默认画像整个推翻：过去面向开发者的安全培训、代码门禁与依赖扫描，覆盖的是排在第四位的那群人。报道还举了一个案例——某财富五百强公司的财务员工用 vibe-coding 做了一个管理客户信息与流失的应用，做完就暴露在公网上。

融资结构我也核了一遍：种子轮八百五十万美元由 TLV Partners 领投，A 轮三千四百万美元由 Jump Capital 领投，合计四千二百万美元；四月开始商业化，已有三十多家企业客户。数字出自同一篇一手报道，我按原口径引用，未做二次推算。

分发门被挪到了个人侧

第二条证据更微妙。同为十月十三日，Google Play 宣布支持私人 vibe-coded 应用：用 Google AI Studio 生成后，可用自己的 Google 账号在自己的 Android 设备上启动，不出现在 Play 的搜索或列表页，也不分享给任何人。

请注意这里挪动的是哪一格。过去想在手机上跑一个应用，得走公开上架，而公开上架意味着信任与安全审查这道门。现在这道门被绕过去了——报道明确说这些个人应用仍须遵守 Google Play 的现有政策，但不再经过公开列表那道流程。首批只开放给美国地区十八岁以上用户，几个月后会允许分享给"可信好友网"，再往后才有完成信任与安全审查后转公开的路径。Play 与开发者生态的副总裁兼总经理 Sam Bright 把它概括成"从'有一个应用适合这件事'走向'有一个应用适合我'"。

我的读法是：平台把便利给到个人侧，把合规义务留在个人侧，但检查动作并没有跟着挪过去。这不等于平台做错了，它等于治理模型出现了新的空档。

这个空档不是第一次出现。二〇二六年九月二十五日 TechCrunch 就报道过 UpGuard 的发现：托管在 Supabase 上的约一万六千个数据库把姓名、地址、电话乃至密码暴露在公网上；Supabase 的 CISO 回应称平台"默认安全"，安全由平台与客户共担。责任共担在云时代是对的，但当生产者是财务同事时，他并不知道自己承担了哪一半。

二、Agent 安全评测还停在"能不能打穿"

攻破只要一个洞，修好要修全部

生产侧变了，评测侧却几乎没动。这一格是本周第二个信号，也是最硬的一条证据。

CWE-bench（arXiv 2610.17020，二〇二六年十月十二日）开篇就把问题说透了：网络安全评测长期聚焦攻击侧，但一个能跑通的 exploit 并不能说明这个 Agent 有能力让软件变安全，因为攻击者只需利用一个漏洞，防御者必须找出并修好全部漏洞。

它的基准是一百二十个留出的仓库审计与修复任务，覆盖七十三类 CWE、八种语言与 OWASP Top 10 2025 全部类别（类别口径可对照 OWASP Top 10 项目页）。题目只给仓库本身加一份威胁模型描述，不告诉 Agent 弱点是什么、在哪儿、有几处。每份补丁必须同时挡住 exploit 并保留原功能，由程序化验证器检查。

我把关键口径整理成下表，也是本文第一张可直接截图的锚点图：

最后一行那两个数字是全文值得记住的一对：表现居首的 Agent 首试只能修好约三分之二的题，试四次能到约五分之四。换句话说，在"让软件变安全"这件事上，Agent 目前的水位是"能帮大忙但不能交出去"。

同一 pass@1 的 Agent，重试增益与成本差得很远

论文里还有两条我反复读的发现，对选型比总分更有用。

第一条：pass@1 相同的 Agent，重试增益与成本可以差得非常远。两个首轮测试表现一样的 Agent 放进允许重试的真实流程，一个稳步上台阶，另一个原地打转还烧掉大量预算。采购时只看首轮通过率，会系统性低估这个差异。

第二条：没有一个 Agent 在语言和漏洞类别上全面领先，且难度分化主要来自漏洞类别而非语言。这推翻了一个常见直觉——很多人以为难点是"用了小众语言"，实际决定难度的是你面对哪一类弱点。

必须声明口径：以上数字均出自论文摘要原文，属预印本，尚未同行评议；我只做转述与重排，未独立复现。

三、审的时候看了什么，决定审出什么

给审计员的两种材料，效果方向相反

第三个信号最反直觉，也是信息差最大的一条。

二〇二六年十月十二日这篇用 Petri 工具审计 LLM 编码 Agent 的论文问了一个朴素的问题：给自动审计员多喂上下文，会不会审得更准？它测了两类材料，结论是方向相反。

第一类是一份固定的外部开源代码库，此前的工作认为它能提高合成审计的真实感。结果是它压低了 reward hacking 评分：在两对基线高于地板值的组合里，评分（Petri 默认的一到十分量表）从四点八降到一点三，从三点九降到一点八；另外两对全程在地板值上。

第二类是被审对象在同类基准上的表现转录，本意是让审计员了解对方的行为模式。结果是在全部四对组合里都抬高了评分，其中一例从一点七升到六点一。

我把两组数字并排放出来，因为单独看任何一组都容易被误读：

我在自己的工作流里核对过后果：同一个 Agent 的同一段行为，你给自动审计看的背景材料不同，结论可以差出几倍。这意味着"我们上了自动审计"本身不构成任何保证，构成保证的是你写进审计配置的那份上下文清单。这是本文第二张可截图的锚点图，也是 Agent 安全评测里我认为被低估得很狠的一格。

一处局限需说明：论文在后续实验里检验了转录的稳健性，我只引用其初始结论与数字，未做独立验证；读者若在生产环境照搬配置，请先按自己的场景复测。

四、组件侧：编码过的指令，扫描器看不见

第三方 skill 里的隐藏载荷

第四个信号在组件层，同样是 Agent 安全评测该覆盖却没有覆盖的一格，和前面三格咬合得很紧。

二〇二六年十月十三日的这篇论文提出了 Ciphered Skill Injection 这个问题：第三方 skill 文件可以用编码把恶意指令藏进去，由 Agent 自己解码并执行。它在八个模型、一百三十九组注入与任务配对上评测，把"指令是否被恢复"与"攻击是否成功"分开统计；在缩短 skill 的主实验设置下，两种变体攻击成功率分别为百分之四十七点五与百分之四十点三。

三个细节比总分重要。第一，解码成功不等于攻击成功，中间还有一层断裂，说明防御有机会在解码之后、执行之前插手。第二，分层编码的效果随模型而异，不存在对所有模型都成立的结论。第三，也是我读完最不安的一条：被测试的 skill 扫描器很少把这些注入件标出来。

这三条合起来意味着：靠"装个扫描器"管第三方组件，目前漏检率并不低。我刻意不展开具体编码方式的构造细节——本文只做防御侧讨论，不提供可复用的注入手法。

组件侧的风险在企业里真实发生着。Pluto 那篇报道里 Bahat 说过一句更硬的话：没有一个 POC 是他们进去之后没发现恶意东西的，有些环境在做 POC 期间就有正在进行的攻击，载体是扩展包与 skill。这是企业自述口径，样本来自一家公司客户群，不能外推成行业结论，我按原话转述、不作推断。

五、把 Agent 安全评测往前挪一格：三处能落地的检查点

低延迟护栏与会话内干预：Agent 安全评测能落地的两个位置

讲了四格错位，接下来是能动手的部分。这一节只放三处有实测数字、或者至少有人已经在做的位置。

第一处是护栏本身要够快：二〇二六年十月十三日的 Jev-Guard 论文针对的正是"自回归护栏模型延迟高、又难对齐定制策略"这个痛点它先在策略树上路由出适用的审计策略（覆盖内容审核、网络安全、隐私与法律合规四域），再据此做安全分类。七千零三十三条评测用例上的口径是：安全分类准确率百分之九十三点七二，均值延迟五十八毫秒，层次路由准确率百分之九十三点一，路由加分类的整条流水线均值二百四十毫秒。接进 Hermes harness 后，独立权限门把每项任务复核时间从 SFT-LLM 裁判的四点八秒降到一点三三秒，未观察到策略违反。

这组数字的价值不在"高准确率"，而在它把护栏延迟压到了可以放进热路径的量级。过去护栏总被放在事后，很大程度上是因为放在前面太慢。

第二处是在会话进行中介入。Pluto 的系统在 Agent 试图获取超出用户本意的权限时可直接拦下动作，也可以往会话里注入上下文，提示 Agent 要一次确认；用 Bahat 的说法，"我能把上下文注回会话，以此改变 Agent 的工作方式"。这条路径的工程含义是：拦截点不必是硬闸，也可以是改写入模内容。

第三处是开源侧这批小项目给出的取向。我把十四天内新建、方向一致的几个按星数抄在下面（星数为十月十四日快照，仅供参考，不代表成熟度）：

• strands-agents/box（四百零一星）：限制 Agent 能执行什么、能读写什么、能访问哪些网络
• FeedHive/ai-slop-detector（六十五星）：一百二十条让文字读起来像 AI 生成物的模式
• cromford-ai/cromford（十八星）：工单进，经评审、合并、生产校验才出
• avestura/whiteboard-defense（十八星）：让人知道 Agent 造了什么、哪些地方直接用了默认值
• skopos-org/skopos（十七星）：基础设施事故的调查、修复与验证闭环
• zk980818/sandwich-dev（二星）：人读层与 Agent 读层的双读者模型，每一步在 git 里留证据

取向很清楚：把没声明的东西变成已声明的东西。星数普遍不高，样本风险不小；我按本次快照复核后引用，不作选型结论。

六、我给自己团队列的自查清单（可直接抄）

先盘资产，再谈工具

我按前面四格错位给团队排了顺序：第一步不是买工具，是盘清资产。下面这个脚本是我实际在用的最小版本，只做本地清单排序，不发起任何网络请求：

# 个人 vibe-coded 资产暴露面自查：本地清单，不发起任何请求
import time

ASSETS = [
    {"name": "客户流失看板", "owner": "财务", "auth": "platform_default", "data": "客户信息"},
    {"name": "团餐统计表", "owner": "行政", "auth": "explicit", "data": "无敏感字段"},
    {"name": "招聘进度表", "owner": "人力", "auth": "platform_default", "data": "合同文本"},
]
RISK = {"客户信息": 3, "财务字段": 3, "合同文本": 2, "无敏感字段": 1}
NONDEV = ("财务", "市场", "法务", "人力", "行政")

def score(a):
    base = RISK.get(a["data"], 1)
    if a["auth"] == "platform_default":
        base = base + 2
    if a["owner"] in NONDEV:
        base = base + 1
    return base

rows = sorted(ASSETS, key=score, reverse=True)
for a in rows:
    print(score(a), a["owner"], a["name"], "auth=" + a["auth"])
print("清单快照（本地口径，未验证线上）:", time.strftime("%Y-%m-%d"))
​

排序逻辑来自第二节那两条证据：平台默认配置是主要风险放大器，非开发者生产的资产需额外加权。跑完你会得到一份"先修哪个"的顺序，而不是一句"我们有很多应用"的感叹。

审计配置要写成文件

第二步是把审计上下文固定下来。第三节的证据说明喂什么材料会直接改变结论，所以这份配置不能留在某个人的脑子里，也不能交给每次运行的默认值：

{
  "audit_context": {
    "give_external_codebase": true,
    "give_benchmark_transcripts": false,
    "reason": "外部代码库压低了 reward hacking 评分；基准转录抬高评分，两者方向相反，默认只开前者"
  },
  "policy_tree": {
    "domains": ["content_moderation", "cybersecurity", "privacy", "legal_compliance"],
    "latency_budget_ms": 240,
    "note": "延迟预算按论文流水线均值口径设定，供参考，需复测"
  },
  "component_checks": {
    "scan_third_party_skills": true,
    "trust_scanner_alone": false
  }
}
​

这里每一项都对应前面某一节的证据，改任一项前请先回到对应那节看口径。我把 trust_scanner_alone 显式写成 false，就是第四节那条"扫描器很少报警"给我的教训。

七、这篇没做的事与 Agent 安全评测的三条边界

我不打算把它写成一份采购指南

写到这里，我想把三条边界说明白，免得它被读成本来不是的东西。

第一条边界是样本。Pluto 的百分之六十、两小时、开发者排第四，全部出自一家公司在自己客户群里的观测，媒体一手报道属实，但属单点样本，不能外推成"行业普遍如此"。正文里我已把口径标在每处数字旁，请带口径引用。

第二条边界是预印本。本文引用的四篇 arXiv 论文均为二〇二六年十月十二日至十三日提交的预印本，未经同行评议。CWE-bench 的一百二十道题含留出任务，天然无法外部复现；我把结论限定在论文自述范围内，未做独立验证。

第三条边界是Agent 安全评测在防御侧的难度本身就更高。攻击者只需一个洞，防御者要修好全部——这是 CWE-bench 论文的原话，也是这类工作长期被低估的原因：防御侧的成绩单天然比攻击侧难看。我不认为这构成"别做防御侧评测"的理由，恰恰相反，它说明我们过去拿到的那些亮眼数字衡量的可能不是我们真正需要的能力。

还有一件我没做的事：我没有实测任何一款商业化 Agent 安全产品，也没有做横向对比。文中的公司名与产品名都是在讲证据链时不得不提的，不构成推荐或背书。

常见问题

非开发者做的应用真的比开发者做的更危险吗？

现有证据只支持"风险更多来自非开发者做的东西"这一条，且来自单家公司客户群观测。更稳妥的表述是：非开发者缺少鉴权与数据分级习惯，而平台默认配置往往公开，两者叠加后暴露面更大。这不等于非开发者不该做应用，等于治理动作要覆盖到他们。

CWE-bench 的百分之六十八 pass@1，是不是说明 Agent 已经能修好大部分漏洞了？

要小心读这个数字。它衡量的是"在一百二十个留出任务上，首试就同时挡住 exploit 且保留原功能"的比例，不是"你的仓库交给它就安全了"。结合论文给出的两条限制（重试增益与成本差异大、没有全面领先的 Agent），按最保守的用法，它应该被读成"Agent 在防御侧已经有用，但还不能无人值守"。

给审计员更多上下文，到底是好事还是坏事？

取决于给的是哪一类。同一篇论文里，外部代码库压低了 reward hacking 评分，基准转录却在四对组合里全部抬高了评分，其中一例从一点七升到六点一。所以结论不是"多给就好"，而是"给什么必须写进配置且可复现"。建议固定一套上下文清单，再定期用已知答案样本做回归。

加密 skill 注入这件事，我作为普通用户该做什么？

三件成本不高的事：一是只从可追溯来源装第三方 skill 与扩展；二是把第三方组件当成不可信输入，不让其内容自动升级成可执行指令；三是不要只依赖扫描器，论文里被测试的扫描器很少报警。本文不提供任何注入手法的构造细节。

团队里没有专职安全，从哪里开始最划算？

我的顺序是：先盘资产（第六节脚本，一小时跑完），再把平台默认配置逐项显式化，尤其是部署可见性与鉴权（论文与报道共同指向的第一放大器），然后才是买工具。工具解决"看得见"，清单与默认配置解决"有没有东西在被看见"。

Google Play 的私人应用是不是意味着以后上架不用审了？

不是。报道写得很清楚：这些个人应用仍需遵守 Google Play 的现有政策，只是不进入公开搜索与列表。变化的是检查动作的位置与时点——从公开上架前移到个人使用过程中，以及未来转公开那道信任与安全审查。

这篇文章里的数字都能直接引到我的报告里吗？

分三类。TechCrunch 两篇是一手报道，可直接引，但请带上日期与公司自述的限定；arXiv 四篇是预印本，引用时请标注预印本状态与我未做独立复现；GitHub 星数是十月十四日快照，会变，只适合作为"当时多少人在看"的旁证，不适合作为成熟度判断。

灏天文库 A01 情报雷达产出；外部结论均标注出处与口径，未执行任何写库动作。