In April, Anthropic announced Claude Mythos Preview and chose not to release it to the public. The model was good enough at offensive security work that the company judged broad access too risky, so it gave the model to a small coalition instead. Project Glasswing launched on April 7 with twelve organizations, including AWS, Apple, Google, Microsoft, CrowdStrike, and Palo Alto Networks, using Mythos Preview to find and fix vulnerabilities in critical software. Anthropic backed it with up to $100 million in usage credits and $4 million in donations to open-source security organizations.
By late May, Anthropic reported that Glasswing partners had found more than 10,000 high- or critical-severity vulnerabilities in critical software. Some of those bugs had survived decades of human review and automated testing, including a 27-year-old flaw in OpenBSD's TCP handling and a 16-year-old FFmpeg bug that millions of automated test runs had missed.
Most coverage has focused on the vulnerability counts. For enterprise architects, the more useful question is what happens between the day a bug is found and the day it is patched in your environment. That window has always existed. This spring, the number of bugs sitting in it went up, and so did the speed at which attackers can move through it.
When finding and exploiting software flaws gets cheap, some exploits will land. What an attacker can do after that depends on identity: which credentials are on the compromised host, which tokens can be replayed, which roles are permanently assigned, and which workloads hold long-lived secrets.
What Mythos Actually Changed
Fuzzers, static analysis, and dependency scanners have produced findings at scale for years. They found candidates, and a skilled human then had to confirm each one, work out how to reach it, and build a working exploit. That last step was expensive, and it limited how many bugs any attacker could use. Mythos does that step itself.
Anthropic reported that the model chained several Linux kernel vulnerabilities together to escalate a basic user account to root without human guidance. Independent testers noticed the same pattern. Analyses published in May found the model especially good at turning individual vulnerabilities into end-to-end attack chains.
The validation numbers matter too, because false positives are what usually kill automated findings. Anthropic scanned more than 1,000 open-source projects and found 6,202 high- or critical-severity vulnerabilities. Of the 1,752 findings reviewed by Anthropic and six independent security firms, more than 90% were confirmed as real. A tool with that accuracy sends findings straight into remediation queues at a volume those queues were never sized for.
Anthropic drew the right conclusion from its own data. Its first Glasswing update said software security used to be limited by how fast defenders could find vulnerabilities, and is now limited by how fast they can verify, disclose, and patch what AI finds.
For an enterprise security team, the queue grew in April and the patch process did not. The number of known, exploitable flaws in the software you run went up and will keep going up.
These Capabilities Will Spread
Glasswing gives defenders a head start, and Anthropic has said the head start won't last. Its own announcement warned that, given the pace of AI progress, these capabilities will spread soon, possibly to people who will not use them responsibly.
This is already happening. Anthropic has said it expects other AI companies to reach Mythos-level capability soon, and OpenAI has released its own cybersecurity-focused model, GPT-5.5-Cyber, to a large group of testing partners. Those are controlled releases. The concern is the next tier: open-weight models that get close enough, fine-tuned by people who never signed a coalition agreement.
It also matters who gets protected first. Glasswing members find and patch vulnerabilities in the software they maintain before public disclosure. Coverage has grown, and in early June Anthropic expanded access to 150 organizations across 15 countries, focused on power, water, healthcare, and communications. Your enterprise runs far more than the software those organizations maintain. It runs line-of-business applications, vendor appliances, internal tools written in 2014, and a long tail of open-source packages nobody on your team has read. Attackers with equivalent tooling will go looking there.
The planning assumption for the next two to three years should be that exploitable bugs in your environment will be found faster than you can patch them. The rest of this post is about designing for that.
The Patch Gap Is Now the Main Attack Window
Every organization has a patch gap: the time between a fix becoming available and that fix being deployed everywhere it needs to be. For well-run endpoint fleets it can be days. For servers it is often weeks. For appliances, operational technology, and anything under a change freeze, it can be months or years.
There is also a gap before that one, between a bug existing and anyone publishing a fix. Historically that gap was long but mostly harmless, because nobody knew about the bug. Mythos shrinks the discovery side dramatically. More bugs get found, and both defenders and attackers can find them.
The combined effect is that at any given moment, the software in your environment contains more known-exploitable flaws than it did a year ago. Some are known only to whoever found them. Others are disclosed but not yet patched in your estate. Your vulnerability management program will still reduce that number, but it will not get it to zero, and the queue will grow faster than your team.
Many organizations treated patching as the primary control and everything else as backup. That held up while exploit development was slow and expensive. It stops holding up once exploits are cheap.
The better model is to assume an attacker can get code running on some host in your environment. Maybe it is a web server with an unpatched library, or a developer laptop with a browser zero-day. Then ask what the attacker can reach from there. Answering it mostly means looking at identity.
Why Identity Decides the Outcome
An exploit gives an attacker code execution in the context of some process on some machine. On its own, that is rarely the goal. Attackers want data, money, persistence, or control over systems they did not initially reach. To get any of those, they have to move, and moving in a modern enterprise means authenticating to something.
Look at what sits on a typical compromised host:
- Cached credentials and tokens for whoever is signed in, including refresh tokens that can outlive the session.
- Service account passwords in configuration files, environment variables, or scheduled tasks.
- API keys and connection strings in application settings.
- On cloud VMs, a metadata endpoint that will hand out tokens for any managed identity assigned to the machine.
- On developer machines, CLI sessions for cloud providers, source control tokens, and package registry credentials.
- Kerberos tickets and, on domain-joined Windows machines, whatever the local security authority has in memory.
Every one of those is an identity artifact, and each one decides how far the attacker gets. If the web server's managed identity has Contributor on the subscription, a single library bug becomes a subscription compromise. If the developer is permanently assigned Global Administrator, a single browser bug becomes a tenant compromise. If a service account password in a config file is shared across 40 servers, one server becomes 40.
This is why the numbers in my Identity Management as a Tapestry post look the way they do. Identity weaknesses show up in most incident investigations because attackers use them after the initial foothold, however that foothold was gained. Mythos makes footholds cheaper and more frequent, but attackers still do the same things once they have one.
So the architecture question becomes how much a single compromised host, process, or credential can actually do. If the answer is "very little, for a short time, and we will notice," you can absorb a high exploit rate. If the answer is "anything the most privileged account on that machine could do, indefinitely," you cannot.
Design Principle: Assume the Exploit Lands
"Assume breach" has been a Zero Trust slogan for years. Most organizations applied it to network design and stopped there. Cheap exploits force you to apply it to identity, because identity is where blast radius gets decided.
In practice that means four changes: just-in-time privilege, short credential lifetimes, tokens bound to the device that received them, and treating identity infrastructure as software with bugs.
Remove Standing Privilege
Standing privilege is the biggest multiplier of damage from any exploit. An account that is always an administrator turns every compromise of that account's session into an administrative compromise.
Privileged Identity Management in Entra solves most of this for cloud roles. Administrative roles become eligible instead of active. Activation requires a justification, optionally an approval, and a fresh multi-factor challenge, and it expires after a set window. An attacker who lands on an admin's laptop while no role is active finds a regular user session. To go further, they would have to trigger an activation, which generates an audit event and, if configured, an approval request to someone else.
Two details decide whether PIM holds up under pressure. The first is separate administrative accounts. If the same identity is used for email, browsing, and role activation, any browser or document exploit reaches an account one activation away from admin. Separate accounts, used only from hardened devices, break that chain. The second is scope. Tenant-wide roles like Global Administrator and Privileged Role Administrator should have very few eligible members, and those roles should require approval. Most administrative work can be done with narrower roles scoped to administrative units or resource groups.
The same applies to Azure resources. Subscription Owner and Contributor assignments made years ago for convenience are standing privilege. Move them into PIM for Azure resources, scope them down, and make activation time-bound.
On-premises Active Directory is harder. Tiered administration, separate admin forests, and just-in-time group membership through Microsoft Identity Manager's PAM feature or a third-party privileged access platform are all options, and none are quick. If you still have large on-premises footprints, start with Domain Admins. Every permanent member is a path from one exploited workstation to the whole domain.
Shorten Credential Lifetimes
A stolen credential is valuable in proportion to how long it keeps working. A client secret with a two-year expiry, taken from an app configuration file, gives an attacker two years of access unless someone notices and rotates it. Most organizations do not notice.
The fix is to stop issuing long-lived secrets wherever the platform allows it.
For workloads running in Azure, managed identities remove the secret entirely. The platform issues tokens to the resource on demand, and there is nothing to store or leak. Code running on the host can still pull tokens from the metadata endpoint, which is why managed identity permissions have to be tightly scoped, but there is no secret that works from outside the host.
For workloads outside Azure, such as GitHub Actions, Kubernetes clusters in other clouds, or on-premises systems with their own token issuer, workload identity federation lets them exchange a token from their own platform for an Entra token. No client secret is stored on either side. This is the single most effective change you can make to CI/CD pipelines, which are among the most attractive targets in any environment. A pipeline with a long-lived deployment secret is a standing path to production.
Where secrets cannot be avoided, prefer certificates over client secrets, keep lifetimes short, store them in Key Vault with access restricted to the identity that needs them, and automate rotation. Treat any secret older than its intended rotation window as a finding.
For users, the equivalent is phishing-resistant authentication. Passwords are long-lived secrets. They get reused, typed into fake pages, and pulled from memory. FIDO2 security keys, passkeys, Windows Hello for Business, and certificate-based authentication bind sign-in to a device and to the legitimate site, which removes most of the value of a stolen password. Entra's authentication strengths let you require phishing-resistant methods for specific applications or roles through Conditional Access. Start with administrators and anyone with access to financial systems.
Make Stolen Tokens Useless
Phishing-resistant sign-in does not help if an attacker can steal the token issued after sign-in and replay it from their own machine. Token theft is already one of the most common ways around multi-factor authentication, and code execution on an endpoint makes it trivial.
Three Entra capabilities address this.
Token Protection, configured as a Conditional Access session control, binds sign-in session tokens to the device they were issued to. A token copied off the device and replayed elsewhere fails validation. Coverage depends on client platform and application, so check current support for your environment, but where it applies it closes the replay path.
Continuous Access Evaluation lets supported services reject tokens in near real time when a critical event happens, such as the account being disabled, the password being reset, or the user's network location violating policy. Without it, a revoked user's access token keeps working until it expires.
Conditional Access device compliance requirements limit which devices can get tokens in the first place. If a sensitive application only accepts sign-ins from compliant, managed devices, an attacker with a stolen password on their own machine gets nothing.
Each control covers a different gap. With all three in place, a stolen token works only on the original device, only until the next policy check, and only while that device stays compliant.
Treat Identity Infrastructure as Vulnerable Software
Most identity programs skip this part. The systems that issue and validate identity are software, written in the same languages and prone to the same kinds of bugs as everything Mythos has been finding.
Glasswing produced a clear example. Anthropic said Mythos Preview built an exploit for a wolfSSL vulnerability that could let an attacker forge certificates and make a fake bank or email site appear legitimate. Certificate validation is a trust anchor for TLS, code signing, smart card logon, and certificate-based authentication. A bug in the library that checks certificates is a bug in your identity layer, even if nobody on the identity team owns that library.
The identity path in most enterprises includes:
- Federation servers such as AD FS, often internet-facing, often patched slowly, and able to mint tokens for every federated application.
- Domain controllers, the root of trust for on-premises AD.
- Internal certificate authorities that can issue certificates usable for authentication.
- VPN concentrators and remote access gateways that authenticate users before anything else does.
- MFA servers, RADIUS proxies, and legacy SSO gateways.
- Password reset portals and helpdesk tools with account recovery rights.
Each of these is high-value, frequently exposed, and often older than the rest of the stack. When exploits get cheaper, the attackers targeting them get more capable.
The architectural response is to run less of this yourself. Moving federation from AD FS to native Entra authentication removes an internet-facing token issuer you would otherwise have to patch at the speed of the threat. Replacing VPN-first access with identity-aware access to individual applications reduces what a single gateway compromise exposes. Managed services have bugs too, but their operators patch the whole fleet at once, and several of the largest are Glasswing members with direct access to the tooling finding those bugs.
Where you cannot move, isolate. Domain controllers, CAs, and federation servers belong in the highest administrative tier, reachable only from dedicated administrative workstations, with no internet browsing and no credentials shared with lower tiers. Active Directory Certificate Services deserves its own review. Misconfigured certificate templates are a well-documented path from ordinary user to domain administrator, and a certificate issued through one works as a long-lived credential that survives password resets.
Non-Human Identities Are the Largest Exposure
Human accounts get most of the attention because they are visible. Most of the unmanaged risk sits with non-human identities.
Service principals, managed identities, service accounts, API keys, and OAuth client credentials often outnumber human users many times over in cloud-heavy environments. They tend to carry broad permissions because someone needed an integration working quickly. They rarely have a named owner, and they almost never go through access reviews. Many hold long-lived secrets in exactly the places an exploit reaches first: configuration files, environment variables, and pipeline definitions.
With cheap exploits, each of those is a potential pivot. An attacker who compromises a reporting server does not need to escalate privileges on that server if the application's service principal already has read access to the entire data lake.
The work follows the same order as it does for user accounts.
First, build an inventory. Enumerate every service principal, app registration, managed identity, and on-premises service account. For each, record what it can access, what credentials it holds and when they expire, when it last authenticated, and who owns it. Anything that has not authenticated in 90 days is a candidate for removal.
Second, assign owners. Every non-human identity needs a named person or team accountable for it. Ownerless identities are the ones nobody notices being misused.
Third, reduce permissions. Microsoft Graph application permissions are the most dangerous category because they apply tenant-wide with no user in the loop. Mail.Read, Files.Read.All, Directory.ReadWrite.All, or RoleManagement.ReadWrite.Directory granted as application permissions let one stolen credential read every mailbox or change directory roles. Audit them, justify them, and replace them with narrower scopes or resource-specific consent where Microsoft supports it.
Fourth, replace secrets with federation or managed identities, as described above.
Fifth, apply Conditional Access to workload identities. Entra supports location-based and risk-based Conditional Access for service principals with the right licensing. A service principal that should only authenticate from your build agents' IP ranges should be blocked everywhere else, which turns a stolen secret into a credential that only works from infrastructure you control.
AI Agents Are Identities Too
The same class of models that finds these bugs is also being deployed inside enterprises as agents: assistants that read email, query databases, open tickets, run scripts, and call APIs on behalf of users.
Each agent is an identity, and many organizations have not treated them that way yet.
An agent acts either with its own identity, as an application with its own permissions, or on behalf of a user, with delegated permissions. Both carry risks traditional identity controls were not designed for.
Agents with their own identity usually get broad application permissions so they can serve many users. That is the same risk profile as any over-permissioned service principal, with one addition. An agent's behavior is driven by the content it reads, and attackers can plant instructions in that content. Prompt injection turns an agent into a confused deputy that uses its own legitimate permissions to do what an attacker asked for in a document, email, or web page. No exploit is needed, only a way to put text in front of the agent.
Agents acting on behalf of users inherit the user's delegated access unless scopes are deliberately restricted. A user with access to finance, HR, and engineering systems who connects an agent to all of them has created one component that can reach everything they can, driven by inputs from anywhere.
Start by registering every agent as a distinct identity with a named owner. Agents should never run under shared service accounts or borrowed human credentials, because you cannot review, scope, or revoke what you cannot see. Microsoft has started adding agent-specific identity constructs to Entra, and the direction is clear: agents are becoming directory objects with owners, sponsors, and lifecycle policy.
Next, keep delegated permissions narrow. Grant the smallest OAuth scopes that let the agent do its job, and require admin consent for agents requesting sensitive scopes. The admin consent workflow routes those requests to reviewers instead of forcing a choice between blocking them and approving them blindly.
Finally, separate reading from acting. An agent that summarizes documents does not need permission to send email or modify records, and an agent that does act should hit a human approval step before anything high-impact. Log and baseline agent sign-ins and API calls like any other workload, so an agent suddenly reading mailboxes it never touched shows up as a detection. Include agents in scheduled access reviews and remove the ones nobody uses.
Agent counts will grow as every business unit asks for them and every vendor ships them. If the foundation for non-human identity is weak, agents will spread that weakness faster than any previous wave of automation.
Detection Has to Move to the Identity Layer
If prevention cannot stop every exploit, detection has to catch what happens next. Endpoint detection will still see some exploits land, but Mythos-class tools produce the kind of exploits existing signatures miss. Many of these bugs survived years of scrutiny because they did not look like anything.
What attackers do after the exploit is far more consistent. They harvest credentials, request tokens, enumerate the directory, activate roles, add credentials to service principals, create inbox rules, register new devices, and grant consent to malicious applications. All of it passes through the identity layer and generates identity telemetry.
That makes identity threat detection and response one of the highest-return investments for this threat model. The signals worth prioritizing:
- Token replay from unfamiliar devices or locations, including anomalous token detections in Entra ID Protection.
- New credentials added to existing service principals or app registrations, especially privileged ones. This is a common persistence technique and should almost never happen outside a change window.
- Privileged role activations outside normal patterns, including by accounts that rarely use their eligibility.
- Consent grants to new applications requesting broad permissions.
- Workload identities authenticating from new IP ranges.
- Sudden directory enumeration, such as one account querying large numbers of users, groups, or role assignments.
Send Entra sign-in logs, audit logs, and service principal sign-in logs to your SIEM, and keep them long enough to investigate incidents that start quietly. Build response playbooks that revoke sessions, disable accounts, and remove service principal credentials in minutes. With Continuous Access Evaluation in place, revocation reaches supported services quickly. The tools speeding up exploitation also speed up everything an attacker does afterward, so dwell time is the number to drive down.
What Still Applies
Most identity fundamentals still hold, and skipping them now costs more. Phishing-resistant authentication still stops the most common initial access techniques. Least privilege still limits blast radius. Access reviews still catch drift. Separate admin accounts still break the most common escalation paths. The advice is years old; the price of ignoring it went up this spring.
Social engineering does not depend on software bugs at all. Helpdesk impersonation, MFA fatigue, and consent phishing will keep working against organizations that have not hardened account recovery and consent policy, however fast their patch cycle is.
Keep investing in patch velocity, especially for internet-facing systems and identity infrastructure. It just can't be the only control.
How the Controls Fit Together
| Control | What It Limits After an Exploit Lands | Typical Microsoft Component |
|---|---|---|
| Just-in-time privilege | Compromise of an admin's session does not grant admin rights | Privileged Identity Management |
| Separate admin accounts | Browser and document exploits do not reach privileged identities | Account tiering, privileged access workstations |
| Phishing-resistant authentication | Stolen passwords cannot be used to sign in | FIDO2, passkeys, Windows Hello for Business, authentication strengths |
| Token binding | Stolen tokens cannot be replayed from another device | Conditional Access Token Protection |
| Real-time revocation | Disabled accounts and reset credentials take effect immediately | Continuous Access Evaluation |
| Secretless workloads | No long-lived secrets to steal from compromised hosts | Managed identities, workload identity federation |
| Workload Conditional Access | Stolen service principal credentials only work from approved locations | Conditional Access for workload identities |
| Scoped application permissions | A compromised app cannot read or change the whole tenant | Graph permission review, admin consent workflow |
| Agent identity governance | Prompt-injected agents are limited to narrow, reviewed permissions | Distinct agent identities, access reviews |
| Reduced identity infrastructure | Fewer self-hosted token issuers and trust anchors to exploit | Native Entra authentication instead of on-premises federation |
| Identity threat detection | Post-exploit credential abuse is caught quickly | Entra ID Protection, Defender for Identity, Sentinel |
Common Failure Modes
Organizations that struggle with this tend to fail in familiar ways.
They treat Mythos purely as a vulnerability management problem. They buy more scanning, expand patch teams, and push for faster SLAs, all worthwhile, and never ask what an attacker could do on the day a patch is late.
They deploy PIM but leave tenant-wide roles with many eligible members and no approval requirement. Activation becomes a click, and the control adds an audit log and little else.
They enforce phishing-resistant MFA and stop there, leaving session tokens unbound and revocation slow. Attackers adapt by stealing tokens instead of passwords.
They move human users to strong authentication while service principals keep multi-year client secrets in pipeline variables. The easiest path into production runs through the build system.
They let AI agents onto the network with borrowed user credentials or shared service accounts because it was the fastest way to get a pilot working. Six months later, nobody knows how many agents exist or what they can reach.
They leave AD FS, internal CAs, and legacy MFA servers on slow patch cycles because they count as "infrastructure." Those are the systems attackers want most, and they run the same kind of code Mythos keeps finding decade-old bugs in.
In each case, a control was deployed to pass an audit and never tested against an attacker who already has a foothold.
A Practical 90-Day Plan
For a typical enterprise baseline, sequence matters more than tooling. This order produces real risk reduction early.
Days 1 to 30: Inventory and Privilege
Enumerate every account with a tenant-wide administrative role, every Azure subscription Owner and Contributor, every member of Domain Admins and Enterprise Admins, and every service principal with high-privilege Graph application permissions. Move cloud admin roles into PIM, with approval required for the most sensitive ones. Create separate admin accounts for anyone who does not already have one. Identify every self-hosted identity system, including federation servers, CAs, and MFA servers, and confirm its patch status.
Days 31 to 60: Credentials and Tokens
Require phishing-resistant authentication for all administrators through authentication strengths. Turn on Token Protection where your client platforms support it, starting with administrators and high-value applications. Confirm Continuous Access Evaluation is active. Find every client secret on privileged service principals and replace it with a managed identity, federation, or a short-lived certificate, starting with CI/CD pipelines.
Days 61 to 90: Workloads, Agents, and Detection
Assign owners to every service principal and service account, and remove the ones that have not authenticated in 90 days. Apply Conditional Access location restrictions to workload identities that should only run from known infrastructure. Register any AI agents in use as distinct identities with scoped permissions and named owners. Build detections for new service principal credentials, anomalous role activations, and token replay, then test the playbooks that revoke access.
After 90 days, set a cadence. Review privileged roles and high-permission applications quarterly, and report credential age and ownerless identities monthly. Include agents in both.
A Mythos-class exploit will still get an attacker onto a host. This plan limits what that host gives them.
Wrapping Up
Mythos found decades-old bugs in software everyone assumed was well tested, and similar tools are spreading beyond the coalition. For everything in your environment that Glasswing members don't maintain, the useful question is what one compromised host can reach. Answer it for your admin roles, service principals, pipelines, and agents, then shrink each answer.