McDonald’s McHire Breach Shows Why APIs Need Non-Human Identity and Strong Auth

Heather Howland

Why unauthenticated APIs are a critical risk—and how SPIFFE and modern Non-Human IAM platforms prevent these attacks.

This time, it’s McDonald’s hiring platform, McHire (powered by Paradox.ai). Security researchers found a legacy admin account using—wait for it—123456:123456. No MFA. And worse: an API endpoint with no authentication at all. Just guessable applicant IDs and open access to names, emails, phone numbers… all of it.

Roughly 64 million records exposed.

This wasn’t a sophisticated breach. It was a failure to enforce the basics—leaving an API wide open in a production system that should’ve known better.

APIs Are Not Internal Anymore

APIs aren’t tucked safely behind the firewall. They’re everywhere — powering workflows, connecting services, and increasingly exposed to the outside world. That makes them a massive attack surface.

If you’re not authenticating and authorizing every call, you’re gambling with access.

Here’s what went wrong in this case:

  • Default credentials were still active
  • No MFA on sensitive accounts
  • An API accepted unauthenticated requests
  • No identity, no scoped access, no controls

This isn’t a new problem — it’s one we should’ve solved a long time ago. But it keeps showing up, especially when the systems making these calls aren’t people. They’re bots, scripts, containers, jobs — and we still don’t have a consistent way to verify what they are or what they should be allowed to do.

That’s the identity gap.

The Identity Gap in Infrastructure

We’ve made huge progress securing human access — MFA, SSO, device trust — but when it comes to everything else (scripts, bots, containers, pipelines), identity is still broken. We rely on static secrets, hardcoded tokens, or nothing at all.

This is the gap attackers exploit.

What’s needed is a consistent way to authenticate and authorize non-human actors — one that doesn’t depend on brittle credentials or IP-based assumptions. One that’s easy for application developers to understand and use.

That’s where open standards like SPIFFE come in. SPIFFE (Secure Production Identity Framework for Everyone) provides a way to assign cryptographic identities to workloads — so you can verify who or what is calling an API, enforce policy based on that identity, and eliminate the need for long-lived credentials entirely.

But like any standard, SPIFFE needs a platform to bring it to life.

SPIRL: Identity for Non Humans / Machines

Most identity platforms were built for people. SPIRL was built for everything else — the non-human actors that make up the majority of modern infrastructure.

With SPIRL, every API, workload, job, AI agent, or container gets a verifiable identity that’s:

  • Issued automatically
  • Assigned using its underlying attributes
  • Short-lived by default

That means:

  • No default credentials or static secrets
  • No ambiguity about who’s calling your APIs
  • No overly permissive roles that outlive the job they were created for

Access is granted only when needed, tied to identity, and disappears when the job ends. Every action is logged and attributable. And policy is enforced consistently — no matter the environment.

SPIRL uses SPIFFE under the hood — just like Okta uses OAuth. But what matters is the outcome: a unified way to manage and secure non-human access across your infrastructure, without relying on error-prone credentials or blind trust.

Don’t Let AI Distract You from API Security

We’re all moving fast — plugging in AI, building orchestration layers, automating workflows. But none of that matters if your APIs are still accepting unauthenticated requests.

AI may be the future of work, but APIs are the pipes that run it. If they’re unprotected, everything built on top is vulnerable.

Modern infrastructure needs modern identity.
And identity can’t just stop at humans — it has to cover everything else, too.