Since at least February 2025, Okta Threat Intelligence has tracked an extortion campaign in which threat actors leveraged voice-based social engineering, credential phishing and device code phishing to access and exfiltrate data from Salesforce environments.
Attackers impersonated technical support personnel in phone calls to targeted users. These users were often tricked on these calls into authorizing an attacker-controlled OAuth application (“Salesforce Data Loader”) to access their Salesforce organization. As a result, the application was granted the permissions required to access and exfiltrate data in the user context.
An initial campaign of credential phishing attacks in February 2025 targeted dozens of organizations. From March 2025, the attackers pivoted to using device code phishing in attacks that exfiltrated data from Google, Workday and many others.
A question worth asking is: why are these relatively simple attacks effective against multiple organizations with well-resourced security programs?
The answer lies in two unrealistic expectations:
It’s unacceptable to expect users to consistently distinguish between a benign and a malicious OAuth application. In these attacks, a user is directed to interact with genuine sign-in and consent pages from a trusted domain and is provided with little context with which to scrutinize the application requesting access. Security awareness programs can play a mitigating role, but should not be the primary control.
It’s complex and inefficient for security administrators to manage (i.e. allowlist) thousands of OAuth connections to hundreds of core applications on a point-to-point basis.
Okta’s internal security team, for example, has blocked thousands of OAuth integrations that sought some level of access to one of our main productivity platforms. The average enterprise has over 200 core applications, dozens of which have aspirations to be extensible enough to be considered a “platform”.
This complexity will grow as AI agents request access to protected resources to perform tasks on behalf of users. Agentic AI will ultimately bring this authorization crisis to a head: our industry has little choice but to re-think app-to-app authorization for an agentic world.
By default, most enterprise app ecosystems historically allowed users to consent to allow third-party applications to access data in their account. Microsoft announced its intention to reverse course for all new Azure apps by the end of August 2025, and Salesforce announced that users will no longer be able to consent to authorizing uninstalled connected apps from the end of September 2025.
The controls available for security teams to allowlist third-party connections are highly fragmented. Organizations can outsource the job of evaluating the reputation of OAuth apps to third-party vendors, but this already doesn’t scale well today and will become unmanageable in an agentic context.
To solve the current problems and secure the agentic future, we first need to address this fundamental app-to-app authorization problem.
The most logical place to solve this problem is at the Identity Provider (IdP) layer. Today, authentication policies configured at the IdP determine which users can access which resources under a specified set of conditions. Single sign-on (SSO) can be used to reduce the number of credentials a user has to remember, as well as reduce the total number of sign-in challenges they have to satisfy. It makes logical sense to govern authorization of data exchanges between those same applications via the same policy engine.
Okta has proposed Cross App Access as a way of restoring visibility and control of the app ecosystem for IT and security teams. The promise of Cross App Access is to centralize visibility and control of app-to-app and agent-to-app connections.
Built on industry standard OAuth flows, Cross App Access would offer administrators the first say on what data apps or agents can access from an enterprise application.
Figure 1: Managing app-to-app and agent-to-app authorization at the IdP
Requests for access from an unauthorized agent or application could subsequently be audited or blocked at the IdP, rather than within each individual application or using third-party security tools
And just like SSO, centralizing authorization decisions at the IdP has the potential to reduce the cognitive load on users. If an integration between two applications is pre-approved in policy by security administrators, and a user is signed into both of the applications using SSO, administrators may gain the confidence to reduce the total number of consent prompts a user is challenged with.
When the industry embraces Cross App Access, we can feasibly remove the burden on users having to determine whether any given application integration is legitimate or malicious. Users will only be able to consent to an allowlisted set of connections, with a pre-defined scope, and in many cases won’t need to be presented with a consent screen.
Recommendations for ISVs
We recommend ISVs and developers learn about integrating Cross App Access and prepare support for the emerging standards that underpin it.
Recommendations for CISOs
Help build awareness of Cross App Access with your peers and with enterprise software vendors.
Enroll users in phishing resistant authenticators, such as Okta FastPass or passkeys, and enforce phishing resistance in policy.
Audit which of your existing applications support app-to-app or agent-to-app connections via OAuth. Consider a staged approach to allowlisting.
Provide the security team visibility of user-assigned apps via identity security posture management (ISPM) tools.
Conduct security awareness exercises that simulate consent prompt phishing to educate users on the risks of approving unsanctioned and unsolicited app integrations.
Ensure your primary security contact at Okta is up-to-date for access to the latest threat advisories from Okta Threat Intelligence. Please note that the primary security contact can now invite other users from their organization to view documents, without having to add them to the contact record. The Invite a Colleague function is found in the user profile after signing into security.okta.com
