As threat actors operationalize AI to accelerate attacks, they are also leveraging the wider global interest around AI itself as a social engineering lure. In recent months, Microsoft Threat Intelligence has observed a growing number of campaigns that impersonate the branding of popular AI platforms such as ChatGPT, Microsoft Copilot, DeepSeek, and Anthropic’s Claude as lures. These campaigns, which don’t represent compromise of services, span phishing, malvertising, and search engine optimization (SEO)-driven attacks that ultimately lead to credential theft, financial fraud, or malware infection.

Threat actors are quick to capitalize on highly anticipated launches or emerging trends, leveraging trusted branding and exploiting user curiosity to improve the success rates of their campaigns. Despite the AI-themed lures, however, these campaigns combine longstanding tactics, such as urgency-driven messaging, abuse of trusted services, and multi-stage redirection chains that require user interaction to evade detection.

While traditional lures like invoices, payment notifications, or delivery alerts remain effective and continue to be widely used, AI-themed lures reflect a shift in social engineering that is likely to persist as a long-term tactic used by threat actors, from cybercriminal groups to nation states. Notably, Microsoft Threat Intelligence has observed the initial access broker Storm-3075 employing AI-themed malvertising to deliver payloads, including malware signed by the malware-signing-as-a-service (MSaaS) offering attributed to the financially motivated threat actor Fox Tempest, on behalf of multiple downstream actors.

This blog details several of the campaigns observed by Microsoft Threat Intelligence in the past few months that used AI brands and references as lures, and provides guidance to help users and organizations detect, mitigate, and respond to these threats. Importantly, Microsoft believes that the activity noted in this blog is purely abuse of AI brand names as lures, not reflecting a compromise of any referenced vendor. As threat actors scale their operations with AI, organizations should leverage AI-powered security capabilities to enhance visibility, automate detection, and accelerate response across email, identity, and endpoint surfaces.

ChatGPT-themed lure leads to phishing kit collecting credit card data

On May 5, 2026, Microsoft detected a ChatGPT-themed phishing attack that delivered malicious URLs leading to phishing pages that collected credit card and personal information such as names and addresses. This phishing activity, which consisted of 4,500 emails sent to targets in South Africa (97%), was part of a broader campaign using similar themes and infrastructure. We also observed this campaign delivering as much as 100,000 emails on a single day to targets in Switzerland, Austria, and South Africa affecting a broad range of industries, including higher education and professional services.

The emails used the sender display name ChatGPT and the subject “To ensure your ChatGPT Plus continues to work – please update your payment method”. The emails posed as an urgent request to update the ChatGPT Plus subscription payment method. They warned the recipient that if a new payment method was not provided within seven days, the account would be downgraded to a free plan. A ChatGPT logo was prominently displayed at the top of the email body.

The phishing email contained a clickable Update payment method button, which did not directly send users to the attacker-controlled site. Instead, users were redirected through a series of legitimate and abused redirector hops. This is a common technique used by threat actors to exploit the reputation of trusted domains and bypass email filters, evade detection, and track victim engagement.

Targets were first directed to grupoconstat[.]bitrix24[.]com[.]br (a legitimate customer relationship management (CRM) service), which redirected to awstrack[.]me (an Amazon domain used for tracking email opens and clicks), which in turn redirected to a Rebrandly URL (a legitimate but often abused URL shortener service). Targets were finally sent to a likely legitimate but compromised domain legendarytrendsbay[.]shop where the threat actor had placed the phishing page in the /ChatGPT/ folder.

The landing page did not immediately display the phishing content. It first required visitors to pass a custom CAPTCHA, which was a simple Update payment button. If they clicked this button, users were sent to the next page where personal information, including first name, last name, and address was collected. The final page then collected the name, credit card number, expiration date, and card verification code.

Claude-themed phishing campaign collected credentials and access tokens

From April 20 to 22, 2026, Microsoft observed a phishing campaign impersonating Anthropic-branded services to target users with account-related lures tied to the Claude AI platform. The campaign sent phishing emails to targets across more than 2,000 organizations, primarily in the United States (62%), the United Kingdom (18%), and India (9%). While this campaign impacted a broad range of industries, it was most notably focused on information technology (56%), other business entities (21%), and financial services (8%).

The campaign used enforcement-themed messaging claiming that the recipient’s account was in violation of acceptable use policies and required immediate action. The emails impersonated Anthropic’s popular AI service Claude using the display names Anthropic Teams and Anthropic PBC, masquerading as legitimate account-related communications. Subject lines followed a consistent structure of “Claude Appeal Request” combined with date elements.

The email body was delivered as HTML and included Anthropic and Claude branding. The message informed recipients that their account was violating “AUP (Account Usage Policy)” and that Anthropic had “initiated an appeal procedure”. The message instructed recipients to review the attached material to access their appeal and indicated that Claude features would be limited pending review.

The email attachment was a PDF named Fill and Sign Claude Appeal Form.pdf, which was designed to resemble an official process tied to Claude account enforcement. The document presented an appeal workflow, prompting users to copy an appeal ID and click the “Claude Appeal” link, which initiated the credential harvesting process.

