No Check on Who Was Authorized

TL;DR

When you hear “AI screens the applicants,” you picture something cutting-edge. But in June 2025, security researchers Ian Carroll and Sam Curry found that the admin console of McDonald’s recruitment platform McHire (where Paradox.ai’s AI chatbot “Olivia” handles applicants) could be entered with an admin account whose username and password were both “123456” — a test account left abandoned since 2019. Then, via an IDOR (Insecure Direct Object Reference), applicant IDs could be enumerated sequentially, reaching up to 64 million application records (names, emails, phone numbers, interview transcripts, IP addresses). We analyze this through Pillar 03 (Agent Authority Proof) as a structure in which, for access to an AI system’s sensitive data, the authority attribute of “who may legitimately access” is not independently verified, so reachability became retrieval. Paradox disabled the account the day it was reported, but the failure primitive is not the presence of guessable credentials — it is the absence of an authorization-verification layer. It connects to Brief 057 (reachable meant readable, with no authentication), 013 (raw PII kept for compliance becomes the breach surface), 034 (the origin of capture goes unverified), and 022 (bypass of attribute verification).

Incident overview

• Subject: McHire (McDonald’s job-application platform) / Paradox.ai’s AI recruiting chatbot “Olivia”
• Discoverers: Ian Carroll, Sam Curry (security researchers)
• Entry point: The admin login had a valid account with username and password both “123456” — a test account left abandoned since 2019
• Lateral movement: After entering the admin side, an IDOR vulnerability allowed sequential enumeration and retrieval of applicant IDs
• Exposure scale: Up to 64 million application records — names, emails, phone numbers, interview (chat) transcripts, IP addresses, etc.
• Response: Paradox.ai disabled and fixed the account the day it was reported (2025-06-30) and opened a bug bounty. It stated only the researchers accessed any data, and only a small number of records
• The crux: Access to sensitive personal data passed with only a guessable credential and a reference ID; the authority attribute of the accessing party was not independently verified

Note: This Brief does not assert the presence or absence of actual harm; its object of analysis is the structure of absent authority-attribute verification in AI-system data access.

Timeline

• 2025-06-30: Researchers Carroll and Curry access the McHire admin console with “123456,” confirm record enumeration via IDOR, and report to Paradox.ai / McDonald’s
• 2025-06-30: Paradox.ai disables and fixes the account the same day and opens a bug bounty
• Thereafter: Logged in the AI Incident Database as Incident #1179

How access propagates into “unverified retrieval”

This incident stems from a structure in which, for access to the data plane of an AI system, the party’s authority attribute is not independently verified.

1. Initial reach via credentials: A valid session could be established to the admin interface with a guessable default credential (123456). Whether “this party holds admin authority” is effectively not verified
2. Lateral movement via reference ID (IDOR): A direct object reference without an authorization check let one reach others’ records simply by incrementing the applicant ID. Per-record authority verification is missing
3. Reaching sensitive data = retrieving it: Personal data — names, contacts, interview transcripts, IPs — could be enumerated and retrieved without further verification. Reachability becomes full retrieval
4. Lack of visibility: Because the access uses a legitimate path, illicit enumeration is recorded as ordinary access and is hard to detect as an anomaly

Structural analysis

This incident belongs to the identity-auth category under Pillar 03 (Agent Authority Proof). The central failure primitive is that in access to an AI system’s sensitive data, the party’s authority attribute (who, and up to which records, is legitimate) is not independently verified, so reachability connects directly to retrieval. As secondary we note attribute-proof-bypass (bypass of authority-attribute verification) and data-provenance (handling of application records as personal data).

It shares the primitive of missing authority/attribute verification with Brief 013 (the Coinbase KYC insider breach — raw PII whose storage is mandated by regulation became the breach surface). The new cross-section here is that in the domain of an AI recruiting bot, a non-human (system) identity’s weak credential became the entry point to the personal data of tens of millions. Behind the appearance of “screening with the latest AI,” the data-plane authorization relied on a classic access-control flaw. Where Brief 057 (DeepSeek) was “the absence of authentication itself,” this case is “a guessable credential plus missing per-record authorization” — another manifestation of the same primitive.

The gap between detection and proof

