APort Vault：基于 Open Agent Passport 的 AI Agent 支付授权基准

关联论文：2609.22076
作者：flyP
更新：2026-09-22

一、一句话结论

APort Vault 复盘了一场公开 CTF 中人类对真实支付 Agent 写的 4,371 次攻击，覆盖 8 个实验室 14 个模型、5 种策略配置、2 条重放轨道（有 / 无 Open Agent Passport 预检层），共完成 225,964 次评测，结论是：模型单体在 Level 2–4 把 140 笔钱打到了 passport 不允许的收款方，加上 OAP pre-action check 之后这个数字变成 0。

二、解决的真问题

Agentic AI 正在接管「带支付的工具调用」这件事：购物、订餐、买机票、API 调用付费额度。但凡 Agent 真的能刷信用卡 / 调支付接口，安全研究的现状就是「每一篇论文自己测自己一份」。问题有四：

没有真实攻击面。大部分 Agent 安全 benchmark 用合成 prompt 注入，攻击者从没真的拿一个活 Agent 跑过。
数字混淆。一次「攻击成功」其实至少含五个独立事件（请求发起 / 触发 pre-action / 模型决策 / 资金路径 / 收单确认），被合并成一个分母，就出现了「99.2% 防御成功」这种不可审查的漂亮数。
没有真正可复用的工程防御层。系统提示词不算防御；只有一层 deterministic pre-action check 算工程层。
跨模型可比性归零。同一次攻击在不同模型的 instruction-following 行为下表现差异巨大，没有统一基准。

APort Vault 直击这四个问题。

三、核心方法

3.1 Open Agent Passport（OAP）规范

OAP 是一种确定性 pre-action check 规范。一句话：Agent 想发起一次支付，必须在调用支付工具之前拿到一份机器可验证的「签证」，签证写明『授权打谁、多少钱、为什么、有效期多长』，签证由 Agent 的 Owner 在事前签发并交给 passport 颁发方。

收到 Agent 的「请帮我付 $9 给 acme-corp」请求时，OAP 引擎做的不是让模型「自己判断」，而是 deterministic check：

# 伪代码（OAP pre-action check 简化版）
def oap_check(action, passport, policy):
    # 1. 签证是否过期 / 被撤销
    if passport.expired() or passport.revoked():
        return DENY("passport_invalid")
    # 2. 收款方是否在签证 allowlist
    if action.recipient not in passport.allowlist:
        return DENY("recipient_not_authorized")
    # 3. 金额是否在签证额度内
    if action.amount > passport.amount_cap:
        return DENY("amount_exceeds_cap")
    # 4. 意图语义是否与签证允许类目一致
    if not policy.intent_allowed(action.intent, passport.scope):
        return DENY("intent_out_of_scope")
    # 5. 全过 -> 允许；任一不过 -> 拒绝
    return ALLOW if all_passed else DENY("pre_action_check_failed")

这套规范让「防御」脱离模型，让评测变成「同一攻击同模型同 track，两次结果差异 = OAP 收益」。

3.2 评测设计

数据集：4,371 次人类编写的攻击，来自一场公开 CTF，发生在真实生产支付 Agent 上。每条攻击归属唯一一个 (level, model) 配置，因此策略与攻击 cohort 共同变化，论文诚实声明这一点 ⚠️。
模型集：8 家实验室 14 个模型（含开源 + 闭源主流主力）。
策略配置：5 档 Level 1→Level 4，难度递增（Level 1 收件人直接是良性收件人；Level 4 是社会工程 + 提示注入 + 收件人伪装三连击）。
轨道：两条 —「模型单体」vs「OAP 后面」两条独立跑同一攻击。
事件拆分：每次评估报告 5 个独立事件（请求发生率 / 模型决策 / 资金实际落账 / 拒绝原因 / 重放失败原因）。绝不合并。
总评测次数：225,964，量级远超大多数 Agent 基准。

