[Webinar] Ditch Static Credentials: Embrace WIF for Enhanced Security | Nov 6 at 11 a.m. PT | Register Now

Aembit Earns Prestigious Runner-Up Spot at RSA Innovation Sandbox Contest! Watch the Announcement

5 Non-Human Identity Breaches That Workload IAM Could Have Prevented

Workload to workload breach prevention.

As counterintuitive and unsettling as it may be to hear, the most devastating breaches rarely involve zero-days or nation-state attackers using novel techniques. When examining recent high-profile incidents, a simpler, more troubling pattern tends to emerge.

While skilled adversaries were often involved, their access methods weren’t exotic.They exploited the same fundamental weaknesses that have plagued security for years: exposed credentials, overprivileged accounts, and misplaced trust relationships.

Except in the cases we’ll highlight below, they weren’t targeting user identities as the inroad – they went after non-human access paths woven into modern IT infrastructure.

Today’s enterprises are increasingly driven by workload-to-workload interactions: Applications call APIs. Software pipelines deploy code. Services exchange data. All of it is driven by non-human identities, which are tied to credentials that are often:

  • Long-lived and rarely rotated.

  • Hardcoded in repositories or config files.

  • Difficult to monitor with conventional security tools.

Security teams have spent the past decade-plus tightening controls for human users: implementing MFA and SSO, reducing privilege, and monitoring for anomalies. But workloads and AI agents have largely been left behind. And attackers know it.

Many enterprise teams are doing their best with what’s been available: secrets managers to store credentials, rotation schedules to reduce risk, and scripts to wire it all together. But storing a credential isn’t the same as securing an identity. Legacy tools weren’t designed to offer scale, enforce policy, or provide runtime assurance — and they often fall short in dynamic, distributed environments.

Let’s quickly examine five real-world breaches – all different in scope and target, but united by a shared failure: poor control over how non-human identities authenticate and access systems. We’ll also share lessons learned and how the Aembit Workload IAM Platform can help.

1) BeyondTrust: API Key + CVE = Privilege Escalation

In December 2024, BeyondTrust discovered anomalous behavior in its Remote Support SaaS environment. An API key had been compromised — one that allowed password resets for local application accounts. But that was just the beginning.

Attackers paired the static and overprivileged credential with a critical command injection vulnerability (CVE-2024-12356, CVSS 9.8). The result: unauthenticated remote code execution and privilege escalation across systems. While the breach affected a limited set of customers, it served as a clear example of how a single, unmonitored credential can become the pivot point for a deeper compromise.

Diagram of BeyondTrust breach.

How the Aembit Workload IAM Platform would have helped:

  • Eliminates the need for long-lived API keys entirely.

  • Issues short-lived credentials tied to workload identity and posture.

  • Enforces policy at the point of access — so even if a CVE is exploited, a credential alone isn’t enough.

2) tj-actions: CI/CD Bot Breach Spreads via Pipelines

Adversaries compromised the tj-actions/changed-files GitHub Action by stealing credentials from a maintainer’s bot account. They pushed a malicious version that injected a memory scraper into thousands of CI/CD pipelines, exposing secrets like AWS keys, GitHub tokens, and RSA private keys.

The attack began as a targeted campaign against Coinbase’s agentkit project but quickly scaled. Mutable tags, long-lived secrets, and lack of workload identity controls allowed the breach to spread to at least 218 repositories.

How the Aembit would have helped:

  • Replaces static CI/CD secrets with short-lived, just-in-time credentials.

  • Prevents bot and pipeline misuse with identity-based, policy-enforced access.

  • Ensures secrets aren’t stored in memory or exposed in logs.

3) Cloudflare: Supply Chain Breach via Forgotten Tokens

Following the 2023 Okta breach, Cloudflare rotated over 5,000 credentials and scanned nearly 4,900 systems. But they missed one access token and three service account credentials — just enough for nation-state actors to infiltrate their Atlassian environment, access sensitive documentation, and potentially establish long-term persistence.

Diagram of Cloudflare-Okta breach

The episode was a stark example of supply chain blast radius – where a breach at a major identity provider cascaded into downstream compromise. 

How Aembit would have helped:

  • Requires both token validity and verified workload identity at runtime.

  • Denies access if a credential is used by an unauthorized workload — even if the token is technically valid.

  • Lights up suspicious usage patterns immediately, with full authentication logging.

4) New York Times: Hardcoded Token Leaks 270GB

In January 2024, a GitHub credential exposed in code gave attackers unauthorized access to The New York Times’ private repositories. They exfiltrated 270GB of source code and internal data, including Wordle projects, WordPress database info, and embedded API secrets.

How Aembit would have helped:

  • Prevents hardcoded credentials in codebases by issuing them at runtime.
  • Validates access based on workload identity – even if a token is leaked, it can’t be reused elsewhere.
  • Neutralizes the impact of exposed source code by ensuring there are no secrets embedded to begin with.

5) Microsoft: Stolen Key Enables Token Forgery

Storm-0558, a suspected Chinese nation-state group, extracted a consumer signing key from a crash dump and used it to mint tokens for Microsoft Outlook environments. Over 25 organizations – including U.S. government agencies – were impacted, with sensitive diplomatic communications compromised.

Diagram of Storm-0558-led breach.

How Aembit would have helped:

  • Supports multiple trust providers and validates identity context dynamically.

  • Blocks access even if credentials appear valid, unless the calling workload meets strict trust conditions.

  • Adds MFA-like capabilities – a core tenet of zero trust, finally applied to workloads.

Secure Workload Access Can’t Be Left to Legacy Practices

Recent breaches at major organizations revealed a common vulnerability: compromised workload-to-workload access. In each case, attackers exploited outdated security practices that remain widespread across industries.

Hardcoded credentials, overprivileged service accounts, and static API keys were never designed for today’s dynamic environments. The evidence is clear—these mechanisms cannot withstand modern attack techniques, scale requirements, or the complexity of distributed systems.

Rotating secrets more frequently provides marginal improvement at best. Secrets management tools alone cannot solve the fundamental problem: as long as credentials remain persistent, embedded, or implicitly trusted, they represent significant security liabilities.

Aembit delivers a fundamentally different approach:

  • Elimination of stored or hardcoded secrets.
  • Just-in-time credential issuance based on verified workload identity.
  • Access governed by real-time policy enforcement, not static configuration.

When credentials don’t persist in your environment, they can’t be compromised. When access depends on continuous identity verification and contextual controls, it remains secure even when other defenses fail.

To try the Aemibit Workload IAM platform for free or receive a demo, visit aembit.io.

Aembit logo

The Workload IAM Company

Manage Access, Not Secrets

Boost Productivity, Slash DevSecOps Time

No-Code, Centralized Access Management

You might also like

How my week went exploring the emerging WIMSE standard and the meticulous work shaping secure, cross-domain workload interactions.
Non-human identities can now access Azure resources securely, without hardcoded credentials or custom code.