TL;DR
- AI has changed the cost of finding security exposure in Salesforce, particularly.
- Public sites, guest users, Apex, files, permissions, connected apps, and service accounts make this challenge a particularly unique one.
- Salesforce security now requires continuous exposure management: discover what is exposed, understand why it matters, remediate safely, and monitor what changes.
————-
Salesforce exposure used to have an awkward kind of protection: it was hard to find. Not impossible. Just… relatively difficult.
A risky guest user permission might sit inside an Experience Cloud site. A forgotten Apex method might be callable from a public surface.
These kind of issues were of course present, but finding the dangerous combination required an unusual combination of talents that included a great deal of patience, a great deal of context, and a great deal of Salesforce-specific expertise.
That’s all changed now.
Recent research from Reco has shown an AI-powered agent performing end-to-end security assessments of Salesforce Experience Cloud sites.
Starting with a URL, the agent mapped exposed Salesforce objects, Apex methods, routes, files; then it analyzed accessible data; then it probed for vulnerabilities; and finally it validated impact.
In one case, it found sensitive files among ordinary assets. In another, it found a path in through an exposed Apex method.
The lesson, which is pretty uncomfortable, is that AI did not create the exposure.. it just changed the economics of finding it. And that should change how every security, IT, and Salesforce team thinks about risk.
Exposure used to be expensive to find
Most Salesforce environments are not simple systems. They are highly complex, living maps of how the business actually works in reality.
There are public sites, partner portals, customer communities, integrations, managed packages, flows, validation rules, permission sets, permission set groups (deep breath) profiles, connected apps, files, Apex classes, and service accounts.
There are also years of exceptions: the emergency change that became permanent times what might as well be infinity.
As it is often the record of a business adapting, complexity itself is not inherently bad.
Complexity is how Salesforce runs, but unmanaged complexity is where exposure hides. That exposure can span permissions, public surfaces, connected apps, service accounts, files, automations, integrations, data platforms, and business processes.
Historically, defenders could tell themselves a story about that exposure. Sure, it existed. Yes, it should probably be cleaned up. But exploiting it required a human attacker to do a lot of tedious work: list surfaces, understand object access, test endpoints, inspect files, infer business meaning, and connect a lot of those weak signals across the org.
This fable is now totally outmoded.
Google Threat Intelligence Group reported in 2025 that threat actors tracked as UNC6040 had repeatedly used voice phishing to compromise Salesforce orgs. Mostly, by tricking employees into authorizing a malicious connected app resembling Salesforce Data Loader.
Once authorized, that app could access, query, and exfiltrate sensitive information from customer environments.
A joint FBI advisory made the same point from another angle: once victims authorized malicious connected apps, attackers could use API queries to exfiltrate large volumes of data, and the OAuth-token-based activity could appear to come from a trusted integration.
Notice that this isn’t the same attack path as an exposed Experience Cloud guest user or vulnerable Apex method. But it points to the same deeper issue: Salesforce risk increasingly lives in the connection-spaces between identity, configuration, data access, public surfaces, integrations, and business process.
AI lowers the cost of patience
A human security team has constraints. A backlog. Meetings. It has other systems to protect.
An AI agent does not have the same limitations.
It can enumerate. It can compare. It can read. It can retry. It can inspect a hundred boring files to find the one that should not be public. It can test many exposed methods to find the one that behaves differently. It can connect a public record, a parameter name, an error message, and a likely data path without getting bored.
That is the new economics of exposure.
The cost of discovery is falling. The cost of patience is falling. The cost of connecting seemingly minor weaknesses is falling.
Microsoft’s Digital Defense Report framed the broader risk clearly: AI agents could allow threat actors to automate the attack lifecycle through reconnaissance, vulnerability scanning, and exploitation at scale. The same report noted that defenders are also using AI to scan threat intelligence, identify protection gaps, and respond faster.
Verizon’s 2026 DBIR likewise describes a threat landscape where vulnerabilities have become a leading breach entry point, and where different techniques of attack are being bolstered by gen AI, helping threat actors work faster across all the stages of attack.
The Salesforce implication is direct: risks that were previously dismissed as “low exploitability” deserve a real-good-hard second pass.
The problem is not one setting
The instinct after reading about Salesforce exposure is probably to jump straight to a checklist… and sure.
Audit those guest users. Disable those unnecessary public APIs. Review that Apex. Review those connected apps.
All good. All helpful.
Salesforce itself recommends tightly controlling Experience Cloud guest user access. Its guidance says unauthenticated guest users should only access the data intended for them, and it recommends reviewing guest object, record, and field access. Salesforce also recommends disabling guest access to public APIs where it is not needed and restricting portal and site user visibility to prevent enumeration of internal users.
Salesforce’s guest-user documentation is similarly clear that sharing data with guest users should be deliberate and carefully controlled, because Experience Cloud sites can support many different use cases and only the business knows which records and fields should be accessible.
For code-level risk, Salesforce’s Trailhead guidance says the first and most recommended way to prevent SOQL injection is to use static queries with bind variables, rather than inserting user input directly into dynamic queries.
But the deeper problem is the system around the setting.
A guest user profile can connect to a site, a sharing model, objects, fields, files, pages, forms, and business processes.
An Apex method can connect to a controller, a user mode, a sharing assumption, a data model, a page, an integration, and a workflow someone may still depend on.
The risk does not live in the component alone.
It lives in the relationship between components. The structural context, as it wre.
Technical debt = security debt
Salesforce teams have chatted for years about technical debt as a delivery problem.
Too many fields. Too many flows. Too many permission sets.
That is still true. Technical debt slows change.
But in the AI era, Salesforce technical debt is also security debt. Let’s think of a few examples…
- A stale permission
- A forgotten public site
- A broad service account
- A downloadable file in the wrong place
- A without sharing class.
- A connected app nobody owns
They are all possible paths.
Interestingly enough, IBM’s Cost of a Data Breach report puts real-money numbers behind the urgency: the global average cost of a data breach was $4.4 million, while organizations making extensive use of AI in security saw $1.9 million in cost savings compared to those that did not. (For what it’s worth, IBM also emphasized faster identification and containment as drivers of reduced breach cost.)
Salesforce often contains customer data, partner data, pipeline data, support data, identity-adjacent data, contractual information, and operational workflows. The cost of exposure extends beyond the breach to the response, the investigation, the remediation, the customer trust problem, and the operational risk of even fixing the wrong thing too quickly.
The remediation paradox
Most security advice gets too confident on this one.
“Review guest permissions” sounds straightforward.
In a real Salesforce org, that is rarely as utopian as it sounds.
The moment a finding appears, teams have to answer much harder questions:
- What data is actually exposed?
- Which business process depends on this access?
- Who owns the site, object, app, service account, or file?
- Is this permission inherited through a profile, permission set, permission set group, sharing rule, or code path?
- What breaks if we remove it?
- What should be remediated first?
- How do we validate the fix?
- How do we know the same exposure will not return next month?
A scan can identify a problem. A report can describe a problem. But remediation requires context.
That is why Salesforce exposure management has to move beyond point-in-time assessment. The org keeps changing. A new site goes live. A permission set gets edited. A flow changes. A file is uploaded. A connected app is approved. A service account is reused. A “temporary” access grant becomes invisible.
What Salesforce exposure management now requires
The new economics of exposure demand a new operating model. A modern Salesforce exposure program needs to continuously answer four questions.
1. What exactly is exposed?
Teams need visibility across public sites, guest users, files, Apex, permissions, connected apps, service accounts, integrations, automations, and data platforms.
2. Why does that matter?
Exposure only becomes meaningful when it is connected to business context: sensitive data, customer workflows, revenue processes, partner operations, support processes, or regulated information.
3. What should we fix first?
Not every issue carries the same risk. Prioritization should consider exploitability, blast radius, ownership, dependencies, and business impact.
4. How do we keep it fixed?
Salesforce changes constantly. Monitoring has to track metadata and configuration changes that could reintroduce exposure after remediation.
This is the shift from security assessment to continuous exposure management.
Complexity is not the enemy
The answer is not to pretend your Salesforce org can be made simple.
It cannot. And honestly, it probably should not.
A simple Salesforce org is often a whiteboard fantasy. Real Salesforce environments are complex because real businesses operating in real… reality… are complex. They have exceptions, channels, products, regions, partners, legacy processes, compliance needs, and customer promises embedded into the system.
The goal cannot be to erase complexity but to make it visible, understandable, governable, and safe to change.
AI has changed the risk calculation. What used to be buried can now be found. What used to require patient manual work can now be automated. What used to look like scattered hygiene issues can now become a connected path to sensitive data.
The exposure was already there.
AI changed the economics.
Now, Salesforce teams must change the operating model to survive.
