Procurement teams have been treating SOC 2 as a property of the vendor: a PDF you collect from the second party and file. Three of April 2026's most-discussed AI-vendor breaches have made it clear that the attestation is not a property; it is a chain, and the chain is only as good as the firm at the end of it. Vercel was reached through Context.ai, Mercor was reached through LiteLLM, and a whistleblower-named list of additional Delve customers includes Lovable, Cluely, and Wispr Flow. All three of the disclosed breaches share the same SOC 2 auditor, and that fact is the procurement story.
Vercel Through Context.ai
The Vercel breach disclosed in mid-April followed an OAuth supply-chain pattern that has become almost routine: a Vercel employee installed a Context.ai application and connected it to Vercel's corporate Google account, and attackers used that employee's Google access to reach Vercel's internal systems. Context.ai disclosed afterward that its compliance vendor was Delve, and it has since moved to Vanta and engaged Insight Assurance for new examinations. The post-incident audit-firm switch is the relevant signal here, not the OAuth mechanic itself, because Context.ai is the second customer in two months to drop Delve after a breach. I covered the broader fourth-party angle in my Vercel and Context.ai post; this post extends that chain by one more link.
Mercor Through LiteLLM
The earlier case was structurally identical. LiteLLM, an AI-gateway library that reports roughly 97 million monthly PyPI downloads and a 36% cloud-environment presence, shipped two malicious versions to PyPI on March 27 after attackers used credentials from an earlier supply-chain compromise to push to its CI/CD. Mercor was the publicly disclosed downstream victim; extortionists claimed roughly 4TB exfiltrated and more than 40,000 contractors affected, with training methodologies tied to Anthropic, OpenAI, and Meta among the data at risk; Meta paused work with Mercor in response. LiteLLM had used Delve as its SOC 2 vendor and dropped Delve on March 30, four days after the malicious upload. The CI/CD compromise itself traced back to a Trivy supply-chain attack I analyzed earlier, and the Mercor vendor-governance gap is a separate but related thread; the auditor angle is the new one.
Lovable, Cluely, and Wispr Flow Per the Whistleblower
A leaked corpus of Delve-issued reports surfaced through the DeepDelver Substack and was summarized by Captain Compliance; a community-built public index reproduced via Trust Compliance covers 533 reports across 455 companies, and the analysis indicates that 99.8% of the text was identical across files, with only the company name and logo swapped (the original DeepDelver writeup details the methodology). Per that whistleblower-leaked customer list, which neither Delve nor the named companies have independently confirmed, additional Delve customers include Lovable, Cluely, and Wispr Flow. The corpus contains the same paragraphs and the same grammatical errors across hundreds of Type II reports, including the typo "because there no security incidents reported" repeated verbatim across files and test placeholder values like "sdf" and "dlkjf" that survived into delivered reports. I covered Lovable's 76-day platform-level BOLA in Lovable's disclosure-maturity post; the new fact is that the SOC 2 attestation Lovable was relying on appears to be one of the near-duplicate reports, which means the attestation row in any buyer's diligence file on Lovable was misweighted from the start.
The Pattern Becomes Visible Only Through Cross-Reference
The three incidents look like three different stories until you put the auditor row into the vendor inventory. Vercel's diligence on Context.ai, Mercor's diligence on LiteLLM, and any procurement team that accepted Lovable's SOC 2 Type II at face value were all relying on attestations issued by the same firm, and that firm's audit work appears, per the whistleblower analysis, to have been concentrated through two sub-firms (Accorp and Gradient, alleged to be the same India-based operation) that reportedly handled virtually all of the engagements. The whistleblower corpus shows that the reports themselves were not independently produced for each client, and the repeated typo and the surviving test strings establish that the substantive review described in those reports did not happen in the way SOC 2 Type II requires. Trust is transitive but security is not, which means none of this is information a buyer could discover by reading any single attestation; each attestation looks legitimate on its own, and the failure is only visible when you cross-reference reports across the auditor's full client base.
This is the same diligence move that any M&A analyst running a sell-side process would apply to a financial audit. At Houlihan Lokey, the principle was unambiguous: you do not accept a single auditor's letter as the complete answer to whether the numbers are real. You cross-reference, you check the auditor's other engagements for warning signs, and you confirm that the audit firm has the staffing and the independence to actually perform the work it claims to have performed. Procurement teams have not been doing this for SOC 2 because the incentive structure was the opposite: faster vendor onboarding meant accepting the PDF and moving on, and the cost of cross-referencing fell on the buyer while the benefit accrued only on the rare day a chain like this one gets exposed.
The Auditor Concentration Problem
The Delve case is sharper than a single bad-actor story because the audit work was concentrated, not distributed. Two sub-firms appear to have processed the bulk of the engagements, and the 493-of-494 near-identical-report finding from the DeepDelver review of one Type II sub-sample (a narrower cut of the broader 533-report, 455-company indexed corpus referenced earlier) is a structural feature of that concentration: when one operation produces nearly all of an audit firm's reports, the failure mode shifts from per-engagement risk to platform risk. This is the same concentration blind spot the Dutch regulator missed at ChipSoft, where one vendor running 80% of the country's hospitals turned a single ransomware event into a national outage. Insight Partners has scrubbed its $32M investment thesis post on Delve, Y Combinator removed Delve from its companies directory and asked the founders to leave the program, and CEO Karun Kaushik has admitted Delve "grew too fast and fell short" while denying fraud. The denials are not the part procurement should focus on. The part that matters is that buyers cannot detect concentration risk in their auditor without explicitly looking for it, because no SOC 2 report names the engagement team's actual workload or the share of the firm's revenue passing through a single sub-firm.
AICPA Just Made This Discoverable
The accounting profession's standard-setting body shifted the ground in April. The Journal of Accountancy published tool-provider ethics guidance that does not name Delve but is responsive to the same fact pattern: "Any such arrangement that restricts a service auditor's ability to determine scope and timing, obtain sufficient appropriate evidence, communicate deficiencies, or maintain objectivity may introduce significant ethics and independence threats," and where threats cannot be mitigated, "the service auditor should decline or discontinue the engagement or business arrangement." That language is the procurement-relevant part. It establishes that auditor entanglement with a tool provider is a now-articulated independence threat, which means a buyer who fails to ask about it after April 2026 is failing to apply a standard the AICPA itself has put on the table. IANS Research framed the downstream liability question precisely: "If certifications are flawed, liability and regulatory exposure may sit with the companies that relied on them."
What the Vendor Inventory Should Add
Procurement teams already track the vendor and the vendor's subprocessors, and the better-run programs added CI/CD posture to the inventory after the LiteLLM and Trivy incidents. The auditor is the missing row, and the case for adding it is no longer hypothetical. A working version of that row carries the auditor's firm name, the lead engagement partner, the firm's AICPA accreditation status, the auditor's physical U.S. presence, the auditor's annual client volume relative to staffing, any business relationship between the auditor and the platform vendors the audited company sells into, and the count of the auditor's other clients already inside your vendor inventory. The last item is the cheapest to compute and the most diagnostic, because concentration of a single auditor across multiple of your vendors is exactly the failure mode the Delve case exposed.
The spot-check is the second piece. IANS recommends pulling five to ten controls from the SOC 2 report and confirming them independently with the vendor, which is a manageable amount of work for any buyer with a real diligence function and would have caught the placeholder-text reports in the Delve corpus on the first request. The spot-check should be standard for any vendor handling production data or platform credentials, not an exception reserved for the largest contracts.
The Buyer's Obligation
The Vercel, Mercor, and Lovable cases are not three vendor failures; they are one auditor failure surfacing through three vendors, and the fix is structural rather than procedural. A procurement function that adds the auditor as a row, cross-references that row against the rest of the vendor inventory, treats the AICPA's April tool-provider language as a required diligence question, and spot-checks five to ten controls per engagement will catch the next Delve before the breach disclosure does. The buyers who do not add that row will keep collecting PDFs, and the next concentrated-auditor exposure will read exactly like this one: three customers reading the same boilerplate report and discovering, on the day of the incident, that they had all bought attestation from the same place.
