Transaction redirection is an attack pattern where an adversary changes the destination, amount, or conditions of a payment without stealing the underlying credential. In agentic commerce, the attacker aims to influence the agent’s decision path so the transaction still looks legitimate while benefiting the wrong party.
How Transaction Redirection Works
Transaction redirection is a manipulation of a payment flow, not a credential theft event. The adversary alters where value goes, how much is sent, or what conditions govern execution, while preserving the appearance of a legitimate transaction to the user or system approving it.
This pattern matters because many payment controls focus on authenticating the actor, while the harmful change happens in the instructions or decision path itself. In agentic commerce, that means the agent can be steered toward a payment that still satisfies its own logic checks, even though the beneficiary or terms have been quietly changed.
Why It Is Dangerous in Payment and Agentic Flows
The core danger is that the payment may look valid at the point of approval. If the sender, session, or workflow remains intact, monitoring may miss the fact that the destination account, amount, or timing has been redirected. That makes the attack effective even when standard credential protections are working.
In human-led commerce, this can resemble invoice fraud, supplier impersonation, or business email compromise where the payment instruction is altered upstream. In agentic commerce, the same outcome can arise when a model, tool chain, or policy layer is influenced to choose the wrong recipient or to approve a modified transaction path.
Where Organisations Should Look for Exposure
Exposure usually sits in the instruction path, not just the authentication layer. Organisations should examine how payment details are created, transformed, reviewed, and handed off across portals, APIs, assistants, back offices, and approval workflows.
The most important question is whether a trusted workflow can be changed without triggering a strong secondary check. If a transaction can be redirected after an initial approval, or if an agent can be persuaded to follow a new destination while keeping the rest of the request intact, the organisation has a material integrity gap.
OWASP API Security Top 10 is useful here because transaction redirection often behaves like a business-logic integrity problem, where the request is technically accepted but semantically altered in a harmful way.
Detection, Prevention, and Recovery
Defence should focus on preserving transaction integrity end to end. High-risk payments need strong out-of-band verification, explicit beneficiary confirmation, and controls that compare the intended recipient and amount against trusted reference data before execution.
After an incident, review not only the payment itself but the full decision chain, including prompts, workflow inputs, API calls, approval steps, and any content or instructions that may have influenced the agent or operator. If redirection succeeded once, the same path may be reusable until the underlying integrity weakness is closed.
NIST Cybersecurity Framework 2.0 supports this work through governance, protection, detection, response, and recovery activities that treat transaction integrity as an operational security objective.
Risk and Threat Considerations
Transaction redirection creates direct financial exposure because the payment still appears to be authorised while the value is routed elsewhere. The same pattern can also be used to create false confidence in automated approvals, especially where agents or workflow automation are trusted to carry out routine transactions.
Failure mechanism: An attacker changes the transaction instruction, destination, or conditions at a point where the workflow still treats the request as legitimate, so the fraud survives normal authentication and approval checks.
Impact: Funds can be misdirected, payment disputes become harder to resolve, and compromised workflows may continue to produce harmful transactions until the redirection path is identified and blocked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Transaction redirection abuses payment flow integrity and business logic. |
| Recommendation — Protect sensitive payment flows with step-up checks and beneficiary validation. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The term concerns transaction approval paths that must remain controlled and trustworthy. |
| DE.CM-06 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Redirection often shows up as anomalous workflow or transaction changes. | |
| Recommendation — Enforce controlled approval paths for high-value transactions. Monitor payment workflows for unexpected destination or amount changes. | ||
Practitioner Guidance
Why practitioners should care: The control problem is not only “who approved the payment” but “whether the approved payment is still the one that gets executed.” That distinction is critical in agentic commerce, where a legitimate decision path can be steered toward the wrong outcome without obvious alarm conditions.
Common misunderstanding: Many teams assume that strong login controls or signed-in sessions are enough to prevent payment fraud. Transaction redirection shows that the higher-risk failure is often semantic, meaning the transaction content itself must be protected and re-checked at the point of execution.
Related resources from NHI Mgmt Group
- What is the difference between entitlement review and transaction-first governance?
- How should security teams implement continuous transaction monitoring across business systems?
- When does transaction monitoring become more useful than manual review?
- What do organisations get wrong about transaction control assurance?