In previous editions of Salesforce Security Signal, we’ve covered Apex security anti-patterns and Shield encryption gaps. Those posts were about defects that already exist in most orgs. Today’s topic is about who, or what, will find them next.

On April 7, Anthropic announced Project Glasswing, a coordinated cybersecurity effort built around an unreleased frontier model called Claude Mythos Preview. Anthropic says Mythos has already identified thousands of zero-day vulnerabilities across every major operating system and browser, including a 27-year-old flaw in OpenBSD. The company is deliberately withholding the model from general availability because it can not only discover vulnerabilities but also weaponize and chain them end-to-end. Mythos is being made available only to a coalition of twelve launch partners (AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, Nvidia, and Palo Alto Networks) plus roughly 40 additional critical-infrastructure organizations.

Salesforce is not on that list. Neither is the long tail of ISVs whose managed packages run inside customer orgs. That gap is the story for Salesforce security teams.

Why This Is a Salesforce Problem, Not Just an OS Problem

It’s easy to read the Glasswing announcement as a story about operating systems and browsers. The part that matters for Salesforce is the underlying capability claim: Mythos is effective at finding and exploiting software vulnerabilities in general-purpose code. Apex, Lightning Web Components, Visualforce, and Flow metadata are all general-purpose code. SOQL injection, CRUD/FLS bypass, insecure without sharing, deserialization issues in custom REST endpoints, and insecure Named Credential usage are exactly the class of defects a capable code-reasoning model is good at spotting.

Three structural facts about the Salesforce ecosystem make this uncomfortable:

1. Customer orgs contain large amounts of custom Apex that has never been formally audited. Code review at most customers is limited to PR-time review by the developers who wrote it.
2. Managed packages ship with obfuscated Apex, but the runtime behavior (endpoints, callable methods, exposed pages, sharing model) is observable from inside the org. A model that can reason about behavior from API surface alone doesn’t need source.
3. AppExchange ISVs vary enormously in security maturity. A vulnerability in a widely installed package is effectively a vulnerability in thousands of orgs at once.

If the capability to auto-discover vulnerabilities at Mythos’s claimed level proliferates before Salesforce customers have done defensive cleanup, the attack surface that gets hit hardest is the one that has been under-audited the longest: custom Apex and installed packages.

The Disclosure Window

Anthropic’s disclosure policy for Mythos findings is 135 days between notifying the affected party and publishing details. For a launch partner like Microsoft or AWS, 135 days is enough time to patch, test, and push fixes through their release train. For a Salesforce customer with a vulnerable custom Apex controller or a third-party managed package that hasn’t shipped an update in two years, 135 days is not obviously enough.

More importantly, Mythos is the model Anthropic has chosen to withhold. The capability class is what matters. Anthropic’s own statement is that these capabilities will proliferate. The defensive question for Salesforce orgs is not “what will Mythos find in my org,” because Mythos won’t be pointed at your org. It’s “what happens when a comparable capability, from any source, gets pointed at my org, and have I done the work to not be the easy target.”

What Salesforce Security Teams Should Be Doing Now

The defensive posture is straightforward. The work is not.

• Inventory custom Apex by security sensitivity. Every class marked without sharing, every @RestResource endpoint, every @AuraEnabled method, every custom Visualforce page that accepts URL parameters. These are the first places a capable analyzer will look.
• Inventory installed managed packages and cross-reference them against the last update date and the vendor’s security disclosure track record. Packages that haven’t shipped a security update in years are not “stable.” They’re stale.
• Treat Salesforce Code Analyzer, PMD rules for Apex, and Checkmarx/Fortify scans as a floor, not a ceiling. Static analysis will catch syntactic patterns. It won’t catch logic flaws or sharing-bypass chains that a reasoning model would catch.
• Accelerate least-privilege work. A vulnerability in a class that only runs for two users is materially less severe than one in a class that runs for everyone. Every profile-to-permission-set migration and every unused permission revoked reduces the blast radius of a finding.

Deeper Dive

Mapping Mythos’s Capability Claims to Salesforce-Specific Defect Classes

Anthropic’s public description of Mythos emphasizes three capabilities: identifying undisclosed vulnerabilities, writing exploitation code, and chaining multiple vulnerabilities into an end-to-end attack. Each of these maps cleanly onto defect classes that are common in Salesforce environments.

Identification: Static and Behavioral Analysis of Apex

Most Apex vulnerabilities fall into a small number of patterns:

• Dynamic SOQL built via string concatenation with user input (SOQL injection).
• DML or queries in without sharing classes that should have been with sharing or inherited sharing.
• @AuraEnabled methods that don’t perform explicit CRUD/FLS checks (Schema.sObjectType.X.isAccessible(), Security.stripInaccessible()).
• @RestResource endpoints that accept an Id parameter and return the record without verifying the caller’s sharing access.
• Custom Visualforce or LWC controllers that expose setter-based actions without re-validating permissions.
• Insecure use of Database.query() with untrusted input in merge fields.
• Deserialization of user-controlled JSON into sObjects that then get upserted without validation.

A capable code-reasoning model doesn’t need exotic tooling for this. These are pattern-matching problems with a reasoning layer on top. The reason they persist in production is not that they’re hard to find in isolation, it’s that there’s no one systematically looking across every class in every org.

Exploitation: Generating Working Payloads

