Anatomy of Mercor's Data Breach ¶

A technical analysis a complete operational data (production database, user & customer data) loss ¶

Disclaimer: All personally identifiable information (PII) in this document has been obfuscated. Names are partially masked (e.g., T** O****), emails redacted (e.g., e****a1@gmail.com), phone numbers truncated (e.g., +4479571****), bank details masked (e.g., 000**-***), financial identifiers hidden (e.g., acct_1Rc*****), IP addresses truncated (e.g., 71.194.*.*), and MAC addresses partially redacted (e.g., 1C:93:7C:**:**:**). This analysis is conducted for educational and security research purposes.

Note on source material: This entire analysis is based on two small sample files made publicly available by Lapsus$ — a database schema sample and a database export containing table structures with example rows, plus partial Airtable workspace exports. These files were shared after Mercor allegedly paid a ransom to have the data removed from the group's leak site — a fact confirmed to us directly by Lapsus$. Despite receiving payment, the group continues to share samples and is actively engaged in selling the full dataset to private bidders. Together these two files represent a fraction of a percent of the claimed 211GB production database. We did not have access to the full database, the 939GB of source code, the 3TB of cloud storage, the Slack exports, or the Tailscale VPN data. Everything documented in this report — every bank routing number, every Apple Foundation Model output, every Persona KYC session token, every desktop screenshot URL — was found in these two small files alone. The full breach is orders of magnitude larger. What follows is the tip of the iceberg.

Table of Contents ¶

1. Executive Summary
2. Why This Breach Is Serious
   • Why AI Training Data Is Worth Billions
   • The Extent - What Data Was Exposed
   • The Scope - Who Is Affected
   • The Scale - Mercor Client Ecosystem
   • The Airtable Export - 84 Workspaces 1055 Files
   • Customer and Third-Party Platform URLs
   • The Screenshot Problem
3. Platform Overview
4. Evidence - The Database Layer by Layer
   • Part I - User and Identity Layer
   • Part II - Identity Verification and Fraud Detection
   • Part III - The Hiring Pipeline
   • Part IV - Interviews and Assessments
   • Part V - Work Trials and Onboarding
   • Part VI - Projects and AI Task Management
   • Part VII - Time Tracking and Productivity Surveillance
   • Part VIII - Payments and Financial Infrastructure
   • Part IX - Communications and Outreach
5. Reverse Engineering - Architecture and Infrastructure
   • Part X - Infrastructure and DevOps
   • Part XI - Analytics and ML Layer
   • Part XII - Reference Data Layer
6. Exposed Surface Area Summary
7. Technical Architecture Reverse-Engineered
8. Grounds for Legal Action
   • I. Client Company Claims - Loss of Proprietary AI Training Data and Trade Secrets
   • II. Contractor Class Claims
   • III. Statutory Violations
   • IV. Negligence
   • V. Third-Party Claims
9. Conclusion - What Happens Now
   • The Data Is Still in Circulation
   • The Ongoing Threat
   • The Case for Radical Transparency
   • A Structural Critique
10. Appendix A - Complete Table Inventory

Executive Summary ¶

This document presents a systematic technical analysis of a small sample from a database export from Mercor, an AI-powered talent marketplace that connects software engineers, AI data labelers, and knowledge workers with companies seeking contract labor. As reported by the Wall Street Journal, Mercor has rapidly become one of the key intermediaries in the AI industry — placing contractors inside organizations like Meta, OpenAI, Google DeepMind, Anthropic, Apple, and Amazon to perform AI training, data labeling, software engineering, and other knowledge work.

What we analyzed is two small sample files shared by Lapsus$ after Mercor allegedly paid a ransom to have the breach data removed. Despite that payment, the group continues to distribute samples and is actively selling the full dataset to private bidders. Together these files represent a tiny sliver of the claimed 211GB production database. Yet even these small samples contain over 250 table schemas with sample data rows exported from Mercor's Aurora MySQL production environment, plus Airtable workspace exports containing actual AI training data and model evaluation records. The samples cover every operational dimension of the platform — from contractor signup through identity verification, AI-conducted interviews, job placement, real-time work surveillance, and payment disbursement.

If these samples — containing just one or two rows per table — already expose full bank routing numbers, government ID verification tokens, desktop screenshot URLs, signed legal documents, and proprietary AI model outputs from Apple and Amazon, the full 211GB database contains the same data for every contractor and every transaction Mercor has ever processed.

Scope of This Article and the Full Scale of the Breach ¶

Important: This article analyzes only two small sample files from the production database, shared by Lapsus$ after Mercor allegedly paid a ransom. The full production database is 211GB, which is itself a fraction of the claimed 4-terabyte breach. Every finding documented below was derived from these small samples alone. The full database would contain the complete records for every contractor, every transaction, every screenshot, and every payment Mercor has ever processed.

The Breach at a Glance ¶

Mercor's official account attributes the breach to a supply-chain attack on the open-source Python package LiteLLM — a widely used AI proxy library estimated to be present in 36% of cloud environments. On March 27, 2026, using a maintainer's compromised credentials, the TeamPCP hacking group published two malicious PyPI package versions (1.82.7 and 1.82.8) that were available for download for approximately 40 minutes. The reported attack chain: the poisoned dependency landed in Mercor's development environment, swept the machine for SSH keys, AWS tokens, Kubernetes secrets, and .env files, deployed privileged containers across Mercor's Kubernetes clusters, and used the stolen credentials to begin exfiltrating data through Mercor's Tailscale VPN.

However, there are reasons to question whether LiteLLM was the sole or even primary attack vector. Exfiltrating 4 terabytes of data — production databases, 939GB of source code repositories, 3TB of cloud storage including video recordings and screenshots, plus Slack, Airtable, and Tailscale exports — is not a fast operation. At typical egress speeds, this would have taken days to weeks of sustained data transfer. A 40-minute window of malicious package availability seems insufficient to establish the deep, persistent access required to systematically exfiltrate this volume of data across this many distinct systems (Aurora MySQL, S3 buckets, GitHub repositories, Airtable, Slack, Tailscale). It is entirely possible that Mercor was already compromised through other means — whether through prior credential exposure, an insider threat, or a separate vulnerability — and that the LiteLLM incident was coincidental or merely one of multiple entry points. Mercor's characterization of itself as "one of thousands of companies" affected by LiteLLM may be an attempt to deflect from deeper, more embarrassing security failures.

Lapsus$ group subsequently claimed responsibility for the breach, posting samples of the allegedly stolen data. Lapsus$ confirmed to us directly that ransom negotiations with Mercor took place and that Mercor paid. Despite that payment, the group continues to distribute samples and is actively selling the full dataset to private bidders.

Mercor confirmed the security incident but characterized itself as "one of thousands of companies" affected by the LiteLLM compromise. The company declined to answer whether any customer or contractor data had been accessed, exfiltrated, or misused.

Security researcher Archie Sengupta noted it was a "very big breach." Y Combinator president Garry Tan was more direct: "Incredible amount of SOTA training data now just available to China thanks to @mercor_ai leak. Every major lab. Billions and billions of value and a major national security issue."

What Was Taken - The Full 4TB ¶

The attackers claim to have exfiltrated the following assets. This article only analyzes the first item — the production database. The remaining categories are not covered in this analysis but are described here to convey the full scale of exposure.

Why This Matters Beyond Mercor ¶

The database analyzed in this report is merely the index — the structured metadata that describes, catalogs, and points to the stolen assets. Think of it as the card catalog for an entire stolen library:

• The source code reveals how the system works — every algorithm, every API endpoint, every security mechanism, and every hardcoded credential
• The Slack export reveals what was said about it internally — incident responses, client negotiations, and operational discussions
• The cloud storage contains the actual files — the screenshots of contractor screens showing client systems, the video interviews showing candidates' faces and voices, the passport scans and government IDs submitted for verification
• The Airtable export contains the work product itself — the annotation data, task submissions, and quality reviews that Mercor's clients (including frontier AI labs) paid for
• The Tailscale VPN data provides a map to anything that was missed — the internal network topology that could enable further unauthorized access if credentials haven't been fully rotated

As Garry Tan noted, the AI training data alone — the prompts, responses, evaluations, and RLHF annotations produced by Mercor's contractors for organizations like OpenAI, Meta, and Google DeepMind — represents potentially billions of dollars in value. If this data reaches competitors — whether domestic rivals or labs in other countries — it would allow them to shortcut years of investment. The source code for Mercor's proprietary ranking algorithms (MercorScore, the Bradley-Terry tournament system, the Bayesian fraud model) adds further competitive intelligence value.

Together, this represents one of the most comprehensive corporate breaches in recent memory: not a single database table or a handful of credentials, but the complete digital footprint — code, data, communications, files, network maps, and work product — of an organization entrusted with some of the most sensitive work in the AI industry.

Why This Breach Is Serious ¶

Why AI Training Data Is Worth Billions ¶

To understand why this breach is significant and not just another corporate data leak, it helps to understand what AI training data is and why companies like OpenAI, Anthropic, Apple, Amazon, Meta, and Google pay enormous sums to produce it.

Modern AI models like GPT-4, Claude, and Gemini are not programmed — they are trained. The raw intelligence comes from pre-training on internet text, but the ability to follow instructions, reason carefully, and refuse harmful requests comes from a second phase that depends entirely on human-generated data. This is the data Mercor's contractors produce. It falls into several categories, all of which are present in the breach:

Supervised Fine-Tuning (SFT) data — Humans write high-quality responses to prompts, demonstrating how the model should behave. The TASKS and TASK_VERSIONS tables across Mercor's 84 Airtable workspaces contain these prompt-response pairs, organized by domain (legal, medicine, finance, coding, etc.). A single SFT dataset covering a specialized domain can cost millions of dollars to produce because it requires experts — lawyers, doctors, engineers — writing at $95/hour for months.

Reinforcement Learning (RL) preference data — Humans compare two model outputs and judge which is better. This is the core of RLHF (Reinforcement Learning from Human Feedback), the technique that transformed GPT-3 into ChatGPT. The API_PREFERENCE workspaces, PHASE_1_TASKS (Amazon), and the GPT-4 vs Claude Evaluation project all contain this data — complete with the prompts, both model responses, and the human preference judgment. This data teaches models what humans actually want, which is the hardest and most expensive part of AI development.

