Catching Cross-Session AI Attacks with Anti-Money-Laundering Graph Analysis
I work in fraud detection and risk engineering for a payment platform. It’s a field that has been around for decades, and some of its concepts and methods can carry over to the burgeoning field of AI security.
Most standard risk controls already exist in agent security: risk scoring, step-up approval, rate limits, scoped permissions, even undo. One problem is still unsolved: catching an attack that’s spread across sessions. This essay looks at applying one part of the risk playbook, anti-money laundering (AML), to that problem.
Attacks split across sessions
In Red-Teaming Auto Mode, the authors red-teamed the monitors that guard Claude Code and Codex. The hardest case was an attack spread across several sessions or agents, where each monitor only sees its own piece. The more pieces, the more often the attack got through, and the authors call stopping it “at an acceptable cost” an open problem.
Phuong et al. saw the same with multiple agents: split an attack across more agents and each piece looks less suspicious. Merging all the pieces and scoring them together does catch it, but in a real deployment you don’t know which pieces belong together.
The mechanics are simple. A monitor judges one session at a time, so no single step looks bad:
- An agent sends $50 to an account it’s allowed to pay, then does it nine more times.
- Ten sub-agents each move $50 through a shared workspace, each in its own session, each watched alone.
- One agent writes a harmless-looking script, and a second agent runs it.
Every step passes, and the attack only exists in the sum. The signal is in the aggregate, but no one has shown a deployable way to aggregate yet.
Finance has a name for this
It’s called structuring: breaking one large transfer into many small ones, each under the reporting threshold, so no single transaction raises an alert. Banks didn’t beat it with a smarter per-transaction model. They beat it with link analysis: connect the accounts, then score the network.
The trick is how you connect them. Merging everything drowns you in false positives, so instead you link accounts that share something, such as a device, an address, a phone, or a beneficiary. Then you collapse the aliases of one real actor and score the cluster.
Ten accounts each sending small amounts look innocent one at a time. Once you see they share a device and pay the same destination, they look like what they are.
This is mature, productized technology, and the core idea fits in one line: the unit of suspicion is the linked cluster, not the single action.
Mapping it to agents
Ported to agents, the question becomes: what links one session to another? The AML links have fairly direct analogs:
| AML link | Agent version |
|---|---|
| Shared device / IP | Shared workspace, filesystem, or tool server |
| Money flowing A → B | Data flowing: one agent writes a file, another reads or runs it |
| Same beneficiary | Same target account, endpoint, or credential |
| Same person behind many accounts | Same principal or deployment behind many sessions |
The links exist, but agent systems mostly don’t record them. That’s starting to change: there’s a growing push for explicit provenance in agent systems, a record of where each piece of context and each action came from. Provenance is the join key, which is exactly what an AML graph runs on.
I haven’t found work that uses it for cluster-level scoring in monitoring, and the path seems worth exploring. The merge-and-score check in Phuong et al. only works because the researchers already know which pieces belong to the same attack. On real traffic nobody knows that in advance, and provenance could be what supplies the grouping:
- Link sessions by shared provenance.
- Score the cluster.
- Measure how much of the cross-session gap it closes versus per-event monitoring.
Technical challenges
1. Links that connect everything. A shared device is a useful signal in AML because legitimate accounts rarely share one. Agents are the opposite: most of a company’s agents work in the same repo, the same workspace, for the same principal. Link on those and every session ends up in one giant cluster, which is the merge-everything problem all over again. The real question is which links actually discriminate, such as a specific file one agent wrote and another executed, as opposed to links nearly every session has.
2. Missing links. Banks have strong identifiers. Agent links are softer, often inferred, and often not recorded at all. Without provenance there’s no graph to build.
3. Short-lived identities. An agent may exist for minutes, too short to build a profile. You may have to anchor on the deployment or role instead of the instance.
4. Machine speed. A fraud ring grows at human pace, but a thousand sub-agents can spin up in seconds. The clustering has to keep up inside a latency budget.
5. Attackers who break the links. An agent that knows how the monitor works can avoid leaving provenance: switch tools, pass data through an intermediate file, or get another agent to take the step. Launderers do the same thing. It’s called layering: moving money through enough hops that the trail goes cold. Any link-based defense has to assume the attacker is trying to cut the links.
Takeaway
Per-event defenses and per-cluster defenses are different tools. Agent security has built the first; finance built the second years ago. On this one, AI security can copy a lot of finance’s homework.
First draft produced with AI assistance; reviewed and edited by the author.
Also published on Substack.