When clicked, the link embedded in the PDF directed users to an attacker-controlled domain, dash.awaydouble[.]org. The initial landing page displayed a Cloudflare verification prompt, presented as confirming the user was arriving from a “legitimate session”. This step likely served as a gating mechanism to impede automated analysis and sandbox detonation.

Users who completed the verification were redirected to another Claude-themed landing page hosted on servicing.pureplantcravings[.]com. This page was named “Account Appeal Notice” and contained “Account Security & Compliance” message informing users that their account had been flagged for repeated violations of usage policies. The page provided a reference date and a one-time access code, prompting users to copy the code and continue.

Clicking “Continue” redirected users to the final page, which was not available at the time of analysis. Source code revealed conditional redirect logic that routed users to one of two final landing pages, depending on whether the site was accessed through mobile device or a desktop system.

While the final redirect destination was no longer active at the time of analysis, infrastructure overlap, including shared intermediate domains and consistent redirect logic, strongly suggested that users were ultimately presented with a Microsoft sign-in experience. This final stage is consistent with adversary-in-the-middle (AiTM) tactics designed to intercept authentication tokens and facilitate account compromise.

“Awesome AI Windows Plugin” malvertising deploys Vidar stealer

Since at least early 2026, Microsoft Threat Intelligence has observed malvertising campaigns that use AI-themed terms such as “Awesome AI Windows Plugin” and “Flux Pro AI” in social engineering lures in malicious popups, in malware executable names, and GitHub repository and folder names throughout the attack chain. These campaigns are notable for their scale and velocity, moving from launch to mass impact within hours and infecting tens to hundreds of thousands of endpoints. The malware delivered in these campaigns is frequently code-signed, lending an additional layer of perceived trust to both the operating system and the user.

Microsoft attributes this malvertising activity to an initial access broker and malware distributor tracked as Storm-3075. We assess that Storm-3075 delivers final payloads on behalf of multiple downstream actors. While the example campaign described in this section delivered Vidar Stealer, we have also observed this campaign distributing Lumma Stealer, Hijack Loader, and Oyster.

On March 13, 2026, a single campaign run targeted over 66,000 devices. Microsoft has revoked the related signing certificate and GitHub has taken down the associated repository, helping to prevent tens of thousands of additional infections. Given the nature of the attack source, majority of impacted devices were likely consumer rather than enterprise endpoints. Telemetry showed global distribution, with the top affected countries being Japan, South Africa, the United States, and France.

Analysis of the redirection chain determined that the attack likely originated from free movie streaming sites. Infections on such sites typically begin when users interact with embedded movie players or click popups. Malvertising embedded in such sites can redirect users to a range of unwanted content, including malware. In this campaign, users were redirected to a page advertising a download for an “Awesome AI Windows plugin”, a fictitious product name. The plugin purported to help users watch free, high-quality videos, a lure aligned with the context of users already streaming free or pirated content.

Clicking the download button retrieved an executable named ProFluxeFlowAi-win-Setup.exe, which the user then had to manually launch. The file name mimicked a legitimate product with a similar name, Flux Pro AI, which supports text, image, and video creation. This lure reinforced the perceived legitimacy of the executable within the streaming of free movies context. The executable itself was hosted on GitHub in a repository named shippingtechnologymovie under a folder named AI-techVideos, both tailored to the AI video helper narrative.

The malware executable was signed with a fraudulently obtained Microsoft-issued code-signing certificate obtained through Artifact Signing (certificate thumbprint: 4f5c5b3ef45cfff7721754487a86aeff9a2e6e32). Microsoft attributes the signing service used by the threat actor to Fox Tempest, a financially motivated threat actor operating a malware-signing-as-a-service (MSaaS) offering used by other threat actors. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), in partnership with Resecurity, facilitated a disruption of Fox Tempest infrastructure and access model.   

Signing malware through such a service is expensive; however, for a threat actor targeting tens or hundreds of thousands of infections, the cost can be justified by the additional level of trust signed binaries imply to both the operating system and the user. Signed malware also tends to exhibit lower detection rates early in the infection lifecycle, extending the window of effective distribution.

Another notable feature of the malware is that, immediately after launch, it displays a window with a “Continue” checkmark and does not proceed until the box is clicked. This extra user interaction step is uncommon. We assess that this technique is intended to hide the malicious functionality from sandboxes and automated analysis environments that cannot dynamically perform the click. Until the user clicks “Continue,” the malware performs no suspicious activity on the operating system. This technique is functionally analogous to the CAPTCHAs frequently seen in phishing attacks.

Once the user clicks “Continue”, the executable drops and runs a malicious Python-based downloader. Both the Python interpreter and the downloader script are saved in the \AppData\Local\ folder as pythonw.exe and LICENSE.txt, respectively. The malicious script runs shellcode that loads the next-stage malware from the command-and-control (C2) domain brokeapt[.]com. The final payload observed in this campaign was Vidar infostealer.

Fake DeepSeek V4 installers on GitHub delivered Vidar Stealer

