Two weeks ago on the Tython blog, we covered Project Glasswing and what Claude Mythos means for Salesforce security. The central argument was that Mythos-class vulnerability discovery capability would proliferate, and that Salesforce orgs needed to do defensive work before it did. The piece ended with a question: have you done the work to not be the easy target?

That question aged faster than expected. On April 22, reports confirmed that a group of users gained unauthorized access to Claude Mythos Preview through a third-party contractor’s credentials. The group used information from the earlier Mercor breach to locate the model, and according to reporting, still has access. Anthropic has confirmed it is investigating.

How It Happened–And Why the Vector Matters More Than the Model

The breach path is straightforward. A third-party contractor for Anthropic had access to internal environments. A member of the group that accessed Mythos was that contractor, or had access through them. Information leaked in the separate Mercor breach helped the group identify where the model was hosted. They used the contractor’s access to reach it.

This is not an exotic attack. It is the most common breach pattern in enterprise software: a third party with legitimate access to one part of the environment uses (or loses) that access in a way that reaches something they were never meant to touch. Anthropic limited Mythos to 40 organizations and it leaked within weeks. The mechanism was a contractor.

The Salesforce Parallel

Every Salesforce org has its own version of this. Implementation partners, managed service providers, AppExchange vendors, and freelance consultants routinely receive elevated access to customer orgs. That access typically includes:

• System Administrator profiles or permission sets with Modify All Data
• Delegated administration rights scoped broadly enough to create users and assign permissions
• Connected apps authorized during an engagement that persist indefinitely after the engagement ends
• Integration users whose credentials are managed by the external party, not the customer

The Mythos breach pattern–contractor access, combined with information from a separate breach, leading to unauthorized access to something sensitive–maps directly to how Salesforce orgs get compromised through their vendor relationships. A consultant whose credentials were exposed in a breach at another client. An SI that authorized a connected app with full API scope and never revoked it. A managed service provider whose integration user still has Modify All Data two years after the contract ended.

What to Do Now

The previous article focused on preparing for AI-assisted vulnerability discovery. This one is narrower: audit your third-party access before someone else does.

• Identify every active user account belonging to someone outside your organization. Query User records where the email domain doesn’t match your company. Check which of those accounts have admin-level profiles or permission sets.
• Inventory connected apps and check who authorized them. Connected apps installed by a former consultant during an engagement are still active unless someone explicitly revoked them. Look for apps with refresh tokens that never expire.
• Review integration users managed by external parties. If a third party controls the credentials for an integration user in your org, you have the same exposure Anthropic had: a contractor whose own security posture determines yours.
• Time-box elevated access. If a consultant needs System Administrator for a two-week sprint, assign a permission set that gets removed at the end of the engagement–not a profile that persists until someone remembers to deactivate the account.
• Rotate credentials for any integration user that has been accessed by an external party. If you don’t know when credentials were last rotated, the answer is “too long ago.”

Deeper Dive

The Anatomy of Third-Party Access Compromise in Salesforce

The Mythos breach followed a pattern that security teams call “trusted-path compromise”: the attacker didn’t break in through a vulnerability. They walked in through a door that was left open for a legitimate purpose. The contractor had real access. The problem was that the access was broader than necessary and persisted longer than it should have.

In Salesforce orgs, trusted-path compromise through third parties takes several specific forms:

System Administrator Profiles Granted to Consultants

The most common anti-pattern. An SI engagement begins, the project team needs a handful of consultant accounts, and the fastest path is to clone the System Administrator profile or assign it directly. The consultants get Modify All Data, View All Data, Manage Users, Author Apex, and every other system-level permission. The engagement ends. The accounts stay active, either because no one owns the deactivation process or because “we might need them again.”

The risk is not that the consultant is malicious. It’s that the consultant’s own security–their email account, their laptop, their password manager–now determines whether an attacker can reach your org with full admin access. This is exactly the Mythos pattern. Anthropic’s contractor wasn’t the threat. The contractor’s access was the threat.

Connected Apps That Outlive Engagements

