TL;DR: McDonald’s AI hiring platform exposed data from an estimated 64 million applicants after a default admin credential of 123456 and an IDOR flaw let researchers reach live records, according to Oasis Security. The case shows how weak NHI governance, not just application logic, can turn an AI workflow into a broad exposure event.
At a glance
What this is: This is a breach analysis of McHire’s AI hiring workflow, where a default admin credential and an IDOR flaw exposed applicant records and revealed non-human identity governance gaps.
Why it matters: It matters because AI-enabled business workflows often rely on bots, service accounts, and APIs whose access is governed less rigorously than human accounts, yet their compromise can expose personal data at scale.
By the numbers:
- Researchers uncovered a vulnerability in June 2025 that exposed sensitive data from an estimated 64 million job applicants.
- Enterprise AI adoption grew by 187% between 2023 and 2025, while security spending increased by only 43% during the same period.
Context
McHire was an AI-powered hiring workflow built to screen applicants at scale, but the security model behind it depended on non-human identities such as a bot administrator account and API access controls. When those identities are weakly governed, the workflow itself becomes a direct path to applicant data rather than a controlled automation layer.
The breach shows a familiar identity problem in a new form. Default credentials, orphaned admin access, and object-level authorization failures are not just application defects when they sit behind AI-driven business processes; they become governance failures across the NHI estate.
The article’s subject is therefore not only McDonald’s hiring platform. It is the broader question of how organisations inventory, protect, and continuously review the identities that AI workflows use to operate.
Key questions
Q: What breaks when default credentials exist on an AI workflow account?
A: A default credential turns a non-human identity into a ready-made entry point, especially when the account sits behind a chatbot, hiring portal, or API gateway. The failure is not only weak authentication. It is the absence of governance over a privileged backend identity that can expose data, actions, and administrative functions at once.
Q: Why do AI hiring platforms create higher exposure when object-level access is weak?
A: Because applicant records are often accessed through APIs that expose internal object identifiers, so one authorization flaw can turn into bulk record retrieval. The risk rises when the workflow aggregates personal data, chat transcripts, and hiring decisions behind a small number of interfaces.
Q: How do teams know whether non-human identity controls are actually working?
A: Look for reduced use of shared credentials, fewer manually rotated secrets, shorter credential lifetimes, and clear ownership for each workload identity. If access still depends on long-lived material in code, tickets, or inboxes, the control plane is not working as intended.
Q: Who is accountable for AI workflow access when a hiring vendor and employer both touch the system?
A: Accountability should sit with the organisation that permits production access and owns the data, even when a vendor operates part of the workflow. Shared responsibility does not remove the need for explicit ownership of bot accounts, API privileges, and offboarding decisions.
Technical breakdown
Default credentials on AI workflow administrators
AI hiring systems often sit behind service accounts, admin consoles, and bot credentials that are treated as deployment conveniences rather than governed identities. In this case, the weak default username and password provided direct administrative access to live data. The technical issue is not just authentication failure, but the persistence of privileged identities that were never forced through strong onboarding, ownership, or credential hygiene. Once a default credential remains valid in production, any external party who finds it inherits the same authority as the operator who created it.
Practical implication: remove default credentials from AI workflow accounts before production and require explicit ownership for every non-human admin identity.
IDOR in applicant record access
An insecure direct object reference, or IDOR, occurs when an application exposes internal object identifiers and relies on the client or caller to guess or sequence access rather than enforcing server-side authorization. Here, enumerating applicant IDs allowed sequential record retrieval after the admin console was compromised. That pattern matters because AI workflow APIs often expose high-volume records, making object-level authorization the real control point. When IDOR is present, privileged access to one object can become bulk access to an entire dataset with minimal effort.
Practical implication: enforce object-level authorization on every AI workflow API and test for sequential record traversal, not just login success.
NHI sprawl behind automated hiring
Non-human identity sprawl occurs when bots, API keys, test admins, and service accounts accumulate faster than the organisation can inventory and retire them. The article points to exactly that pattern: a forgotten test admin, a bot account, and a live hiring data path. These identities are hard to govern because they do not follow employee lifecycle patterns, yet they often hold the keys to regulated data. Without inventory, rotation, and offboarding, the attack surface persists long after the system goes live.
Practical implication: treat AI hiring bots, admin accounts, and API keys as governed identities with inventory, lifecycle ownership, and revocation controls.
Threat narrative
Attacker objective: The objective was to demonstrate that a weakly governed AI hiring workflow could expose large volumes of applicant data through identity and authorization failures.
- Entry occurred through a default administrative credential on the McHire AI hiring platform, giving the researchers access to live hiring data.
- Credential abuse then exposed an IDOR flaw that allowed sequential enumeration of applicant records through the platform’s API.
- The combined access path enabled broad collection of personal and hiring conversation data, creating downstream phishing and identity theft risk.
Breaches seen in the wild
- McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.
- Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Default credentials on non-human admin accounts are a governance failure, not a narrow configuration mistake. The McHire case shows that a single weak bot credential can expose production data if the organisation has not made non-human identity ownership, onboarding, and credential hygiene mandatory. In NHI terms, this is not just poor password discipline. It is evidence that the access model for automated workflows was never brought under the same control expectations as human admin access. Practitioners should treat every default credential on an AI workflow as a governance defect, not a local bug.
AI hiring workflows expand the blast radius of ordinary authorization flaws. IDOR is dangerous in any application, but AI-driven applicant systems concentrate high volumes of personal data behind few interfaces, so one broken object check can expose entire record sets. The article also ties the incident to identity theft and phishing risk, which means the impact is not limited to application misuse. Practitioners must recognise that object-level authorization becomes a high-value governance control when the subject is an automated, data-rich business process.
NHI sprawl is the named concept this breach illustrates. Service accounts, test admins, bots, and API keys become a persistent exposure layer when lifecycle ownership is unclear and offboarding is weak. The breach did not require advanced tradecraft, only neglected machine identities and a predictable application flaw. The implication is that AI adoption without NHI inventory and lifecycle governance creates a durable security debt that accumulates faster than traditional review cycles can absorb.
Access review models built for human accounts do not adequately describe AI hiring access. The relevant question is not who logged in, but which non-human identity was allowed to hold production authority, for how long, and with what delegated scope. That governance gap matters because bots do not leave the same operational trail as employees and may outlive the project, vendor relationship, or test window that created them. Practitioners should treat AI workflow identities as first-class governance objects, not as implementation detail.
The breach shows that NHI controls now sit on the critical path for personal-data protection. The article links the incident to GDPR exposure, which is a reminder that machine identity governance is no longer separate from privacy and regulatory risk. When an AI system handles applicant records, identity governance failures become compliance failures as well as security failures. Practitioners should align NHI controls with data handling obligations, because the control gap is shared even when the identity subject is not human.
What this signals
NHI sprawl now includes AI hiring systems. When bots and service accounts can touch applicant data, the programme risk is no longer limited to secret rotation. It extends to ownership, offboarding, and object-level authorization across every workflow that processes personal data.
The useful programme shift is to treat AI workflow identities as governed assets rather than implementation artefacts. That means inventorying them, naming owners, and validating that each privileged action is still justified at the point of use, not merely at deployment.
A breach like this also shows why lifecycle governance has to reach beyond the human employee lifecycle. Access that starts with a test account or bot credential can outlive the business need that created it, and that mismatch is where exposure accumulates.
For practitioners
- Eliminate default admin credentials Remove factory or test credentials from every AI workflow account before production and verify that no privileged bot login can be reused across environments.
- Inventory every non-human identity in hiring flows Build a complete register of bots, service accounts, API keys, and test admins that can touch applicant data, and assign explicit owners for each one.
- Enforce object-level authorization on applicant records Test every hiring API and admin workflow for sequential object access, and require server-side checks on each record before data is returned.
- Rotate and revoke AI workflow credentials on lifecycle events Tie credential rotation and decommissioning to environment changes, vendor offboarding, and test-to-production transitions so stale access does not survive deployment.
Key takeaways
- The breach shows that weak governance of non-human identities can turn an AI hiring workflow into a mass exposure event.
- Researchers said the incident exposed an estimated 64 million job applicants, which is large enough to make lifecycle control and object authorization board-level issues.
- Default credentials, object-level authorization, and explicit ownership of bot accounts are the controls most directly tied to limiting this failure pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The breach began with a default credential that should never have remained usable in production. |
| NHI-04 — Insecure Authentication | Weak bot authentication enabled access to live hiring data before any further control failed. | |
| NHI-05 — Overprivileged NHI | A privileged test admin account had far more access than the workflow needed. | |
| Recommendation — Eliminate exposed or default NHI secrets and revoke any credential that reaches a live workflow. Harden authentication for AI workflow identities and remove authentication paths that depend on weak defaults. Reduce NHI privilege to the smallest viable scope and segregate test access from production records. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path moved from credential abuse to broader record access through the exposed API. |
| Recommendation — Map default-credential abuse and API traversal to TA0006 and TA0008 in your detections. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Production auth hygiene and rotation are central to preventing reused or default NHI credentials. |
| Recommendation — Apply IA-5 to manage, rotate, and revoke authenticators used by AI workflow accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident shows that access rights were broader and less controlled than the workflow required. |
| Recommendation — Enforce PR.AA-05 so every AI workflow identity has explicit, least-privilege authorisation. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Default Credential: A default credential is a factory-set or preset username, password, or secret that remains unchanged after deployment. In NHI environments, it is a high-risk failure because it creates predictable access to privileged systems and often survives into production unless ownership and hardening are explicitly enforced.
- Insecure Direct Object Reference: Insecure direct object reference is an access control flaw where an application exposes an identifier that allows callers to reach records or objects they should not be able to access. In practice, it means the system trusts the request too much and fails to verify object-level permission on each access.
- Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org