← All posts

When Your Compliance Vendor Goes Dark

Chainalysis is the company that banks, crypto exchanges, and federal law enforcement agencies rely on to follow the money. Its Reactor platform maps cryptocurrency flows across wallets for investigators. Its KYT (Know Your Transaction) service flags suspicious activity in real time for compliance teams. The company says more than 1,500 organizations use its tools, including government agencies like the FBI and IRS. When the Department of Justice announces a sanctions enforcement action or the FBI traces ransom payments, Chainalysis tools are often in the background.

On October 30, Chainalysis disclosed that external attackers had gained unauthorized access to its systems using what the company described as “offensive agentic techniques.” The initial notice was measured: user IDs, names, and email addresses had been accessed. The company said it had found no indication that passwords, tokens, or investigation data were compromised.

Within a week, that picture changed dramatically.

By November 5, Chainalysis acknowledged that names, usernames, password hashes, and live session tokens for all of its users had been exposed. A separate “on-path” attack, an adversary-in-the-middle technique, had captured a subset of customer passwords in transit. Starting November 2, the company took Reactor and Data Solutions offline. By November 4, the KYT interface, the address-screening API, and even the login page followed.

For organizations that built their anti-money laundering compliance around a single platform, the lights had gone out.

The Business Problem Nobody Planned For

This is not a story about cryptocurrency. It is a story about what happens when a critical vendor in your compliance stack goes offline without warning.

Banks, exchanges, and payment processors use Chainalysis to satisfy regulatory obligations under the Bank Secrecy Act and similar frameworks worldwide. When that service goes dark, the question is not “when will it come back?” The question is: can you still demonstrate compliance to your regulators while it is down?

Most organizations will not have a good answer. They integrated the tool, checked the compliance box, and moved on. Few built a fallback. Few asked what would happen if their screening vendor was unreachable for days. Few negotiated contractual rights to be notified within hours, not days, of an incident that exposed their users’ credentials.

This is the gap that separates compliance from security. Compliance tells you what boxes to check. Security tells you what to do when the box itself breaks. If your entire anti-money laundering posture depends on one vendor’s API staying online, you have a compliance program, not a resilience plan.

AI Agents as Attack Weapons

The phrase “offensive agentic techniques” in Chainalysis’s disclosure deserves attention. It indicates the attackers used autonomous AI-driven tools to probe and exploit the company’s infrastructure.

This is not theoretical anymore. Security researchers have warned for years that the same AI capabilities helping defenders would be turned against them. Now we have a high-profile case where the target company itself says it happened. An AI-driven attack tool does not sleep, does not get bored, and can test thousands of approaches per hour. The bar to defend against that kind of pressure is fundamentally different from defending against a human team working in shifts.

For board members and executives, this raises a concrete question: has your security team assessed whether your defenses can withstand an AI-assisted attack? Not a tabletop exercise on paper, but a real evaluation of whether your monitoring, access controls, and response procedures can keep pace with an adversary operating at machine speed.

The Disclosure Gap

One detail in the Chainalysis timeline should concern every executive who relies on a vendor for a critical function. On October 30, the company said it had found no indication that passwords, tokens, or session data were compromised. By November 5, it confirmed that password hashes and live session tokens for every user had been exposed.

That is not unusual. Breach investigations regularly uncover worse news as they continue. But if your organization received the October 30 notice and concluded no action was needed, you were operating on incomplete information for nearly a week. During that time, live tokens that could grant access to accounts without a password were in unknown hands.

The Three Questions framework from Cyber Risk Is Business Risk applies here. What can go wrong? Your vendor gets breached and the initial notice understates the damage. What are you doing about it? You should have a playbook that treats vendor breach notices as the floor of the problem, not the ceiling. How do you know it’s working? You test the playbook before you need it.

What to Ask Your CISO This Week

The Chainalysis breach hands executives a ready-made agenda for their next security conversation:

On vendor concentration risk: “Which vendors, if they went offline tomorrow, would stop us from meeting our regulatory obligations? Do we have a fallback for each one?”

On credential exposure: “If a vendor told us that every user’s password hash and session token had been exposed, how fast could we rotate credentials and confirm no unauthorized access occurred on our side?”

On AI-driven threats: “Has our red team or our penetration testing partner simulated an AI-assisted attack? What did we learn?”

On notification timelines: “What are our contractual notification requirements with critical vendors? Would we know about an incident within hours, or would we find out from the news?”

These are not technical questions. They are governance questions. They belong in the boardroom, not the server room.

The Bigger Pattern

Chainalysis joins a growing list of security and trust providers that have themselves been breached: SolarWinds, Okta, LastPass, and now the company that traces criminal transactions for the world’s largest economies. Each time, the pattern repeats. Organizations trusted a vendor with a critical function, assumed the vendor’s own security was adequate, and discovered the assumption was wrong only after the damage was done.

The lesson is not that vendors cannot be trusted. It is that trust must be verified, not assumed, and that verification must include the question: “What do we do if this vendor fails?”