When an SI builds an integration during an implementation, they often create a connected app in the customer’s org. That connected app has OAuth scopes–sometimes full or api–and it authorizes an external system to access the org on behalf of users. After the engagement ends, the connected app remains installed. The OAuth tokens it issued may still be valid. If the SI’s infrastructure is compromised, those tokens provide a direct path into the customer’s org.

Connected apps are particularly dangerous because they don’t show up in the user list. An admin auditing active users won’t see them. They’re visible under Setup > Connected Apps OAuth Usage, but most teams never look there.

Integration Users with External Credential Management

Many Salesforce integrations authenticate using a dedicated integration user. When the integration is managed by a third party–a middleware vendor, a managed service provider, a marketing platform–the third party often controls the credentials for that user. The customer org has a user account with elevated permissions whose password, security token, or OAuth refresh token is stored in someone else’s system.

If that third party is breached, the integration user’s credentials are exposed. The attacker doesn’t need to breach the Salesforce org. They breach the third party and inherit the access the third party already had.

Delegated Administration Overreach

Salesforce’s delegated administration feature allows admins to grant other users the ability to manage users, assign permission sets, and reset passwords within a defined scope. In practice, the scope is often set too broadly. A managed service provider granted delegated admin rights to manage their own team’s accounts may also be able to create new accounts, assign permission sets to users outside their team, or reset passwords for other admins.

The Mythos contractor didn’t need full system access to cause the breach. They needed enough access to locate the model and reach it. In Salesforce terms, delegated admin access that’s scoped too broadly gives a third party the ability to escalate their own privileges or create new access paths that weren’t intended.

Auditing Third-Party Access in Your Org

The following queries and checks identify the most common third-party access exposures. These are starting points, not comprehensive audits.

Identify External Users with Elevated Access

Query active users whose email domain doesn’t match your organization and check their profiles and permission set assignments:

SELECT Id, Username, Email, Profile.Name, IsActive, LastLoginDate
FROM User
WHERE IsActive = true
AND Email != null
AND (NOT Email LIKE '%@yourcompany.com')
ORDER BY LastLoginDate DESC

Cross-reference results against your list of active vendor engagements. Any user who doesn’t map to a current engagement should be deactivated immediately.

For permission set assignments on those users:

SELECT Assignee.Username, Assignee.Email, PermissionSet.Name, PermissionSet.IsOwnedByProfile
FROM PermissionSetAssignment
WHERE Assignee.IsActive = true
AND (NOT Assignee.Email LIKE '%@yourcompany.com')

Look for permission sets that grant Modify All Data, View All Data, Manage Users, Customize Application, or Author Apex. Any external user with these permissions needs justification.

Audit Connected App Authorization

Check which connected apps are installed and actively used in your org:

SELECT AppName, UserId, User.Username, UseCount, LastUsedDate
FROM OAuthToken
ORDER BY LastUsedDate DESC

Look for connected apps where LastUsedDate is recent but the associated engagement ended months or years ago. Also look for apps where the installing user is a former consultant.

Check Login History for Third-Party Access

Review login history to understand which third-party accounts are actively being used and from where:

SELECT UserId, LoginTime, SourceIp, LoginType, Status, Application
FROM LoginHistory
WHERE LoginTime = LAST_N_DAYS:90
AND UserId IN (SELECT Id FROM User WHERE NOT Email LIKE '%@yourcompany.com')
ORDER BY LoginTime DESC

Flag logins from unexpected IP ranges, logins using API access (which may indicate automated credential use), and logins to accounts that should have been deactivated.

Review Integration User Credentials

For each integration user in your org:

1. Determine who controls the credentials (internal team or third party).
2. Check whether the user authenticates via password + security token, OAuth, or JWT. Password-based authentication with a static security token is the highest risk.
3. Determine when credentials were last rotated.
4. Check whether the user’s connected app has refresh tokens that never expire (RefreshTokenPolicy in the connected app settings).

Any integration user whose credentials are controlled by a third party and haven’t been rotated since the engagement started is an open exposure.

The Mercor Breach Parallel

