This note covers APort Vault: Benchmarking AI Agent Payment Authorization with the Open Agent Passport, by Uchi Uchibeke of APort Technologies Inc. (arXiv:2609.22076, posted 18 September 2026, https://arxiv.org/abs/2609.22076). It is a preprint and it is not peer reviewed.

What the paper says

APort Vault is a benchmark for payment authorization in AI agents that use tools. The attacks come from a public capture-the-flag event against a live agentic bank. The event ran from March to August 2026 and had a prize pool of 6,500 dollars. 1,128 sessions produced 4,371 attack attempts, with 4,272 of them (97.7 percent) in the launch week of March 6 to 12. The author replays the attacks on 14 models from 8 labs, at five policy levels, in two replay tracks, in two architectures. 225,964 evaluations completed out of 244,776 planned.

The one changed variable is whether a deterministic authorization check sits between the tool call and the execution. The check implements the Open Agent Passport (OAP) specification. Model, prompt, decode settings, and tool schema stay the same. The headline outcome is whether money moved to a recipient outside the policy, read from executed tool calls. It is not a refusal and not a judge's opinion. At Levels 2 to 4, unpermitted transfers were 140 of 76,842 evaluations with the model alone, and 0 of 69,297 behind the check.

The zero has a per-session upper bound of 0.38 percent over 790 source sessions, and the paper says "a zero is not a rate of zero". The zero did not come from a full stop of payments. 25,370 payments executed behind the check, which denied 187 of 25,640 transfer calls, with 148 for a forbidden recipient.

What it does not show

The author is the founder of APort Technologies Inc., which develops the authorization layer under test. The author designed, ran, and analyzed the benchmark, and calls this a conflict of interest. The test used a local engine ported from the event server, not the hosted service. At Level 4 the local engine required an audit code that the published policy pack does not enforce. So the Level 4 zero concerns the engine as configured, not the published pack.

The scope is payments with one tool in a simulated bank, and no real money moved. The attackers were self-selected competitors for a prize, not a general population and not state-grade adversaries. The check allowed 99.27 percent of the transfer calls it evaluated. That share does not measure false blocks or utility, because every request came from an attack.

Why it matters in payments

The check in the paper tests each transfer against an explicit policy, including a list of allowed recipients. My disbursement scaling case study has a policy of the same shape: the payout account must match the registered business account.

The paper also lists its own gaps. I try to do the same in my case studies. My merchant payments platform case study names the metrics I would instrument next time: product reuse rate, API-generated link share, and support-ticket reduction. My refunds experience case study states which number was never fully measured.