In April 2026, Microsoft identified a social engineering campaignsocial-engineering campaign that leveraged interest in the newly released DeepSeek V4 by impersonating it through a fraudulent GitHub repository and organization. The campaign abused GitHub’s release-asset infrastructure to deliver information-stealing malware such as Vidar stealer. Search engines increased the exposure of the malicious repository, exacerbated by the fact that DeepSeek did not publish an official V4 repository on GitHub.

Our investigation shows the DeepSeek lure is one identity in a broader rotating brand-abuse ecosystem that recycles whichever AI tool is trending into a fresh malware download experience. After discovering this activity, Microsoft shared the details with GitHub, and GitHub has since taken down the malicious organization, repository, and operator account.

On April 24, 2026, within hours of DeepSeek officially previewing its new V4 frontier model, a threat actor initiated the attack chain that can be summarized as:

1. Resource development on GitHub, all within roughly 45 minutes: A new GitHub organization (DeepSeek-V4), a single repository (deepseek-V4), and a release tag (deepseek-V4). The repository was decorated with stolen DeepSeek branding, real benchmark data, and SEO-optimized topics.
2. Search-driven discovery: Users found the repository through GitHub repository search, search engines, social sharing, and AI-assisted search results pointing to the lure page. The repository’s llms.txt and topic taxonomy were designed to be discovered by both classical search engines and large-language-model-powered search; observed top-rank results on search engines are consistent with that design, though we did not observe paid advertising and therefore do not assess this as malvertising.
3. Archive download from GitHub’s release-asset CDN: The release page hosted two archives, deepseek-v4-pro_x64.7z and deepseek-v4-flash_x64.7z.
4. User extraction: Users needed to extract the executable from the archive using common Windows archive tools.
5. Payload execution: The archives contained a heavyweight Win32 PE that masqueraded as the DeepSeek installer. At least one confirmed victim endpoint revealed the extracted payload landed at: C:\Users\<user>\Downloads\Programs\IA DeepSeek-V4\deepseek-v4-flash_x64.exe.
6. Active payload rotation: The threat actor actively rotated archive content while preserving file names and the release page. We observed at least three distinct archive hash generations in three days.

Microsoft Defender telemetry observed the first victim download approximately four hours later. The threat actor’s operational tempo on April 24, 2026, is consistent with a prepared, rehearsed workflow. The repository was designed to be convincing at a glance. It accumulated 91 stars and 27 forks within four days, though the proportion of organic versus inflated engagement is not independently confirmed. The attacker invested in several credibility-building elements:

• Stolen branding: The repository’s README and assets folder embedded the legitimate DeepSeek whale logo, copied from the real deepseek-ai/DeepSeek-V2 repository.
• Real benchmark data as lure: The release notes displayed authentic DeepSeek V4 benchmark scores against Claude Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, copied from the official release announcement.
• Action-oriented SEO topics: The repository was tagged with deepseek-v4, deepseek-v4-download, deepseek-v4-downloader, deepseek-v4-install, and deepseek-v4-installer, which are queries users are expected to use when intent-shopping for an installer.
• LLM-aware discoverability: A top-level llms.txt file repeated the same SEO copy in a format aimed at AI-assisted search engines.

On closer inspection, the staging gives the operation away: the repository contained only a README, LICENSE, llms.txt, and stub assets/ and inference/ directories with no real model code; all nine commits were made in a single burst on April 24, 2026 by a single author; the README claimed an MIT license while repository metadata specified Apache 2.0.

Once the lure was live, search engines increased the exposure of the malicious repository. We tested the queries an interested user would naturally try when looking for DeepSeek V4 on GitHub or the open web. In a snapshot captured on April 28, 2026, the results were as follows (search results are volatile and may differ at the time of reading):

The 7z archives hosted on GitHub contained a loader executable such as SHA-256: 5455341ed1bbe75a664fca2dd0794c508e1874f75360253a7ff5bc119bc92d80. The loader was observed downloading and installing Vidar stealer and potentially additional malware.

Lastly, Microsoft observed that the DeepSeek-themed payloads share infrastructure with a much larger rotating fake-AI / fake-tool ecosystem. The same shared loader hash (SHA-256 5455341…) appeared under file names impersonating GPT-5.5, Claude Code, Kimi, Seedance, Gemma, GrokCLI, Manus AI, FraudGPT, and others (see table below). Public research from Trend Micro, Zscaler ThreatLabz, and Huntress describe the same broader ecosystem, with TradeAI.exe, OpenClaw_x64.7z, WormGPT_x64.7z, and DeepSeekAI_agent_x64.7z appearing as sibling lures and the downstream payload set documented as Vidar plus GhostSocks.

Mitigation and protection guidance

To defend against social engineering campaigns that leverage AI brands as lures, Microsoft recommends the following mitigation measures:

• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices in all locations at all times.
• Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals.
• Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Enable Zero-hour auto purge (ZAP) in Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Configure Microsoft Defender for Office 365 Safe Links to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow and time-of-click verification of URLs and links in email messages, other Microsoft Office applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers like Microsoft Edge that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Threat overview profile: Evolving phishing threats

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Indicators of compromise

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post AI brands as bait: How threat actors are using the AI hype in social engineering appeared first on Microsoft Security Blog.