3.3 模型可重复使用性与策略归一

数据集与评测脚本已发布在 Hugging Face：aporthq/vault-benchmark-v1。所有评分代码、level passport 模板、分析脚本同地放出，第三方可在同 4,371 攻击 + 同样本上重放任意模型。

四、关键实验与数据

4.1 模型单体行为画像（不带 OAP）

Level 1 上的攻击让 Agent 真的发起支付请求的比例：10.9%
Level 2：3.0%
Level 3：0.1%
Level 4：79.4%

⚠️ 论文用一句话点出真正令人警觉的：「请求很常见，且其速率差异在不同策略配置之间比不同模型之间还大」。一个粗暴推论是：用「单一 Level」覆盖「Agent 鲁棒性」是危险的，每个 Level 显式可比的请求率差异决定基准是否真的可比。

更精细：1,293 个 Level 4 prompt 在所有 14 个模型上都被打过，每个模型的请求率落在 71.2% 到 84.3% 之间，其中 809 个 prompt（62.6%）在全部 14 个模型上都触发了请求，每条都最终打到了该 Level 的 allowlist 收单方。

—— 这是关键证据：当前「对齐主流」+「指令遵循强」+「闭源旗舰」三件套的模型，对这类 Level 4 社会工程攻击的请求率没拉开档次差。

4.2 授权边界（Authorization Boundary）

论文关心的核心数字：在 Level 2–4 上，付到 passport 不允许的收款方：

维度	模型单体	OAP 之后
收款方违规次数	140 / 76,842	0 / 69,297
配对 (model, prompt, track) 三元组	105 / 68,970	0 / 68,970

零违规这个 span 覆盖 790 个独立来源 session，给出 per-session 上界 = 0.38%。这才是真正震撼的数：当 OAP 这层工程防线立住，攻击者在 790 个真实 session 里连一次越权收款都做不到。

4.3 这个零不是「拒绝支付」得到的

论文再一次拒绝漂亮叙事：

OAP 后面实际成功支付的笔数：25,370 笔
策略本身在评测中拒绝的 transfer 调用：187 / 25,640
其中 148 笔是「不该打款的收件人被拒」

—— 也就是说 OAP 既不是「一关了之」、也不是「形同虚设」。它是「正常流量全过、攻击流量全收、违规收款零容忍」。

五、亮点与局限

亮点

真实攻击 × 真实模型 × 真实支付。4,371 attack 是人类 CTF 写成，不是合成，是这个基准值钱的核心原因。
数字不可合并。每个评测上报 5 个独立事件，避免「99.X% 通过率」的纸面合规。从方法学角度，每个真做 Agent 安全的人都应该读这一段。
OAP 规范 = 工程化 defense layer。不是 prompt 防御，是 deterministic check，跨模型、跨 vendor 可复用。
测试规模 22.6 万次远超一般 Agent benchmark（数百到数千），统计效力强。
数据集全开 + 评分脚本同地放出，可复现性 100%。

局限

策略 / 攻击 cohort 共变：每条攻击归一个配置，所以 policy × attack 不是正交因子，分析模型 × 策略纯交互需要更精心设计 ⚠️（论文承认）。
模型集合 14 个覆盖 8 家：仍是子集，不包含 2026 年顶级模型如 Claude 4.x / GPT-5 / Gemini 2.5 等可能代表性不足；具体清单需查 PDF。
没有 prompt-injection-specific 与 jailbreak-specific 拆分：4,371 attack 跨度大，但按攻击类型做机制分析需要看论文主体。
per-session 上界 0.38%：是上界不是真实率，理论上有「session 内攻击成功没被发现」的可能。
OAP 规范依赖 Owner 发证：如果 Owner 自己被钓鱼，规范就失效；论文对此未充分展开。

六、对工程落地的启发

