AI-driven fraud in financial services exposes a two-layer detection gap

At a glance

What this is: This is an analysis of why AI-driven fraud and exfiltration in financial services can evade both fraud surveillance and cloud workload security, even when each stack is operating normally.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern AI agents as active initiators of transactions and data access, not just as workload consumers with static permissions.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read ARMO's analysis of AI-driven fraud and data exfiltration in financial services

Context

Financial services security often splits detection into separate layers for transaction risk and workload behaviour. That model works until an AI agent becomes the initiator of both the financial action and the infrastructure activity, because the highest-value signal is no longer inside either stack on its own. The primary identity problem here is not model accuracy, but the lack of governance over agent intent, tool use, and delegated privilege.

In practice, that means the bank can see a valid transfer, a valid service account, and a valid container, yet still miss the attack that connected them. This is exactly where NHI governance intersects with AI security: an AI agent is acting as a non-human identity with permissions that must be scoped, logged, and correlated at runtime rather than assumed safe because the access was authorised.

Key questions

Q: What breaks when AI agents can initiate financial transactions through legitimate APIs?

A: Fraud and workload controls lose the ability to see intent. The transaction may look valid, the service account may look authorised, and the runtime may look normal, yet the combined sequence can still be malicious. Without correlated telemetry across agent behaviour and transaction outcomes, the attack is invisible to each stack on its own.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: How do security and fraud teams know if AI fraud scoring is working?

A: They should look for stable approval rates, lower false positives, consistent reason codes and a defensible review trail. A model can look accurate in aggregate while still creating operational harm if it cannot explain why a legitimate order was rejected. The test is whether the decision can be audited and improved.

Q: Who is accountable when an AI agent accesses regulated data improperly?

A: Accountability sits with the teams that govern the agent's identity, the data classification, and the policy that allowed the access path. If those controls are disconnected, no single owner can explain why the access existed or why it was not removed sooner. Shared context is what makes accountability traceable.

Technical breakdown

Why transaction surveillance misses AI agent abuse

Fraud and AML systems are built to score transactions, counterparties, velocity, geography, and historical money movement. They assume the initiator behaves like a customer or a fixed process, so an AI agent using approved payment APIs inside normal thresholds can look benign. The distinguishing signal is not the transaction itself, but the sequence of tool calls that produced it, including the prompt context that shaped the action. When that sequence is invisible to the fraud layer, the system cannot tell legitimate automation from hijacked automation.

Practical implication: teams need telemetry that ties agent tool invocation to transaction outcomes, not just transaction risk scoring.

Why workload security sees the wrong layer of evidence

CNAPP, EDR, runtime monitors, and SIEM all observe infrastructure behaviour such as containers, identities, syscalls, and network flows. That is useful for compromise detection, but it does not expose why the AI agent chose a specific action or whether a message, document, or poisoned dependency altered its reasoning. In an AI-driven attack, the infrastructure may remain perfectly normal while the application-level decision is compromised. The gap is architectural, not operational, because the evidence needed for detection sits above the workload layer.

Practical implication: correlate application-level agent telemetry with workload telemetry before you rely on infrastructure alerts.

How the detection gap becomes an identity governance problem

When an AI agent can initiate transfers, query sensitive records, or route data through authorised APIs, it is functioning as a non-human identity with delegated authority. That makes entitlement scope, session intent, and lifecycle control central to the security model. Traditional IAM often proves that a token is valid, but not that the agent is still acting within its approved purpose. For financial services, the governance question becomes whether the identity can be bounded tightly enough to prevent legitimate access from turning into attacker-controlled action.

Practical implication: treat AI agent permissions as governed identities with explicit purpose, scope, and revocation controls.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent into an unwitting execution path for fraudulent transactions or sensitive data exfiltration while avoiding detection.

1. Entry occurs when a customer email, document, or other ingested content carries prompt injection that changes how the AI agent interprets the task.
2. Escalation occurs when the agent uses its legitimate permissions to initiate transfers or query sensitive records in ways that remain inside normal operational thresholds.
3. Impact occurs when fraud, exfiltration, or investigation data exposure is completed without either the financial layer or the workload layer independently assembling the causal chain.

NHI Mgmt Group analysis

AI-driven financial crime is a cross-layer identity problem, not just a fraud problem. The article shows that valid transactions and valid workload activity can still be malicious when an AI agent sits in the middle. That means banks cannot rely on transaction scoring alone or infrastructure telemetry alone. The identity of the agent, the purpose of its actions, and the sequence of delegated tool calls must become part of the control model. Practitioners should treat agent behaviour as governed access, not background automation.