Why This Matters

Your AI agent just forgot everything. Again.

If you've built agents that need to track work across days or weeks—not just single conversations—you've hit this wall: the agent loop is stateless. Each turn reasons over what it's handed, then forgets. But real business workflows don't fit in one conversation.

This post shows how to build agents that remember, using Foundry's per-project sandbox VMs to maintain state across weeks of discontinuous work. No external database required.

What you'll learn: - How to persist agent state in Foundry microVMs - Session handling patterns for long-running workflows - When to choose hosted vs. local agent architecture

Quick glossary for this post: 

• MAF (Microsoft Agent Framework): The framework for building AI agents that can use tools and orchestrate sub-agents
• Foundry: Microsoft's platform for hosting and running AI agents in production
• MicroVM: A lightweight, isolated virtual machine that Foundry provisions per project—think of it as your agent's persistent workspace
• MCP (Model Context Protocol): A standard for connecting AI models to external tools and data sources
• WorkIQ: Our custom component that exposes M365 capabilities as MCP endpoints

The business workflow and the core challenge

The reference workflow here is Statement of Work (SOW) response orchestration. A SOW Owner kicks off an RFP response and the agent runs the whole engagement across Microsoft 365: it finds the RFP, drafts a project charter, extracts owners and tasks from the kickoff meeting, allocates the work, fans out kickoff briefs (after the owner approves), then polls email and chat to track each task to closure and drafts nudges for stragglers. The catch is that this isn't a single conversation — it plays out over days or weeks, with people contributing at their own pace and the agent waking up intermittently to advance the work. That is the core challenge: an agent loop is stateless — each turn reasons over what it's handed and then forgets — yet the process demands continuity across long, discontinuous gaps. Something has to remember every outstanding task, every submission, and every next step, and reconstruct that picture flawlessly each time the loop wakes.

The solution approach

Rather than push that burden onto the client, we let the Foundry hosted agent carry its own state in a per-project sandbox VM (microVM). The high-level idea:

• State lives in the sandbox, not the client. Each project gets its own Foundry microVM with a durable $HOME. The agent writes everything it needs there — the charter, a structured project log of tasks and status, channel cursors, an activity trail.
• Every wake-up reconstructs the world. The loop doesn't rely on a dangling in-memory pointer. On each turn it reads its own state files back into context, rebuilds the full status of the engagement, advances exactly the phase that's due, and writes the updated state back. Whether the human returns in five minutes or five days, the agent recreates an authoritative picture from disk.
• The client stays thin. Because the substance is server-side, the desktop app only needs to remember which sandbox belongs to which project — a session id — and nothing sensitive ever lands on the endpoint.

This turns a stateless loop into a genuinely stateful, long-running workflow without an external database and without parking business data on the local machine.

Architecture and design

The system is two components.

1) The Foundry Hosted Agent is the brain: built using the Microsoft Agent Framework (MAF), reasons with OpenAI models on Foundry, reaches Microsoft 365 through a single Foundry Toolbox fronting the WorkIQ MCP endpoints, and owns the agent loop, skills, memory, session, state, and orchestration — calling M365 as the signed-in user via Foundry OAuth Identity Passthrough, so it never holds a user token.

The workflow is built as an orchestrator skill (sow-response) with specialist sub-skills (RFP search, charter draft, kickoff extract, task allocate, reply poll); the orchestrator inspects state, decides the current phase, and delegates to the right sub-agent.

Every skill is a warm MAF Agent built once at boot, all sharing one FoundryChatClient — so sub-agent invocations reason through the same model client. The skill-based design is what makes it extensible: a skill is just a folder with a SKILL.md; drop a new one in and the loader builds it an agent and starts routing to it by its description — a brand-new business process, no framework changes.

The agent runs locally during development and deployed as a Foundry hosted agent in production, identical code either way.

2) The second component, the Desktop App, is a deliberately thin shim: it signs the user in, attaches their bearer to the call, remembers a session id per project, polls in the background so the workflow advances unattended, and renders the result — holding session pointers and a non-sensitive UI cache, nothing more. The two talk over the OpenAI Responses API. MAF supplies the loop itself — the per-turn reasoning, tool dispatch over MCP, and sub-agent orchestration that drives every phase to completion.

Session and state handling in code

On a project's first turn, the Desktop client asks Foundry to mint a session. The returned agent session id is the handle to the distinct microVM provisioned for that project, and the client persists it immediately:

From then on, every request embeds that session id (reattaching the sandbox) over the Responses API surface — responses.create(stream=True, ...) — plus a previous_response_id to chain the transcript:

The agent_session_id pins the durable sandbox (survives restarts and idle); the previous_response_id chains the in-memory transcript (best-effort). Inside the sandbox, the agent rehydrates and updates its own state through system state tools exposed alongside the Toolbox — chiefly a JSON-patch operation so each skill updates only the keys it owns:

The whole "reconstruct the world on every wake-up" guarantee rests on these reads and patches against $HOME.

Telemetry, the easy way