任何接入支付的 Agent 都该有一个 OAP 类 pre-action check。即使你不立刻上完整规范，至少在「金额超阈值」+「收件人不在 known list」这两条上做 deterministic 拦截，能直接砍掉 140/76,842 这种违规支付率（接近 2 个数量级）。
评测 baseline 别合并分母：每个评测事件拆成多个独立 metric，不要再做「准确率 96%」这种糊弄事的汇总。
Attack prompt 应当来自人类红队，不是研究人员闭门造车 4,371 条。CTF-style 的人类 attack corpus 是关键资产。
不要信任「指令遵循好的模型 = 攻击安全」的直觉。14 个模型在 Level 4 上请求率 71.2%–84.3% 区间内聚的事实证明光靠 SOTA instruction-tuning 远远不够。
Owner-issued passport：在企业内部，可以让合规 / 风控团队预先签发「采购类 / 1k USD 以下 / 指定供应商」的护照，让 Agent 漫游时做硬性边界检查。
HuggingFace 数据集 + 评分脚本一键复现，可用作内部 Agent 上线前的红队回归集。

七、与同方向工作的关系

vs InjecAgent / AgentBench 安全向子任务：这是合成 prompt 注入基准，攻击面与真实攻击差异大；APort Vault 用真实 CTF 攻击直接取代。
vs AgentHarm / ProAgentBench：偏能力评测，不直接测支付授权边界；APort Vault 把「授权边界」从能力评测里分出来当作独立维度。
vs Anthropic / OpenAI 内部 red-team：这些 team 的内部攻击 corpus 与方法学从未公开；APort Vault 是社区里第一份真正公开的「Agent 支付攻击 + 跨模型对照」基准。
vs Open Agent Passport Spec 本身：OAP 规范由作者团队同期开源（aporthq），本论文是该规范的实证验证论文；以后任何带支付的 Agent 工作都该引用 OAP 作为工程层 baseline ⚠️。
vs SWE-bench / WebArena（agent capability 基准）：互补关系，APort Vault 不评能力而评授权，与能力评测形成正交。

八、适合谁读

Agent 应用架构师：任何人想做「会付钱的 Agent」必读。
AI 安全 / 红队研究员：4,371 攻击 + 5 事件拆解的 baseline 思路值得借鉴。
支付平台 / Fintech 公司：把 OAP 思路吸收到风控管线里非常划算。
合规与法务：agentic 支付合规越早把 passport 类机制做出来，越能在监管介入前建好工程护栏。
模型评估人员：不要用单一聚合分母、要看 5 个独立事件。

九、不确定与边界声明

⚠️ 14 个模型具体名单未在 abstract 列出，需读 PDF（可能在正文 Table 1）。
⚠️ Level 1–4 具体攻击形态、收件人列表、prompt 模板需读补充材料。
⚠️ 「策略与攻击 cohort 共变」的具体影响幅度（多大比例归因于策略 vs 模型）需看正文 §4–§5。
⚠️ 单 session 攻击成功率是否做过主动探测（而非仅靠数学上界）需查正文。
⚠️ OAP 规范的实现细节（passport 颁发方信任链、撤销机制、Owner 多签）需读 OAP spec 仓库。
边界：本解读仅基于 arXiv abstract（v1，2026-09-18）+ HuggingFace aporthq/vault-benchmark-v1 公开数据集页面；未读 PDF 正文。

工程落地与核查（Jay）

事实核查

