McHire exposed the API identity gap in non-human access

At a glance

What this is: This is a vendor analysis of the McHire breach that shows how default credentials, missing MFA, and an unauthenticated API left millions of records exposed.

Why it matters: It matters because IAM, PAM, and NHI programmes all fail when machine-facing access is left outside the same identity controls used for people.

By the numbers:

• Roughly 64 million records were exposed.

👉 Read Defakto Security's analysis of the McHire API identity breach

Context

API security breaks when machine-facing systems are allowed to behave as if they are internal and trusted. In this case, the primary keyword is API security, but the governance gap is broader: non-human identities were left without strong authentication, scoped authorization, or basic account hygiene.

The breach matters to NHI governance because APIs are now the control plane for bots, scripts, services, and workloads as much as for applications. When identity stops at human users, organisations inherit blind trust in the very interfaces attackers target most easily.

Key questions

Q: How should security teams protect APIs that expose non-human identity risk?

A: Security teams should require authentication on every exposed API, eliminate anonymous access, and bind each call to a specific workload or service identity. They should also remove static secrets where possible, enforce scoped authorization, and keep a current owner for every machine-facing credential. API security fails fastest when identity is optional.

Q: Why do default credentials still create major breach risk?

A: Default credentials are still dangerous because they create a predictable standing privilege path that attackers can test immediately. If the account also lacks MFA or has broad permissions, the compromise becomes simple credential abuse rather than a sophisticated intrusion. That is why default admin access must be treated as an urgent removal item.

Q: What breaks when organisations treat APIs as internal by default?

A: When APIs are treated as internal by default, teams skip authentication, rely on network trust, and overlook how outside parties can reach the same interfaces. The result is unauthorised requests, weak accountability, and broad data exposure. The control failure is identity blind trust, not just poor perimeter design.

Q: Who is accountable when a machine-facing account exposes production data?

A: Accountability should sit with the system owner and the team that governs the credential lifecycle, not with the identity type itself. If an API, service account, or admin account remains active without review, the programme has failed its lifecycle obligation. Frameworks such as the NIST Cybersecurity Framework 2.0 reinforce ownership, access control, and recovery discipline.

Technical breakdown

Why unauthenticated APIs become an identity problem

An API is not secure because it sits inside a production environment. It is secure only when every request can be authenticated, authorised, and tied to a specific identity with a narrow permission set. In this case, the exposed endpoint accepted requests without authentication, which means there was no identity check at the point of access. That is not merely a web application flaw. It is an identity failure for machine-facing access, because the system had no reliable way to distinguish a legitimate call from an attacker’s request.

Practical implication: require identity-bound authentication on every externally reachable API and remove anonymous access paths from production systems.

Why default credentials and no MFA still matter for non-human access

Default credentials on administrative accounts create a standing trust relationship that attackers can test immediately, especially when MFA is absent. For non-human environments, this problem is often worse because service and admin accounts are inherited across teams, embedded in workflows, and rarely reviewed with the same discipline as human accounts. The issue is not just weak authentication. It is the persistence of credentials that were never designed for modern exposure. Once those credentials exist in production, the attack surface becomes a simple login problem rather than a difficult intrusion problem.

Practical implication: eliminate default admin credentials, add MFA where human-interactive admin paths remain, and remove any account that cannot be tied to a current owner.

How SPIFFE-style workload identity closes the trust gap

Workload identity frameworks such as SPIFFE assign cryptographic identity to non-human actors so policy can be enforced on the basis of who or what is calling, not where the call came from. That matters because API security collapses when teams rely on network location, shared secrets, or long-lived tokens as the only proof of legitimacy. A workload identity model replaces that with short-lived, verifiable identity and tighter policy control. The technical lesson is straightforward: if an API serves machines, the authentication model must be machine-native rather than a human IAM pattern stretched past its limits.

Practical implication: map service, workload, and API identities to cryptographic trust anchors rather than reusable secrets or IP-based allow lists.

Threat narrative

Attacker objective: The objective was simple data access through the weakest identity control path, then broad exfiltration from a production system that should have been gated by authentication.

1. Entry occurred through an unauthenticated API endpoint and a legacy admin account that still accepted default credentials.
2. Credential abuse followed because the exposed administrative path had no MFA and no meaningful identity scoping.
3. Impact was broad record exposure, with names, emails, phone numbers, and other applicant data reachable at scale.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API identity is now a first-class governance problem, not an implementation detail. The McHire incident shows what happens when machine-to-machine access is treated as infrastructure convenience instead of an identity domain with its own controls. Once APIs can be reached without authentication, the organisation has already lost the ability to govern who or what is calling. The practitioner conclusion is that API identity needs the same policy rigor as human IAM, with stronger ownership and lifecycle discipline.

