The vault held. That was never the way in.

LastPass got breached again this month. The part everyone braces for did not happen. No vault was cracked. No master password fell. The encrypted secrets sat untouched. LastPass confirmed its "products, services, and infrastructure were not affected" and that customer vaults "remained secure." [1]

The attackers never went near the vault. They walked in through a vendor.

Here is the chain, because the mechanism is the whole point. On June 11 a group calling itself Icarus got into Klue, a market-intelligence platform @LastPass used internally. Their way in, according to @HuntressLabs, who worked the incident: "a long-dormant API credential originally created for an abandoned third-party integration prototype." [2] A key made for a project that no longer existed, for a purpose no one remembered, still live. From inside Klue they pushed malicious code that harvested the OAuth tokens Klue held for its customers: the standing grants that let it read @salesforce, Slack, HubSpot and more on those companies' behalf. One of those tokens was LastPass's. With it, the attackers read LastPass's Salesforce CRM. Names, emails, phone numbers, addresses, support-case contents. Then the extortion note. Pay, or it goes on the leak site.

LastPass was not alone in the blast. Huntress, Recorded Future, Tanium, Jamf, BeyondTrust. Security companies, most of them. The kind that do this for a living.

So credit where it is due. LastPass's cryptography did exactly what it promised. The vault is not the story. The story is a class of secret that almost nobody treats as a secret: the long-lived token sitting inside a SaaS integration you approved once and never looked at again. It does not expire. It does not know it has been stolen. It grants far more than the reason it was created for, and it keeps granting it, quietly, until a human remembers to go turn it off. Usually no human does.

That is the shift. The threat model moved from "can they break the vault" to "how many forgotten keys are propped in doors you stopped watching." A dead credential from an abandoned prototype was enough to reach a string of companies' customer data. The math was never the weak point. The sprawl was.

This is the exact failure a credential should be built to refuse. A secret Clavitor issues is short-lived and scoped. It is brokered for one operation, it expires on its own, and it is bound and attributed to the machine that used it. A token like that cannot become what did the damage here: a forgotten grant, harvested long after anyone remembered it existed, replayed from a stranger's infrastructure with nothing tying it to an actor. It is gone before it can be found, and it never reached past its one job.

There is a limit worth stating plainly. Clavitor governs the credentials it holds, not the standing OAuth grant you handed a vendor's platform. That token lives in their system, under their controls, and no vault reaches in to expire it for you. What changes is everything in Clavitor's lane. It refuses to be the place a never-expiring secret can quietly sit. The discipline whose absence opened Klue (short lives, tight scope, real attribution) is the default here, not a setting someone was supposed to remember.

The question this leaves is an uncomfortable one. How many live tokens are sitting in vendors you onboarded a year ago and have not thought about since?

We wrote up the handful of properties a credential should hold before you trust it with anything. [3]

Clavitor (@clavitorai) is the credential vault built for AI agents, and against them. clavitor.ai

Sources

[1] BleepingComputer, "LastPass confirms data breach in Klue supply chain attack" — @BleepinComputer

[2] Huntress incident findings, reported via Help Net Security, "Klue breach lead to Salesforce data theft, Huntress affected" — @HuntressLabs, @helpnetsecurity

[3] The Ten Rules of Credential Management (native X Article) — @clavitorai