Here the detection chain — external research by the researchers, responsible disclosure, Paradox.ai’s same-day fix, and the bug bounty — functioned, and the vulnerability was made visible and remediated before exploitation spread. This is a detection/disclosure success, and this Brief does not deny its role.

But the problem is that no matter how well detection functions, it does not provide the material to independently prove, at the moment of access, “does the party making this access request hold legitimate authority over this record.” Strengthening one guessable credential leaves the separate flaw of per-record authorization (IDOR) intact. “Logged in legitimately” or “referenced by ID” is not proof of “having legitimate authority.” Because it is enumeration over a legitimate path, after-the-fact log analysis tends to become a trailing sequence that operates only after retrieval has occurred.

At present, in AI-service data access, authority-attribute verification is left to per-implementation access control and is not treated as an independent layer. Pre-execution attestation places, ahead of the sensitive-data access path, an attribute proof that “the requesting party legitimately holds the authority for this scope,” and with selective disclosure makes authorization independently verifiable without exposing the personal data itself. Detection (external research, fixes) contributes to shrinking harm, while pre-execution attestation (authority verification at access time) contributes to independently verifying authorization — each complementary. For verifying independently before the action see “Proof-as-Auth: Sign In Without Ever Sending Your Key” (Lemma, 2026-05); for the detection-and-proof thesis see “The Last Layer Left for Cyber Defense in the Age of AI” (Lemma, 2026-05).

Response and industry trends

• Vendor response: Paradox.ai disabled and fixed the account the day it was reported and opened a bug bounty, stating only the researchers accessed any data
• Industry point: With the rapid adoption of AI chatbots in recruiting / HR, the protection of applicants’ large-scale, sensitive personal data and the credential management of system (non-human) identities have become focal points
• Regulatory context: From both the protection of applicants’ personal data (national privacy laws) and accountability for AI-driven hiring processes, demand grows to make data-access authorization verifiable

A picture in which access to the personal data of tens of millions relied on a guessable credential and missing per-record authorization is not one vendor’s misconfiguration; it remains an access-authorization design issue for every organization embedding AI into its operations.

Lemma’s analysis

Against the gap McHire exposed — for access to an AI system’s sensitive data, the party’s authority attribute goes unverified and reachability connects directly to retrieval — Lemma proposes a design that fixes the basis for access as an independently verifiable cryptographic proof at that moment.

• Pre-execution attestation of authority attributes: Before accessing sensitive data, prove as an independently verifiable attribute that “the requesting party legitimately holds the authority for this scope (this set of records).” Guessable credentials or swapped reference IDs do not pass
• Per-record authorization binding: Bind reference IDs (object references) to the authority scope so that sequential ID enumeration does not pass without authorization
• Selective disclosure: Prove only that “the access was within the scope of authority,” with minimal disclosure, without sending the applicants’ personal data outside
• Proof for non-human identity: Treat system-account authority, too, as a verifiable attribute rather than a fixed credential

Proof fixed at the moment of action functions as evidence that can be independently verified later — without disclosing the personal data — when asked “was this access based on legitimate authority.” Detection and disclosure (researcher investigation, fixes) contribute to shrinking harm, while pre-execution attestation (authority verification at access time) contributes to independently verifying authorization — each complementary. For the design and scope see Pillar 03 — Agent Authority Proof.

Sources

• Ian Carroll: “Hacking McDonald’s McHire / Paradox.ai” (the researchers’ original account of the discovery and technique; 2025-06-30) — https://ian.sh/mcdonalds
• AI Incident Database: Incident #1179 (McHire / Paradox.ai) — https://incidentdatabase.ai/cite/1179/
• CSO Online: “McDonald’s AI hiring tool’s password ‘123456’ exposed data of 64M applicants” (scale and timeline) — https://www.csoonline.com/article/4020919/mcdonalds-ai-hiring-tools-password-123456-exposes-data-of-64m-applicants.html

About Brief distribution

The Lemma Critical Brief is a threat-intelligence brief published by Lemma. This material is a structured analysis of public information and is not an audit, diagnosis, or recommendation for any specific organization. If you use it as a reference for decision-making, please consult your Lemma Critical contact directly.

Discovery Call → Whitepaper → ✉️ Newsletter →

(c) 2026 FRAME00, INC. — Built for decisions that matter.