Two mature detection stacks can still fail when the attack signal is distributed across both. Financial surveillance sees the payment pattern, while cloud security sees the runtime. Neither stack is designed to reconstruct the causal chain from prompt to tool invocation to financial outcome. That creates a detection seam that attackers can exploit without needing to break either control plane. Practitioners should re-evaluate whether their monitoring architecture can join evidence across application, identity, and transaction layers.

AI agents create a new form of privilege drift: authorised access used for unauthorised intent. This is not classic credential theft, and it is not simply fraud. It is a governance failure where a non-human identity retains valid permissions while its reasoning path has been manipulated. The right concept here is delegated intent abuse, meaning authorised access is redirected into attacker-defined outcomes. Practitioners should build controls that bound intent, not just entitlement.

Financial services will need execution-path evidence because regulation already assumes causality can be reconstructed. The article correctly notes that regulators ask for root cause and evidence of what function accessed what data under what authorisation. If the bank cannot show that chain, the control framework is incomplete even if the alerting stack is busy. This makes agent telemetry, audit correlation, and evidence retention core governance requirements. Practitioners should align AI agent monitoring with forensic reconstruction from day one.

Least privilege matters more for AI agents because over-permissioned agents can create both fraud and disclosure risk at speed. In this domain, the same delegated access can move money, query case files, or exfiltrate sensitive content. That means privilege scope, approval boundaries, and purpose-specific entitlements are not administrative detail. They are the difference between a contained incident and an untraceable one. Practitioners should review every AI agent entitlement as if it were a high-risk privileged account.

What this signals

Delegated intent abuse is becoming the key operational concept for banks that are experimenting with AI agents in payment and investigation workflows. The problem is no longer whether the token is valid, but whether the agent is still acting within the purpose for which access was granted. That pushes financial institutions toward correlated identity, workflow, and transaction monitoring rather than isolated alerts.

The control lesson is straightforward: if your SOC cannot join a prompt, a tool call, and a transaction into one evidentiary chain, it will struggle to prove causality after an incident. Financial institutions should evaluate whether their AI agent telemetry can support forensics, audit, and regulatory response before production usage expands further.

For identity teams, this is a prompt to align AI agent governance with workload identity and privileged access controls, including the guidance in the NHI Lifecycle Management Guide and NIST Cybersecurity Framework 2.0. The programme signal to watch is whether agent access can be bounded, reviewed, and revoked at the same speed that business workflows change.

For practitioners

• Instrument agent tool calls end to end Capture prompt inputs, tool invocations, and resulting financial actions in a single correlated telemetry path so investigators can reconstruct causality before the regulatory clock starts running.
• Bind AI agent access to explicit purpose Scope each agent to a narrow task set, then revoke or reissue permissions when the workflow changes so valid credentials cannot be reused for unrelated transactions or data access.
• Add cross-layer correlation rules Correlate fraud signals, DLP events, and workload telemetry around the same agent session to detect cases where every individual control looks normal but the combined sequence is not.
• Treat agent permissions as privileged identities Apply approval, review, and monitoring standards normally reserved for privileged accounts, including tighter access reviews for service accounts that can initiate payments or query sensitive records.

Key takeaways

• AI-driven fraud in financial services exploits a detection seam between transaction surveillance and workload security, so neither stack can be treated as complete on its own.
• The core evidence gap is causal reconstruction, because the useful signal lives in the relationship between agent behaviour, tool invocation, and resulting financial actions.
• Banks need tighter AI agent governance, especially around delegated purpose, privilege scope, and cross-layer telemetry, if they want fraud control to remain credible.

Key terms

• Delegated Intent Abuse: A failure mode where an AI agent uses valid permissions to pursue outcomes that differ from the approved task. The identity is authorised, but the reasoning path has been manipulated, so the resulting actions remain technically permitted while being operationally hostile.
• Two-Layer Detection Gap: A condition where transaction surveillance and workload security each see part of an AI attack, but neither can reconstruct the full causal chain. The problem is not missing logs alone. It is the absence of a control that joins agent behaviour to downstream financial or data events.
• Tool Invocation Telemetry: Tool invocation telemetry is the event data generated when an AI client calls a tool through an MCP server. It typically includes the tool name, timing, outcome, and source client, giving identity and security teams the evidence needed to review runtime behaviour rather than just configuration.

What's in the full article

ARMO's full analysis covers the operational detail this post intentionally leaves for the source:

• Stage-by-stage walkthroughs of payment-agent compromise and AML investigation exfiltration.
• A detection coverage map showing what fraud, DLP, and workload layers each see, and what they miss.
• Regulatory evidence expectations tied to PCI DSS, SOX, NYDFS, and SEC notification timing.
• Implementation guidance for runtime correlation between agent telemetry and financial events.

👉 ARMO's full post breaks down the two-layer gap, detection coverage map, and regulatory evidence demands.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners managing delegated access. It helps security teams translate identity principles into operational controls for AI agents, service accounts, and privileged workflows.