🤖 AI

Zero-Trust Runtime Verification for Agentic Payment Protocols: Mitigating Replay and Context-Binding Failures in AP2

This paper proposes and evaluates a zero-trust runtime verification framework for the Agent Payments Protocol (AP2) that utilizes dynamic nonces and consume-once semantics to effectively mitigate replay and context-binding attacks in autonomous payment systems while maintaining high throughput and low latency.

Original authors: Qianlong Lan, Anuj Kaul, Shaun Jones, Stephanie Westrum

Published 2026-02-09

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Qianlong Lan, Anuj Kaul, Shaun Jones, Stephanie Westrum

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a world where your personal AI assistant is so trusted that it can go to the store, pick out groceries, and pay for them all on its own, without you needing to tap a card or enter a password every time. This is the future of "Agentic Payments."

However, giving an AI this much freedom creates a new kind of security problem. This paper, written by researchers at eBay, explores how to keep these AI transactions safe when things get chaotic, like when the AI tries to pay for the same item twice by accident or gets confused about which store it's in.

Here is the breakdown of their solution using simple analogies.

The Problem: The "Magic Ticket" That Never Expires

Currently, there is a new system called AP2 (Agent Payments Protocol). Think of this like a Magic Ticket (a cryptographic mandate) that a user gives to their AI.

How it works: The ticket says, "You can buy a $50 shirt at Store A." It has a digital signature (like a wax seal) to prove it's real, and an expiration time.
The Flaw: In the old days, you had to be there to buy the shirt. Now, the AI runs on its own.
- The Glitch: If the AI gets a "timeout" error, it might try to use the same Magic Ticket again immediately (a Replay Attack).
- The Mix-up: If the AI is juggling tasks, it might accidentally try to use the "Shirt Ticket" to buy a "TV" at a different store (a Context-Binding Failure).

The paper argues that the current rules (the protocol) assume the AI is perfect and doesn't make mistakes. But in the real world, AI agents retry things, run tasks in parallel, and get confused. The "Magic Ticket" system doesn't have a way to stop these mistakes from becoming security breaches.

The Solution: The "Zero-Trust Gatekeeper"

The authors propose a new security guard called the Zero-Trust Runtime Verifier (ZTRV). Think of this as a bouncer at a very strict club who stands between the AI and the store.

Instead of trusting the Magic Ticket just because it has a wax seal, the bouncer checks two specific things every single time the AI tries to enter:

The "One-Time Use" Stamp (Consume-Once):
- Imagine every time you try to use a ticket, the bouncer stamps it with a unique, time-sensitive code.
- If the AI tries to use that same ticket again (even by accident), the bouncer sees the stamp and says, "Nope, this ticket was already used. You can't come in."
- This stops the AI from accidentally paying for the same item twice.
The "Context Check" (Binding):
- The bouncer checks the ticket against the current situation.
- If the ticket says "Buy a shirt at Store A," but the AI is currently standing in front of "Store B" or trying to buy a "TV," the bouncer says, "Wrong context! This ticket doesn't match what you are doing right now."
- This stops the AI from accidentally using a ticket meant for one task on a completely different task.

How They Tested It

The researchers built a simulation to see how this "Gatekeeper" performed under pressure.

The Stress Test: They simulated a chaotic environment where thousands of AI agents were trying to make transactions at the exact same time (up to 10,000 per second).
The Result:
- The old system (without the Gatekeeper) let 100% of the fake or mistaken transactions through.
- The new system (with the Gatekeeper) blocked 100% of the bad transactions.
The Speed: The Gatekeeper was incredibly fast. It added only about 3.8 milliseconds (less than the blink of an eye) to the transaction time, even when the system was super busy.

Why This Matters

The paper concludes that you can't just rely on the "rules written on the ticket" (the protocol). You need a runtime check (the Gatekeeper) that watches what the AI is actually doing in real-time.

They also found that this system doesn't need to remember every single transaction in history. It only needs to remember what's happening right now (peak concurrency). This means the system stays fast and doesn't get bogged down by a massive database of old data.

In short: To let AI agents spend money safely, we need a security guard that checks if the ticket is being used for the right thing, at the right place, and only once, all while moving as fast as the AI does.

Technical Summary: Zero-Trust Runtime Verification for Agentic Payment Protocols

1. Problem Statement

The deployment of autonomous AI agents capable of executing commercial transactions has necessitated a shift from interactive, session-based authorization to mandate-based protocols, specifically the Universal Commerce Protocol (UCP) and the Agent Payments Protocol (AP2). While AP2 provides specification-level security guarantees—such as cryptographic integrity, authenticity, and expiration semantics—these guarantees rely on assumptions that abstract away the complex runtime behaviors of autonomous agents.

