Leaks hit AI and tech companies hardest, where the exposed asset might be model weights or source code rather than a spreadsheet, and the path out can run through a tool your own team trusts. In March 2026, a compromised version of the open-source LiteLLM tool exfiltrated credentials from Mercor, an AI company with roughly 5 million experts on its platform. Common Defense responds to these scenarios, tracing the leak, containing it, and hardening against a repeat.
Scope comes first
The urgent question is narrow: what left, through which path, and who can still use it. A customer-data leak, a source-code leak, and a model-weight leak each carry a different blast radius. We establish which one you’re facing, the channel it left through, and whether that access can still be abused. That gives your team a defensible scope before public statements and legal decisions harden around guesses.
Where leaks come from
The path out usually runs outside the application: an over-permissioned cloud bucket, a forgotten model artifact, a contractor account, a compromised dependency, or an API key left in a notebook. For AI teams the exposure reaches past regulated data, into model weights, evaluation sets, prompt logs, and training pipelines. Generic response stops short here. Closing the exposed bucket does little if the same token still reaches the model registry, so we trace the leak back to the operating surface that enabled it.
Contain, then close the class
Containment starts with cutting access without destroying evidence. We preserve the logs, snapshots, and identity history needed to reconstruct the path, then shut the route the data took. Once it’s closed, you get the account of record customers and regulators need: what was exposed, what wasn’t, and how it happened. Then we harden the operating surface that allowed it, so the fix closes the whole class of exposure, not just this incident.