The Mythos Breach Was a Non-Human Identity Problem. So Is Yours.

If you’ve been paying attention this week, you’ll know the story. Anthropic announced Claude Mythos Preview on 7 April. An AI model so capable at finding and exploiting software vulnerabilities that the company decided it was too dangerous to release publicly. Access restricted to roughly 50 trusted organisations under Project Glasswing. Microsoft, Apple, AWS, the major US banks, that sort of company.

And then, on the day of announcement, a group on a private Discord guessed the model’s URL based on Anthropic’s naming conventions, used shared API keys belonging to a third-party contractor, and walked right in. They’ve been using it ever since.

Read that back. The most sensitive AI model in the world, guarded by one of the most safety-focused labs in the industry, breached through a shared credential belonging to a non-human identity. Not a zero-day. Not a prompt injection. A contractor’s API key.

This is the whole story of modern identity security. And if you think your estate is any better protected, I’ve got some bad news.

What We Actually Mean by Non-Human Identity

Let’s get the terminology out of the way, because it’s a mess.

Non-human identity, or NHI, covers anything that authenticates to a system that isn’t a person. In a Microsoft environment that typically means:

• Service principals in Entra ID, used by applications to call APIs
• Managed identities, Microsoft’s recommended pattern for Azure workloads authenticating to Azure services
• Application registrations, the definition of the app itself plus its credentials
• Service accounts, usually ancient AD objects with a password that rotates never
• API keys and access tokens, sitting in config files, Key Vaults, environment variables, and depressingly often, Teams chats
• Certificates, used for authentication to everything from Exchange Online to SCEP profiles on managed devices
• Workload identities, the broader Microsoft term that covers SPNs and managed identities under Entra Workload ID

The typical enterprise has somewhere between 10 and 50 non-human identities for every human identity. Most organisations cannot tell you with confidence how many they have, who owns them, what they’re for, or when the credentials were last rotated.

Why NHIs Are the Hardest Identity Problem to Solve

Humans have MFA, Conditional Access, passwordless, session policies, sign-in risk scoring, and a whole industry of tooling built around protecting them. NHIs typically have a secret or certificate, often with an expiry measured in years, and a set of API permissions granted at creation and never reviewed.

Three things make this genuinely difficult.

They don’t sit still. A human joins, moves, or leaves and HR tells you. An NHI gets created when a developer needs to integrate two systems, and nobody tells anyone. The first time your identity team hears about it is when the secret expires and production breaks.

They’re often over-privileged. The developer who created the SPN asked for the permissions they needed to get the integration working, plus a bit more in case they needed them later. Nobody has ever reviewed this. Five years later the integration is still running with Global Reader, or worse.

Ownership is fiction. Pull any estate’s SPN inventory and you’ll find a third of them have no owner, a third have an owner who left the company, and the remaining third have an owner who has no idea what the SPN does.

This is where the Mythos breach becomes instructive. Anthropic granted a third-party contractor legitimate access for testing. The credentials got shared internally within the contractor. Someone used them in a way Anthropic never sanctioned. There’s no MFA on an API key. There’s no sign-in risk detection on a workload identity without the right licensing. The guardrails for humans don’t apply.

The Microsoft Stack, Honestly Assessed

Microsoft has genuinely good tooling for NHI, but it’s scattered across products and licences, and most customers aren’t using half of what they’re paying for. Here’s what actually helps.

Entra Workload ID Premium

This is the licence you probably don’t have turned on. It adds Conditional Access for workload identities, sign-in risk detection for service principals, and access reviews specifically for workload identity permissions. It’s a per-workload-identity licence which makes the commercials interesting at scale, but for high-privilege SPNs the cost is trivial compared to the blast radius.

If you do one thing after reading this post, work out which of your service principals have privileged roles and put Workload ID Premium on them. Conditional Access restricting those SPNs to known IP ranges alone would have stopped the Mythos-style attack vector dead.

Managed Identities, Everywhere You Can

Every time you use a managed identity instead of an SPN with a client secret, you eliminate a credential that can be stolen. Azure rotates the underlying tokens automatically. There’s nothing to leak into a Teams chat.

If you’re still creating SPNs with client secrets for Azure-to-Azure authentication in 2026, stop. User-assigned managed identities solve this cleanly and the developer experience is genuinely better.

Access Reviews for Application Permissions

Entra ID Governance includes access reviews for applications. Run them quarterly on anything with Graph permissions above User.Read.All. Make the application owner certify the permissions are still needed. Watch what happens.

The first review will be painful. The fifth will take twenty minutes and will catch things that matter.

Secret Expiry, Enforced

The default expiry for a client secret in Entra is generous, but you can cap it tenant-wide using Application Management policies. Enforce a maximum of, say, 180 days. Combine with a policy that restricts asymmetric key credentials to 12 months and you’ve removed the “secret created in 2019 and never rotated” problem.

This breaks things. Do it anyway. Breaking things on your schedule is better than an attacker breaking things on theirs.

Defender for Cloud Apps — OAuth App Governance

Sitting inside Defender for Cloud Apps is an OAuth app governance capability that most customers don’t use. It scores third-party and first-party applications connected to your tenant, flags suspicious behaviour, and lets you revoke consent in bulk. For any tenant that’s been running for more than a couple of years, the first scan will horrify you.

Entra ID Governance for Lifecycle

Lifecycle workflows work for users, but the broader governance capabilities — combined with custom security attributes on workload identities — let you build ownership into the identity itself. Tag every SPN with an owner, a business justification, and an expiry date. Build reporting on SPNs missing those tags. It’s not elegant but it works.

The Mythos-Specific Takeaways

A few lessons land particularly hard given how the Mythos access played out.

Third-party vendor NHIs are your biggest gap. When you grant a vendor access for integration, testing, or support, you are granting an NHI. You have no visibility into how they manage that credential internally. Assume it’s sitting in a shared password manager that thirty people can access. Price that risk accordingly, and put compensating controls on the tenant side.

Shared credentials are the original sin. The Mythos contractor used a shared account. This is still incredibly common. Every NHI should be unique to its purpose, owned by one person, and rotated when that person moves.

URL predictability matters. The Discord group found Mythos because Anthropic’s URL conventions were predictable from prior leaks. Any security-through-obscurity assumption in your own estate — admin portals on predictable subdomains, test environments reachable from the internet, function apps with default naming — is a disclosure waiting to happen. Assume your URLs are known.

Monitoring is the backstop. None of the above prevents a determined attacker with valid credentials. What catches them is behavioural detection on the workload identity itself. Sign-in from an unexpected IP, token use outside business hours, a sudden spike in API calls. You need Workload ID Premium and a SIEM ingesting the signals to make this real.

Where to Start on Monday Morning

If your eyes have glazed over, I don’t blame you. There’s a lot here. Three things to do on Monday.

1. Run a privileged SPN audit. Pull every application with a Directory Role or a Graph permission above User.Read.All. For each one, find the owner, validate the business case, and rotate the secret. This will take a week. It’s worth it.
2. Enable Conditional Access for workload identities on your top 20 SPNs. Restrict them to known IP ranges. If a legitimate integration needs more flexibility, deal with that case individually. The default for everything else should be locked down.
3. Put a secret expiry cap in place. 180 days for new secrets, grandfather existing secrets with a 12-month deadline to migrate. Yes, it will break things. Better you break them.

None of this is new advice. The tooling has been available for years. The Mythos breach should be the nudge that makes it actually happen, because the attackers are not going to wait for your next governance initiative.

The most powerful offensive security AI ever built got compromised through a contractor’s shared API key. If that doesn’t focus the mind on non-human identity, nothing will.