In real-world agentic environments, systems exhibit behaviors such as automatic retries, parallel task execution, inter-agent delegation, and observability-driven replays. These dynamics introduce temporal and contextual complexities that challenge implicit assumptions about mandate usage. Specifically, the paper identifies a gap between protocol design and runtime reality: AP2 mandates, while cryptographically valid, can be misused if consumed multiple times within their validity window (replay) or redirected to unintended execution contexts (context-binding failure). The authors argue that specification-level correctness does not guarantee secure execution in asynchronous, highly concurrent agent runtimes.

2. Methodology and System Model

To address these enforcement gaps, the authors propose a Zero-Trust Runtime Verification (ZTRV) framework. The system model comprises three entities:

User Agent (A): An autonomous entity holding a cryptographic mandate.
Merchant Endpoint (M): The service provider fulfilling the transaction.
Runtime Verifier (V): A trusted middleware component (acting as a security gateway) positioned between the agent and the merchant.

The ZTRV operates as a stateless verification gateway augmented with minimal, time-bounded state. It enforces a strict, fail-closed verification pipeline where all mandate-bearing requests must pass explicit checks before reaching the payment infrastructure.

Core Mechanisms

The framework enforces security through two primary mechanisms:

Context-Aware Binding:
Each mandate is cryptographically bound to a specific runtime execution context. The verifier computes a hash ( $H_{ctx}$ ) based on execution attributes (e.g., task.id, agent.id, merchant.id, scope) and compares it against the hash embedded in the mandate's signature. Any mismatch results in immediate rejection, preventing mandates from being reused across different tasks, agents, or merchants.
Dynamic Consume-Once Nonce Registry:
To prevent replay attacks (both same-context and cross-context), the system enforces "consume-once" semantics. Each mandate includes a unique, dynamically generated nonce. The verifier maintains a sliding-window nonce registry (implemented as a distributed data structure) to perform atomic check-and-set operations. A nonce is accepted only once within its validity window ( $\Delta t$ ). This ensures idempotent execution and prevents multiple consumptions of the same mandate, even under high concurrency.

The verification algorithm proceeds in five steps: parsing the mandate, verifying cryptographic signatures and freshness, validating context integrity, performing atomic nonce consumption, and finally authorizing the request.

3. Key Contributions

The paper makes the following specific contributions:

Threat Modeling: It presents a systematic threat model for AP2 mandate execution in autonomous agent runtimes, identifying specific threats such as Same-Context Replay (T1), Cross-Context Replay (T2), Context Leakage Induced Misuse (T3), and Observability-Based Replay (T4).
Identification of Enforcement Gaps: The authors demonstrate that the AP2 specification lacks normative definitions for verifier-side, stateful execution semantics (e.g., consume-once enforcement and strict execution-time context binding) required for real-world agent retries and orchestration.
Framework Design: It introduces the ZTRV framework, which enforces explicit context binding and consume-once semantics at execution time, moving beyond static issuance properties.
Empirical Evaluation: Through simulation-based evaluation, the paper demonstrates that both context-aware binding and consume-once enforcement are distinct and complementary; neither is sufficient alone to prevent all classes of mandate misuse.

4. Experimental Results

The framework was evaluated under high-concurrency conditions (up to 10,000 transactions per second) against a baseline verifier that performs only standard AP2 checks (signature and expiration).

Security Effectiveness: The ZTRV achieved a 100% interception rate across all evaluated attack scenarios (replay and context-redirect attacks). In contrast, the baseline verifier failed to intercept any of the tested attacks.
Performance Overhead: The framework maintained stable verification latency of approximately 3.8 ms at peak throughput. The overhead was dominated by cryptographic signature verification, while context binding and nonce registry operations incurred negligible additional cost.
Scalability: The study on storage overhead revealed that the required runtime state is bounded by peak concurrency rather than cumulative transaction history. Even with a 60-second nonce window at 10,000 TPS, the memory footprint remained modest (approximately 12 MB), indicating suitability for cloud-native deployments.
Ablation Studies: Experiments isolating the mechanisms confirmed that context binding alone prevents cross-context attacks but fails against same-context replays, while consume-once enforcement prevents replays but fails against context redirection. Only the combination of both mechanisms provided comprehensive protection.

5. Significance and Claims

The paper claims that the proposed framework bridges the critical gap between protocol assumptions and runtime reality in agentic payment systems. By enforcing authorization properties at execution time rather than relying solely on static specification-level guarantees, ZTRV mitigates replay and context-binding failures without imposing significant performance overhead.

The authors emphasize that their approach provides deterministic security guarantees through cryptographic logic, distinguishing it from heuristic-based fraud detection systems that are susceptible to false positives and negatives. They assert that robust runtime security for agentic payment execution can be achieved with minimal, predictable overhead.

The work concludes that runtime enforcement should be considered a foundational component of secure engineering for autonomous systems. It notes that while ZTRV addresses execution-layer misuse, it does not prevent semantic attacks (e.g., prompt injection manipulating an agent's intent) and assumes the underlying cryptographic primitives remain uncompromised. Future work is suggested to explore the integration of Trusted Execution Environments (TEEs) to further harden the verifier.