Because the agent runs on Foundry with MAF, connecting the Foundry project to Application Insights gives you the entire agent loop as OpenTelemetry traces, turnkey — model calls, every MCP tools/call, every sub-agent invocation, every state patch. The only custom wiring is a span processor that stamps project.id on each span at boot; the platform owns the exporter. You see the full multi-week loop end to end with no bespoke logging pipeline to build.

The alternative: run the loop on the client

The other option is to run the agent loop and its state on the local machine. The trade-offs:

• Data residency. Hosted: sensitive substance stays in an Azure-governed sandbox; the endpoint holds only session ids — ideal where compliance limits business data on local devices. Local: charter, artifacts, and task ledger all live on the laptop, expanding the DLP and vulnerability footprint.
• Scale & sharing. Hosted: per-project sandboxes are provisioned by the platform and any signed-in teammate can attach. Local: bounded by one user's machine; multi-user collaboration is awkward.
• Simplicity for a single user. Local: no session plumbing, no cold-start latency, fully offline-capable — genuinely simpler for one power-user on a permissive setup. Hosted: a little more wiring (session minting, resume handling) in exchange for the governance and scale.

When to choose what: go hosted for teams, multi-project portfolios, or any regulated environment; keep it local for a single power-user on a data-permissive machine who values zero roundtrips.

See it in action

Get Started

Ready to build your own stateful agent? Here are three paths forward:

🚀 Explore the code: The complete Charter Agent source is on GitHub: Charter-Agent-Repo — clone it, run it locally, and adapt the patterns for your workflow.

📚 Learn the fundamentals:

• Microsoft Agent Framework documentation — understand the agent loop and skill architecture 
• Foundry hosted agents quickstart — deploy your first agent in minutes
• Working with Sessions in Foundry Hosted Agents
• Foundry Toolbox overview — connect your agent to M365 and other services

What workflow would you build with a stateful agent? Drop a comment below.

The Summer ’26 release is rolling out to your sandbox environments through May and June, and is scheduled to go live in production mid-June. Specifically, the key dates for this release are: May 8, 2026 (sandbox preview), and May 15, June 5, June 12, and June 13, 2026 (production rollouts), depending on your instance. Check the maintenance calendar for your specific org. 

In this post, we’ll take a look at the highlights for developers across Salesforce Headless 360, Lightning Web Components (LWC), Apex, Agentforce, Data 360, and Agentforce 360 Platform developer tools.

Salesforce Headless 360

Headless 360 makes every major Salesforce capability available as an API, Model Context Protocol (MCP) tool, or CLI command — accessible to any authenticated caller, whether that’s an app, a human, or an autonomous AI agent. It’s the biggest theme of the Summer ’26 release. Headless 360 brings several innovations: hosted MCP servers, new MCP tools, coding skills, and CLI and API enhancements. Let’s dive into the primary developer features related to Headless 360 available in this release.

Salesforce Hosted MCP Servers

Salesforce Hosted MCP Servers let you connect any MCP-compatible AI client, such as Claude, ChatGPT, Cursor, or custom agents, to your Salesforce org and data through the open MCP standard. Every connection uses standard OAuth authentication, so your agents interact with Salesforce data and automation in a secure, governed way. Because Salesforce hosts them, there’s no additional infrastructure to manage. 

You get two flavors: pre-built standard servers, and custom servers that you define yourself.

Standard MCP Servers

Salesforce Hosted Standard MCP Servers are now generally available. Salesforce provides several pre-built standard hosted MCP servers, including:

• SObject Servers: SObject CRUD, SOQL queries, search
• Data 360: Data 360 queries and graph traversal
• Tableau: Analytics and visualization

Custom MCP Servers

When standard MCP servers aren’t enough, you can build custom MCP servers with granular control over which tools and prompts you expose. Custom MCP servers respect the full sharing and security model you have configured for your Salesforce org. Custom MCP tools can be built from:

• Apex Actions: Expose @InvocableMethod (see docs) annotated methods as MCP tools
• Lightning Flows: Expose autolaunched flows as MCP tools
• Apex REST: Expose custom Apex REST endpoints as MCP tools
• AuraEnabled: Expose @AuraEnabled annotated Apex methods as MCP tools
• Named Query API: Expose parameterized SOQL queries as MCP tools
• Prompt Builder: Expose prompts from Prompt Builder as MCP prompts
• Agentforce: Expose Agentforce agents as MCP tools
• API Catalog: Map Salesforce API Catalog (curated registry of REST API endpoints) to MCP tools

For a complete walkthrough, including OAuth configuration details and connecting Claude Desktop and Claude Code, read Connect Claude with Salesforce Hosted MCP Servers and Expose Custom Apex as a Hosted MCP Tool for Agents.

Developer and designer MCP servers and tools

Developers and designers get a productivity boost from MCP-powered tools that bring AI assistance directly into the IDE and coding agents.

Salesforce DX MCP server (Beta):  Two important tools land here. SLDS Guideline tools speeds up UI work with instant Salesforce Lightning Design System (SLDS) styling-hook and component-blueprint guidance. ApexGuru  brings Apex code review into your coding agent from your org’s runtime metrics.  It flags and fixes anti-patterns inline, such as SOQL or DML inside loops and redundant SOQL, and its Test Case Insights surface inefficient tests that drag down coverage.