RL rubrics and evaluation criteria — Before humans can judge model outputs, someone must define what good looks like. The CRITERIA, RUBRIC_VERSIONS, QA_SPECS, and LLM_CALL_CONFIGURATION tables across 60+ Airtable workspaces contain these rubrics. They encode the evaluation methodology itself — the scoring frameworks, the edge cases, the quality thresholds. This is proprietary intellectual property that defines how each AI lab measures progress. A competitor with access to these rubrics doesn't just get the training data — they get the recipe.

RL environments and Chain-of-Thought data — The AMAZON_LLM_COT_EVALUATION workspace contains full Chain-of-Thought traces — the step-by-step reasoning that models produce before giving a final answer. The ACADEMIC_REASONING_SFT workspace contains a COT table explicitly for reasoning supervision. The Panacea — Consulting RL Envs project built reinforcement learning environments. This data teaches models how to think, not just what to say.

Benchmark evaluation data — The ATHENA_HLE workspaces (likely Humanity's Last Exam) and AIME_RUBRICS (AIME math competition) contain evaluation data for some of the most important AI benchmarks. The MODEL_RESPONSES and AWAITING_REVIEW_METRICS tables contain graded model outputs against these benchmarks. If this data is used to train future models, it contaminates the benchmarks — the models will appear to perform better than they actually do, undermining the entire AI evaluation ecosystem.

Pre-release model outputs — The APPLE_ENDPOINT_SANDBOX workspace contains actual outputs from Apple's unreleased Foundation Models (afm-text-083, afm-model-086). These responses reveal the model's capabilities, limitations, safety alignment, and failure modes before Apple has publicly launched them. For a competitor, this is the equivalent of obtaining a rival's product prototype.

Why this data is so expensive to reproduce:

Each data point requires a skilled human — often a domain expert — spending minutes to hours crafting, evaluating, or comparing model outputs. At Mercor's reported average rate of $95/hour across 30,000+ contractors, the annual cost of data production runs into hundreds of millions of dollars. OpenAI, Anthropic, and the other labs have each spent years and billions of dollars building these datasets incrementally, refining their rubrics, and developing their evaluation methodologies.

The breach doesn't just expose data. It exposes the methodology — the rubrics, the evaluation criteria, the domain taxonomies, the quality control processes, and the scoring frameworks that each lab has spent years developing. Any competitor with access to this material — domestic or foreign — could replicate years of alignment research in months, at a fraction of the cost, by simply adopting the proven evaluation frameworks and training on the stolen preference data.

This is why Garry Tan called it "billions and billions of value." The data in these Airtable workspaces is not supplementary. It is the core competitive advantage of the AI labs that produced it — and it is now for sale.

The Extent - What Data Was Exposed ¶

The breadth of personally identifiable information (PII) in this breach is staggering. The following inventory documents every category of sensitive data present in the database dump, with specific column names, source tables, and — where available — the format of the exposed data as observed in sample records. This inventory is intended to serve as a factual reference for affected individuals, regulators, and legal counsel.

1. Personal Identity Information ¶

2. Government Identity Documents and Biometrics ¶

Note: The cloud storage buckets (mercor-background-check-photos, certn-api-s3-one-id-images, certn-api-s3-certn-rcmp-documents) reportedly contain the actual document images — passports, driver's licenses, and RCMP criminal record documents — referenced by these database records.

3. Financial and Banking Data ¶

The MercorUserFinancials.accountDetails field is particularly egregious — it stores the complete Stripe Connect API response as a JSON blob, which includes the contractor's full legal name, personal email, bank name, routing number, last four digits of the account, account holder name, country, currency, and TOS acceptance details. This is not a reference or a token — it is the raw financial identity of each contractor stored in a single database column.

4. Employment and Performance Records ¶

The MLExperimentsJobPerformanceReviews table is especially damaging: it contains the contractor's full name, email, client company name (e.g., OpenAI), project name, reviewer's name, quality score, engagement score, offboarding reason, and a free-text justification — all in a single row. Sample: A***** D****, a*****s@gmail.com, OpenAI, Apertus - Elephant, reviewed by A*** K*****, rated 4 - Redefines Expectations.

5. Criminal Background and Adverse Media Checks ¶

6. Work Authorization and Immigration Status ¶

Work authorization status is classified as sensitive personal data under GDPR and many state privacy laws. Its exposure, combined with physical location data and location mismatch fraud flags, could be used to identify individuals working from countries where they lack authorization — creating potential immigration enforcement risk.

7. Device Fingerprints, Network Identifiers and Surveillance Data ¶

The combination of IP address + MAC address + HWID creates a triple device fingerprint that uniquely identifies not just the person but the specific physical machine they used. Under GDPR, device fingerprints are explicitly classified as personal data. Under CCPA, unique device identifiers constitute personal information.

8. Fraud Profiling and Algorithmic Decision-Making ¶

Automated fraud decisions directly impacted individuals' ability to earn income through the platform. Under GDPR Article 22, individuals have the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects. The exposure of the complete fraud reasoning — including the LLM-generated explanations — reveals the inner workings of an automated decision-making system that determined whether people could work and earn money.

9. Communications and Third-Party PII ¶

The exposure of third-party PII is particularly significant for legal liability. UserReferences contains the names, email addresses, employers, and relationships of professional references — individuals who never created Mercor accounts and never consented to having their data stored in Mercor's production database. LinkedinWarmIntros contains LinkedIn URLs and emails of people contacted for recruitment outreach. These third parties had no contractual relationship with Mercor and no opportunity to consent to or opt out of data collection.

10. PostHog Behavioral Analytics De-Anonymized ¶

PostHog sessions are typically anonymous or pseudonymous. The PosthogAnalytics table explicitly links userEmail to session data — effectively de-anonymizing behavioral analytics and creating a personally identifiable record of how each contractor and company user navigated the platform.

Legal Significance of This PII Inventory ¶

Any single category above would trigger breach notification obligations under most privacy laws. The combination creates exposure across multiple overlapping regulatory regimes:

The exposed data supports claims for:

• Negligence — Failure to implement reasonable security measures for highly sensitive personal data
• Breach of contract — Violation of privacy commitments made to contractors in terms of service and privacy policies
• Breach of fiduciary duty — Mishandling of financial and identity data entrusted to Mercor as an employment intermediary
• Violations of specific statutes — BIPA (facial geometry scans from Persona KYC liveness detection), FCRA (background check data used in employment), CCPA (failure to maintain reasonable security), GDPR (multiple articles)
• Unjust enrichment — Mercor profited from collecting and processing this data without adequately protecting it
• Third-party claims — Professional references, LinkedIn contacts, and vouching parties whose data was collected without direct consent

The Scope - Who Is Affected ¶

The breach affects multiple distinct populations, each with different legal standing:

1. Contractors (Primary Class) — Every person who signed up, completed an interview, or performed work through Mercor has their full PII exposed: full legal name, personal email, phone number, date of birth, home address, government ID verification status, bank name and routing number, employment terms with exact pay rates, performance reviews with dismissal reasons, and in many cases desktop screenshots of their computer screens while working. The MercorUserFinancials table alone contains sufficient information for bank account fraud — the bank name, routing number, last four digits of account number, account holder name, and country are all stored in plaintext JSON.

2. Client Companies — Companies that hired through Mercor have their project names (including OpenAI, Apertus - Elephant), internal tooling references, billing details, hiring criteria, candidate evaluation notes, Slack workspace URLs, Okta SSO group configurations, and annotation platform URLs exposed. These include some of the most valuable and secretive AI organizations on the planet.

3. Mercor Employees — Internal staff are identifiable through the IacDeploymentRuns table (GitHub usernames as actor fields), CatfishAuditLog (Slack user IDs and real names), DATABASECHANGELOG (migration author names), MLExperimentsJobPerformanceReviews (reviewer names like A*** K*****), and the IAM table (users with ghost role assignments within client companies).

4. Third Parties Who Never Consented — Professional references (UserReferences) provided their name, email, employer, and relationship to the contractor. LinkedIn contacts (LinkedinWarmIntros) had their profile URLs and email addresses stored. Vouching parties (CandidateVouches) provided detailed relationship information. These individuals had no direct contractual relationship with Mercor, likely received no privacy notice, and had no opportunity to consent to or opt out of data collection. Their data was collected incidentally through the contractors they were associated with.

The Scale - Mercor Client Ecosystem ¶

What elevates this breach from a typical startup data leak to an industry-wide crisis is who Mercor's clients are.

Meta, OpenAI, and Google DeepMind are among Mercor's publicly known clients — as reported by the Wall Street Journal — but even our small sample reveals direct evidence of engagements with at least six major technology companies, plus numerous additional clients identifiable through project codenames and Airtable workspace names.

Confirmed Client Engagements Found in the Sample ¶

The sample file contains not just the production database tables but also an ./EXPORTS/ directory with full Airtable workspace dumps — organized by client name. These exports contain the actual work product: prompts, model responses, evaluation rubrics, and contractor submissions. The client names appear directly in the directory structure:

Airtable Workspace Inventory ¶

The sample file reveals 25+ distinct Airtable workspaces that were exported as part of the breach. Each workspace name follows a pattern that often includes the client name or project identifier. Beyond the named clients above, the Airtable exports include:

The ATHENA_HLE workspaces are particularly significant — "HLE" likely refers to Humanity's Last Exam, a high-profile AI benchmark designed to test frontier model capabilities. The MODEL_RESPONSES table in the rubrics workspace suggests Mercor contractors were grading AI model outputs against this benchmark, and the AWAITING_REVIEW_METRICS table indicates an active review pipeline. If this data reached adversarial actors, it could be used to game or contaminate one of the most important AI evaluation benchmarks.

The BEAR_MEDICINE workspace reveals medical domain annotation work with DISCIPLINES, REVIEWER_ASSESSMENT, and WRITER_DAILY_ACTIVITY tables — indicating Mercor contractors were creating or evaluating medical AI training data, adding healthcare data to the breach's sensitivity profile.

Evidence from Named Projects in the Database ¶

Beyond the Airtable exports, the production database tables contain additional project references:

The Magnificent Seven, Frontier AI Labs, and the Competitive Fallout ¶

Mercor is not a niche startup. According to Big Think and TechCrunch, Mercor has signed deals with six of the seven "Magnificent Seven" tech giants — Apple, Microsoft, Alphabet, Amazon, Meta, and Nvidia — plus frontier model developers OpenAI and Anthropic. The company employs over 30,000 contractors, pays an average rate of $95/hour, and reached a $500 million annual revenue run rate within 17 months of launch. It is valued at $10 billion.

This means the stolen data — the 211GB database, the 939GB of source code, the 3TB of cloud storage, and the 84 Airtable workspaces documented above — contains the operational records, AI training data, and work product for engagements touching nearly every major AI program in the Western world.

The small sample analyzed in this report already confirms direct evidence of work for Apple (Foundation Model outputs), Amazon (LLM Chain-of-Thought evaluation), OpenAI (Feather platform, Apertus project), Anthropic (Claude evaluation), and Meta (multimedia annotation templates). The full 211GB database — which we have not seen — would contain the complete records for all six Magnificent Seven clients plus the frontier labs.

The competitive implications are severe:

1. The training data itself is the prize. The leaked RLHF annotations, model evaluation data, and preference rankings produced by Mercor's contractors represent billions of dollars in training data investment. This data — now in the hands of Lapsus$ and available to any buyer — could be used by any competitor to accelerate their own model development without incurring the cost of generating it. As Y Combinator president Garry Tan noted: "Incredible amount of SOTA training data now just available to China thanks to @mercor_ai leak. Every major lab. Billions and billions of value."

2. Apple Foundation Model outputs are in the dump. The AIRTABLE_APPLE_ENDPOINT_SANDBOX workspace contains actual afm-text-083 and afm-model-086 model responses — pre-release Apple Intelligence outputs. These provide direct insight into Apple's model capabilities, safety alignment approach, and weaknesses before public release. Any competitor — whether a Silicon Valley rival or a lab in Beijing, London, or Tel Aviv — now has access to Apple's unreleased model behavior.

3. Amazon's Chain-of-Thought evaluation methodology is exposed. The AIRTABLE_AMAZON_LLM_COT_EVALUATION workspace reveals how Amazon evaluates LLM reasoning quality, including the full prompts, complete Chain-of-Thought traces, and preference rubrics. The methodology itself is as valuable as the data — it reveals what Amazon considers "good reasoning" and how they measure it.

4. The Anthropic/Claude evaluation data could inform adversarial attacks. The preference evaluation data comparing Claude 3.5 Sonnet against GPT-4 — including the exact prompts, response pairs, and preference reasoning — could be used to identify weaknesses in Claude's alignment or to train models that specifically exploit those weaknesses.

5. Mercor's global contractor base spans dozens of jurisdictions. With 30,000+ contractors across many countries, Mercor's database contains work authorization records, physical location data, and IP-based geolocation. The platform's fraud detection system flags contractors whose physical IP doesn't match their declared residence — meaning the database contains a map of which contractors may be working from undisclosed locations.

Beyond the companies confirmed in the data, multiple sources — including former Mercor employees — claim that Mercor also maintains engagements with Chinese AI laboratories, including companies developing frontier models that compete directly with the labs whose training data is now in the breach. If true, this means Mercor was a single point of compromise connecting competing labs on opposite sides of the global AI race, with training data, evaluation methodologies, model outputs, and contractor talent pools for all of them sitting in the same breached infrastructure.

Even setting aside the question of direct Chinese client relationships, the stolen data — RLHF annotations, preference rankings, model evaluation rubrics, and Chain-of-Thought traces produced for OpenAI, Anthropic, Apple, Amazon, Meta, and Google — is now available on the black market. Given that Lapsus$ is actively auctioning the data, this material will reach whoever is willing to pay for it.

The TaskDefinitions table also references autograder configurations using openai/gpt-4.1 and openai/gpt-5 as scoring models, and task rubrics include constraints like "LLMs other than ChatGPT are prohibited" — rules that only make sense when the work product is destined for a specific model vendor's training pipeline.

The scope of client engagements extends far beyond AI companies. The Airtable workspaces alone span legal, insurance, data science, mechanical engineering, medicine, academic research, and mathematics — suggesting Mercor's contractor workforce touches data and systems across a wide range of industries. Any attacker with access to the full dump could enumerate every active client engagement by cross-referencing the Company, Projects_Audit, ProjectIntegrations, Listings_New tables, and the complete Airtable export directory.

The Airtable Export - 84 Workspaces, 1055 Files ¶

A separate directory tree from the breach (EXPORTS/) reveals the full structure of the exfiltrated Airtable data. The export contains 84 unique Airtable workspaces totaling 1,055 JSONL files — each file containing the complete contents of one Airtable table. This is not a sample. It is the complete export of every Airtable base connected to Mercor's Fivetran data pipeline.

The directory structure reveals how Airtable sits at the center of Mercor's operation. It is used as:

1. The annotation task management system — Every domain-specific project has its own Airtable base with a standardized schema: TASKS, TASK_VERSIONS, CRITERIA, DOMAIN, SUBDOMAIN, TALENT, QA_SPECS, WORKFLOW, LLM_CALL_CONFIGURATION, CONTROL_PANEL, and FILES. This is a fully industrialized annotation pipeline.

2. The work product repository — Tables like PHASE_1_TASKS (Amazon), TEXT (Apple), PROMPTS/RESPONSES (API Preference), and MODEL_RESPONSES (Athena HLE) contain the actual task inputs and outputs — the prompts sent to AI models, the model responses, and the human evaluations. This is the training data itself.

3. The talent and compensation ledger — TALENT tables appear in nearly every workspace, tracking which contractors worked on which tasks. CALCULATED_BONUSES, BONUS_PAYOUTS, TIMELOG, and CLAIMS tables track compensation. WRITER_STATS, REVIEWER_STATS, and WRITER_DAILY_ACTIVITY tables (in BEAR_MEDICINE) track individual productivity.

4. The QA and audit system — QA_SPECS, LEAD_AUDIT_QA, DOUBLE_BLIND, and REVIEWER_ASSESSMENT tables track quality control processes.

The named workspaces can be organized into categories that reveal the full breadth of Mercor's operations:

Client-Named Workspaces (Direct Client Evidence):

APEX - Mercor's AI Benchmark Suite (Compromised):

The APEX_ prefix identifies Mercor's proprietary suite of AI benchmarks — domain-specific evaluation frameworks used to measure AI model performance across verticals. Each APEX benchmark has its own Airtable workspace with a standardized schema: TASKS, TASK_VERSIONS, CRITERIA, DOMAIN, SUBDOMAIN, QA_SPECS, WORKFLOW, LLM_CALL_CONFIGURATION, and CONTROL_PANEL. The complete APEX suite spans 15+ domains:

The exposure of the complete APEX benchmark suite — including all tasks, criteria, scoring rubrics, and LLM_CALL_CONFIGURATION — renders these benchmarks untrustworthy. Any AI model trained on the leaked APEX data will appear to perform well on these benchmarks without genuinely possessing the evaluated capabilities. This is benchmark contamination at scale. Unless Mercor rebuilds the entire APEX suite from scratch with new tasks, new criteria, and new evaluation data, every APEX benchmark result produced after this breach is suspect. The EVALS workspace — which contains APEX_RESULTS, BOREALIS_RESULTS, and LUCIUS_RESULTS — further confirms that APEX was actively used to evaluate and compare models, making the contamination risk concrete and immediate.

Other AI Benchmark and Evaluation Workspaces:

Medical Domain Workspaces:

Aircall Integration (complete phone system export):

The export also includes a full Aircall directory — Mercor's VoIP phone system — containing 27 tables: CALL, CALL_TRANSCRIPTION, CALL_TRANSCRIPTION_CONTENT_UTTERANCE, CALL_SENTIMENT, CALL_SENTIMENT_PARTICIPANT, CALL_SUMMARY, CALL_ACTION_ITEM, CALL_TAG, CALL_TOPIC, CONTACT, CONTACT_EMAIL, CONTACT_NUMBER, USERS, USER_AVAILABILITY, and more. This represents the complete call history including full transcriptions, sentiment analysis, AI-generated summaries, and contact information for every recruiter phone call.

What the Airtable Export Means:

The Airtable export transforms this breach from a database leak into a complete AI training data theft. The database tables documented in the rest of this article provide the metadata — who worked on what, when, and how much they were paid. The Airtable export contains the actual work product: every prompt, every model response, every human evaluation, every rubric score, every Chain-of-Thought trace, and every preference judgment that Mercor's contractors produced for Apple, Amazon, OpenAI, Anthropic, Meta, and dozens of other clients.

The iterative versioning visible in the workspace names (e.g., APEX_RUBRICS with 12+ dated copies from August 7, 2025 through January 23, 2026) reveals that this export captured the complete historical evolution of Mercor's benchmark and evaluation pipeline — not just a snapshot, but the full development history of rubrics, task definitions, and evaluation criteria across months of refinement. For the APEX benchmarks specifically, this means every iteration of every benchmark task is now public — an attacker can study how the benchmarks evolved and craft model training data that targets the final versions.

Customer and Third-Party Platform URLs Found in the Dump ¶

Beyond project codenames, the dump contains direct URLs to customer platforms, internal tools, and third-party services — embedded in configuration fields, JSON blobs, onboarding documents, and metadata columns across dozens of tables. An exhaustive search of the file reveals 1,800+ unique URLs. The most sensitive are catalogued below.

Client Annotation and Work Platforms ¶

These are URLs to the actual platforms where Mercor contractors perform work for clients. Each one identifies a specific client engagement and, in many cases, a specific campaign or task within that client's systems:

Mercor Internal Infrastructure URLs ¶

These URLs expose Mercor's own internal architecture, allowing an attacker to map the entire operational surface:

AWS S3 Buckets ¶

Each S3 bucket below contains files that are directly addressable via URL if the bucket permissions are misconfigured. The bucket names alone reveal the categories of stored data:

The S3 bucket kite-uhn-brain-injury is particularly alarming — it suggests that either Mercor or a client project involved handling protected medical records, and the bucket name alone leaks the nature of the data and the institution involved.

Google Workspace Documents ¶

The dump contains direct URLs to 30+ Google Docs, 2+ Google Sheets, 2+ Google Forms, and 10+ shared Google Drive folders used for project onboarding, task instructions, rubric definitions, and team coordination:

• docs.google.com/document/d/1111XpiZ9eZvH8X_... — Onboarding materials
• docs.google.com/document/d/1770ZnTy0_Yt-U-U7W... — Project documentation
• docs.google.com/spreadsheets/d/10LWCzAD1e-J8W7v... — Tracking spreadsheets
• docs.google.com/forms/d/e/1FAIpQLSdLnOJ9DZoq... — Assessment/intake forms
• drive.google.com/drive/folders/14eFptQgb2FjWoFh... — 10+ shared project folders

Many of these Google Docs likely remain live and accessible if the sharing permissions are set to "anyone with the link" — a common practice for contractor onboarding materials.

Communication and Collaboration Evidence ¶

What This URL Inventory Means ¶

An attacker with this data does not need to guess what Mercor's clients are or what systems contractors access. The URLs are already in the database. Specifically:

1. OpenAI's Feather platform URL with a campaign UUID gives an attacker a direct entry point to probe OpenAI's annotation infrastructure
2. S3 bucket names allow targeted enumeration attacks — checking whether buckets are publicly accessible or brute-forcing object keys based on the naming patterns visible in the dump
3. Google Docs and Drive folders may still be live and accessible if shared via link — giving an attacker access to project rubrics, onboarding materials, and task instructions
4. Slack workspace identifiers enable social engineering against teams working on specific projects
5. The ngrok tunnel URL embeds a developer's IPv6 address, adding another vector for targeting Mercor engineering staff
6. The AWS account ID (5557735*****) embedded in the S3 bucket name enables targeted cloud reconnaissance

The Screenshot Problem ¶

The most dangerous element of this breach is the Insightful time-tracking screenshot system — and the danger compounds with every client Mercor serves, every platform URL catalogued above, and every S3 bucket of screenshots that can be systematically correlated.

Mercor requires contractors to install the Insightful (formerly Workpuls) monitoring agent on their computers. This agent captures a screenshot of the contractor's desktop every few minutes while they are clocked in. Each screenshot is uploaded to mercor-insightful-screenshots-production.s3.amazonaws.com and indexed in the InsightfulScreenshots table with rich metadata:

• The full screenshot image (stored at a direct, addressable S3 URL — e.g., https://mercor-insightful-screenshots-production.s3.amazonaws.com/screenshots/[employeeId]/[timestamp]_[uuid].png)
• The application open at the time (appName, appFileName, appFilePath)
• The window title (which often contains document names, code file paths, or chat conversations)
• The browser URL being visited (which can include feather.openai.com, client Airtable workspaces, or any of the platform URLs catalogued above)
• The contractor's IP address, MAC address (via gateways), and hardware fingerprint (hwid)
• The contractor's timezone, OS version, and Insightful agent version

A sample screenshot record from the dump shows a contractor working in Google Chrome on alabaster-studio.com/project/abacus/conversation/... — with their IP (71.194.*.*), MAC address (1C:93:7C:64:**:**), hardware ID, and full filesystem path to Chrome all recorded.

Here is why this is catastrophic in context:

The database contains all the ingredients for a systematic visual intelligence operation. An attacker can join tables to correlate screenshots with client projects and platform URLs:

1. Which client project a contractor was assigned to (from ProjectIAM and Jobs)
2. Which annotation platform that project uses (from Projects_Audit.annotationPlatform — e.g., feather.openai.com, specific Airtable workspace IDs)
3. Every screenshot taken while the contractor worked on that project (from InsightfulScreenshots filtered by contractorId and projectId)
4. The exact URLs, window titles, and application contents visible in those screenshots — cross-referenced against the known client platform URLs to confirm which client's systems are shown

This means an attacker doesn't just get a list of Mercor's clients — they get a visual archive of what contractors saw inside those clients' systems. If the project was for OpenAI, the screenshots show OpenAI's Feather annotation interface, the prompts being graded, and the evaluation criteria. If the project was for Meta, the screenshots show Meta's internal tooling. If the project involved reinforcement learning environments, the screenshots show the RL training data and reward models.

The scope of what these screenshots can reveal includes:

• Proprietary client code and architecture visible in IDE windows, terminal sessions, and browser tabs
• Annotation platform interfaces showing the exact tasks, rubrics, and datasets used to train frontier AI models
• Internal Slack channels and email threads visible in background windows — the ProjectIntegrations table confirms contractors are added to client Slack workspaces (project-mega.slack.com, mercor.enterprise.slack.com)
• Authentication tokens, API keys, and session cookies potentially visible in browser URL bars, developer tools, or terminal output
• Unreleased product features, research results, and trade secrets visible in dashboards or documents
• Other contractors' work and personal information if collaborative tools were open on screen

Perhaps most critically, the screenshots create an involuntary record of contractor misconduct. As the Wall Street Journal has reported on the growing concerns around AI training data supply chains, contractors in these roles often have privileged access to sensitive client systems. If any contractor was engaged in unauthorized data exfiltration — copying proprietary datasets, screenshotting confidential research, leaking model weights, or otherwise violating their employment agreements — that activity was captured frame by frame by the monitoring system and is now available to anyone with the dump.

The monitoring system that was designed to protect Mercor's clients has become a comprehensive, timestamped, visually indexed archive of everything those clients wanted to keep secret.

This creates a cascading breach. Mercor's data exposure is not just a breach of Mercor — it is a proxy breach of every client organization whose internal systems, annotation platforms, Slack workspaces, and proprietary tooling were visible on a contractor's screen during monitored work sessions. The number of indirectly breached organizations equals the number of clients Mercor has ever served.

Platform Overview ¶

Mercor presents itself publicly as an AI-powered hiring platform. The database tells a more complete story: it is a full-stack labor marketplace and employment management system that spans acquisition, vetting, matching, contracting, surveillance, and payment.

The platform operates across at least three distinct product surfaces:

1. Talent Portal — Where contractors create profiles, complete interviews, apply to listings, and track their work
2. Company Portal — Where client companies post listings, review candidates, manage projects, and receive invoices
3. Godmode / Internal Admin — An internal dashboard (GodmodeCompanies, GodmodeArbitraryCells) used by Mercor staff for operations

The backend is a microservices architecture with at least 13 named services: coil, site_fe, team_fe, work_fe, mercor_go, mercor_api, mercor_api_nginx, celery, workflow, db_trigger_consumer, steve, woz, and payments_temporal_worker. These are deployed on AWS ECS and managed via Terraform/Terragrunt in the mercor-monorepo GitHub repository.

The primary database is Aurora MySQL (AWS), with the analytics warehouse being Snowflake (evidenced by dbt model tables like DbtFirmSchoolRank and DbtSchoolRankings). Schema migrations are managed by Liquibase (evidenced by DATABASECHANGELOG and DATABASECHANGELOGLOCK tables).

Evidence - The Database Layer by Layer ¶

The following sections present a systematic walk through every domain of the exposed database, with obfuscated sample records drawn directly from the dump. This is the evidence base for the claims made above.

Part I - User and Identity Layer ¶

The Contractor Profile ¶

At the core of Mercor's data model is the contractor. The MercorUsers_New table stores the primary user record, while MercorUsers_New_backup appears to be a historical snapshot. A sample (obfuscated):

The insightfulId field is particularly significant — it links this user to their Insightful (formerly Workpuls) monitoring agent, meaning every screenshot taken of this person while working is tied to this identifier.

The MercorUsers_New table extends the backup with additional fields: phoneVerificationStatus, phoneVerifiedAt, phoneOptIn — indicating ongoing additions to the user data model. The authType field suggests support for multiple authentication providers (Firebase, Google OAuth, email/password).

Location and Residence Data ¶

UserLocation stores both declared residence and physical presence:

The distinction between residence and physical country is central to Mercor's fraud detection logic — a mismatch between declared location and actual IP-derived location is one of the primary fraud signals.

UserMetadata enriches the contractor record with:

• workAuthorizationStatus — eligibility to work in specific countries
• birthday — date of birth
• physicalLocation — freeform address field
• contractorMail — a Mercor-provisioned email address (e.g., @mercor.com)
• oktaUserId / oktaAccountState — SSO integration
• maxContracts — cap on concurrent engagements
• fraudStatusEnum — a denormalized fraud verdict

UserAvailability_Audit captures declared working hours: maxWeeklyHours, desiredWeeklyHours, expectedStartOffset, and timezone — allowing Mercor to understand contractor bandwidth and scheduling preferences.

Referral and Social Vouching ¶

CandidateVouches is a comprehensive social trust mechanism. When a voucher endorses a candidate, they fill out a structured questionnaire:

• How did you know this person? (social platforms, working together, studying together, other)
• Why are they qualified? (skills, education, employer, expertise, other)

Each field has a paired *Detail text field. This creates a rich graph of professional and social relationships.

UserReferences stores professional references with names, companies, relationships, and contact emails — conventional hiring data now sitting in an exposed database.

UserState tracks lifecycle metrics: resumeUploaded, interviewsCompletedCount, jobApplicationsCount, totalMillisWorked.

Part II - Identity Verification and Fraud Detection ¶

The KYC Layer ¶

Mercor uses Persona as its identity verification provider. The IDVerificationChecks table records each check with:

• provider: persona
• source: e.g., interview-face-comparison
• sessionId: the Persona interview session token
• verificationStatus, governmentIdStatus, livenessStatus, addressStatus
• fraudDecision: NULL / escalated / approved
• providerResponse: full JSON blob from Persona's API

A sample Persona response shows:

{
  "type": "baseline",
  "interview_id": "intr_AAABnNOWs0wnj7Tmg0hBQpL5",
  "thumbnail_key": "intr_AAABnNOWs0wnj7Tmg0hBQpL5_thumbnail.jpg",
  "persona_account_id": "act_QMTuQh33A4QU23J8ECPSd32BBKb4"
}

The thumbnail key references a stored facial image from the verification session.

BackgroundCheck and BackgroundCheck_New record criminal background and adverse media checks (via Checkr or Certn):

ScreeningPackage defines what checks are bundled per company engagement, including checkConfig (JSON with individual check types) and graceDays (how many days a contractor has to complete checks before being blocked).

The Fraud Pipeline ¶

Mercor operates a multi-stage fraud pipeline that is one of the most sophisticated components in the database. It runs at four stages: profile, interview, post-interview, and on-project.

FraudStates — The current fraud verdict per user, maintained as a state machine:

The reasoning field contains LLM-generated natural language explanations — almost certainly from Vertex AI / Gemini based on the signal schema.

FraudCheck — The central fraud queue:

• stage, interviewId, jobId — context of the check
• process_status, retryCount — pipeline execution state
• flag_reasons, automatedReasons, manual_review_rational, manual_review_signs
• assigned_to, assigned_on — human reviewer assignment
• splReview — special review flag

FraudSignalAuditLog — Every individual signal evaluated:

• signalType — e.g., location_mismatch, email_is_pwned, vpn_detected
• modelName — which ML model produced the score
• modelScore — numeric confidence
• status — accepted / rejected

FraudEvents — Bayesian belief updates per event:

• priorAlpha, priorBeta, priorProbability, priorStatus
• posteriorAlpha, posteriorBeta, posteriorProbability, posteriorStatus
• evidence — JSON describing what caused the update

This is a textbook Beta-Binomial Bayesian fraud model — prior beliefs updated with evidence to produce posterior fraud probability estimates.

ProductionFraudState — Final fraud disposition:

• fraudModality — type of fraud (identity, time, quality)
• source — automated / manual
• productionModelId — versioned model that made the call

OnProjectFraudWindows — Time-based on-project fraud analysis:

• fraudType, flags, flagMetadata, windowMetadata, screenshotMetadata
• Analyzes patterns within work sessions using screenshot data

CheatingDetection / CheatingDetection_Audit — Interview cheating detection:

• isCheating, cheatingProbability, signs
• Tracks whether candidates used external resources during AI interviews

QAReviewLog — Manual fraud review outcomes:

• stage, signalType, decision, comments
• Assigned to specific reviewerId for human-in-the-loop adjudication

AutoFraudChecks — Automated rule-based checks triggered on a schedule or event.

DuplicateGroups — Groups of user IDs believed to be the same person (userIdList), with merge tracking (mergedIntoGroupId).

Part III - The Hiring Pipeline ¶

Listings ¶

Listings_New is the job posting table. A Mercor listing is considerably more structured than a typical job board entry:

EvaluationCriteria stores the per-listing scoring rubric used during candidate ranking — each criterion has shortCriteria, type (hard filter or soft score), hardFilter boolean, and position for display ordering.

ListingNotes stores internal recruiter notes per listing — including candid operational commentary. A sample (obfuscated):

"33 leads confirmed on sheet by B***** to send offers — @N*** to staff RM for conversion"*

This reveals that Mercor staff are managing candidate pipelines directly, with named individuals responsible for conversions.

Candidates ¶

Candidates / Candidates_Audit tracks every application:

CandidateMatchScores provides ML-generated match scores:

• matchScore — numeric compatibility score
• contextualSummary — LLM-generated natural language explanation of why this candidate fits this listing

MercorScores stores the tournament-based ranking scores:

• mScoreRaw / mScoreNormalized — the MercorScore
• numComparisons — how many pairwise comparisons informed the score
• contextualSummary — LLM narrative on the candidate's standing
• aggregateFeatureScore — combined feature vector score

PairwiseComparisons stores individual A/B comparisons:

• winnerResumeId / loserResumeId
• winnerUserId / loserUserId
• reasoning — LLM explanation of why candidate A beat candidate B

This implements a Bradley-Terry tournament ranking model — candidates are repeatedly compared in pairs, with each comparison updating relative ranking scores.

TalentViewSearchUsers and SharableTalentViewConfig enable companies to create saved talent searches and share curated candidate shortlists with colleagues. SharableTalentViewConfigUsers adds per-candidate evaluation data including likeCount, dislikeCount, and free-text feedback.

Part IV - Interviews and Assessments ¶

AI Interview System ¶

Mercor's interview process is AI-conducted and rubric-graded. The Forms_Audit table reveals the full interview configuration:

• items — JSON array of interview questions
• evaluationCriteria — per-question scoring criteria
• assessmentRubricId — linked rubric
• allowCopyPaste — flag to restrict copy-paste (cheating prevention)
• allowFormRetakes / maxRetakeAttempts — retry policy
• prep — pre-interview preparation materials shown to candidate
• feedbackConfig — how/whether to share scoring feedback

AssessmentRubrics defines the grading framework:

• title, instructions — rubric metadata
• sumScores, sumSquareScores, countScores — aggregate statistics across all uses of this rubric
• passThreshold — minimum score to pass

AssessmentRubricItems_Audit stores individual rubric criteria:

• criteria — the evaluation criterion text
• shortName — abbreviated label
• points — maximum points
• format — scoring format (binary, scale, etc.)
• webSearch — whether web search context is provided to the grader
• smartScoring — whether AI auto-scoring is enabled
• type — criterion type

FormSubmissions records every interview submission:

• responseStatus — submitted / abandoned / in_progress
• activeTimeSeconds — actual time spent on the form
• posthogSessionIds — linked PostHog analytics session
• assessmentVersionId — which version of the assessment was taken

AssessmentEvalState tracks the grading pipeline:

• assessmentType, jobType, status
• retryCount, reason
• triggerSource, triggeredByUserId
• durationMs — how long grading took

InterviewEvals stores scored results:

• communicationScore, technicalScore
• qaPairScores — per question-answer pair scores

InterviewIssues records reported problems during interviews:

• issue — issue type (technical problem, suspected cheating, content issue)
• source — who reported it (candidate, system, reviewer)
• startPosition / endPosition — timestamp positions within the interview
• reportedBy — user ID of reporter

InterviewScores provides the final aggregate score per interview.

Part V - Work Trials and Onboarding ¶

Work Trial Contracts ¶

WorkTrial_Audit captures the structured trial engagement contract:

The presence of offerLetter and signature fields indicates that signed legal documents are stored directly in the production database.

WorkTrialConfig defines reusable work trial templates per company:

• emailTemplateSubject / emailTemplateBody — invitation email content
• emailTemplateSubjectExtension / emailTemplateBodyExtension — offer extension emails
• interviewIds, formIds — prerequisite steps before trial activation
• isUnified — whether trial is shared across listings

Onboarding Pipeline ¶

OnboardingState defines the onboarding funnel steps:

OnboardingDocument stores the per-project onboarding materials (links, instructions, or document content) shown to newly hired contractors.

TierProgress tracks contractor progress through Mercor's internal tier/certification system — mapping contractors to planId, tierId, status, and completedAt.

PlanAssignments assigns contractors to specific plans with defined startDate, endDate, userHours allocation, and tasksCompleted tracking.

Part VI - Projects and AI Task Management ¶

Project Structure ¶

Projects_Audit reveals the full project configuration:

ProjectIAM / ProjectIAM_Audit defines role-based access: each record maps a userId to a roleId within a projectId, with status and assignedBy for audit purposes.

ProjectIntegrations is particularly revealing — it links each project to:

• oktaGroupId / oktaOwnerGroupId / oktaEPMGroupId — Okta SSO groups
• googleGroupId — Google Workspace group
• slackChannelId / workspaceNotificationChannel — Slack notification channels
• projectShortId — human-readable project identifier

This table effectively maps every production project to its Slack workspace and Okta group, providing a complete picture of Mercor's organizational structure.

AI Task System ¶

TaskDefinitions / TaskDefinitions_Audit define the structure of AI training tasks:

TaskAudits records individual task submissions for review:

TaskAssignments maps tasks to specific jobs and users, with appliedBy tracking who made the assignment.

DeliverableBatches groups deliverables for invoicing:

• uid, name — batch identifier
• invoiceLineItemId — linked invoice line
• taskCount, status
• metadata — additional batch configuration

ProjectCustomColumns adds arbitrary metadata fields to projects, with sqlQuery indicating some columns are dynamically computed from database queries. ProjectCustomColumnValueHistory tracks changes to these values over time.

ProjectArchetypes stores character/role descriptions for specific project types — suggesting Mercor operates AI roleplay or persona-based annotation tasks (archetypeText, elements).

ProductivityProjectRules defines per-project productivity monitoring rules (rules JSON, is_active, versioned).

Part VII - Time Tracking and Productivity Surveillance ¶

The Insightful Integration ¶

This is the most invasive component of the exposed data. Mercor uses Insightful (formerly Workpuls) — a workforce monitoring agent installed on contractors' computers — to capture screenshots and activity data.

InsightfulScreenshots — Every screenshot record contains:

Every screenshot includes the contractor's IP address, MAC address (gateway), hardware fingerprint, operating system, the exact application open, the window title, and the URL being visited — all timestamped to the millisecond.

The storageUrl field contains direct S3 URLs to screenshot image files. The S3 bucket mercor-insightful-screenshots-production is referenced explicitly.

The hwid (hardware ID) field provides a persistent device fingerprint that can re-identify a contractor even if they change their email or create a new account.

Timelog ¶

Timelog / Timelog_Audit records every work session:

Deductions ¶

Deductions records time deducted from pay:

This reveals that Mercor can and does subtract pay from contractors based on monitored activity, with an approval workflow for doing so.

Part VIII - Payments and Financial Infrastructure ¶

Contractor Payment Methods ¶

UserPaymentMethods / UserPaymentMethods_Audit stores linked payment accounts:

US contractors use Stripe Express accounts. International contractors use Wise (evidenced by WiseDisbursements). The metadata field includes context like "context": "backfill" — indicating historical payment method imports.

MercorUserFinancials stores additional financial account details:

• paymentProvider — stripe / wise
• providerIdentifier — account identifier
• accountDetails — JSON with bank routing and account details
• lastFetchedOn — when the financial data was last synced

Payment Line Items ¶

PaymentLineItems is the core payment ledger:

PayoutCycles defines payment periods:

• cycleStartTs / cycleEndTs — date boundaries
• status — open / processing / completed
• configId / configVersion — which payout configuration governs this cycle

PayoutConfigs stores payout rules:

• type — payment cadence (daily, weekly, etc.)
• configuration — JSON with limits, caps, and routing rules

MoneyOut_Audit records every outbound payment:

• externalAccountId — contractor's Stripe or Wise account
• externalTransferId — transfer ID at the payment provider
• totalAmount — disbursed amount
• paymentMethod — stripe / wise
• status — pending / paid / failed
• failureReason — structured failure code

WiseDisbursements records international transfers:

• wiseTransferId, wiseQuoteId — Wise API identifiers
• amount, currency
• sequenceNumber — ordering within a batch
• status, failureReason

Company Billing ¶

BillingAccounts manages company-side billing:

• Multiple billing accounts per company
• Linked to Stripe customer IDs

BillingConfigs defines billing rules:

• rules JSON — markup percentages, caps, billing model
• isLatestVersion — versioned configuration

BillingRateCards defines per-contract rate structures:

• formulaType — e.g., markup_percentage, flat_rate
• rateRows — tiered rate table

InvoiceLineItems records invoice line entries:

• rawAmount / adjustedAmount — pre- and post-adjustment amounts
• taskCount — number of tasks in this line
• sowId — Statement of Work identifier

RevenueAdjustments records revenue corrections:

• amountCentsUsd, category, reason
• revenueRecognitionDate — accounting date
• formula, labels, aggregationFields
• attachments, invoices — supporting documentation

Referral System ¶

Referrals / Referrals_Audit tracks the contractor referral program:

ReferralEligibility manages the conditions under which referral payments vest — including onboardingStateId requirements and criteriaId checks.

GuaranteedReferralQuota manages quota-based guaranteed referral programs:

• quotaId, referringUserId, offPlatformUserId
• shortenedLink — the referral tracking URL
• weekStart, status

Part IX - Communications and Outreach ¶

Internal Messaging ¶

Comms is the platform messaging table:

CommsSent records delivery tracking — when messages were sent, to whom, via what channel.

EmailTemplates stores company-specific email templates:

• subject, content — template body
• isGlobal — available to all companies
• isPersonal — creator-private
• tags — categorization

External Outreach ¶

LinkedinWarmIntros manages LinkedIn outreach campaigns:

OffPlatformCampaigns and OffPlatformCampaignSteps manage multi-step email/LinkedIn outreach sequences:

• campaignType — category
• stepNumber — sequence position
• subject / messageTemplate — email content with template variables
• scheduledAt — send time
• outreachedCandidateIds / failedCandidateIds — delivery tracking

AircallComms records phone call logs from Mercor's Aircall integration — the VoIP platform used for recruiter outbound calls, with call metadata and outcomes.

FirstTimeInvites tracks first-contact outreach to candidates:

• commEvent — invitation type
• contentType / subject — message details
• listingIdCount — how many listings the invite covers
• refListingUid — the originating listing

Notification Infrastructure ¶

AutomationTemplates defines automated workflow triggers:

• handler — which service handles this automation
• sourceType / sourceSql — SQL query that triggers the automation
• templateBody — notification content template
• cron — scheduled execution
• autoApprove — whether human approval is required
• triggerConfig, config — detailed trigger configuration

ProjectAutomations links automation templates to specific projects.

Reverse Engineering - Architecture and Infrastructure ¶

The database schema, table names, column conventions, and embedded metadata allow us to reverse-engineer Mercor's complete technical architecture — from microservice names to third-party integrations — purely from the contents of this dump.

Part X - Infrastructure and DevOps ¶

Deployment Pipeline ¶

IacDeploymentRuns is one of the most operationally sensitive tables:

This table exposes:

• The full URL path to the private GitHub monorepo
• Individual engineer GitHub usernames (actors)
• Branch naming conventions
• Terraform variable names and deprecated configurations
• Number of AWS resources created/modified/destroyed per deployment
• Complete Terraform plan output in summary

Named Terraform service stacks include: talent-success-coil, referrals-coil, iac/aws/envs/staging.

ProductionDeployment records ECS production releases:

• releaseTag — semantic version tag
• buildHash — Docker image hash
• deployedAt — deployment timestamp
• deploymentIds — ECS deployment identifiers
• taskDefinitionArns — ECS task definition ARNs (include AWS account ID)

PreprodDeployment records pre-production (staging) releases:

• commitSha — exact commit deployed
• loadTestPassed — whether load testing passed
• releaseOwner — engineer responsible for the release

ProductionVersion maintains a single-row current version pointer:

• lastVersion, lastReleaseTag, lastBuildHash, updatedAt

RollbackExecution records emergency rollback events:

• services — which microservices were rolled back
• Details of 4-second rollback capability observed in the data

Database Schema Management ¶

DATABASECHANGELOG and DATABASECHANGELOGLOCK are Liquibase tables that record every schema migration:

• ID, AUTHOR, FILENAME, DATEEXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, LIQUIBASE

These tables reveal the full history of schema changes, including the names of engineers who authored migrations, the migration scripts' filenames (revealing internal project structure), and the exact timestamp each change was applied to production.

Agent Sandboxes ¶

AgentSandboxes records AI coding agent sessions:

The sandboxToken field suggests that expired sandbox tokens are persisted in the database — a potential credential exposure if these tokens have long validity windows.

Part XI - Analytics and ML Layer ¶

School and Firm Rankings ¶

DbtFirmSchoolRank contains Mercor's proprietary employer prestige scores:

This table represents a proprietary ranking of ~154,000 firms by the average educational prestige of their employees — effectively a derived signal used to score resumes. It is computed from the full contractor profile database using an empirical Bayesian model (ebPriorStrength, ebAvgSchoolRank).

DbtSchoolRankings ranks individual schools within academic fields:

• schoolName, academicField, schoolScore, schoolRank

Resume Evaluation ¶

UserResumeEvaluation stores ML-generated resume scores:

Behavioral Analytics ¶

PosthogAnalytics links PostHog behavioral sessions to user identity:

• userEmail — email address (PII)
• company — company context
• startTimeUtc / endTimeUtc — session boundaries
• activetime / inactivetime — engagement metrics
• startUrl — entry point URL

This directly links PostHog analytics sessions (which include click-level behavior) to user identity — a significant privacy concern as PostHog sessions are typically anonymized.

SearchAnalytics records search quality metrics:

• avg_relevance_score, avg_prestige_score
• p99_latency_ms — 99th percentile search latency
• position_weighted_relevance_score — ranking quality metric

ForecastMetrics stores ML forecast outputs:

• entity, id, dt, snapshot_dt
• modelVersion, predictedValue

Used for capacity planning, fill rate forecasting, and contractor supply predictions.

ML Experiments ¶

MLExperimentsJobPerformanceReviews reveals the experimental ML pipeline:

This table contains raw performance review data used to train or evaluate ML models for automated contractor performance assessment — with staff names, contractor names, and qualitative judgments all stored in plaintext.

Part XII - Reference Data Layer ¶

Skills and Certifications ¶

Skills is the platform's skills taxonomy:

• skillId, name, description, type, parent — hierarchical skill tree
• CertificationPolicy — linked certification requirement

CertificationPolicies_Audit defines the rules for earning certifications:

• rules — JSON eligibility criteria
• isRevokable, requiresApproval
• icon, iconColor, showBadge, displayText — display configuration

Certifications_Audit records individual earned certifications:

• evidence — JSON array of qualifying events (e.g., {"id": "proj_...", "score": 88.84, "sourceType": "project_hours_worked"})
• status — AUTO_AWARDED / MANUALLY_AWARDED / REVOKED
• isCertified — current state

SkillCertifications_Audit and SkillCertificationsEvidence_Audit track per-skill certification with scores and source evidence.

ContractorEndorsements stores peer endorsements:

• endorsingUserId / endorsedUserId
• contents — endorsement text
• tags — skills endorsed
• sentiment — positive/negative
• source — where the endorsement originated

Company Data ¶

Company stores client company records:

• name, description, website, logo
• billingModel — pricing structure
• billingStartDay / billingEndDay — billing cycle configuration
• brandVisible — whether company name is shown to candidates
• universe — internal company segmentation
• externalName — display name if different from legal name

IAM / IAM_Audit manages company-level role assignments:

• roleId — e.g., ghost (internal Mercor staff), admin, member
• companyId, userId_v4, status

A sample IAM record shows a user with roleId: ghost being REMOVED from a company — revealing Mercor's internal staff operated within client company contexts under a ghost role identity.

URL Management ¶

ShortenedUrls manages the platform's link shortening system:

• Used for referral tracking, campaign links, and onboarding flows

UrlClicks records every click on shortened URLs:

• urlId, clickedAt, ipHash, userId, country

Even with ipHash (rather than raw IP), the combination of userId, country, and timestamp enables click attribution across the contractor population.

Catfish Audit Log ¶

CatfishAuditLog is a security/compliance tool:

This table records every time an internal Mercor employee looks up a user's information through an internal tool called "Catfish" — indicating awareness that internal user lookup is an auditable, privacy-sensitive operation. Ironically, this audit log itself now sits in the exposed dataset.

Exposed Surface Area Summary ¶

Technical Architecture Reverse-Engineered ¶

The following architecture is entirely reconstructed from database table names, column values, JSON blobs, and embedded metadata. No source code or documentation was available — everything below was inferred from the data alone.

Backend Services ¶

Based on the database content, Mercor's backend comprises at least 13 microservices:

Frontend Portals ¶

• Public site — site_fe, routes handled by Next.js (inferred from URL patterns)
• Company portal — team_fe — for clients to manage listings and review candidates
• Work portal — work_fe — for contractors to find and complete tasks
• Internal admin — Godmode interface used by Mercor staff

Data Infrastructure ¶

• Primary DB: Aurora MySQL (AWS)
• Analytics warehouse: Snowflake (via Fivetran sync, evidenced by dbt models)
• Schema migrations: Liquibase
• Object storage: S3 (screenshots, offer letters, transcripts)
• Monitoring: Insightful agent on contractor machines
• Auth: Firebase + Okta (SSO)
• Analytics: PostHog
• Feature flags / A-B: Inferred from configVersion patterns

Third-Party Integration ¶

Grounds for Legal Action ¶

The evidence documented throughout this report supports multiple independent legal claims by distinct plaintiff classes. This section consolidates the factual basis for each claim, cross-referencing the specific database tables, column names, and sample values that constitute the evidentiary foundation.

I. Client Company Claims - Loss of Proprietary AI Training Data and Trade Secrets ¶

This is the most consequential category of legal exposure. Mercor's client companies — Apple, Amazon, OpenAI, Anthropic, Meta, Google, and others — entrusted Mercor with their most valuable competitive assets: the data, methodologies, and evaluation frameworks that define how their AI models are built. All of it is now in criminal hands.

A. Trade Secret Misappropriation

Under the federal Defend Trade Secrets Act (DTSA) and state Uniform Trade Secrets Acts, a trade secret is information that derives economic value from not being generally known and is subject to reasonable efforts to maintain its secrecy. The breach exposes client trade secrets across three categories:

1. AI Training Data as Trade Secrets. The SFT data, RLHF preference rankings, and Chain-of-Thought traces produced by Mercor's contractors for each client constitute trade secrets. Each dataset represents millions of dollars of investment and years of iterative refinement. The TASKS, TASK_VERSIONS, and PHASE_1_TASKS tables across 84 Airtable workspaces contain the actual work product — prompts, model responses, and human evaluations — that each client paid to produce. Their value derives entirely from secrecy: once a competitor has access to another lab's RLHF preference data, they can train equivalent alignment without the cost.

2. Evaluation Methodology as Trade Secrets. How an AI lab evaluates its models — what rubrics it uses, what scoring thresholds it applies, how it structures domain-specific benchmarks — is core intellectual property. The CRITERIA, RUBRIC_VERSIONS, QA_SPECS, and LLM_CALL_CONFIGURATION tables across 60+ workspaces expose this methodology in full. Amazon's Chain-of-Thought evaluation framework, Apple's endpoint testing rubrics, and the cross-model preference evaluation criteria are all now available to any buyer. This is not just data — it is the recipe for how each lab measures AI progress.

3. Pre-Release Model Capabilities as Trade Secrets. The APPLE_ENDPOINT_SANDBOX workspace contains actual outputs from Apple's unreleased Foundation Models (afm-text-083, afm-model-086). These responses reveal the model's capabilities, safety alignment, and failure modes before public launch. Under trade secret law, the unauthorized disclosure of pre-release product capabilities is a textbook misappropriation.

Key legal point: Trade secret protection requires "reasonable efforts to maintain secrecy." Mercor's storage of this data — in plaintext, behind a flat network with no segmentation, accessible via a single VPN hop — likely fails this standard. Clients may argue that they maintained secrecy on their end but that Mercor's negligent security destroyed the trade secret status of the data. This creates a damages claim for the full economic value of the lost trade secrets.

B. Breach of Confidentiality and NDA Violations

The database confirms confidentiality agreements governed the relationship. The Jobs table contains ciiaa_direct, ciiaaPassthrough, confidentiality, and tow (terms of work) fields. The WorkTrial_Audit table contains signed CIIAs and offer letters. The exposure of:

• Apple: Foundation Model outputs (afm-text-083, afm-model-086), endpoint sandbox testing data, translation evaluation, orchestrator configurations
• Amazon: Complete LLM Chain-of-Thought evaluation framework with full reasoning traces, preference judgments, domain taxonomy (math, STEM), and named Mercor staff assignments
• OpenAI: Feather platform campaign UUIDs, Apertus - Elephant project data, contractor performance reviews naming OpenAI as the account
• Meta: Multimedia annotation template command center (AAIE___META_MULTIMEDIA_TEMPLATE), project configurations
• Anthropic: Claude 3.5 Sonnet evaluation data compared against GPT-4, preference reasoning, agent sandbox configurations running Claude

constitutes a breach of these confidentiality obligations. Each client has a separate breach of contract claim with damages measured by the economic harm caused by the disclosure.

C. Loss of Competitive Advantage

The breach doesn't just expose data — it destroys competitive moats. If a Chinese AI lab purchases the stolen data, they acquire:

• The exact prompts and rubrics that OpenAI uses to fine-tune its models
• The evaluation methodology that Amazon uses to measure Chain-of-Thought reasoning quality
• Apple's pre-release model outputs revealing capabilities and weaknesses
• The preference data that teaches Anthropic's Claude how to respond to contentious queries

Each client's AI training pipeline is now potentially replicable by any competitor with access to the stolen Airtable workspaces. The damages extend beyond the cost of producing the data — they include the competitive harm of having that data available to rivals.

D. Secondary Breach via Desktop Screenshots

The InsightfulScreenshots table creates a mechanism for visual intelligence extraction from client systems. Screenshots captured during monitored work sessions show whatever was on the contractor's screen — client internal dashboards, Slack conversations, code repositories, proprietary tools, unreleased product interfaces. Mercor stored these screenshots on S3 with metadata linking each image to the specific projectId. An attacker can systematically extract visual intelligence about every client's internal systems by filtering screenshots by project. This constitutes a secondary breach of each client's confidential systems, for which Mercor bears direct liability.

E. APEX Benchmark Contamination

Mercor's proprietary APEX benchmark suite — covering 15+ domains from legal to medicine to mechanical engineering — is now compromised. All tasks, criteria, scoring rubrics, and evaluation data are exposed. Any client that relied on APEX benchmark results for vendor selection, model comparison, or procurement decisions now faces the risk that those results are unreliable. Models trained on the leaked APEX data will appear to perform well without genuinely possessing the evaluated capabilities. Clients may claim damages for decisions made in reliance on benchmarks that are now contaminated.

II. Contractor Class Claims ¶

A. Financial Data Exposure and Identity Theft Risk

The MercorUserFinancials table stores the complete Stripe Connect API response as plaintext JSON — including bank name, routing number, last four digits, account holder name, email, and country. This is sufficient for bank account fraud. Every contractor whose financial data is in this table faces ongoing risk of unauthorized transactions, account takeover, and identity theft. The UserPaymentMethods table adds Stripe Express account IDs and Wise transfer identifiers. The exposure of this data — unencrypted, untokenized, in a database accessible via a single VPN hop — constitutes negligence per se under multiple state data breach statutes.

B. Surveillance Overreach and Privacy Violations

The Insightful monitoring system captured far more than work activity:

• Full desktop screenshots every few minutes — not just the work application, but everything on screen
• Browser URLs for all tabs, including personal browsing
• IP addresses and MAC addresses from personal home networks
• Hardware fingerprints of personal devices

Contractors used personal computers for Mercor work (the data shows personal Chrome installations, personal hostnames like desktop-ue2kgro). The monitoring system captured personal activity on personal devices — personal emails, banking sessions, medical information, or other private content visible in background windows. All of this is now in criminal hands. Under ECPA and state wiretap laws, the capture of third-party communications visible in screenshots (Slack messages, emails, video calls) may constitute unlawful interception.

C. Wrongful Termination via Automated Fraud Decisions

The database reveals that automated fraud decisions directly determined whether contractors could earn a living:

• FraudStates.currentDecision = REJECT → contractor blocked from the platform
• FraudStates.currentReasoning contains LLM-generated explanations that were almost certainly never disclosed to affected contractors
• ProductionFraudState.status → final production fraud verdict with no apparent appeal mechanism

Under FCRA, if Mercor used these automated fraud scores or background check results (BackgroundCheck.status) to deny, suspend, or terminate contractor engagements without providing required adverse action notices, each instance is a separate violation. Under GDPR Article 22, EU/UK contractors have the right not to be subject to decisions based solely on automated processing.

D. Wage-Related Claims

The Deductions table records pay subtractions based on monitored activity — exact milliseconds deducted, which application triggered the deduction, and who approved it. If deductions were applied using data from the now-compromised monitoring system, or if the breach reveals inconsistent application, contractors have wage theft claims in addition to privacy claims.

III. Statutory Violations ¶

A. CCPA/CPRA — Private right of action for data breaches resulting from failure to maintain reasonable security (Cal. Civ. Code § 1798.150). Plaintext bank routing numbers, unencrypted PII, and excessive data collection constitute failure to implement reasonable security. Statutory damages: $100–$750 per consumer per incident.

B. GDPR — EU/UK contractors confirmed in the data (sample: United Kingdom, Harrow). Violations include data minimization failure (Article 5(1)(c)), integrity/confidentiality failure (Article 5(1)(f)), automated decision-making without safeguards (Article 22), and breach notification delays (Article 33). Fines up to €20 million or 4% of annual global turnover.

C. Illinois BIPA — Persona's liveness detection requires a scan of face geometry, explicitly listed as a biometric identifier (740 ILCS 14/10). The IDVerificationChecks table confirms facial geometry scans were captured (livenessStatus), facial comparison performed (interview-face-comparison), and thumbnail images stored (thumbnail_key). Statutory damages: $1,000–$5,000 per violation, no harm requirement. (Note: MAC addresses and hardware fingerprints are not biometric identifiers under BIPA.)

D. FCRA — Background check results and automated fraud scores used in employment decisions without required adverse action notices. Per-violation damages.

E. ECPA / State Wiretap Laws — Desktop screenshots capturing third-party communications visible on screen. Per-interception damages.

F. PIPEDA — Canadian contractors confirmed (sample: country: CA, BANK OF M*******). Breach notification to Privacy Commissioner and affected individuals required.

IV. Negligence - Security Failures Evidenced in the Data ¶

The database structure itself constitutes evidence of systemic negligence:

• Plaintext financial data: Complete Stripe API responses with bank names, routing numbers, and account holder names stored as unencrypted JSON
• No field-level encryption: Names, emails, phones, DOBs, and addresses readable as-is in the export
• Excessive data collection: Full Stripe API responses when only an account ID was needed; desktop screenshots capturing vastly more than needed to verify work hours; HaveIBeenPwned results stored as fraud signals; Persona KYC session tokens persisted indefinitely
• Infrastructure failures: ngrok dev tunnels with developer IPv6 in production config; AWS account ID embedded in S3 bucket names; sandbox tokens persisted after session expiry; GitHub Actions URLs exposing the private monorepo

V. Third-Party Claims ¶

Individuals who never created Mercor accounts have their data exposed:

• UserReferences: Names, emails, employers, and relationships of professional references
• LinkedinWarmIntros: LinkedIn profile URLs and email addresses of people contacted for outreach
• CandidateVouches: Relationship details provided by vouchers

These individuals never consented to data collection and likely never received a privacy notice. Under GDPR Article 14, Mercor was required to notify them within one month. The breach exposes them to targeted social engineering using their real relationship data.

Summary - Combined Legal Exposure ¶

The client claims are likely the largest in dollar terms — the economic value of the lost trade secrets (training data, evaluation methodologies, pre-release model outputs) runs into the billions. The contractor claims are the broadest in scope — affecting every individual who ever used the platform. Together, the total legal exposure is conservatively in the hundreds of millions of dollars before punitive damages.

Conclusion - What Happens Now ¶

The breach is not a past event. It is an ongoing situation with no clear resolution.

The Data Is Still in Circulation ¶

Mercor allegedly paid the attackers to have the data removed from the Lapsus$ leak site — a fact confirmed to us directly by Lapsus$ themselves. The data was taken down briefly. It reappeared. The group is now actively selling the full dataset to private bidders while continuing to distribute samples. The two files analyzed in this report were obtained after the ransom was paid. This is the predictable outcome of paying ransom for digital assets — there is no mechanism to verify deletion, no way to revoke copies already distributed, and every economic incentive for the attackers to continue monetizing the data through private sales, selective leaks, and derivative attacks. Mercor's ransom payment bought nothing except proof that they considered the data worth paying to suppress.

The attackers now possess:

• The complete identity of every Mercor contractor — name, email, phone, date of birth, home address, bank routing number, government ID verification status, and a photographic record of their desktop activity
• The complete client map — which companies use Mercor, what projects they run, which annotation platforms they use, and what their internal Slack workspaces and Okta SSO groups are called
• Apple's pre-release Foundation Model outputs, Amazon's Chain-of-Thought evaluation methodology, OpenAI's Feather platform campaign UUIDs, and Anthropic's model comparison data
• The source code for Mercor's entire platform — including its fraud detection algorithms, MercorScore ranking system, and payment infrastructure — providing a complete blueprint for exploitation
• Tailscale VPN credentials and network topology — a map of Mercor's internal infrastructure that could enable further unauthorized access if credentials have not been fully rotated
• 939GB of code repositories that likely contain hardcoded API keys, database credentials, and third-party service tokens scattered across commit history

This is not a dataset that loses value over time. The PII is permanent. The bank routing numbers don't expire. The government ID verification records don't reset. The signed legal documents don't un-sign. And the AI training data — the RLHF annotations, preference rankings, and rubric evaluations produced for frontier AI labs — retains its full value to any competitor seeking to accelerate their own model development.

The Ongoing Threat ¶

With this data, the attackers (or any subsequent buyer) can:

1. Launch targeted phishing campaigns against every Mercor contractor, using their real name, employer, project assignment, and pay rate to craft highly convincing social engineering attacks
2. Commit financial fraud using the bank names, routing numbers, and account holder names stored in MercorUserFinancials
3. Blackmail contractors whose desktop screenshots may reveal confidential client information, personal browsing activity, or employment at companies their current employer doesn't know about
4. Attack Mercor's clients using the Slack workspace URLs, Okta SSO configurations, and annotation platform campaign IDs as entry points for further social engineering or credential stuffing
5. Sell the AI training data — the prompts, responses, evaluations, and preference rankings — to competitors or foreign actors, undermining billions of dollars of investment by OpenAI, Anthropic, Apple, Amazon, Meta, and Google DeepMind
6. Exploit the source code to identify vulnerabilities in Mercor's (and potentially its clients') systems that have not yet been patched
7. Impersonate Mercor staff using the internal employee names, Slack IDs, and GitHub usernames found throughout the database to conduct supply-chain attacks against Mercor's clients and partners

Each of these vectors becomes more dangerous the longer the data remains in circulation — and there is no indication it will stop circulating.

The Case for Radical Transparency ¶

There is an uncomfortable truth that Mercor, its clients, and the affected contractors must confront: the data is out. It cannot be put back.

The current trajectory — where the breach is acknowledged in vague corporate language, specific questions are deflected, and affected individuals receive minimal information about what was exposed — serves no one except the attackers. It creates an information asymmetry where the adversary has complete knowledge of what was taken, while the victims operate in the dark.

Every contractor whose bank routing number is in MercorUserFinancials deserves to know — specifically — that their bank name, routing number, and account holder name were stored in plaintext JSON and are now in the hands of criminal actors. Every contractor whose desktop screenshots are in the mercor-insightful-screenshots-production S3 bucket deserves to know that their IP address, MAC address, browser history, and application usage during work sessions are exposed. Every client whose annotation platform URLs, Slack workspaces, and proprietary model outputs appear in the Airtable exports deserves to understand the exact scope of their secondary exposure.

The alternative to transparency is prolonged paranoia. If Mercor does not disclose the specific contents of the breach, every contractor must assume the worst about what was taken. Every client must assume their internal systems were visible on a contractor's screen. Every reference, every LinkedIn contact, every vouching party must assume their personal information was collected without their knowledge and is now compromised.

Perhaps the most constructive path forward — however counterintuitive — is full, detailed, public disclosure of exactly what the breach contained. Not the raw data itself, but a complete accounting: which tables, which fields, which categories of PII, which clients, which time periods. The world can adjust to a known breach. It cannot adjust to an unknown one. Sunlight remains the best disinfectant, and in the aftermath of a breach of this magnitude, the cost of silence far exceeds the cost of honesty.

The contractors who built the AI training data that powers the world's most valuable models deserve at least that much.

A Structural Critique - Youth Velocity and the Cost of Immaturity ¶

Mercor's three founders — Brendan Foody, Adarsh Hiremath, and Surya Midha — were 21 years old when they raised their Series A. They became the world's youngest self-made paper billionaires at 22 when their Series C valued the company at $10 billion. The average age of the Mercor team was reported at 22 years old. They are Thiel Fellows — college dropouts celebrated for building fast. They stored bank routing numbers in plaintext, ran a flat network where a single VPN hop reached everything, and let 4 terabytes walk out the door without anyone noticing.

Perhaps Mercor is best understood as a phenomenon of hype and strong mimetic desire within the AI industry. Perhaps the AI labs got ahead of themselves too early. Perhaps researchers and vendor managers chose Mercor not because they evaluated the vendor thoroughly enough to handle critical workloads, but because OpenAI was already using it.

The pattern is worth examining. OpenAI was one of Mercor's earliest major customers. The relationship began when Mercor's 20-year-old CEO cold-emailed OpenAI's head of human data operations, Shaun VanWeelden, and landed a contract to recruit Math Olympiad winners for model training. VanWeelden later left OpenAI to become Mercor's managing director. Two sitting OpenAI board members — Adam D'Angelo (Quora CEO) and Larry Summers (former U.S. Treasury Secretary) — invested in Mercor's earlier funding rounds.

This is not without precedent. Much of the AI data infrastructure landscape has been shaped by proximity to OpenAI. Scale AI's Alexandr Wang was Sam Altman's roommate during the pandemic. Scale went through Y Combinator when Altman ran it. Altman and Wang later discussed an acquisition.

With Mercor, the signal was unmistakable. OpenAI used them. OpenAI's board members invested in them. OpenAI's head of data operations joined them. Once that signal propagated, perhaps the other labs followed not because of independent evaluation, but because OpenAI had validated the choice for them. The $10 billion valuation, the press coverage, and the youngest-billionaires narrative reinforced what was already a foregone conclusion.

The Girardian irony is that this breach — the scapegoating event — may produce the same mimetic cycle in reverse. The labs may collectively abandon Mercor, collectively discover the next shiny vendor, and collectively onboard without asking the hard questions about security and privacy. The sacrifice of the scapegoat restores order. The community moves on, having learned nothing structural — only that this particular vendor was the wrong one.

Having reverse-engineered Mercor's complete operational architecture from its database schema — the annotation pipeline, the evaluation frameworks, the contractor management system, the payment infrastructure — it is clear that the underlying business is well-understood and replicable. For new entrepreneurs, the opportunity is straightforward: build the same platform, but treat security and privacy as foundational rather than an afterthought. The market for AI training data is not going away. The demand for a vendor that handles it responsibly has never been higher.

Appendix A - Complete Table Inventory ¶

All 149+ tables organized by functional domain, with column lists and sample data where present.

Domain 1 - User and Identity ¶

Domain 2 - Identity Verification and Background Checks ¶

Domain 3 - Fraud Detection ¶

Domain 4 - Hiring Pipeline ¶

Domain 5 - Interviews and Assessments ¶

Domain 6 - Work Trials and Onboarding ¶

Domain 7 - Projects and AI Task Management ¶

Domain 8 - Jobs and Contracts ¶

Domain 9 - Time Tracking and Productivity Surveillance ¶

Domain 10 - Payments and Financial Infrastructure ¶

Domain 11 - Referrals and Growth ¶

Domain 12 - Communications and Outreach ¶

Domain 13 - Company and Access Management ¶

Domain 14 - Skills Certifications and Endorsements ¶

Domain 15 - Analytics and ML ¶

Domain 16 - Infrastructure and DevOps ¶

Domain 17 - Reference and Miscellaneous ¶

End of Appendix A

Document prepared for security research and educational purposes. All PII has been obfuscated.