Mercor is not supposed to be interesting. The company, founded by three Bay Area high school friends in 2023, built what looks on paper like a recruitment platform: AI-matched talent networks for the frontier labs that need human experts to generate high-quality training data. OpenAI, Anthropic, Google, and Meta all hired Mercor to source attorneys, physicians, bankers, and engineers whose reasoning could train the next generation of models. By early 2026, Mercor carried a $10 billion valuation.
On April 2, 2026, Mercor confirmed a cyberattack that exposed 4 terabytes of data to the threat group Lapsus$. The attack originated upstream, in the Trivy supply chain cascade that poisoned LiteLLM: TeamPCP had pushed a malicious LiteLLM package to PyPI that lived in the registry for approximately 40 minutes before removal. That compromise reached Mercor because Mercor's infrastructure depended on LiteLLM.
The technical chain is well documented. The part the coverage understates is what one vendor was actually holding.
What Mercor Was Built to Be
Mercor's pitch is velocity. The platform uses AI-enabled matching to place expert human contractors with frontier labs in days, not months. Ship fast, rate fast, pay fast. By April 2026, more than 40,000 contractors were active on the platform, and Mercor was closing contracts with every major AI lab.
The procurement reality followed from the pitch. To the AI labs, Mercor looked like a SaaS supplier of human talent. The vendor risk profile was evaluated as a capability risk: can they deliver contractors fast enough, can they match the expertise required, can they pay at scale. The data-surface risk profile was not the primary question. It is easy to see why. When the product is "high-quality human reasoning, delivered as training data," the vendor is framed as a labor marketplace, not a data custodian.
This is the same misclassification pattern I wrote about in AI's broken shared responsibility model. At every layer of the AI stack, vendors and customers are shipping integrations without agreeing on whose job it is to classify the data sensitivity, validate the inputs, or audit the access. Mercor got the same treatment the MCP protocol did: trusted by default.
What Mercor Actually Held
The Lapsus$ exfiltration tells a different story. According to claims from the attackers and subsequent reporting, the 4TB dataset includes:
- 939 GB of source code, including matching algorithms and the internal benchmarking code Mercor uses to evaluate contractor output for frontier labs.
- 211 GB of user records, including resumes, verified contact information, and Social Security numbers for more than 40,000 contractors.
- 3 TB of video interview recordings, including facial biometrics and passport and driver's license scans used for identity verification.
- Hardcoded API keys to Mercor's cloud infrastructure.
- Internal network maps and device certificates that allow attackers to impersonate trusted internal machines even after remediation.
- Internal Slack communications and ticketing data.
Read the list again. One vendor held biometric KYC data for tens of thousands of people, operational infrastructure credentials, and proprietary code for the matching process that selects human experts for frontier AI labs. That is not a capability supplier. That is a privileged-access third party in the same category a bank would classify as critical infrastructure.
This is the same concentration problem that defined the IDMerit identity verification honeypot: a vendor treated as a convenience layer was actually the chokepoint where the most sensitive data in the transaction came to rest. The faces, the documents, the SSNs. None of that is recoverable after exfiltration. You can rotate a password. You cannot rotate a face.
The Pattern: AI Procurement Is Optimized for the Wrong Dimension
The clearest evidence that the category error is industry-wide is the asymmetric response. Meta indefinitely paused all Mercor contracts. OpenAI confirmed it is investigating but continuing current projects. Anthropic and Google declined public comment. A class action lawsuit was filed on behalf of the affected contractors.
If these companies had classified Mercor as a privileged-access vendor from the start, the response would be uniform. The asymmetry reveals that each AI lab is now negotiating its own vendor risk calculus in real time, deciding what a capability supplier that turned out to be a privileged-access vendor actually means for their exposure.
Banks and defense primes settled this question two decades ago through standardized third-party risk frameworks. AI labs are relearning it in public. It is a specific instance of the broader dynamic in third-party data sharing becoming 2026's biggest security risk: when the transitive trust chain lengthens faster than the governance frameworks that evaluate it, the blast radius of any single compromise grows with every new vendor integration.
Vendor dependencies are forming faster than the risk assessments can catch up. Mercor is the downstream case: the labs never ran the risk assessment on their training data vendors either.
What AI Vendor Governance Should Actually Look Like
The lesson I learned advising cross-border M&A at Houlihan Lokey applies here directly: vendor risk is a function of what they hold, not what they do. An expense management SaaS and a payroll provider both look like routine vendors on an org chart. One of them has access to every bank account number in the company, and you treat them accordingly.
AI labs are not making that distinction. They are classifying Mercor like the expense management SaaS, then handing it biometric KYC data and access credentials for internal infrastructure. The same misclassification is the core argument in the SEC investor data delete lawsuit: centralization of sensitive data is a risk multiplier that only matters after it gets breached.
Three practices should become standard in AI training data procurement:
Classify vendors by what they hold, not what they do. A training data broker that collects biometric KYC is a privileged-access vendor, regardless of whether the procurement team treats it as a talent marketplace. Apply the same controls you would apply to your identity provider or your secrets manager.
Require cryptographic separation between capability delivery and data storage. Mercor could have completed its matching function without retaining 3 TB of identity verification videos. The retention was a product decision, not a technical requirement. Contracts with AI training data vendors should require automatic deletion of biometric and KYC data within a fixed window after verification.
Audit residual access after every incident, not just the initial compromise. Mercor's attackers walked away with device certificates. The same root-cause failure that enabled the Trivy attack, an incomplete credential rotation, allowed post-breach persistence at Mercor. Treat every breach as a trust revocation event, not a credential rotation event.
The 40-minute window for the LiteLLM compromise is a reminder of how little time attackers need when the access is already provisioned. The 4-terabyte exfiltration is a reminder of how much one vendor can hold. The asymmetric industry response is a reminder that AI's vendor governance model has not caught up to what these vendors actually are.
Mercor will not be the last. Every AI lab has a list of vendors with similar access profiles, classified by capability rather than by data sensitivity. The procurement teams who fix this classification error first will be the ones still in the news when the next breach happens, as the model rather than the cautionary tale.