A critical detail in the Mythos leak is that the group used information from a prior, unrelated breach–the Mercor breach–to locate the model. They didn’t need to extract that information from Anthropic. They got it from a different company’s data that pointed them in the right direction.

This pattern has a direct parallel in Salesforce security. Consultants and SIs work across many clients. A credential exposed in a breach at Client A may work at Client B if:

• The consultant reused passwords across client orgs (common when orgs require username/password authentication for sandbox access).
• The consultant’s email account was compromised and contained Salesforce login URLs, usernames, or security tokens for multiple clients.
• The SI’s internal systems (Confluence, Jira, Slack, shared drives) contained client org credentials and those systems were breached.

The Mercor breach didn’t compromise Anthropic directly. It provided the context that made the Mythos access possible. A breach at an SI or consulting firm can do the same thing to every Salesforce org that SI has ever touched.

This is why credential rotation at the end of every engagement is non-negotiable, and why monitoring for credential reuse across environments matters.

Third-Party Access Governance Framework

A governance framework for third-party access to Salesforce doesn’t need to be elaborate. It needs to be enforced.

At Engagement Start

• Create dedicated user accounts for each external party. Never share accounts across vendors or reuse accounts from previous engagements.
• Assign a purpose-built permission set scoped to the minimum access required for the engagement. Never assign the System Administrator profile.
• Set an expiration reminder. Salesforce doesn’t natively expire user accounts, so this needs to be tracked externally (calendar reminder, project management tool, or a scheduled Flow that deactivates users after a defined date).
• Document the access granted, including permission sets, connected apps, and any delegated administration rights, in a location your security team can review.

During the Engagement

• Monitor login activity for third-party accounts. Logins outside expected hours, from unexpected IP ranges, or via API when the engagement is UI-based should trigger review.
• If the third party installs a connected app, review the OAuth scopes before approving. Reject full scope unless there’s a documented justification.
• Review any permission set changes requested by the third party against the original scope of access.

At Engagement End

• Deactivate all user accounts associated with the engagement on the last day of the contract. Not the week after. The day of.
• Revoke all connected apps installed or authorized during the engagement. Remove the connected app from Setup > Connected Apps and revoke all OAuth tokens from Connected Apps OAuth Usage.
• Rotate credentials for any integration user that was accessed by the third party during the engagement.
• Remove any delegated administration grants associated with the engagement.
• Conduct a post-engagement access review: query SetupAuditTrail for changes made by the third-party users during the engagement and verify no persistent access paths were created (new users, new connected apps, modified permission sets).

Ongoing

• Quarterly review of all active user accounts with external email domains. Cross-reference against active vendor contracts.
• Quarterly review of connected app usage. Any connected app with no usage in 90 days should be reviewed for removal.
• Annual credential rotation for all integration users, regardless of whether the third party has changed.

The Bottom Line

The Mythos leak is a case study in third-party access risk. Anthropic built a model it considered too dangerous to release broadly, restricted access to 40 organizations, and lost control of it through a contractor. The mechanism wasn’t a zero-day exploit or a sophisticated intrusion. It was a third party with too much access and a piece of information from someone else’s breach.

Every Salesforce org with consultant accounts, SI-managed integrations, or AppExchange vendor access has the same structural exposure. The defensive work is unglamorous–auditing user accounts, revoking stale connected apps, rotating credentials, enforcing time-boxed access–but it’s the work that would have prevented this.

The question from the last article still applies, and the timeline for answering it just got shorter: have you done the work?

Book a 15-Minute Security Strategy Call

Reference(s):

https://fortune.com/2026/04/23/anthropic-mythos-leak-dario-amodei-ceo-cybersecurity-hackers-exploits-ai/

https://fortune.com/2026/03/26/anthropic-says-testing-mythos-powerful-new-ai-model-after-data-leak-reveals-its-existence-step-change-in-capabilities/

https://www.siliconrepublic.com/enterprise/anthropic-probing-reported-mythos-leak-on-discord

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

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

https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm

https://help.salesforce.com/s/articleView?id=sf.connected_app_manage_oauth.htm

‍