Dynamic linking: why approvals must bind to actions

The attack dynamic linking killed

Before the rule arrived, authorization and transaction were only loosely coupled in most payment architectures: the user authenticated, and the session, now trusted, submitted whatever the software in the middle chose. Malware and manipulated merchants exploited the gap in matched pairs: show the user one amount, submit another; display the intended payee, pay the mule. The authentication was genuine, the user's intent was genuine, and the money still went to the attacker, because nothing bound the genuine approval to the genuine details.

PSD2's Article 5 answer has three legs: the payer is shown the amount and payee at authentication time; the authentication code generated is specific to that amount and that payee; and any change to either invalidates the code. The security property is precise: a captured, replayed, or middleware-manipulated approval is worthless for any transaction except the one displayed, which converts the entire tamper-in-the-middle family from profitable to pointless. W3C's Secure Payment Confirmation carries the same logic to the browser, with the relying party verifying that the signed data matches the expected transaction, explicitly contemplating the case where a merchant tells the bank one amount and the user another.

The hard half: display integrity

Binding an approval to displayed details only helps if the display was honest, which makes the screen part of the security boundary, the insight that promotes dynamic linking from a payments rule to an architecture principle. The requirements stack up: the details shown must derive from the same structured description the execution layer enforces, not from a parallel rendering the intermediary controls; the confirmation environment must resist overlay and injection, which is why secure elements and trusted UI paths exist; and the verifier must check the relationship among displayed, confirmed, and executed, because a valid signature proves nothing about what the application chose to render. The test discipline follows: mutate everything after approval, amount, payee, permissions, file, recipient, and expect rejection; attempt replay of one approval against a second transaction, and expect rejection; present an expired approval, and expect rejection. A system that passes those mutations has an approval that means something; a system that fails any of them has a signature theater.

Generalizing the pattern

The principle transfers wherever an intermediary sits between intent and execution, and three transfers matter now.

Wires and treasury: high-value payment ceremonies increasingly bind approvals to exact amount and beneficiary, so the redirected-payee variant, approval harvested for one payment, executed for another, dies the PSD2 death. The binding also voids the topped-up amount and the "same payee, new account" switch, the beneficiary-change scam's mechanical core.

Consents and data: a consent to share this record with this recipient for this purpose is dynamic linking applied to data flows, and the EU's wallet and health-data architectures already speak it, selective disclosure plus purpose binding, which is why consent artifacts that name their scope outlive blanket authorizations in every privacy review.

AI agent approvals: the sharpest transfer, because agents are intermediaries by definition. As this week's presence analysis argues, an agent's approval screen must derive from the same structured action the execution service enforces, the agent must be unable to alter destination or permissions post-confirmation without triggering a new decision, and approvals must expire and resist reuse across services. Pair the binding with verified human presence, structural liveness rather than a mere touch, and the HAPS checkpoint acquires its full mechanical specification: a living, present, identified human confirmed these exact facts, and execution will enforce exactly these facts.

Designing bound approvals well

Four rules keep the pattern effective rather than ornamental. Bind to canonical structure, not prose: the approval references the machine-enforceable action description, amounts as values, payees as identifiers, permissions as scopes, because binding to a rendered sentence invites paraphrase attacks. Scope the expiry: approvals age out on short clocks matched to the action, and an expired approval restarts cleanly rather than degrading into judgment calls. Record the triple: what was displayed, what was confirmed, what executed, per decision, which is simultaneously the fraud evidence, the dispute answer, and the regulator's sample, the evidence posture every ceremony in this publication's coverage ends at. And reserve fresh binding for consequence: standing mandates legitimately cover routine actions, so the bound-approval ceremony fires on the triggers that matter, irreversibility, external movement, authority expansion, keeping confirmation meaningful instead of habitual, the fatigue lesson NIST's authentication guidelines already absorbed.

Where implementations actually fail

The pattern's production failures are instructive because they repeat. The parallel-render failure: the approval UI builds its display from its own copy of the transaction while execution reads another, and the two drift, which is why the displayed details must derive from the canonical structure, not merely resemble it. The partial-binding failure: the code binds amount but not payee, or payee but not account, leaving exactly the mutation surface the attacker needs; bind the full tuple or accept that the unbound field is the attack. The trusted-intermediary failure: the system exempts its own middleware from the rule, assuming internal components cannot lie, until a compromised or buggy component does; dynamic linking's whole point is refusing that assumption. The exception-flow failure: timeouts, retries, and error paths re-submit transactions outside the bound ceremony, and fraud learns to trigger the error path. And the fatigue failure: binding everything, so users confirm constantly and read nothing, which dissolves the control in habituation; consequence-triggered ceremonies exist precisely to spend attention where it matters. Each failure is cheap to test for with the mutation suite, and expensive to discover any other way.

The agent-era test suite, in one list

Teams building bound approvals for agent workflows can lift the mutation suite directly: change the destination after a valid confirmation; broaden permissions; substitute the file or payload; raise the amount; present an expired approval; replay one confirmation against a second action; and present an approval issued for a different service. Every mutation should be rejected unless the original approval's bound terms allowed it, and every rejection should log which term failed, because the rejection log is where the design proves itself to an auditor.