Your vendor's breach is your incident.

A vendor breach does not stay on the vendor's side of the contract when the attacker has credentials that work in your account.

Chainalysis made that point unusually clear last week. The blockchain intelligence company disclosed that names, usernames, password hashes, and live tokens for all its users were exposed to a malicious actor. It later required password resets and API-key rotation before customers could reconnect.

At that point, customers were no longer watching someone else's incident. They were responding to their own.

The disclosure changed as the evidence changed

On October 30, Chainalysis said it had found no evidence that authentication credentials or session tokens had been accessed. The company said an external actor had used what it called "offensive agentic techniques" to enter its systems and internal tools, but the disclosed customer impact appeared limited to names, email addresses, user IDs, and organizational role labels.

The picture widened on November 4. In its incident updates, Chainalysis said an on-path attack had exposed a subset of customer passwords. Later that day, it disclosed that names, usernames, password hashes, and live tokens for all Chainalysis users had been exposed. The company also found abnormal activity, took its login page and several products offline, and began notifying customers whose Know Your Transaction accounts appeared to have been accessed without authorization.

By November 7, Reactor, KYT, and Address Screening were back online with additional controls. Chainalysis said it still had no evidence that investigation data had been accessed or attribution data manipulated.

There are important limits to what is public. As The Record noted, Chainalysis did not define "live tokens," identify the password-hashing method, or say whether every category of information was exposed for every user. Ars Technica reported that the infrastructure involved in the on-path attack also remains unexplained.

Those unknowns justify caution. They do not justify waiting.

When a vendor says your active credentials may be in an attacker's hands, their investigation timeline cannot become your response timeline.

A password reset is only one part of containment

Companies tend to route vendor notices into procurement, legal, or a third-party risk queue. That works for questionnaires and expiring certificates. It fails when the notice describes usable identity material.

A password hash can give an attacker an offline path to the original password, depending on how it was created and how strong the password was. A live session token may let someone act as an authenticated user without entering the password again. An API key can keep an integration running long after the employee who configured it has changed roles.

These are different credentials with different revocation paths. Resetting passwords while leaving sessions and machine credentials intact creates a clean-looking login page over an unresolved incident.

The operational dependency matters too. Chainalysis customers use KYT and Address Screening in transaction-monitoring workflows. When those products went offline, customers had both a security event and a business-continuity decision: queue transactions, apply an alternate review process, or accept a different level of risk. Vendor resilience is part of security because the control itself can become unavailable during the incident it is meant to help manage.

The "agentic" label is less useful than it sounds. Chainalysis has not published enough detail to assess what an AI system did, which vulnerabilities it used, or how much autonomy it had. The confirmed facts are sufficient: the attacker reached internal systems, identity material was exposed, and customer accounts showed abnormal activity. Response should follow evidence, not the most marketable word in the disclosure.

What we'd do now

Make credential exposure an incident trigger. Write this into the vendor-response plan before the next notice arrives. Exposed passwords, tokens, signing keys, API keys, or federation secrets should page the security owner immediately rather than wait for a vendor-management meeting.
Inventory every trust path to the vendor. Include human users, SSO connections, SCIM provisioning, service accounts, API keys, webhooks, browser sessions, IP allowlists, and secrets stored in automation platforms. The account list in procurement is rarely the complete access map.
Revoke first, then rotate. Invalidate active sessions and tokens, disable affected keys, reset passwords, and issue replacement credentials through a known-good channel. Confirm the old material fails. Rotation without revocation can leave both credentials working.
Hunt in your own records. Review sign-ins, source addresses, user agents, API calls, exports, role changes, key creation, and configuration changes from the earliest plausible exposure date. Preserve the logs. A vendor's statement that it has no evidence of access is not evidence from your environment.
Reduce access while facts are incomplete. Pause nonessential integrations, narrow scopes, restrict source networks, and apply temporary allowlists where the service supports them. Give every temporary control an owner and an expiration date.
Define degraded operations. For every vendor embedded in a security, payment, or compliance decision, document what happens when the service is unavailable or untrusted. Decide in advance which workflows stop, which queue, and which move to manual review.
Close with evidence. Ask the vendor which credential classes were exposed, when they were invalidated, what logs are available, and which customer actions are mandatory. Record the answers with your own containment and review results. A resolved status page is not an incident report.