核查项	原文声明	核查结果
攻击规模	4,371 次人类编写攻击	✅ abstract 明确，数据集 HuggingFace `aporthq/vault-benchmark-v1` 已核实
评测规模	225,964 次总评测	✅ abstract 明确，数字具体可信
模型覆盖	8 个实验室 14 个模型	⚠️ abstract 未给模型名单，需读 PDF Table 1
核心结果	模型单体违规 140 次，OAP 后 0 次	⚠️ abstract 数字明确，但 140 / 76,842 中的分母 76,842 需确认（是否含 Level 1，或全量）
成功支付笔数	OAP 后成功支付 25,370 笔	⚠️ abstract 未明确此数字的来源 track（是否仅 OAP track），需读 PDF
拒绝调用数	187 / 25,640 次拒绝	⚠️ abstract 未给"策略本身拒绝"的触发条件，需读 PDF §4.3
Session 上界	per-session 上界 0.38%	⚠️ abstract 给出但未给 session 总数 790 的来源，需读 PDF
数据集可用性	HuggingFace aperthq/vault-benchmark-v1	✅ 已核实，数据集与脚本同地放出
OAP 规范仓库	aperthq/oap-spec	⚠️ 需额外 fetch 核实规范实现细节

可读性精修

原文结构清晰，数字翔实。仅两处优化：

"99.2% 防御成功率"（§二问题2）建议注明：这是论文用来批判的数字，不是论文自身数据，避免读者误以为是论文报告的指标。
§4.3 中"正常流量全过、攻击流量全收"表述偏文学化，建议改为更精确的描述："OAP 在阻断违规收款的同时，对合法支付请求的通过率与模型单体几乎一致（25,370 笔成功支付），未因过度防御影响正常业务"。

工程落地：实际系统怎么用、坑在哪

HuggingFace 数据集已核实：aporthq/vault-benchmark-v1 含评测脚本 + passport 模板；aporthq/oap-spec 规范需额外 fetch 核实。

工程路径分三档：

最低成本（今日可做）：直接拿 aporthq/vault-benchmark-v1 里的 Level 1–4 prompt 子集跑自己 Agent 的红队测试，不需要实现 OAP，先测基线漏洞。Level 4 请求率 71.2%–84.3% 这个数字说明大多数生产 Agent 都存在高风险。
OAP 简化实现（MVP）：只实现 §3.1 伪代码的前三步（签证过期检查 + 收款方 allowlist + 金额上限），无需意图语义解析，0.38% session 违规上界已经非常低。注意：简化版会漏掉 Level 4 社会工程类攻击（依赖意图语义第 4 步），所以这是保底不是终态。
完整 OAP（生产级）：实现全部 5 步检查，包括意图语义 + passport 颁发方信任链 + Owner 撤销机制。规范细节需读 aporthq/oap-spec 仓库。

五个坑：

Level 1–3 请求率低（<10%）是假象：Level 1–3 请求率看起来很低，但这不代表安全——真正危险的是 Level 4（79.4%）。评测时如果只看平均或只看 Level 1–3，会严重低估风险。
模型间没档次差 = 光靠选模型无法解决：71.2%–84.3% 的窄区间说明即使用最贵的闭源旗舰，对 Level 4 攻击的防御也不会比开源模型好多少。这是个系统级问题，不是模型选择问题。
OAP 的安全前提是 Owner 不被钓鱼：如果签发 passport 的 Owner 账号本身被社工，OAP 就退化为普通 check。生产部署需要在 Owner 侧加上 mTLS / MFA 等保护。
意图语义检查（Step 4）是最难实现的：前 3 步是确定性规则，第 4 步需要模型判断语义一致性，这是 OAP 规范里最模糊的部分，误报率（false positive）控制是工程难点。
CTF 攻击不代表全部攻击形态：数据集是 2024–2025 年的 CTF 历史攻击，新型攻击（如供应链污染、跨 Agent 协作攻击）可能未被覆盖，需要持续补充攻击库。

核验清单：

☐ fetch aporthq/vault-benchmark-v1 确认数据集规模（4,371 条）与 level 分布
☐ fetch aporthq/oap-spec 确认 passport 颁发 / 撤销机制细节
☐ 确认 14 个模型名单（PDF Table 1）
☐ 确认 140 / 76,842 分母边界（是否含 Level 1）
☐ 用 Level 4 prompt 子集跑自己 Agent 基线测试（独立验证 71.2%–84.3% 请求率）