Four Verifiable Boundaries for Agent Payment Authorization

A modal labeled "Approve payment?" with a green button does not constitute a security measure. It fails to verify the identity of the individual who clicked it, nor does it confirm the nature of their approval. Furthermore, it allows the same approval to be reused in different transactions, and if the agent possesses payment credentials, it does not hinder the agent from bypassing the modal.

This article outlines a four-tier architecture that transforms human approval into a cryptographic assurance linked to a singular operation. Each tier includes a test that fails if any component is omitted. The source of the button's inadequacy lies in three key issues: a lack of identity verification, the absence of intent specificity, and the lack of protection against replay attacks.

Most payment processing prototypes incorporate a confirmation dialog preceding the payment API invocation. The agent creates a payment intent, displays a modal, awaits user confirmation, and subsequently executes the transfer. Three problems arise from this approach: The agent has no means to authenticate the individual who clicked the button.

The approval is merely a binary flag, allowing the agent to alter the payment details (amount, recipient, or memo) between clicking the button and initiating the API call. The approval cannot prevent reuse in different sessions. An illustrative example of a supplier invoice agent that reads invoices from emails, extracts payment information, and submits them to the accounting system demonstrates the necessity for approval before initiating a bank transfer.

Threats include prompt injection via invoice PDFs, where an attacker manipulates the invoice text to instruct the agent to modify the payee to an account under their control. Replay attacks pose a risk, as the agent may reuse a prior approval for subsequent invoices without further authorization. Credential leakage is another concern, as logging the payment API key allows an attacker to initiate transfers directly.

The four-tier architecture addresses these vulnerabilities. Layer one, Bounded Session, ensures that an approval is confined to a specific user interaction by generating a session ID at the start of a task. The approval is valid only within that session and expires after a predetermined duration. Layer two, Intent Binding, ties the approval to a cryptographic hash of the payment intent.

Any alteration to the amount, payee, or memo after approval invalidates the hash, preventing unauthorized modifications. Layer three, Single-use Approval, safeguards against replay attacks by associating each approval with a unique nonce, which is stored in a database and flagged as used. Layer four, External Signer, prevents the agent from circumventing the approval process altogether by introducing a separate service responsible for generating and managing the approval tokens.

Each layer is independently testable, allowing for incremental deployment. The provided Python code implements the SessionManager and Approval classes, as well as functions to compute intent hashes and validate sessions. The tests verify session expiry and the integrity of intent binding.