Subscribe to the Non-Human & AI Identity Journal

Why do AI agents complicate transaction risk assessment?

AI agents complicate transaction risk assessment because they can act on a customer’s behalf without producing the human behavioural cues that fraud models expect. That blurs the boundary between normal automation and malicious activity, so merchants need better classification, stronger identity context, and more shared intelligence across transactions.

Why This Matters for Security Teams

Transaction risk models were built to spot human patterns such as typing cadence, device consistency, location drift, and session friction. AI agents weaken those signals because they can initiate purchases, complete forms, retry failures, and adapt to challenge steps at machine speed. That makes it easier for legitimate automation to resemble fraud, and for fraudulent automation to look routine. Guidance from the NIST AI Risk Management Framework is useful here because it pushes teams to treat model behaviour, context, and downstream impact as governance issues, not just scoring problems.

The security issue is not only whether an agent is authorised. It is whether the merchant can prove what the agent is allowed to do, on whose behalf it is acting, and whether the action is consistent with the declared purpose. Without that context, a risk engine may overfit to device and behavioural heuristics that agents naturally evade. The result is more false declines for good customers and more room for abuse by malicious operators who can automate account takeover, card testing, and synthetic checkout flows. In practice, many security teams encounter the true extent of this problem only after fraud losses rise faster than the rule set can be tuned, rather than through intentional agent classification.

How It Works in Practice

Practical transaction risk assessment for AI agents needs to move from human-centric signals to identity-aware and purpose-aware controls. That means separating the agent’s technical identity from the end user’s identity, then binding both to a declared transaction scope. Current guidance suggests using stronger provenance checks, session binding, and policy-based authorisation so the merchant can distinguish a delegated purchase from an unauthorised automated action. The OWASP Top 10 for Agentic Applications 2026 is relevant because it highlights risks around tool abuse, excessive agency, and untrusted inputs that can directly affect payment flows.

  • Classify the actor: human, script, assistant, or autonomous agent.
  • Bind transactions to a declared intent, such as purchase, refill, or booking.
  • Track the agent’s credential type, token scope, and delegation chain.
  • Score context beyond the session, including account age, velocity, and prior disputes.
  • Route suspicious high-risk automation to step-up verification or delayed fulfilment.

Shared intelligence is also important. If one channel sees prompt injection, token abuse, or anomalous tool calls, that should inform fraud and abuse decisions elsewhere. Teams should align telemetry with the NIST Cybersecurity Framework 2.0 and map control ownership to logging, response, and governance. These controls tend to break down in high-volume marketplaces with fragmented identity data because the merchant cannot reliably connect the agent, the customer, and the payment instrument in real time.

Common Variations and Edge Cases

Tighter risk controls often increase checkout friction and operational overhead, requiring organisations to balance fraud reduction against conversion and customer experience. That tradeoff becomes sharper when the agent is legitimate, such as a shopping assistant, procurement bot, or accessibility tool. Best practice is evolving, and there is no universal standard for agent attestation in transactions yet, so policy needs to be explicit about what counts as acceptable automation.

Edge cases include delegated purchasing with shared household accounts, enterprise procurement agents, and cross-border payments where identity evidence is already inconsistent. In those cases, a simple block-or-allow approach is too blunt. Security teams should instead define allowed agent classes, acceptable scopes, and escalation paths for ambiguous activity. The MITRE ATLAS adversarial AI threat matrix helps frame how attackers may manipulate model-driven systems, while the CSA MAESTRO agentic AI threat modeling framework is useful for mapping agent actions, trust boundaries, and control points. The biggest gap appears in environments that lack consistent identity binding and transaction lineage, because the fraud model then cannot separate delegated automation from replayed or repurposed malicious activity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST AI RMF AI risk governance is needed when agents change transaction behaviour and risk signals.
OWASP Agentic AI Top 10 Agentic app risks map directly to tool abuse, excessive agency, and untrusted inputs.
NIST CSF 2.0 ID.AM-2 Asset and service understanding helps classify agent identities and their transaction roles.
MITRE ATLAS AML.T0058 Adversarial model manipulation can distort automated risk decisions and fraud signals.
CSA MAESTRO MAESTRO supports threat modeling for agent trust boundaries and action scopes.

Apply AI RMF governance to define ownership, acceptable agent use, and risk review for automated transactions.