McDonald's AI hiring platform exposed the names, email addresses, and phone numbers of 64 million job applicants. this was reported by the Identity Theft Resource Center in 2025. it's one of the largest data exposures associated with an AI system in history.
you've probably never heard of it. it got almost no coverage relative to its scale. compare the discourse it generated to the coverage of Air Canada's chatbot telling one passenger the wrong refund policy — which was written about hundreds of times and became a canonical example in every article about AI liability. the Air Canada incident affected one person and cost $812. the McDonald's incident affected 64 million people.
the asymmetry in coverage is interesting on its own. but the more important thing is what the McDonald's breach actually was, because it's a template for the AI security failure mode that matters most and gets studied least.
this was not a hack
most large data breaches follow a familiar pattern. an attacker finds a vulnerability — a SQL injection, an unpatched service, stolen credentials — and exploits it to exfiltrate data. the narrative has a villain, a technical flaw, and a fix. this is legible and makes for good reporting.
the McDonald's incident appears to be a different category. based on what was reported, this was a configuration failure. the AI hiring platform had access to 64 million records — probably because that's how it was designed, to draw on a large applicant pool — and those records were accessible in a way they shouldn't have been. no sophisticated attacker. no zero-day exploit. just an AI system that had been given more access than it needed, with insufficient controls on how that access could be exercised.
this distinction matters enormously. a sophisticated hack requires a sophisticated attacker. it's an adversarial problem with a specific threat model. a configuration failure requires no adversary at all. the data walks out the door because someone didn't think carefully enough about what the AI system should be able to see and do.
the principle of least privilege, violated at scale
security professionals have a principle called least privilege: every system, process, and user should have only the minimum access necessary to perform its function. a customer service agent should be able to look up a customer's order history, not every order in the database. a hiring tool should be able to see the applicants for a specific role, not every applicant in the company's history.
this principle is harder to apply to AI systems than to traditional software for several reasons.
first, AI systems are often built to be broad. the value proposition of an AI hiring tool is that it can search across a large pool of candidates, surface unexpected matches, identify patterns. restricting its access undermines that value. there's a real tension between "useful AI" and "minimally privileged AI" that doesn't exist in the same way for a traditional database query tool.
second, AI access patterns are hard to audit. when a database query runs, you can log exactly what it accessed. when an AI model processes a record to build its internal representations of "good candidate," the access is harder to attribute. the model may have seen and been influenced by data that it doesn't explicitly retrieve or surface. this makes least-privilege enforcement fuzzy in a way it isn't for traditional systems.
third, the consequences of access are different. if a database query exfiltrates records, you see the exfiltration. if an AI model's internal representations are somehow compromised or extracted through model inversion attacks, the access happened inside the model. this attack class is early-stage today but maturing fast.
hiring AI is a particularly dangerous category
the McDonald's case involves hiring, which is worth flagging as a category with compound risk.
first, the data is sensitive by default. job applicants provide real contact information. they often provide salary history, work history, education, references. in some cases they provide demographic information. this is a dense profile of a real person who didn't consent to having their data handled sloppily — they applied for a job.
second, hiring AI has a documented discrimination problem. separate from the data breach, Workday faces a class action lawsuit over an AI recruiting tool that allegedly screened out candidates based on race, age, and disability. iTutorGroup settled a federal discrimination complaint after its AI rejected applicants over 55. these aren't edge cases. they're what happens when you optimize a system for "hires who succeeded" without scrutinizing what correlated with success in historical data.
so you have a category where: the data is maximally sensitive, the training data is maximally biased (historical hiring decisions embed decades of discrimination), and the deployment scale is enormous. McDonald's processed tens of millions of applications. a single configuration error at that scale is not a minor incident.
what "AI security" has to mean in practice
after the Air Canada incident, a lot of commentary focused on guardrails: making sure the chatbot doesn't say things it shouldn't. the frame is on outputs. what does the model say, is it accurate, is it authorized to say it.
the McDonald's incident points toward a different frame: access architecture. what can the model see, what can be reached through the model, who designed those access controls, and who audits them.
the practical difference is significant. output guardrails are largely a model-layer problem — you add fine-tuning, system prompts, output filtering. access architecture is an infrastructure problem — you're designing database permissions, tenant isolation, data retention policies, audit logging. these are different teams, different skillsets, different evaluation criteria.
the organizations treating AI security seriously are working on both in parallel. the ones treating it as a model problem are going to get surprised by an infrastructure failure. you can have the world's best-aligned, most carefully guardrailed model, and still expose 64 million records because of how you provisioned its database access.
why configuration failures are the dominant near-term risk
i keep saying this in different ways because i think it's the most underappreciated point: the scary AI failures are mostly not going to be the model doing something unexpected. they're going to be the infrastructure doing something predictable that nobody thought through.
the model being deployed at McDonald's almost certainly did what it was designed to do. the failure was in the architecture around it. and architecture failures are actually harder to fix than model failures, because they live in the configuration layer — IAM policies, network ACLs, database permissions, API access controls — which is distributed across dozens of systems and tends to accrete over time as features get added and nobody does the full audit of what the AI system now touches.
the teams shipping AI products are usually not the teams who own the infrastructure security review. the AI team builds the feature, hands it to platform, platform deploys it, security reviews happen quarterly if you're lucky. the configuration state of the AI system at the moment of a breach reflects months of accumulated decisions made by people who were thinking about functionality, not access minimization.
64 million people's contact information is a real harm, even if it doesn't read as dramatically as a rogue AI. the people who applied for jobs at McDonald's didn't consent to being part of a data incident. they consented to having their information used to evaluate their application. the gap between those two things is where most real-world AI risk actually lives — not in the model's outputs, but in the architecture's assumptions about what the model should have access to and what that access could enable.