The second Mythos claim, writing code that exploits the vulnerabilities it finds, is where the asymmetry gets sharp. Historically, a researcher who finds a SOQL injection in a custom @RestResource endpoint has to construct a working payload, handle the Salesforce API response format, deal with governor limits in the injected query, and produce something reliable enough to demonstrate impact. That’s skilled work, and it’s what has kept a lot of Salesforce-specific defects in the “theoretical” bucket. A model that can generate the exploit code removes that bottleneck. Theoretical findings become practical findings.

Chaining: Combining Low-Severity Findings into High-Severity Outcomes

The third capability is the one that should concern Salesforce architects the most. A single @AuraEnabled method that skips FLS is a medium-severity finding. A without sharing utility class is a medium-severity finding. An unauthenticated Experience Cloud page that calls into an Apex controller is a medium-severity finding. Chained together, they can become a full record exfiltration path.

The historical reason chained exploits are rare in Salesforce security research is that chaining requires deep familiarity with both the org’s custom code and the platform’s runtime behavior. A reasoning model that can hold the full call graph in context removes that barrier. Each individual link is already present in most large orgs. The chain is what makes them dangerous.

What Salesforce Customers Can’t Assume

There are three assumptions about the Salesforce security model that get less defensible in a post-Mythos world:

1. “The platform is secure, so our code inherits that.” Salesforce’s shared responsibility model has always put custom code on the customer. That line is now much sharper. Platform-level vulnerabilities (the kind Salesforce itself patches) are a small fraction of the total Salesforce attack surface. The large fraction is customer code and ISV code.
2. “Nobody is looking at our Apex.” Historically, this has been approximately true for most orgs. Apex vulnerability research has been a small field, and attackers with Salesforce-specific skills have been rare. Both of those constraints relax if vulnerability discovery becomes model-assisted.
3. “Our managed packages are audited by Salesforce.” AppExchange security review is real, but it’s a one-time review at submission (or major-version update). It does not prevent vulnerabilities from being discovered post-review, and it does not force vendors to ship patches on any particular cadence.

Defensive AI in the Salesforce Context

The Glasswing announcement is not purely bad news. Anthropic’s broader thesis is that the same capabilities that make Mythos dangerous in attacker hands will, over time, benefit defenders more. That thesis is applicable to Salesforce security work.

Practical defensive applications that are already possible today with general-availability models (not Mythos itself):

• Apex code review at scale. Feeding every Apex class in an org into a code-reasoning model with a structured prompt asking for CRUD/FLS compliance, sharing-mode correctness, and injection risks. This is roughly what a senior Salesforce security reviewer does on a PR, extended to the entire codebase.
• Permission set and profile analysis. Models are effective at summarizing the effective permission set of a user across stacked permission sets, permission set groups, and profile. This directly supports the least-privilege work that reduces blast radius.
• Sharing rule and role hierarchy reasoning. Salesforce sharing is notoriously hard to audit by hand because the effective visibility of a record depends on ownership, role hierarchy, sharing rules, manual shares, territory management, and Apex-managed sharing. A reasoning model can walk that graph for a specific scenario and explain why a given user can or can’t see a given record.
• Managed package risk assessment. Even without package source, a model can reason about the public API surface of an installed package: exposed global methods, REST endpoints, remote site settings, named credentials, and custom metadata. That produces a threat model without requiring a decompiler.

None of these require Mythos-level capability. They require that someone actually do the work.

What Anthropic Is Signaling (And What It Means for Your Org)

There are two signals in the Glasswing announcement worth taking seriously.

The first is that Anthropic thinks the capability is real and imminent enough to withhold a model over. This is the first time in nearly seven years that a frontier lab has publicly withheld a model on safety grounds. The last time was OpenAI’s GPT-2 decision in 2019, and that decision aged into being widely regarded as overcautious. Anthropic’s willingness to repeat it suggests internal confidence in the capability evaluation, not caution theater.

The second is that the launch partner list tells you who Anthropic thinks needs this capability first. It’s the hyperscalers, the OS and browser vendors, the foundational network and security vendors, and a single major bank. Salesforce is absent. The SaaS ecosystem generally is absent. This is not a judgment about whether SaaS platforms have vulnerabilities worth finding. It’s a judgment about which organizations are positioned to act on findings at scale within the 135-day disclosure window.

For Salesforce customers, the practical implication is that the defensive cleanup is going to have to happen customer-by-customer, without the benefit of a centralized coalition that catches issues before disclosure. That means the work is on you.

The Bottom Line

Project Glasswing is a statement that frontier AI models have reached a capability level where finding and exploiting software vulnerabilities at scale is no longer gated on expert human time. Anthropic has chosen to release that capability carefully, through a coalition focused on critical infrastructure. That’s the responsible path, but it’s also not permanent. Equivalent capability will proliferate, and when it does, the organizations that will absorb the impact are the ones that haven’t done the defensive work.

For Salesforce, the defensive work is known, and it’s the same work that’s been on the list for years: audit custom Apex, inventory managed packages, enforce least privilege, and assume any code running in your org could be read and reasoned about by something more capable than the person who wrote it. The difference now is urgency.

If your org hasn’t done a systematic Apex security review, or hasn’t looked at your installed package inventory against vendor update history, those are the two places to start.

Book a 15-Minute Security Strategy Call

Reference(s):

https://www.anthropic.com/glasswing

https://red.anthropic.com/2026/mythos-preview/

https://www.csoonline.com/article/4155342/what-anthropic-glasswing-reveals-about-the-future-of-vulnerability-discovery.html

https://venturebeat.com/technology/anthropic-says-its-most-powerful-ai-cyber-model-is-too-dangerous-to-release

https://thehackernews.com/2026/04/anthropics-claude-mythos-finds.html

https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/security_code_review.htm

‍