Metadata API Context MCP Server (Beta): This server now ships five granular tools instead of one. These tools provide contextual information about Salesforce metadata types to help generate accurate metadata files, with faster responses and more efficient token usage.

Data 360 MCP Server (Developer Preview):  This open-source server connects your coding agent to Data 360. Instead of exposing roughly 200 REST operations one by one, it fronts them with three facade tools — search (find a capability by intent), payload_examples (fetch a working request body), and execute (run it) — which keep the coding agent from blowing its context window. 

Omnistudio MCP Server (Beta):  This server bridges agentic and low-code development. Use your coding agent to turn requirements — plain text, screenshots, or UX mockups — into functional Flexcard templates.

B2C DX MCP Server: Modify your Storefront Next components quickly with the Figma-to-Component tool set, converting design files directly into components.

Marketing Cloud Engagement MCP Server: Securely connect external AI agents to Marketing Cloud Engagement and expose core developer capabilities like data extensions and journeys as natural-language tools.

Agent Skills for coding agents

Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows. In this release, we are open-sourcing a library of Salesforce development skills. The skills are optimized to work with the Salesforce coding agent Agentforce Vibes, and are also compatible with any other coding agent, such as Claude Code or Codex.

Skills come pre-packaged with Agentforce Vibes. For any other coding agent, install them using the npx command: npx skills add forcedotcom/sf-skills.

Salesforce CLI updates

Salesforce CLI’s 220+ commands are a core part of Salesforce Headless 360. The CLI keeps shipping every week, and recent releases shipped several updates worth knowing about. We’ll look at the highlights for developers, organized by what they help you build. The emphasis is on Agentforce DX tooling and a major credential security overhaul.

Build agents from a working starting point:

• Agent project scaffolding: Spin up a runnable Agentforce sample instead of starting from scratch. The agent template generates a Local Info Agent demonstrating Apex, Prompt Template, and Flow subagents.

sf template generate project --name my-agent --template agent

• One-command agent user: Automate the setup of service agent users, eliminating the need for manual provisioning.

sf org create agent-user --first-name Service --last-name Agent --target-org my-org

Test, preview, and debug agents:

• Agent preview is GA: You can now script interactive test sessions end to end with agent preview start, send, sessions, and end.
• Trace files for diagnosis: Inspect and manage the traces recorded during a preview session to see exactly how your agent routed and acted.

sf agent trace read --session-id  --format detail --dimension actions

• Richer evaluations (Beta): Run YAML- or JSON-defined evaluation tests for higher-quality, repeatable agent testing.

sf agent test run-eval --spec specs/my-agent-testSpec.yaml --target-org my-org

Keep credentials out of your logs:

• Secrets redacted by default: Access tokens, SFDX auth URLs, and passwords are now stripped from commands like org display and org list --json, preventing accidental leaks in continuous integration (CI) and logs.
• Deliberate secret retrieval: When you actually need a credential, ask for it explicitly.

sf org auth show-access-token --target-org my-org

As always, the deep-dive details for every command and flag live in the Salesforce CLI release notes. Read them to go further.

Salesforce Platform API updates

The platform’s APIs are a big part of Headless 360. Summer ’26 ships API version 67.0, and a few changes are worth knowing about as you build.

Plan now: SOAP login() is being retired

This is the most impactful change in this release for integration owners. SOAP login() in API versions 31.0–64.0 retires in Summer ’27. Any integration that authenticates with a username and password over SOAP will stop working. Move those integrations to OAuth — using external client apps with JWT tokens — well ahead of the cutoff. A new Any API Auth user permission lets you control who can authenticate via SOAP login(), and it’s enforced by default in newly created orgs.

Chain dependent records in one GraphQL request

GraphQL mutations can now reference any field returned by an earlier operation in the same request, not just its record ID. Use @{ref.Record.FieldName.value} for a field value, @{ref.Record.Id} (or shorthand @{ref}) for the ID. This lets you create linked records in a single round trip. Below is an example body for chaining dependent request in one GraphQL

mutation CreateChain {
  uiapi(input: { allOrNone: false }) {
    AccountCreate(input: { Account: { Name: "Headless 360 Test Co" } }) {
      Record { Id  Name { value } }
    }
    ContactCreate(input: { Contact: {
      LastName: "@{AccountCreate.Record.Name.value}"
      AccountId: "@{AccountCreate}"   # == AccountCreate.Record.Id
    }}) { Record { Id  LastName { value } } }
    OpportunityCreate(input: { Opportunity: {
      Name: "@{ContactCreate.Record.LastName.value}"
      AccountId: "@{AccountCreate.Record.Id}"
      StageName: "Value Proposition"
      CloseDate: "2026-12-31"
    }}) { Record { Id } }
  }
}

You can use a Beta Salesforce CLI command to execute any GraphQL as shown below.

sf api request graphql --body  --target-org my-org

Use JWT access tokens with SOAP API

