McDonald’s AI hiring tool breach exposes NHI governance gaps

At a glance

What this is: McDonald’s AI hiring tool breach combined a default non-human credential with an IDOR flaw, exposing applicant data at scale and revealing weak NHI governance.

Why it matters: It matters because AI-adjacent service accounts, bots, and API access now sit inside core identity programmes, and one exposed non-human account can bypass controls built for human users.

By the numbers:

• The breach exposed sensitive data from an estimated 64 million job applicants.
• Enterprise AI adoption grew by 187% between 2023 and 2025.
• Security spending increased by only 43% during the same period.

👉 Read Oasis Security’s analysis of the McDonald’s AI hiring tool breach

Context

McDonald’s AI hiring tool breach is a non-human identity governance problem, not just an application flaw. A default admin credential on a chatbot-backed hiring platform created access to live applicant records, and an IDOR issue expanded that access into sequential record retrieval.

For IAM and security teams, the lesson is straightforward: AI workflows still depend on service accounts, API access, and administrative identities that must be inventoried, owned, and protected. The article’s starting point is typical of modern cloud-native sprawl, where convenience settings and weak lifecycle controls intersect with sensitive data exposure.

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 tools increase non-human identity risk?

A: AI hiring tools concentrate sensitive workflow access into service accounts, admin panels, and API calls that often sit outside normal human IAM review. That concentration increases blast radius when credentials are weak or reused, because one compromised non-human identity can expose large volumes of applicant or employee data.

Q: What do teams get wrong about IDOR in AI applications?

A: Teams often treat IDOR as a simple application bug, but in AI-driven workflows it is also an authorisation problem tied to backend identity scope. If a privileged non-human account can enumerate objects or records, the issue is not just validation. The application is failing to enforce record-level access consistently.

Q: Who is accountable when an AI hiring bot exposes applicant data?

A: Accountability sits with the team that owns the backend identity, access scope, and lifecycle of the bot or admin account, not with the interface alone. Governance frameworks, access reviews, and offboarding controls should cover non-human identities in the same way they cover high-risk human privileges.

Technical breakdown

Default credentials in AI hiring workflows

Default usernames and passwords on service accounts or admin panels are a classic NHI failure mode because they create reusable, low-friction access paths that are easy to overlook during deployment. In an AI hiring workflow, the chatbot may look like the visible actor, but the real control plane is often a hidden administrative identity with broad access to applicant data. If that identity ships with a known password, the system begins in a compromised state, even before any attacker activity. The security issue is not AI reasoning. It is unmanaged non-human access tied to business data.

Practical implication: remove default credentials before production cutover and require named ownership for every bot or admin identity.

IDOR and API object exposure behind the chatbot

Insecure direct object reference, or IDOR, occurs when an application exposes object identifiers that can be changed to retrieve records the caller should not see. In this case, the chatbot interface masked an underlying API that let records be enumerated sequentially, which is a design failure in access enforcement, not just input validation. When an identity can reach the API, object-level authorisation has to be enforced on every request. Otherwise, the attacker does not need to break in again. They simply walk the data model through predictable identifiers.

Practical implication: enforce object-level authorisation checks on every API call and test whether sequential identifiers expose records.

Why AI interface layers increase NHI blast radius

AI front ends often concentrate business workflows, but they also aggregate authentication, session handling, and backend access into a single operational path. That concentration widens blast radius when a bot account, token, or admin credential is exposed because the compromised identity inherits all the permissions behind the interface. In identity terms, the chatbot is not the identity problem. The problem is the privileged NHI sitting underneath it. The more that AI systems mediate hiring, support, or onboarding, the more their backend credentials become high-value access assets.

Practical implication: treat AI workflow backends as privileged NHI surfaces and review their access scope as if they were production admin accounts.

Threat narrative

Attacker objective: The objective was to reach live applicant records and use that access for data theft and targeted social engineering.

1. Entry occurred through a default administrator credential of 123456 on the McHire environment, giving access to the live hiring system behind the AI chatbot.
2. Credential access then exposed administrator-level visibility into applicant records, and the IDOR flaw allowed sequential enumeration of applicant IDs to retrieve additional data.
3. Impact would have included mass applicant data exposure, enabling phishing, identity theft, and broader trust damage if the issue had been exploited at scale.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 identities are not a hygiene issue, they are a governance failure. A chatbot or workflow bot that ships with a known administrator password is already outside acceptable identity control. The breach worked because the environment treated a non-human admin path as disposable rather than governed. Practitioners should read this as a lifecycle and ownership problem, not an isolated vulnerability.

