When Security Hardening Becomes Access Friction
Salesforce's June 2026 Security Roadmap, read through a captive-data lens
On June 2, 2026, Salesforce updated its platform Security Roadmap (Knowledge Article 005317465): a slate of identity and access-control changes — mandatory and phishing-resistant MFA, login-anomaly containment, IP-reputation blocking of API connections, and step-up authentication on report export — enforced across June and July 2026. Read on its own terms, it is sound, overdue security hardening against phishing and account takeover. Read through the captive-data lens, several of these controls do something else as well: they raise the cost and feasibility of the systematic, automated, bulk access that external integrations and third-party AI depend on, while Salesforce's own in-platform AI operates inside the trust boundary, largely unaffected.
Executive summary
- Most of the roadmap is legitimate security. But at least four controls double as friction on external, automated data access.
- The friction lands on the systematic, headless, high-volume access pattern that AI agents and integrations use — not on interactive human users, and not on the vendor's own in-tenant AI.
- The clearest example: blocking Connected App and API connections from VPNs, proxies, and "high-risk" IPs (live April 24) — the very ranges cloud-hosted agents and iPaaS run from.
- Effect is not intent. There is no evidence this targets AI. The lens matters precisely because security is becoming the most defensible vector for access friction there is.
- Enforcement is imminent (June–July 2026). The action items below are time-sensitive.
What Salesforce announced
Article 005317465 is a living "Security Roadmap" for the Salesforce Platform, explicitly framed around minimizing phishing and account-takeover risk. The controls and their production enforcement dates:
| Security control | What it does | Production enforcement |
|---|---|---|
| Email domain verification | Verifies ownership of sending email domains (anti-spoofing) | Phased, from April 2026 |
| Block VPNs / proxies / high-risk IPs | Blocks Connected App & API connections from anonymizing or high-risk IP addresses | April 24, 2026 |
| Login anomaly detection & containment | Detects and contains anomalous login sessions | Early April 2026 |
| Phishing-resistant MFA (admins) | Requires phishing-resistant MFA for privileged users | July 1, 2026 |
| MFA for all employees | Requires MFA for all employee logins | July 20, 2026 |
| Step-up auth, report actions | Extra identity challenge to access or export reports | July 1, 2026 |
| Step-up auth, anomalous report export | Extra challenge triggered on anomalous report export | July 13, 2026 |
| Transaction security policy enhancements | Expanded real-time policy enforcement on platform events | July 13, 2026 |
Two stories in one roadmap
There are two ways to read this document, and both are correct. A security administrator reads a well-sequenced program to shut down phishing and account takeover. Anyone responsible for integrations or an external-AI strategy should read a second story underneath it: a tightening of how, and from where, and by whom, data can be reached programmatically. The same control often serves both ends at once. That is not a contradiction; from the platform's side, the friction is the security. The point of this briefing is that if you only run the first read, you will be surprised in July.
Which controls double as access friction
Four of the roadmap items have a second effect — each lands on the access pattern that external automation and AI depend on, and each maps onto a rung of the captive-data framework from our companion briefing.
| Control | How it doubles as access friction | Maps to |
|---|---|---|
| Block VPNs / proxies / high-risk IPs (API) | Gates API and Connected App access by IP reputation — the exact cloud ranges that iPaaS and cloud-hosted AI agents run from | Technical gate (rung 1) |
| Step-up auth on report / anomalous export | Inserts an interactive human challenge a headless job or agent cannot satisfy — friction placed directly on bulk data egress | Data-egress friction |
| Login-anomaly containment + transaction security | High-volume programmatic reads look "anomalous" by definition, so containment becomes a de-facto rate limiter on agentic access | Technical throttling (rung 1) |
| MFA / phishing-resistant MFA | Pushes integrations off passwords and toward Salesforce-sanctioned OAuth and connected-app gates | Channeling to vendor gates |
The asymmetry that matters
The captive-data signature is asymmetry, and it is here. Salesforce's own AI — Einstein, Agentforce, Data Cloud — runs inside the tenant trust boundary. It does not connect over the public API from a flagged cloud IP; it does not pass an interactive step-up challenge to read or export a report; and it is not flagged as "anomalous" for high-volume access, because it is the platform. Your external AI and integrations face every one of those frictions. The vendor's native AI faces none of them. Same data, two tiers of access — which is rung four of the captive-data ladder, architectural privileging, arriving this time dressed as a security release.
Effect is not intent
A necessary caveat, and an important one for credibility. The article never mentions AI, large language models, or competitors. Phishing and account takeover are real and rising, and every control here is a standard, defensible response that most security teams would welcome. This briefing alleges no scheme. The value of the captive-data lens is narrower and more durable than a motive: the effect on your ability to reach your own data is the same whether or not it is intended, and "security" is uniquely hard to contest. No buyer wants to be the one arguing against multi-factor authentication. That is exactly why access friction increasingly travels inside security releases, and why these releases now belong in your AI and integration planning, not only your security review.
What to do before July
- Inventory integration egress IPs. Map the source IPs of every integration and agent. The VPN/proxy/high-risk-IP block (live April 24) can silently break Connected App and API access from cloud ranges. Pin traffic to static, allowlistable egress addresses.
- Re-plumb automated report exports. Move scheduled and bulk report exports to the Bulk API 2.0 with OAuth before step-up (July 1) and anomalous-export (July 13) enforcement; an interactive step-up challenge will fail any headless job.
- Migrate service users to OAuth. Replace username/password-plus-token integration users with OAuth (JWT bearer / connected apps) ahead of MFA enforcement (July 1–20).
- Pressure-test under the anomaly policies. Validate that legitimate high-volume jobs are not tripped by login-anomaly containment or transaction-security policies, and coordinate allowlisting with your Salesforce admin.
- Put it in the contract. Extend your data-egress and agent-access rights clause to cover security-control carve-outs — named integration identities and allowlisted IPs that future "security" controls will not silently block.
Bottom line
This roadmap is good security and a quiet tightening of external access at the same time, and from Salesforce's vantage point those are one and the same. For anyone running integrations or betting on third-party AI over Salesforce data, treat it as the new normal: every security release is now also an access release. Read both axes, plan for the enforcement dates, and negotiate the carve-outs while you still have leverage.
Selected sources
- Salesforce Help — Security-Related Product Updates to the Salesforce Platform (KB 005317465)
- Salesforce Help — Preventing Connections from Anonymizing VPNs, Proxies and High-Risk IP Addresses (KB 005318944)
- Computerworld — Salesforce changes Slack API terms to block bulk data access for LLMs
An independent briefing from Stewart Consulting, published for discussion. Questions or feedback are welcome — see Connect. This briefing synthesizes public Salesforce documentation as of June 2026 and is provided for informational purposes; it is not legal advice. Verify enforcement dates and control details against Salesforce's primary documentation before acting.