SOAP API now accepts JWT-based access tokens from Salesforce OAuth flows in the sessionId header element, reaching parity with REST authentication and making token sharing with external services safer.

Connect REST API rate limits are relaxed

Orgs have been migrated off the restrictive per-user, per-application, per-hour Connect REST API limit and onto the more generous per-org, per-24-hour Salesforce Platform API limit — the same pool that every other API call shares. Only requests that require Chatter keep the old hourly throttle. The identical change applies to Connect in Apex.

User Interface API CSRF token

A new GET /ui-api/session/csrf resource (see docs) returns a token that you can use to protect User Interface API requests from third-party forgeries.

LWC updates

Summer ’26 is a maturity release for LWC. The big themes: cleaner architecture (state finally lives outside your components), a quicker edit-and-preview cycle (real-time previews in the browser and your IDE), better defaults (more virtualization, tighter security), and a new bridge to Agentforce. 

Here are the five features most likely to change how you build — each with the problem it solves.

• State Managers (GA): These pull data and its logic out of components into a reusable, testable layer.
• API 67.0 niceties: This includes zero-JS accordions via grouped <details>, plus faster hot reload.
• Secure downloads: LWS now blocks data: URIs, so generate files the right way.
• Dynamic lists (in Developer Preview): This renders thousands of rows smoothly with built-in virtualization.
• lightning/accApi: This new module lets your components open and drive the Agentforce panel.

State Managers for LWC

State Managers is the most consequential LWC feature going GA during this release. State managers move data and the logic that mutates it out of components into a dedicated layer. Build one as a plain JS module with the new defineState primitive from @lwc/state, which gives you three building blocks:

• atom(value): Reactive state, read through .value
• computed([deps], fn): A derived value that recomputes when a dependency changes
• setAtom(atom, value): The only way to update an atom

defineState returns a factory — each call yields a fresh, independent instance. The essential shape: one atom as the source of truth, a derived computed, and an action that mutates via setAtom.

Below is example code that demonstrates a state manager in action, handling a cart:

cartStateManager.js

import { defineState } from '@lwc/state';
export default defineState(({ atom, computed, setAtom }) => {
    const items = atom([]);                       // source of truth
    const count = computed([items], (l) => l.length); // derived
    const addItem = (item) =>                       // action
        setAtom(items, [...items.value, item]);
    return { items, count, addItem };
});

A component imports the manager module, calls the factory, then reads reactive state through .value — in JS or the template, which re-renders automatically on change. No data logic, no manual subscription:

cartSummary.js

import { LightningElement } from 'lwc';
import createCartStateManager from 'c/cartStateManager';
export default class CartSummary extends LightningElement {
    cart = createCartStateManager();
}

cartSummary.html

<template><h2>Your Cart ({cart.value.count})</h2><p>
</p></template>

For complete, runnable examples, see the open-source lwc-recipes repo. Because each instance is isolated, managers are trivially unit-testable.

Salesforce also ships built-in Lightning state managers that wrap Lightning Data Service (LDS) access to the most common UI API data and metadata — for records, object info, page layouts, and related lists (for example, lightning/stateManagerRecord and lightning/stateManagerObjectInfo). They follow the same pattern as the ones you write and participate fully in LDS caching, normalization, and subscriptions, so reach for them before rolling your own.

LWC API version 67.0: Group <details> and faster HMR

To enable the features of this release, update your bundle .js-meta.xml by setting <apiVersion>67.0</apiVersion>.

Two wins by using the 67.0 API version: hot module reloading (HMR) is faster and more memory-efficient, and you can now group native <details> elements with the name attribute for a zero-JavaScript exclusive accordion (it threw a compiler warning before 67.0). Same name = only one open at a time.

faqAccordion.html

<details key={faq.id} name="summer26-faq">
    <summary>{faq.question}</summary>
    <p>{faq.answer}</p></details>

Secure file downloads: LWS blocks data: URIs

Lightning Web Security (LWS) adds a batch of API distortions in this release. The one most likely to break code: HTMLAnchorElement.prototype.href now blocks the data: URI scheme. If you trigger client-side downloads by setting an anchor’s href to a data: URL, that stops working.

The fix is the supported pattern anyway — build a blob in JavaScript and use a blob: object URL (origin-bound, and revoked after use).

secureDownload.js

// LWS-safe: blob: URL, not data:
const blob = new Blob([this.content], { type: 'text/plain' });
const url = URL.createObjectURL(blob);
anchor.href = url;
anchor.download = this.fileName;
anchor.click();
URL.revokeObjectURL(url); // release memory

Other new distortions include Element.getAttribute, innerHTML/outerHTML getters, MutationObserver.observe, the IndexedDB factory, Promise.then/catch/finally, and more — with matching ESLint rules. Run the updated ESLint package and review the LWS Distortion Viewer before you upgrade the components to this release.

Load large lists dynamically (Developer Preview)

Rendering thousands of rows used to choke the browser, the new lightning-dynamic-list-container (see docs) and lightning-dynamic-list-item (see docs) base components use virtualization. They render only the rows in the viewport and stream the rest in as you scroll, from 50 items to 5,000.