Identity blast radius is the right concept for AI-mediated workflows. The real exposure was not the chatbot itself, but the backend NHI that inherited broad access to applicant data and administrative functions. Once an AI-facing identity is over-privileged, one weak credential can expose an entire workflow. That is why NHI governance has to map permissions to business process scope, not interface convenience.

IDOR is an authorisation failure, but in NHI terms it becomes a credential amplification problem. If a privileged non-human identity can enumerate records through predictable object references, the access path expands far beyond the original login issue. The named failure mode here is exposed admin access plus object-level overreach. Practitioners should treat sequential record retrieval as proof that request-level authorisation is incomplete.

AI hiring systems expose the same lifecycle weakness seen in service account sprawl. The article’s own remediation steps point to discovery, rotation, and decommissioning, which are only effective when every non-human identity has an owner and a retirement path. This is the same discipline applied to service accounts, API keys, and bots. Security teams should align AI workflow governance with NIST CSF and OWASP NHI control expectations.

McHire shows that AI adoption can outpace identity governance without changing the underlying failure pattern. The article notes that enterprise AI adoption grew far faster than security spending, which is exactly how hidden NHI privilege accumulates. The field should expect more incidents where the visible AI layer is not the exploit path, but the privileged non-human identity behind it. Practitioners need to govern the backend, not just the front end.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why hidden admin paths still survive in production environments.
• For a broader control baseline, 52 NHI Breaches Analysis shows how exposure, privilege, and lifecycle gaps repeat across incidents.

What this signals

Default admin access is the kind of failure that security programmes miss when inventory is incomplete. When only 5.7% of organisations have full visibility into their service accounts, hidden bot accounts and test credentials are likely to outlive the systems they protect. The practical signal is clear: if you cannot enumerate the non-human identity estate, you cannot credibly govern AI-enabled workflows.

Identity programme owners should expect AI hiring, support, and onboarding tools to inherit the same NHI failure patterns as legacy service accounts. The issue is not the interface type, it is the backend privilege model. Teams that already track credential rotation, ownership, and offboarding should extend those controls to every AI-facing administrative identity before the blast radius grows.

Backend identity controls now define the security posture of AI-mediated business processes. The more applicant, customer, or employee data flows through bots and API layers, the more the organisation depends on lifecycle discipline for non-human identities. That makes inventory, ownership, and decommissioning the decisive controls, not just monitoring after exposure.

For practitioners

• Eliminate default credentials on all AI workflow administrators Inventory every bot, admin panel, and service account tied to AI-enabled hiring or intake systems, then force unique secrets before go-live. Require an owner for each identity and block production use until default passwords are removed.
• Test object-level authorisation on applicant and customer APIs Run IDOR-focused tests against every API exposed behind an AI interface, including sequential identifier checks and permission boundary validation. Confirm that each record request is re-authorised server side, not trusted because the session is valid.
• Treat chatbot backends as privileged NHI surfaces Classify the backend identities that support AI hiring, support, or onboarding as high-risk non-human accounts and review their scopes separately from the user-facing application. Restrict read access, log all administrative actions, and remove unused privileges quickly.
• Link discovery to decommissioning for every AI bot account Build an offboarding workflow that retires dormant bots, test accounts, and temporary administrators as soon as the business process ends. Tie removal to a tracked owner so orphaned identities do not persist after project changes or vendor handoffs.

Key takeaways

• The breach shows that a default password on a non-human admin path can expose far more data than the front-end AI system appears to control.
• The scale matters: an estimated 64 million applicant records were exposed, showing how quickly one weak backend identity can turn into broad organisational impact.
• The control that would have mattered most is basic NHI governance, including unique credentials, object-level authorisation, and enforced offboarding for bot accounts.

Key terms

• Non-Human Identity: A non-human identity is any machine or software identity used to access systems, data, or services, including service accounts, API keys, tokens, certificates, bots, and AI agents. It needs the same ownership, lifecycle control, and access governance as a human account, but with tighter automation-aware review.
• 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.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and business process exposure created when one identity is compromised. For non-human identities, blast radius is driven by privilege scope, hidden dependencies, and lifecycle gaps, so a single credential can affect far more than the original workflow.

Deepen your knowledge

AI hiring tool governance and non-human identity control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing chatbot-backed workflows or service accounts with applicant data access, it is worth exploring.

This post draws on content published by Oasis Security covering the McDonald’s AI hiring tool breach: McDonald’s AI Hiring Tool Breach: A Wake-Up Call for Non-Human Identity Security. Read the original.