Default credentials create an avoidable standing privilege surface. Legacy admin accounts with unchanged passwords are not just bad hygiene. They are an identity control failure that turns routine administrative access into a predictable entry point. In NHI terms, this is the persistence of access that should have been retired long before production exposure. The practitioner conclusion is that standing administrative access for systems and service actors must be treated as a removal problem, not a monitoring problem.

APIs are now the identity boundary for bots, scripts, and workloads. The article is right to warn that AI should not distract teams from API security, because the same access model governs far more than AI workloads. The governance gap is not intelligence, but identity. As more processes become machine-initiated, teams that still rely on implicit trust or network location will keep exposing data through the easiest available interface. The practitioner conclusion is to govern every machine call as a managed identity event.

Workload identity is the missing control layer when secrets are treated as proof. Static secrets, shared tokens, and hardcoded credentials all assume the caller can safely retain a reusable credential over time. That assumption breaks the moment an exposed interface can be reached externally or a credential is copied into code, config, or an admin account. The practitioner conclusion is to move from credential possession to cryptographic workload identity wherever APIs expose production data.

Identity blast radius, not just breach volume, should frame the lesson here. The exposed record count matters, but the more important signal is that a single weak admin path plus one unauthenticated endpoint was enough to open a broad dataset. That is a governance failure in reach, not just in scale. The practitioner conclusion is to measure how far one identity control failure can propagate across API-connected systems.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Another finding from our research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• For the broader lifecycle and rotation angle, Ultimate Guide to NHIs explains why weak machine identity control keeps turning into breach exposure.

What this signals

Standing trust is still the dominant failure mode in machine-facing identity. The McHire case is a reminder that API identity failures are rarely subtle. When credentials are static, admin access is inherited, and anonymous endpoints remain reachable, the blast radius is defined before the attack even starts. Teams should expect more breaches to begin at identity boundaries rather than application logic. That is why the NIST Cybersecurity Framework 2.0 remains a useful backbone for govern, protect, detect, and recover discipline.

API security and NHI governance are converging operationally. As bots, scripts, and workloads become the real callers of production systems, the programme question shifts from user access to machine access. In our view, the next control gap is not whether APIs exist, but whether each one has a verifiable identity model behind it. Teams should align service accounts, secrets, and workload identity under one governance model.

Identity blast radius is the concept that should guide prioritisation. If one exposed admin account can unlock a production API and a large record set, the problem is not isolated authentication failure. It is the spread of unmanaged trust across connected systems. Practitioners should use 52 NHI Breaches Analysis to compare how often the same pattern repeats across identity-led incidents.

For practitioners

• Remove unauthenticated production endpoints Inventory externally reachable APIs and require authentication on every request path, including internal admin and partner interfaces that can be reached from the internet.
• Eliminate default administrative credentials Find legacy admin accounts, replace vendor or inherited defaults, and revoke any credentials that cannot be mapped to an accountable owner and current business use.
• Replace static secrets with workload identity Move API and service-to-service access toward cryptographic workload identity so access is based on verifiable identity rather than reusable shared secrets.
• Apply MFA to remaining human-interactive admin paths Where administrators still access machine-facing systems directly, enforce MFA and separate those paths from service and workload credentials.
• Review API access as part of lifecycle governance Treat service accounts, admin accounts, and API credentials as lifecycle-managed identities with defined ownership, review, and offboarding steps.

Key takeaways

• The McHire incident shows how unauthenticated APIs and default credentials can turn routine access into mass data exposure.
• The scale matters, but the real lesson is that weak machine identity controls create a broad and predictable attack surface.
• Teams should govern APIs, service accounts, and workload credentials as lifecycle-managed identities, not as background infrastructure details.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software, services, workloads, bots, or agents rather than people. It is governed through authentication, authorization, lifecycle ownership, and revocation. In practice, it includes service accounts, API keys, tokens, and certificates that can expose systems when unmanaged.
• Workload Identity: Workload identity is a cryptographic way to identify software workloads without relying on shared secrets or static network trust. It gives machines a verifiable identity that policy engines can evaluate at runtime. This makes service-to-service access more defensible than long-lived credentials copied across environments.
• Standing Privilege: Standing privilege is access that remains available all the time instead of being granted only when needed. For machine-facing systems, it often appears in admin accounts, service credentials, and broad API permissions. Standing privilege increases blast radius because an attacker only needs to find one active path.
• Identity Blast Radius: Identity blast radius is the amount of damage that can follow from one identity control failure. It measures how far a compromised account, token, or API path can reach across connected systems and data. In NHI governance, it is a practical way to prioritise which identities need the strongest controls first.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Defakto Security: McDonald's McHire breach and the case for non-human identity in API security. Read the original.