dynamicContactList.html

<!-- Container needs a bounded height for scroll + virtualization -->
<div style="height: 400px">
  <lightning-dynamic-list-container
      onrenderlistitems={handleRenderListItems}
      onloadmore={handleLoadMore}>
    <template for:each={visibleContacts} for:item="contact">
      <lightning-dynamic-list-item
          key={contact.id} item-id={contact.id}>
        <div>{contact.name}</div>
      </lightning-dynamic-list-item>
    </template>
  </lightning-dynamic-list-container>
</div>

The container fires renderlistitems as you scroll (which slice to render) and loadmore near the end:

dynamicContactList.js

handleRenderListItems(event) {
    const { startIndex, endIndex } = event.detail;
    this.visibleContacts = this.allContacts.slice(startIndex, endIndex);
}

You also get focus preservation and built-in accessibility (screen readers, Home/End/Arrow nav, Browse-Mode hint). 

Here are some recommendations for working with dynamic lists: keep container and item adjacent, give every item a unique item-id, and don’t set overflow: scroll on your own container — the component handles scrolling.

Talk to Agentforce from LWC with new LWC module lightning/accApi

The standout new module is lightning/accApi (see docs) — the Agentforce Conversation Client API. This headless module lets your LWC components drive the native Agentforce side panel in Lightning Experience: open it, close it, point it at a specific Employee Agent, and send natural-language utterances. Think of a “Summarize this record” button, or a context-aware launcher in a console sidebar.

The entire API is three async methods:

All three return a Promise and are queued, running in sequence. Note execute does not return the reply — the conversation renders in the panel, not your component. Import the methods and call them.

agentforceLauncher.js

import { open, close, execute } from 'lightning/accApi';

@api botId; // design-time property, set on the page

async handleOpen() {
    await open(this.botId);
}
async handleQuickAction(event) {
    const { utterance } = event.currentTarget.dataset;
    await execute(utterance, this.botId); // wrap in try/catch + toast
}

// Deploying this class at API 67.0 fails with:
//   "WITH SECURITY_ENFORCED is no longer supported, use WITH USER_MODE instead."
[SELECT Id FROM Account WITH SECURITY_ENFORCED LIMIT 1];

try {
    List a = [SELECT Id, Name, AnnualRevenue FROM Account WITH USER_MODE LIMIT 1];
} catch (QueryException e) {
    // returns Map fieldNames>
    Map<String, Set> blocked = e.getInaccessibleFields();
}

String payload = '''
{
    "Account": "${accountName}",
    "Last Updated": "${date}"
}'''.template(new Map<String, Object>{
    'accountName' => 'My Account',
    'date' => Datetime.newInstance(2018, 11, 15, 8, 0, 0)
});

@IntegrationTest
public with sharing class MyServiceIntegrationTest {
    @IntegrationTest
    public static void testServiceInteraction() {
        Account a = new Account(Name = 'Integration Test Account');
        insert as user a;
        IntegrationTest.commitTestOnly();           // data survives mid-test
        Account r = [SELECT Name FROM Account WHERE Id = :a.Id WITH USER_MODE];
        Assert.areEqual('Integration Test Account', r.Name);
    }
    @TearDown
    public static void tearDown() {
        delete as user [SELECT Id FROM Account WHERE Name = 'Integration Test Account' WITH USER_MODE];
    }
}

sf api request rest "/services/data/v67.0/einstein/data-libraries" \
  --method POST --target-org my-org \
  --body '{
    "masterLabel": "Product Docs Library",
    "developerName": "Product_Docs_Library",
    "groundingSource": { "sourceType": "SFDRIVE" }
  }'
# → { "libraryId": "1JD...", "status": "IN_PROGRESS" }

knowledge:
    rag_feature_config_id: "ARFPC_1JDcf0000024ZZ7GAM"
    citations_enabled: True

import { AgentforceService } from 'react-native-agentforce';
// Option A — Service Agent (anonymous, customer-facing)
await AgentforceService.configure({
    type: 'service',
    serviceApiURL: 'https://service.salesforce.com',
    organizationId: '00DWs00000Ip47F',
    esDeveloperName: 'Order_Support_Agent',        // the agent's API name
    serviceUISettings: { enableLightningType: true }  // render Custom Lightning Types as cards
});

// Option B — Employee Agent (internal, authenticated)
await AgentforceService.configure({
    type: 'employee',
    instanceUrl: 'https://your-domain.my.salesforce.com',
    organizationId: '00DWs00000Ip47F',
    userId: '005xx0000001234',
    agentId: '0XxWs000001DTDJK'                       // Bot Id from publishing the agent
});

await AgentforceService.setAdditionalContext({
    variables: [{ name: 'userId', type: 'Text', value: '005xx0000001234' }]
});

await AgentforceService.launchConversation();

SELECT Id, EmailOptIn__c
FROM ContactDLO__dlm
WHERE EmailOptIn__c = ''
SET OPTIONS (dataspace = 'default', honorEmptyStrings = true)

The post The Salesforce Developer’s Guide to the Summer ’26 Release appeared first on Salesforce Developers Blog.