<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel>
        <title>Products &amp; Solutions | Blog</title>
        <link>https://www.zscaler.com/blogs/feeds/product-insights</link>
        <description>Latest news and views from the leading voices in cloud security and secure digital transformation.</description>
        <lastBuildDate>Fri, 04 Sep 2026 17:02:11 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>RSS 2.0, JSON Feed 1.0, and Atom 1.0 generator for Node.js</generator>
        <language>en</language>
        <item>
            <title><![CDATA[Zscaler and OpenAI: Bringing Frontier AI-Powered Security to the Enterprise]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zscaler-and-openai-bringing-frontier-ai-powered-security-enterprise</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zscaler-and-openai-bringing-frontier-ai-powered-security-enterprise</guid>
            <pubDate>Fri, 04 Sep 2026 00:01:55 GMT</pubDate>
            <description><![CDATA[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.]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[M-25-21 Changes the AI Conversation for Federal Civilian Agencies]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/m-25-21-changes-ai-conversation-federal-civilian-agencies</link>
            <guid>https://www.zscaler.com/blogs/product-insights/m-25-21-changes-ai-conversation-federal-civilian-agencies</guid>
            <pubDate>Wed, 02 Sep 2026 15:59:53 GMT</pubDate>
            <description><![CDATA[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,&nbsp;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]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Rethinking OT Boundaries: Sandworm&#039;s Cellular Breach of a Polish Power Plant]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/rethinking-ot-boundaries-sandworm-s-cellular-breach-polish-power-plant</link>
            <guid>https://www.zscaler.com/blogs/product-insights/rethinking-ot-boundaries-sandworm-s-cellular-breach-polish-power-plant</guid>
            <pubDate>Mon, 31 Aug 2026 16:50:04 GMT</pubDate>
            <description><![CDATA[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&nbsp;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.&nbsp; 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.&nbsp;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.&nbsp;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 &amp; 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.&nbsp;Read More&nbsp; The Zscaler SolutionTo comprehend how Zscaler secures OT environments, we must first examine the core principles of the&nbsp;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.&nbsp;&nbsp;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.→&nbsp; Learn more at&nbsp;https://resources/security-terms-glossary/what-is-operational-technology-ot-security/products-and-solutions/zscaler-cellular&nbsp;Act Fast. Stay Secure.&nbsp;]]></description>
            <dc:creator>Hitesh Chhabra (Architect, Solutions Consulting)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Hugging Face Breach: Key Questions Every Security Leader Must Answer]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/hugging-face-breach-key-questions-every-security-leader-must-answer</link>
            <guid>https://www.zscaler.com/blogs/product-insights/hugging-face-breach-key-questions-every-security-leader-must-answer</guid>
            <pubDate>Mon, 31 Aug 2026 07:29:58 GMT</pubDate>
            <description><![CDATA[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.&nbsp;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.&nbsp; 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.&nbsp;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.&nbsp;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.&nbsp;&nbsp; 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?&nbsp;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&nbsp;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.&nbsp;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.]]></description>
            <dc:creator>Paul Aiuto (Director, Commercial Sales Engineering - Americas)</dc:creator>
        </item>
        <item>
            <title><![CDATA[It No Longer Takes an Expert to Attack a Factory]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/it-no-longer-takes-expert-attack-factory</link>
            <guid>https://www.zscaler.com/blogs/product-insights/it-no-longer-takes-expert-attack-factory</guid>
            <pubDate>Thu, 27 Aug 2026 16:32:03 GMT</pubDate>
            <description><![CDATA[Factories have never lacked attackers. Manufacturing has sat at or near the top of the&nbsp;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,&nbsp;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,&nbsp;published research has shown AI turning a released patch into a working exploit in hours. And open-weight models that anyone can download are&nbsp;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 -&nbsp;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.&nbsp;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.&nbsp; 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.&nbsp;&nbsp;This is the thinking behind Zscaler's approach to OT - my colleague Amit Aneja's recent post,&nbsp;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.&nbsp; It is the work we do in an&nbsp;OT architecture workshop.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler WebMCP Security Controls: Bringing Zero Trust to the Agentic Web]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zscaler-webmcp-security-controls-bringing-zero-trust-agentic-web</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zscaler-webmcp-security-controls-bringing-zero-trust-agentic-web</guid>
            <pubDate>Thu, 27 Aug 2026 00:08:36 GMT</pubDate>
            <description><![CDATA[We are excited to announce&nbsp;WebMCP Security Controls&nbsp;(Web Model Context Protocol)&nbsp;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&nbsp;Chrome Origin Trials. WebMCP lets websites expose structured, typed JavaScript functions and annotated HTML forms as callable tools for AI agents.&nbsp;&nbsp;An in-page AI agent can then list those tools and invoke them programmatically, i.e.&nbsp;get_cart,&nbsp;update_cart,&nbsp;search_flights,&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;Monitor WebMCP and runs in passthrough mode with all seven&nbsp;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&nbsp;get_cart and answers in real time. On the admin side, each interaction shows up as a new detection with severity&nbsp;Informational and effect&nbsp;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&nbsp;Block WebMCP with a single condition:&nbsp;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&nbsp; visible in real time. The user asks the agent to add an item to their cart. The agent tries to call&nbsp;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&nbsp;Low, effect&nbsp;Block, and the exact rule reason:&nbsp;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&nbsp;submit_payment. A support team’s agens does not need to invoke&nbsp;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:&nbsp;webmcp.tool.arguments contains "book". Every&nbsp;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&nbsp;browse_store, which is allowed, and returns a catalog. Two items in it are relevant here: a&nbsp;Hammer Time Graphic Tee and a&nbsp;Book Cat Graphic Tee. The user asks to add the Hammer Time tee first. The argument payload contains&nbsp;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&nbsp;book-cat-graphic-tee-apple-blossom-26f12103, which does match on&nbsp;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,&nbsp;reach out to your account team for a demo or visit the&nbsp;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.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What to Look for in a Deception Technology Solution]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-to-look-for-deception-technology</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-to-look-for-deception-technology</guid>
            <pubDate>Wed, 26 Aug 2026 17:06:19 GMT</pubDate>
            <description><![CDATA[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&nbsp; 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.&nbsp;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&nbsp; 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&amp;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?&nbsp; 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&nbsp; Common Use Cases &amp; 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:&nbsp;Providing high-fidelity leads that analysts can pivot from to uncover threatsHigh Maintenance: Platforms requiring constant manual updates drain valuable resources&nbsp; 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.&nbsp; 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.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What’s New in GovCloud:  August 2026 Zscaler Product Updates]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-august-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-august-2026-zscaler-product-updates</guid>
            <pubDate>Wed, 26 Aug 2026 08:14:46 GMT</pubDate>
            <description><![CDATA[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:&nbsp;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:&nbsp;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:&nbsp;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:&nbsp;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:&nbsp;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:&nbsp;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.]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust or Bust: Winning Compliance in an AI-Driven Multicloud World]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zero-trust-or-bust-winning-compliance-ai-driven-multicloud-world</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zero-trust-or-bust-winning-compliance-ai-driven-multicloud-world</guid>
            <pubDate>Tue, 25 Aug 2026 21:45:52 GMT</pubDate>
            <description><![CDATA[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.&nbsp; 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 &amp; 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.&nbsp; 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.&nbsp; What Compliance Actually Requires&nbsp;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.&nbsp; 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&nbsp;&nbsp;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&nbsp;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.&nbsp;&nbsp;&nbsp;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:&nbsp;enterprises that integrate compliance and security analytics into a single platform experience 30% fewer regulatory violations.&nbsp; 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:&nbsp;$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&nbsp;continuous, automated state&nbsp;of verified protection&nbsp;with Zscaler. They&nbsp;were able to directly address the stringent network security controls mandated by&nbsp;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&nbsp;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.&nbsp;&nbsp; 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.&nbsp; Ready to turn audit dread into audit readiness?Read this&nbsp;solution brief to learn more about how Zero Trust Cloud helps achieve continuous compliance.Explore the&nbsp;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.&nbsp;]]></description>
            <dc:creator>Nikitha Omkar (Senior Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Fix Has Been Out for a Year. The Controller Is Still Exposed.]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/fix-has-been-out-year-controller-still-exposed</link>
            <guid>https://www.zscaler.com/blogs/product-insights/fix-has-been-out-year-controller-still-exposed</guid>
            <pubDate>Thu, 20 Aug 2026 17:49:11 GMT</pubDate>
            <description><![CDATA[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.&nbsp;&nbsp; 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&nbsp;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&nbsp;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&nbsp;segmentation&nbsp;policy fail in practice. Eaton's security team described exactly this in&nbsp;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.&nbsp;&nbsp; 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&nbsp;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&nbsp;OT architecture workshop maps the controllers, the vendors who reach them, and the enforcement points you already have.&nbsp;&nbsp;]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Aligning ITAR Compliance to Zscaler’s Zero Trust Exchanges]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/aligning-itar-compliance-zscaler-s-zero-trust-exchanges</link>
            <guid>https://www.zscaler.com/blogs/product-insights/aligning-itar-compliance-zscaler-s-zero-trust-exchanges</guid>
            <pubDate>Wed, 19 Aug 2026 22:56:05 GMT</pubDate>
            <description><![CDATA[Navigating When to Purchase Commercial, FedRAMP Moderate, and FedRAMP High Platforms to Support ITAR ComplianceITAR violations carry criminal and civil penalties that can result in debarment from federal contracts. This guide maps ITAR compliance requirements to Zscaler's three platform tiers:&nbsp;1)&nbsp;Zscaler Commercial,&nbsp;&nbsp;2)&nbsp;Zscaler FedRAMP Moderate, and&nbsp;3)&nbsp;Zscaler FedRAMP High.Zscaler's FedRAMP Moderate and High platforms support a customer’s ITAR compliance program, with ITAR reports publicly available at zscaler.com/compliance/overview. Organizations handling ITAR-regulated data should understand which platform tier aligns to their specific compliance posture and that, overall, controls remain a customer responsibility regardless of platform selection. Understanding ITAR RequirementsThe International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State's Directorate of Defense Trade Controls (DDTC), governs the manufacture, export, and brokering of defense articles and related services listed on the United States Munitions List (USML). Before evaluating any cloud security platform, organizations must understand what ITAR demands at the operational level:DDTC Registration:&nbsp;&nbsp;Organizations that manufacture, export, or broker defense articles or defense services must register with the Directorate of Defense Trade Controls (22 CFR Part 122 and Part 129).Access Restricted to U.S. Persons:&nbsp; ITAR-controlled technical data may only be accessed by U.S. persons (citizens, lawful permanent residents, or certain protected individuals) and entities incorporated in the U.S. unless specific DDTC authorization has been granted (22 CFR § 120.62).Deemed Exports: Disclosing or transferring ITAR-controlled technical data to a foreign person, even within the United States, is treated as an export (a 'deemed export') and requires prior DDTC authorization. This is the primary regulatory basis for restricting access to U.S. persons (22 CFR § 120.50).Prohibition on Unauthorized Export:&nbsp; ITAR-controlled technical data may not be exported without prior authorization from the DDTC (22 CFR § 127.1).Release of Technical Data: Under ITAR, technical data is "released" through visual or other inspection of a defense article that reveals technical data to a foreign person, oral or written exchanges with foreign persons, or the use of access information (such as decryption keys or network credentials) that enables a foreign person to access unencrypted technical data. A release to a foreign person constitutes an export under 22 CFR § 120.50 and requires prior DDTC authorization. Organizations using cloud security platforms that inspect, process, or store unencrypted ITAR-controlled technical data must ensure that platform personnel who can access that data in unencrypted form are U.S. persons or that appropriate DDTC authorization is in place (22 CFR § 120.50, 120.55, 120.56).Audit and Continuous Monitoring:&nbsp;&nbsp;DDTC expects organizations to maintain records demonstrating compliance with access controls, data handling policies, and export authorizations. Zscaler's Three Platform TiersZscaler operates three distinct platform environments, each with different compliance postures relevant to ITAR-regulated workloads. Choosing which tier to operate in is a customer responsibility based on their compliance risk tolerance.Zscaler Commercial Platform&nbsp;Zscaler's commercial platform delivers the full Zero Trust Exchange capability set for enterprise customers worldwide. It is cloud-native, operates across a global network of 160+ Points of Presence (PoPs), and is designed to support the security requirements of commercial and multinational companies and organizations.Key Attributes for the Commercial Platform:Compliance:&nbsp;ISO 27001, SOC2 Type 2, CSA STAR Level 2 and other industry and regional compliance certifications, attestations and standards. Please visit Zscaler’s&nbsp;Customer Compliance Center for more information.&nbsp;Locations:&nbsp;US &amp; International.&nbsp;U.S.-person operational support coverage: Support personnel access may include non-U.S. persons, and the platform is not restricted to the U.S.-based infrastructure.Data Types:&nbsp;Suitable for non-ITAR/non-CUI workloads.Zscaler Commercial Platform ITAR PostureOrganizations handling ITAR-regulated technical data should not route that data through commercial-tier nodes without applying additional compensating controls.&nbsp;Organizations that do not handle ITAR-regulated technical data can leverage the commercial platform's full capability set without compliance exposure&nbsp; Zscaler FedRAMP Moderate PlatformZscaler Internet Access (ZIA) and Zscaler Private Access (ZPA) on the FedRAMP Moderate authorized platform are designed for U.S. federal agencies and government contractors processing Controlled Unclassified Information (CUI) at the Moderate baseline. This platform is physically separated from commercial infrastructure and operated with U.S. persons in support roles.Key Attributes of FedRAMP Moderate:Compliance:&nbsp;FedRAMP Moderate, CJIS, IRS 1075 FTI RequirementsLocations: US &amp; International&nbsp;International locations are not enabled by default and require an additional configuration and purchase.&nbsp;U.S.-person operational support coverage:&nbsp;&nbsp;Tier 1 and Tier 2 support personnel accessing government platform environments are subject to screening controls consistent with federal requirements.&nbsp;&nbsp;Technical support provided by personnel from Tier 3 and above may be provided by a mixed population of US- and non-US personnel and may include OCONUS access. Entities managing ITAR-regulated technical data must assess if this operational support coverage aligns with regulatory prohibitions on foreign person access within their unique risk profile.Data Types:&nbsp;Controlled Unclassified Information (CUI) Zscaler FedRAMP High PlatformZscaler's FedRAMP High authorized platform represents the most rigorous compliance posture available within the Zero Trust Exchange. It is designed to protect the government's most sensitive unclassified data and is the recommended environment for organizations with ITAR-regulated technical data, or contractual requirements that demand the highest cloud security baseline.Key attributes of the FedRAMP High platform:Compliance:&nbsp;FedRAMP High, CJIS, IRS 1075 FTI RequirementsLocations:&nbsp;CONUS-only&nbsp;U.S.-Screened Personnel:&nbsp;All access to systems processing customer data on this platform is restricted to screened U.S. persons, consistent with ITAR's foreign person access prohibition.Data Types:&nbsp;Controlled Unclassified Information (CUI)Zscaler FedRAMP High ITAR PostureZscaler's FedRAMP High platform is designed to align with organizations with ITAR-regulated technical data. It is the only Zscaler platform tier for which complete US-person coverage is available. Hundreds of federal agencies and DIB customers currently use Zscaler's FedRAMP authorized platforms to secure their missions.&nbsp; Platform Compliance ComparisonCompliance &amp; CapabilitiesCommercialCloudFedRAMPModerateFedRAMPHighFedRAMP Authorization LevelN/AModerateHighFedRAMP 20x Classification ClassN/AClass CClass DITAR Compliance Report AvailableX✓✓Complete US-person CoverageX/✓U.S.-Person Access Controls&nbsp;(Support Staff)/✓✓U.S. Data SovereigntyX/✓Recommended for ITAR-regulated technical dataXX✓✓ = Supported / Customer Responsibility &nbsp;&nbsp;X = Not Available / No Commitment&nbsp;&nbsp; / = Partial / Risk Acceptance Required&nbsp; Zscaler Capabilities That Can Support ITAR ComplianceThe following capabilities are available across FedRAMP Moderate and High platforms with customer-driven ITAR-relevant configurations.Zero Trust Network Access (ZPA)Unlike legacy VPN architectures, Zscaler Private Access does not expose network topology to users or attackers. ZPA verifies every user and device before access is granted, enforcing least-privilege access to applications, not networks. This eliminates the risk of lateral movement to ITAR-regulated systems and prevents foreign-person attribution through network traffic analysis. ZPA's application-level access model means ITAR technical data remains siloed within authorized application boundaries.Secure Web Gateway (ZIA) with 100% SSL/TLS InspectionZscaler Internet Access performs complete SSL/TLS inspection, including encrypted traffic, without performance degradation. This is operationally critical for ITAR compliance: without full inspection, encrypted exfiltration channels remain a blind spot. ZIA's AI/ML-driven threat detection analyzes over 119 trillion annual transactions to identify and block emerging threats, including those targeting defense-sector organizations.&nbsp;Data Loss Prevention (DLP)Zscaler's DLP capability performs AI-driven content inspection to detect and classify ITAR-regulated technical data, including CAD files, engineering specifications, and defense-related documentation. Inspecting encrypted traffic at scale ensures no blind spots exist for data exfiltration through SSL channels. DLP policies can be configured to block, warn, or log transfers of ITAR-sensitive content, and telemetry feeds directly into audit records required for DDTC compliance demonstration.Cloud Access Security Broker (CASB)Zscaler CASB provides visibility and control over cloud application usage, enabling organizations to detect when ITAR-regulated data is being uploaded to unauthorized cloud services. On FedRAMP Moderate and High platforms, CASB applies ITAR-aware policies, generating the audit record necessary to demonstrate that ITAR technical data is not being transmitted to unauthorized cloud environments or accessed by foreign-person-operated services.Advanced Threat ProtectionNation-state actors routinely target defense contractors handling ITAR-regulated technical data. ZIA blocks an average of 1,700 threats daily and 4.5 billion threats monthly using behavioral analysis and threat intelligence from Zscaler's global sensor network. For DIB organizations, this threat protection layer is the first line of defense against the APT campaigns most likely to pursue ITAR-covered defense technology.FIPS-Validated EncryptionZscaler supports FIPS-validated encryption across all platform tiers. FIPS-validated end-to-end encryption is a primary mechanism to reduce residual risk. However, FIPS-validated encryption should not be used as a substitute for the contractual commitments available on FedRAMP Moderate and High platforms. While properly encrypted data in transit may fall outside the export definition, the carve-out does not eliminate the need for U.S.-person access controls on decryption keys and the underlying data. (22 CFR § 120.54(a)(5))ITAR "Release" Considerations for Cloud Security FeaturesSeveral Zscaler capabilities involve inspecting, analyzing, or processing customer traffic in unencrypted form. When that traffic contains ITAR-controlled technical data, these activities may constitute a "release" of technical data under 22 CFR § 120.56 if platform personnel who are foreign persons can access the unencrypted content. On Zscaler's FedRAMP Moderate and High platforms, support personnel with access to customer environments are screened U.S. persons, which mitigates this risk. On the commercial platform, support personnel may include foreign persons, and Zscaler does not contractually restrict access on a nationality basis. Customers routing ITAR-controlled technical data through any Zscaler platform are responsible for evaluating whether the platform's access controls are sufficient to prevent an unauthorized release under their specific compliance posture.&nbsp; ITAR Requirement MappingTo support customers in leveraging Zscaler to implement ZTNA to meet ITAR requirements, Zscaler provides the following table mapping Zscaler capabilities to some of ITAR’s requirements. This mapping applies to FedRAMP Moderate and High platform deployments.ITAR RequirementZscaler Platform CoverageCustomer ResponsibilityAccess Restricted to U.S. Persons (22 CFR § 120.62)ZIA and ZPA verify identity and device posture before granting application access.FedRAMP Gov platform support staff restricted to screened U.S. persons.ZPA enforces least-privilege access policies.Customers must screen internal users for U.S. person status. Customers must configure ZPA policies to enforce ITAR data access restrictions.Prohibition on Unauthorized Export (22 CFR&nbsp;§&nbsp;127.1)CASB detects and blocks uploads of ITAR data to unauthorized cloud services.DLP identifies and prevents transmission of ITAR-regulated content.ZIA enforces outbound traffic policies.Customers must define DLP policies aligned to their ITAR technical data categories. Customers must obtain and document any required DDTC export authorizations.Data Residency and Transmission ControlsFedRAMP High platform restricts data processing to CONUS infrastructure.FIPS-validated encryption for in-transit data protection.Customers must select FedRAMP Moderate or High platform (not commercial) for ITAR workloads. Customers must document data flows and residency requirements.Audit and Continuous Monitoring (DDTC recordkeeping)ZIA and ZPA generate detailed session logs for audit review.DLP telemetry provides evidence of policy enforcement.CASB reports document cloud application governance posture.Customers must retain logs in accordance with DDTC record retention requirements. Customers must establish continuous monitoring processes aligned to their ITAR compliance program.DDTC Registration and Contractual CommitmentsZscaler provides contractual ITAR commitments on FedRAMP Moderate and High platforms.ITAR compliance reports available at zscaler.com/compliance/overview.Customers must register with DDTC independently.&nbsp; Customers must execute appropriate contractual agreements with Zscaler via the FedRAMP Gov platforms.&nbsp; Choosing the Right Zscaler PlatformThe decision framework for platform selection is straightforward: the nature of the data and the contractual requirements of the organization determine the appropriate platform tier.Select Zscaler FedRAMP High If:Your organization handles ITAR-regulated technical data in the course of normal operations.Your organization handles CUI in the course of normal operations.Your prime contract or government agreement requires a cloud platform with US-person contractual requirements.You need the Zscaler platform that provides the strongest available audit evidence for DDTC compliance demonstration.Select Zscaler FedRAMP Moderate If:Your organization handles ITAR-regulated technical data in the course of normal operations.Your organization handles CUI in the course of normal operations.You are pursuing CMMC Level 2 compliance.You need FedRAMP authorization for civilian agencies or lower-sensitivity government workloads.You are migrating from commercial toward higher compliance posture.Admin Note:&nbsp;Depending on the supported product, technical support provided by personnel from Tier 3 and above may be provided by a mixed population of US- and non-US personnel and may include OCONUS access.Select Zscaler Commercial Platform If:Your organization does not handle&nbsp;ITAR-regulated technical data or&nbsp;CUI at the Moderate or High baseline.You are a commercial enterprise&nbsp;without federal contracting requirements that trigger FedRAMP or ITAR requirements.You require the full commercial capability set, including integrations with the global Azure commercial or AWS commercial ecosystems, and your workloads are not ITAR-restricted. ConclusionITAR compliance in a cloud security context is not a checkbox. It is a continuous operational discipline that begins with selecting the right platform and extends through policy configuration, access governance, audit, and documented risk management.Zscaler's Zero Trust Exchange provides the security architecture and platform tiers necessary to support compliance at every level of the Defense Industrial Base:Zscaler FedRAMP High platform:&nbsp;The highest available unclassified security posture, with contractual ITAR commitments, and FedRAMP authorization. It provides the strongest available controls for organizations processing ITAR-regulated technical data.Zscaler FedRAMP Moderate platform:&nbsp;U.S. government-grade security with ITAR compliance reports for DIB and civilian agency workloads.Zscaler Commercial platform:&nbsp;Full Zero Trust Exchange capabilities for non-ITAR enterprise workloads.Choosing the right platform, and configuring it correctly, is a risk decision that belongs to the customer. Zscaler's Federal and Defense segment is positioned to support that decision through platform guidance, compliance documentation, and field advisory engagement with CISOs, CIOs, and compliance officers across the Defense Industrial Base.This guide is for informational purposes only and does not constitute legal or export-control advice. Information is current as of&nbsp;August 19, 2026 and subject to change. Zscaler makes no representations or warranties regarding the applicability of this guide to any organization’s specific compliance requirements. Consult qualified export-control counsel before making platform or compliance decisions based on this guide.]]></description>
            <dc:creator>Jeffrey Adorno (Director, Emerging Technology)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Securing the Unsecurable: OT, IoT, and the Factory Floor]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/securing-unsecurable-ot-iot-and-factory-floor</link>
            <guid>https://www.zscaler.com/blogs/product-insights/securing-unsecurable-ot-iot-and-factory-floor</guid>
            <pubDate>Mon, 17 Aug 2026 21:57:14 GMT</pubDate>
            <description><![CDATA[Modern manufacturing is undergoing a massive shift toward connected operations. We are seeing a flood of advanced IoT sensors and diverse OT systems that drive everything from real-time vibration monitoring to predictive maintenance. This connectivity is the engine for growth, faster supply chain fulfillment, and the kind of innovation that keeps a manufacturer competitive.However, in this environment, uptime and availability are the only metrics that matter. This is the primary lens through which operators are evaluated and plant managers justify their budgets. Operational resilience is the ultimate win, which means security often takes a backseat to anything that might stop the line.&nbsp;This gap has made manufacturing the&nbsp;top target for ransomware. The recent release of Anthropic’s Claude Mythos has fundamentally changed the math for industrial security. Any connected device can be exploited; if it’s reachable, it’s breachable. In OT, you can’t simply "auto-update" to stay ahead of zero day vulnerabilities; patching requires planned outages and rigorous vendor validation to ensure a "fix" doesn't accidentally shut down the plant.&nbsp; How Attacks Move from IT to the Factory FloorMost factory breaches don’t start on the factory floor. In reality, they almost always start in IT. Attackers look for the low-hanging fruit, i.e. a weak VPN, an exposed service, or through remote access. Once they have that foothold, they don't need to break into your OT network; they just use the connectivity you’ve already built. Whether your plants are connected via MPLS, VPNs, or an SD-WAN mesh, the underlying problem is the same: these technologies&nbsp;extend trust,&nbsp;not just connectivity. You might have intended to give a vendor access to one specific machine, but by advertising a subnet over a routed tunnel, you made that entire vlan or zone routable.&nbsp; The Two Highest Impact Ways to&nbsp;Defend Against AI AttacksMinimize your external attack surface - Zscaler Zero Trust Branch (ZTB) creates helps your branches go dark. We remove all inbound listeners. All the traffic comes in and goes out through Zero Trust Exchange ensuring that there is nothing for an attacker to find. If they can’t find you, they can’t exploit you. Period.Kill lateral movement with microsegmentation: You have to assume a threat will eventually get inside, maybe through a compromised vendor laptop. Most factory networks are flat allowing attackers to laterally move within the VLAN.&nbsp;This makes your attack surface as wide as your subnet mask.&nbsp;For example, a /20 subnet mask puts 4000+ devices at risk.&nbsp;&nbsp;Zscaler Zero Trust Branch handles this by creating a&nbsp;"Network-of-One" for every asset. This isolates every device so one compromised machine can't trigger a plant-wide shutdown.&nbsp; Microsegmentation On the Factory FloorSegmentation has been a long-held elusive goal for many OT architects. Compliance and critical infrastructure safety directives make this mandatory to prevent lateral movement of threats. In this blog series, we will examine how microsegmentation can help you eliminate lateral threat movement in complex OT environments where traditional IT tools just won’t work..&nbsp;There are three strategic pillars to doing microsegmentation right:Bridging the Asset Visibility Gap on a Factory FloorMapping the threat landscape and defining your policy framework.Operations and Incident response with Ransomware Kill Switch First Pillar: Asset Visibility&nbsp;Let’s look at the visibility capabilities in four parts:Asset Inventory: Defending OT systems starts with knowing what you have and its risk profile. Zscaler Zero Trust Branch (ZTB) provides AI-powered device discovery and classification that allows you to inventory OT/IoT devices without the need for endpoint agents, scanners, or traffic mirroring. By sitting natively inline, we fingerprint every asset in real-time as traffic flows through the gateway. By combining DHCP fingerprinting, JA3 TLS hashes, and HTTP User Agent analysis with other L2 and L3 data, ZTB builds a multi-dimensional profile of every asset in real-time.Signature-less AI Discovery: Traditional tools usually fail when they hit a device they haven’t seen before because they’re stuck relying on a pre-built signature database. We’ve moved past that. Using AI/ML logic, Zscaler identifies new IoT and OT devices in real-time—even those we’ve never seen before. By analyzing behavioral patterns through DNS names and weblog data, we classify assets based on where they are going and how they behave.&nbsp;Industrial/OT Context: This is where we speak the language of your IoT/OT assets.&nbsp; ZTB decodes the specific protocols used in your environment to understand exactly what a device is. This context allows us to provide vertical-specific intelligence:Industrial &amp; Heavy Equipment: By inspecting OPC UA, Modbus, and ENIP communications, we can fingerprint specific PLCs or SCADA servers.&nbsp;Life Sciences &amp; Medical Manufacturing: We look into DICOM and HL7 traffic to identify sensitive medical imaging systems like MRI, X-ray.Building Automation: We parse BACnet broadcasts to profile HVAC, lighting, and access control systems.Partnership Ecosystem:&nbsp;We know some of you have already invested in specialist visibility tools. We further enrich this discovery by ingesting data from partners like Armis, Ordr, or CrowdStrike. While Zero Trust Branch sees the Rockwell HMI on the wire, a partner like Armis can add deep-layer context such as the OS (Windows CE), and a Risk Level (80). This enriched data becomes the foundation for building precise, automated security policies without doubling your workload.Intelligence via System-Generated Tags All of this data is distilled into System-Generated Tags, which create the base for your microsegmentation policy. This is where you move away from old-school networking constructs like IPs and subnets and start using security context. We tag assets with its Manufacturer, model, and Device Category.By using these tags, your policy becomes human-readable and automated. Instead of writing a complex rule for a specific IP address, you write a policy for "All Rockwell PLCs at Purdue Level 1."In the next blog, we will dive into how Zscaler turns this asset visibility into actionable intelligence starting with Visualization, Threat Mapping, and finally, how to define dynamic groups for creating policies.&nbsp;]]></description>
            <dc:creator>Amit Aneja (Director, Product Management, SD-WAN)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Project Glasswing and the Coming Inversion of Vulnerability Management]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/project-glasswing-and-coming-inversion-vulnerability-management</link>
            <guid>https://www.zscaler.com/blogs/product-insights/project-glasswing-and-coming-inversion-vulnerability-management</guid>
            <pubDate>Thu, 13 Aug 2026 16:14:37 GMT</pubDate>
            <description><![CDATA[At Black Hat, I had the opportunity to join Jim Reavis (CEO, Cloud Security Alliance), Shailesh Athalye (Chief Product Solutions Architect, Qualys), and Bryan Willett (Field CISO, Rubrik) for the Cloud Security Alliance’s Weathering the Storm: Cybersecurity in the AI Era event. Our panel, “Project Glasswing: From Frontier Discovery to Enterprise Resilience,” explored what Project Glasswing and rapidly improving AI capabilities mean for enterprise cybersecurity. Glasswing gave us a useful starting point because it put numbers behind something many security leaders have sensed for a while: the economics of vulnerability discovery are changing fast and the operating to handle those needs to evolve rapidly as well.That distinction matters. For most of the history of vulnerability management, discovering previously unknown weaknesses was expensive work. Researchers had to understand unfamiliar codebases, trace complex execution paths, identify unusual state transitions, build proof-of-concepts, and distinguish genuine vulnerabilities from interesting but nonexploitable behavior. Enterprises therefore built security programs around a reasonable assumption: vulnerability discovery would remain relatively scarce, while the organization's job was to collect those findings, rank them, and methodically work through the remediation queue.Project Glasswing challenges that assumption rather dramatically. In its initial phase, approximately 50 participating organizations using a frontier AI model reportedly identified more than 10,000 high- or critical-severity vulnerabilities. The important lesson was not simply the volume. It was the realization that as AI accelerates discovery, the constraint moves downstream toward validation, disclosure, prioritization, remediation, and deployment.I think that will ultimately be remembered as Glasswing's most important contribution. It demonstrated that AI could find vulnerabilities. But more importantly, it exposed a systemic problem: what happens to security when discovery approaches machine speed, but risk reduction still moves at human speed? Five numbers that show why the model is changingThe statistics below measure different parts of the problem, so they should not be treated as directly comparable. Taken together, however, they illustrate the scale of the transition now underway.SignalWhat we have observedWhy it mattersProject Glasswing10,000+ high- or critical-severity vulnerabilities across roughly 50 initial participantsVulnerability discovery can scale far beyond traditional researcher-driven modelsAutonomous intrusionApproximately 17,600 attacker actions reconstructed during an AI-driven intrusionAutonomous systems can generate enormous volumes of adaptive attack activityEnterprise AI activity36x growth in AI/ML transactions observed by ThreatLabzAI is rapidly becoming part of the normal enterprise technology surfaceContextual vulnerability prioritizationAs many as 80% of initially critical findings can be reprioritized with additional contextTechnical severity alone becomes less useful as finding volume increasesTriage capacityUp to 10x improvement with contextualized vulnerability managementThe defensive advantage increasingly comes from better prioritization, not more findingsThere is a common thread running through all five numbers. Both attackers and defenders are acquiring the ability to perform security reasoning repeatedly and at machine scale, but most enterprise security processes were built for a world in which humans remained somewhere inside almost every important decision loop.That assumption is beginning to break. We are about to produce security findings faster than organizations can consume themThere is a useful way to think about vulnerability management as a pipeline. A potential weakness is discovered, validated, assigned some measure of technical severity, mapped to affected assets, prioritized in the context of the enterprise, assigned to an owner, remediated, deployed, and finally verified. Each stage has its own throughput, and the effectiveness of the overall system is constrained by the slowest stages rather than the fastest one.Historically, discovery consumed a meaningful portion of that pipeline's scarce capacity. AI changes that. Once highly capable models can repeatedly inspect large codebases, reason across functions, formulate hypotheses, construct tests, interpret results, alter their approach, and continue searching without human fatigue, the marginal cost of producing another candidate vulnerability falls dramatically.But increasing discovery throughput does not automatically increase remediation throughput. The security team still needs to establish whether the finding is real, whether the affected software exists in the environment, whether the vulnerable code is reachable, what privileges surround it, what controls already mitigate it, and what happens to the business if it is exploited. The application team may still need to test a patch, while the enterprise may still have a maintenance window several weeks away.This creates an uncomfortable possibility. AI can make a vulnerability program dramatically better at finding problems without making the organization proportionally better at reducing risk. A 10x improvement in discovery coupled with no improvement in validation, prioritization, and remediation is not a 10x improvement in security. It may simply be a 10x improvement in our ability to manufacture unresolved work. A vulnerability only matters in the context of what it can reachThis is where I think the vulnerability-management conversation needs to evolve. We have traditionally treated the vulnerability as the primary unit of analysis, but attackers do not experience an enterprise as a list of CVEs. They experience it as a collection of paths.A vulnerability exists on a workload. That workload runs with an identity. The identity has permissions. Those permissions provide access to applications, services, APIs, and data. Each successful step changes what the attacker can do next.Consider two workloads running exactly the same vulnerable software. One has no meaningful access to sensitive information, tightly constrained privileges, limited connectivity, and strong compensating controls. The other runs with an identity capable of querying a production database containing customer information. The CVE is identical, but the business risk clearly is not.The difference is the path behind the vulnerability. One useful way to model that path is Vulnerability → Workload → Identity → Data → Business Impact. For AI systems, an increasingly important variation is AI Agent → Identity → Tool/Application → Data.This is why data context belongs inside exposure management rather than beside it. If I know a system is vulnerable but cannot determine what sensitive information that system, its identities, or its applications can ultimately reach, I am missing one of the most important variables in the risk calculation.Zscaler Data Security Posture Management (DSPM) takes this data-centric approach by continuously discovering and classifying sensitive information across hybrid and multicloud environments, understanding access and entitlements, identifying public exposure and misconfigurations, and correlating these conditions to surface higher-risk combinations. The objective is not simply to identify where sensitive data exists, but to understand the conditions under which that data can become exposed.That becomes especially important when vulnerability discovery is cheap. If AI gives me 100,000 findings, the valuable question is no longer which ones have the highest technical severity. It is which ones create a credible path to something the organization cannot afford to lose. The metric that matters is time-to-risk-reductionSecurity teams have traditionally measured vulnerability operations using vulnerability counts, mean vulnerability age, SLA compliance, and mean time to remediation. Those measurements remain useful, but the AI era requires a more consequential metric: time-to-risk-reduction, or TTRR.TTRR asks how much time passes between identifying meaningful exposure and materially reducing either the probability or potential impact of exploitation. Importantly, patch deployment is only one possible endpoint. If I can immediately remove external reachability, revoke an unnecessary privilege, isolate a workload, restrict application access, or prevent a compromised identity from reaching sensitive data, I may have reduced substantial risk before the software owner produces a permanent fix.Operationally, that means examining six delays:Discover: How long can a meaningful exposure exist before we know about it?Validate: How quickly can we distinguish a genuine weakness from noise?Contextualize: What asset, identity, application, and sensitive data sit behind the exposure?Prioritize: Which exposure creates the most credible path to material business impact?Enforce: What control can break that path fastest?Verify: Did we actually reduce exposure, or did we simply close a ticket?The last two steps matter more than they might appear. An attacker does not care about the administrative status of a remediation workflow. The attacker cares whether the path still works. Then the other side of the equation acceleratedOur CSA discussion became even more interesting when we moved from AI-assisted vulnerability discovery to AI-assisted attack. There is a tempting interpretation of autonomous cyberattacks that says nothing fundamental has changed because the underlying techniques remain familiar.There is some truth to that. Recent AI-driven intrusion research has involved techniques security practitioners know well: exploitation, privilege escalation, credential harvesting, reconnaissance, and lateral movement. What changes is not necessarily the individual technique. It is the control system sequencing the techniques together.An autonomous agent can observe an environment, formulate a hypothesis, choose an action, evaluate the result, update its understanding, and choose the next action. It can perform this loop repeatedly without requiring a human operator to make each intermediate decision. Conceptually, the attacker starts operating a continuous loop: Observe → Reason → Act → Evaluate → Adapt → Repeat.The important variable is therefore not simply how many commands the attacker can execute per second. It is how quickly the attacker can reduce uncertainty about the environment. Autonomous attack is fundamentally a search problemImagine the enterprise as a graph. The nodes are users, workloads, identities, applications, APIs, AI agents, credentials, and data stores. The edges represent what each entity can reach, invoke, authenticate to, modify, or retrieve.A human attacker entering that graph faces a search problem. Which credential should I test? Which system can this identity reach? Which privilege enables escalation? Where is valuable information stored? Which sequence of actions connects my current position to that data?Skilled attackers are good at solving this problem, but human cognition, time, and attention naturally limit the number of paths they can investigate. Autonomous systems alter those economics. They can enumerate alternatives, test branches, discard dead ends, combine newly acquired information with earlier observations, and continuously optimize for progress toward an objective.This is what I mean by attack-loop compression. The time between observation, decision, action, and feedback declines, while the number of hypotheses the adversary can evaluate increases.Once that happens, the defender has two options. We can try to make every defensive decision as quickly as the attacker makes offensive decisions, or we can make the attacker's search problem dramatically harder. The strongest architecture does both. Zero Trust shrinks the graph. Data security tells us which paths matter.This is where Zero Trust and data security come together in a particularly useful way. If a compromised identity can reach 500 systems, an autonomous attacker has hundreds of possible branches to explore. If Zero Trust policy reduces effective reachability to the three applications required for that identity's legitimate task, most of those branches disappear before the attacker ever gets to test them.That is the first defensive advantage: shrink the attacker's search space.But not every remaining branch has the same consequence. One application may contain public information, while another may provide access to intellectual property, regulated customer records, credentials, proprietary models, or training data. Understanding that difference requires visibility into the data itself, who and what can access it, and the posture of the systems surrounding it.That is the second defensive advantage: identify which remaining paths lead to something valuable.Zscaler's data security capabilities provide that additional context by discovering and classifying sensitive data, identifying who and what has access to it, detecting overly permissive access and misconfigurations, and correlating those conditions to uncover hidden attack paths. DSPM can also support remediation toward least-privileged access, directly reducing the number of useful paths available to compromised users and non-human identities.This gives us a relatively simple model for AI-era exposure management. Zero Trust reduces the attack surface that an adversary can traverse, while data security identifies the paths whose traversal would create meaningful business impact.That is much more useful than simply producing another list of critical findings. Patching faster is necessary, but breaking the path is the objectiveIf AI finds vulnerabilities faster than organizations can patch them, the industry cannot solve the problem exclusively by demanding that every enterprise patch everything immediately. That is operationally unrealistic.Enterprises operate systems requiring extensive testing before upgrades. They rely on third-party software, legacy platforms, embedded dependencies, operational technology, and business processes that cannot simply be restarted whenever a new critical finding appears. Even in exceptionally well-run environments, there will always be some interval between vulnerability discovery and permanent remediation.The more useful question is what can happen during that interval. If I cannot immediately eliminate the vulnerability, can I remove external exposure? Can I restrict which identities can communicate with the workload? Can I reduce its privileges? Can I isolate it from critical applications? Can I remove unnecessary access to sensitive data?That is the difference between managing vulnerabilities and managing exposure. The patch eliminates the defect. The security architecture prevents the defect from becoming a path to material impact.This is also where data security posture becomes operational rather than observational. Discovering sensitive data is only the beginning. The more consequential questions are which identities and applications can access it, whether those permissions are necessary, what security conditions surround that access, and which combinations of vulnerability, privilege, connectivity, and data create an exploitable path.If a critical vulnerability exists on a workload with access to highly sensitive data, reducing that access may be one of the fastest ways to reduce immediate risk while permanent remediation proceeds. The next vulnerability-management system looks more like a control loopIf we extend the lessons from Glasswing to their logical conclusion, the future vulnerability-management architecture begins to look very different from today's scanner-to-ticket workflow. Discovery becomes only one sensor inside a continuously operating risk-reduction system.An AI system may discover a potential weakness and generate evidence supporting the finding. The enterprise can validate whether the behavior is reproducible and establish whether the affected software actually exists. Asset and identity context can determine reachability and privilege. Data security context can establish what sensitive information sits behind that path and who or what can access it.At that point, prioritization becomes much more meaningful because we are no longer asking whether the vulnerability is severe in isolation. We are asking whether the vulnerability completes a credible path to business impact.The system can then identify the intervention most likely to reduce risk. Sometimes that will be a patch. In other cases, it may be an access-policy change, removal of a data entitlement, credential rotation, workload isolation, configuration adjustment, or another compensating control.Most importantly, the process cannot stop when someone marks a ticket resolved. The system needs to verify that the path has actually been broken and feed that observation back into its understanding of enterprise risk.The resulting loop is relatively simple: Discover → Validate → Understand the Path → Prioritize → Break the Path → Verify.I like this model because it avoids turning AI-era security into a collection of new product categories. Vulnerability management, Zero Trust, identity, data security, and AI security are different control domains, but from the attacker's perspective they are parts of the same graph. The attacker is trying to find a path through that graph, and our job is to continuously remove the paths that matter. What I would change next weekDuring this panel, we were asked what one change CISOs should make based on what we have learned from Glasswing. My answer is that security leaders should stop treating vulnerability management primarily as a process for finding and closing vulnerabilities and begin managing it as a race to break the attack paths that can produce material business impact.Start with your most sensitive data. Understand where it exists, which applications use it, which human and non-human identities can access it, and which workloads and AI systems sit on paths toward it. Then overlay vulnerabilities, exposures, permissions, and connectivity. That exercise will almost certainly produce a very different priority list from one based on CVSS scores alone.Next, measure how quickly your organization can break those paths. If a patch requires three weeks, can access be restricted in three minutes? If an identity is overprivileged, can the unnecessary entitlement be removed? If an application should never communicate with a sensitive workload, can that relationship be eliminated altogether?Finally, examine the human queues. If an autonomous attacker can execute thousands of decisions while your organization waits for an analyst to correlate context, an application team to establish ownership, or a change process to approve containment, those delays are no longer merely operational inefficiencies. They become part of your effective exposure.Project Glasswing gives us an important preview of what happens next. As vulnerability discovery approaches machine scale, finding the weakness becomes less scarce. Validation, context, prioritization, remediation capacity, and time become more scarce.At the same moment, autonomous attackers are getting better at searching enterprise environments for the combinations of vulnerabilities, identities, permissions, applications, and data that produce useful attack paths. That is why I believe the defining security problem of the AI era will not be finding every vulnerability before the attacker does. That is an increasingly unrealistic race.The more defensible objective is to build an environment in which finding a vulnerability does not automatically give the attacker somewhere valuable to go. Zero Trust limits where the attacker can move, data security tells us what we cannot afford to lose, and AI can help defenders continuously reason across both. Together, those capabilities give us something much more useful than another vulnerability score: the ability to understand which paths matter and break them before an adversary can turn exposure into impact.That, to me, is the enduring lesson of Project Glasswing. When finding the vulnerability is no longer the hard part, breaking the path becomes the security problem that matters most.Explore with us how Zscaler can bring Zero Trust, vulnerability management, DSPM, and AI Security together to reduce exposure around sensitive data.&nbsp;]]></description>
            <dc:creator>Anand Singh (Head of Security &amp;amp; Strategy - Data + AI)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Introducing Zscaler Zero Trust Gateway for Google Cloud]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/introducing-zscaler-zero-trust-gateway-google-cloud</link>
            <guid>https://www.zscaler.com/blogs/product-insights/introducing-zscaler-zero-trust-gateway-google-cloud</guid>
            <pubDate>Thu, 13 Aug 2026 03:15:51 GMT</pubDate>
            <description><![CDATA[Google Cloud offers a powerful and flexible foundation for cloud security. To build on this robust security foundation, organizations can further strengthen security by integrating Zscaler’s advanced security solutions with Google Cloud’s&nbsp;Network Security Integration(NSI). By combining the strengths of Google Cloud with the Zscaler Zero Trust Gateway, organizations can achieve both enhanced protection and exceptional operational simplicity for their cloud environment.&nbsp;“At Google Cloud, we're committed to giving enterprises the most secure and scalable cloud infrastructure in the world. Our Network Security Integration with Zscaler is a natural extension of that commitment — it allows customers to apply Zero Trust enforcement within Google Cloud traffic flows, without disrupting application architecture. Together, we're making it easier for organizations to adopt cloud-native security controls at scale,” said Anoop Vetteth, Director, Product Management, Networking Security, Google Cloud. &nbsp;Challenge: The "Security vs. Complexity" ParadoxAs cloud footprints grow, so does the "plumbing" required to secure them. Traditional approaches to securing cloud egress and internal traffic often involve:Manually provisioning and patching security VMs.Complex routing changes and VPN configurations.Fragmented visibility across different cloud projects and regions.Unpredictable costs associated with scaling and data egress.VM sprawl due to redundancy best practicesFragmented security policy across service providersFor DevOps and Security teams, this "security tax" slows down innovation and creates operational blind spots. &nbsp;Solution: Zero Trust Gateway for Google CloudThe Zscaler Zero Trust Gateway (ZTGW) redefines cloud security by integrating seamlessly with Google Cloud’s native security fabric. Instead of managing security appliances, you simply define your policies for your cloud environment, and Zscaler handles the rest.&nbsp;&nbsp;Zscaler Zero Trust Cloud provides consistent threat and data protection for workloads, reducing attack surfaces and lateral movement while simplifying operations. Using the Zscaler-managed Zero Trust Gateway, you can deploy in under 10 minutes to consume security as a fully managed, cloud-native service.&nbsp;&nbsp;Use Cases:Secure AI Development: Protect tools like Devin or Cursor without hindering innovation.Consolidate Infrastructure: Eliminate virtual firewall sprawl to reduce cost and complexity.Identity-Based Microsegmentation: Isolate critical applications to contain breaches instantly.Cloud Migration: De-risk "lift and shift" projects, such as SAP migrations, by decoupling security from the network.Multi-Cloud Governance: Eliminate security silos across AWS, Azure, and Google Cloud with a single, unified policy framework.&nbsp;Key capabilities of Zero Trust Cloud on Google Cloud :Google Cloud deep integration: Zero Trust cloud works with Google Cloud’s Network Security Integration. By using Security Profiles and Profile Groups, traffic is transparently steered to Zscaler for deep inspection. No application changes, no manual tunnels, and no complex route table overhauls are required.Fully Managed, Auto-scaling Infrastructure: Zscaler provisions, operates, and scales the entire gateway infrastructure. From OS updates and security patches to dynamic capacity adjustments based on your traffic volume, the lifecycle management is completely automated.Context-Aware Security via Google Cloud Tags: Security is only as good as its context. ZTGW uses Google Cloud resource labels and network tags as policy metadata. This allows you to enforce stricter Data Loss Prevention (DLP) for "Production" workloads while maintaining flexibility for "Development" environments—all tied directly to your Google Cloud hierarchy.A Comprehensive Security Stack in the Cloud: Benefit from the full suite of Zscaler’s protection, including:High-performance SSL/TLS Inspection at scale.Advanced Threat Protection against malware and ransomware.Inline Data Loss Prevention (DLP) to prevent sensitive data leaks.Cloud Sandboxing for real-time defense against zero-day threats. &nbsp;Why Customers are Choosing ZTGW for Google CloudThe shift to a managed Zero Trust Gateway offers tangible benefits for both the bottom line and your security posture:BenefitDescriptionZero Operational OverheadEliminate the need to manage security VMs. Focus on policy, not plumbing.One security platform to protect workloads deployed across different availability zones, regions, cloudsAdvanced Threat ProtectionInline SSL inspectionInline Data protectionUncompromised VisibilityGain a "single pane of glass" view across GCP, other clouds, and on-premises environments via the Zscaler Admin Portal.Predictable Cost EfficiencyThe cost and complexity of managing security infrastructure, data transfers and NAT gateways are significant challenges in the cloud.&nbsp;Zscaler's ZTGW service simplifies this by delivering the solution as a service. This optimized security architecture delivers efficiencies at scale that can save customers up to $2.1M (on 2PB of monthly traffic) compared to traditional solutions.Seamless DeploymentWhether you use a Single VPC, Multiple VPCs, or a Shared VPC architecture, ZTGW fits into your existing GCP topology. &nbsp;Moving Toward a Zero Trust FutureThe Zscaler Zero Trust Gateway on Google Cloud represents the most streamlined path to strengthen enterprise-grade cloud security. By moving away from legacy network-level controls and embracing a full Zero Trust architecture, your organization can eliminate blind spots, prevent lateral threat movement, and accelerate your cloud journey with confidence.&nbsp;Ready to use Zero Trust Gateway for Google Cloud?&nbsp;Click here to learn more about Zero Trust Cloud]]></description>
            <dc:creator>Sakthi Chandrasekaran (Sr. Director, Product Marketing)</dc:creator>
        </item>
        <item>
            <title><![CDATA[When &quot;Prepare to Disconnect&quot; Becomes Official Guidance: What CI Fortify Means for OT Security]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/when-prepare-disconnect-becomes-official-guidance-what-ci-fortify-means-ot</link>
            <guid>https://www.zscaler.com/blogs/product-insights/when-prepare-disconnect-becomes-official-guidance-what-ci-fortify-means-ot</guid>
            <pubDate>Tue, 11 Aug 2026 16:26:53 GMT</pubDate>
            <description><![CDATA[Quick answer: CI Fortify is joint guidance published July 28, 2026 by CISA, the Australian Signals Directorate's ACSC, the FBI, the UK's NCSC, and the Canadian Centre for Cyber Security. It requires critical infrastructure operators to be able to isolate vital OT systems from all other networks during a cyber incident - and keep delivering essential services while disconnected. For most OT environments, the gap is not the plan but the engineering: flat networks have no pre-built isolation points to execute. On July 28, 2026, CISA - together with the Australian Signals Directorate's ACSC, the FBI, the UK's NCSC, and the Canadian Centre for Cyber Security - published joint guidance titled&nbsp;CI Fortify: Advice for Isolating Vital Systems. The message is blunt: critical infrastructure operators must be able to disconnect vital operational technology from corporate networks, the internet, and third parties during a cyberattack or geopolitical crisis, and keep delivering essential services while disconnected.This is not abstract preparedness language. The agencies name the backdrop explicitly: state-sponsored actors pre-positioning inside critical infrastructure - Volt Typhoon&nbsp;sat undetected in victim networks for at least five years - and&nbsp;ransomware crews who have learned that manufacturers, hospitals, and utilities pay faster when production is down.The question the guidance forces every OT operator to answer is uncomfortable: if you had to isolate your plant network in the next ten minutes, could you? Would you know where to cut, who authorizes it, and what breaks when you do? For most organizations, the honest answer is no. That gap - between an isolation plan on paper and an isolation capability that has been engineered and tested - is exactly what CI Fortify is trying to close. What does CI Fortify actually require?Strip away the framework language and the guidance lays out a six-step path:Identify vital systems - the minimum OT and enabling systems required to keep delivering the critical serviceIdentify critical customers and upstream dependenciesSet criticality and trust levels across networks and hostsMap every connection to vital systems: corporate IT, vendor remote access, cloud platforms, internet-facing services, other operatorsBuild separation and isolation points in advance, with authorization and trigger criteria defined before the incidentCreate and test a graduated isolation plan - full-system exercises, not partial tests, because partial tests miss the shared dependencies (identity services, DNS, historians, licensing) that fail the moment you cut the boundaryThe guidance holds up physical isolation as the most effective protection - but concedes in the same breath that full physical disconnection is impractical for organizations that depend on carrier networks, cloud services, or geographically distributed facilities. That describes most modern manufacturing. For those environments, the agencies recommend hardening OT boundaries, removing unnecessary corporate dependencies, and maintaining the ability to progressively restrict access as threat conditions escalate.That escalation model has a name in the guidance:&nbsp;graduated isolation. First cut remote workers and vendors. Then corporate connectivity. Then connected systems, and eventually all external links - with trigger criteria for each step defined in advance, and complete isolation of the most vital systems as the target state. Why does graduated isolation fail on a flat network?Graduated isolation presupposes that the graduations exist. On a typical brownfield OT network, they don't. On paper, most plants still describe themselves in&nbsp;Purdue model terms - neatly layered levels with controlled conduits between them. In practice, decades of IT/OT convergence have produced flat environments where the HMI, the historian, the engineering workstation, the vendor jump box, and hundreds of unmanaged devices share broadcast domains. The "isolation points" the guidance calls for would have to be improvised during the incident - emergency firewall rules, VLAN surgery, cable pulls - executed from tribal knowledge at 2 a.m. while the attacker is already moving.The guidance itself rates administrative controls like VLANs and access lists as "minimally effective" - interim measures on the road to real isolation, not something to rely on long-term. And the reasons are the ones every operator already knows: they are static, error-prone at scale, and were never designed to contain a threat that is actively pivoting. An isolation plan that depends on hand-editing access lists during an active intrusion is a plan for discovering your hidden dependencies the hard way.The engineering problem: how do you give an OT environment real, pre-built, instantly executable isolation points - without ripping out the network, without agents on devices that can't take them, and without a segmentation project that stalls at the first change-control meeting? How does a ransomware kill switch make graduated isolation executable?This is where&nbsp;zero trust device segmentation changes the equation. Zscaler places enforcement at the local gateway: every device on the OT network is isolated into its own segment of one, and every east-west flow is evaluated against identity- and context-based policy - agentless, with no re-architecture of the plant network and no static ACL sprawl.On top of that enforcement fabric sits the&nbsp;Ransomware Kill Switch, and it maps almost one-to-one onto CI Fortify's graduated isolation model. Rather than improvising containment mid-incident, operators pre-stage policy sets at escalating severity levels: at elevated posture, lock down known-abused lateral-movement protocols across the site; escalate further and cut vendor and third-party remote access; at the most severe posture, disable communication to entire network segments - a production line, a plant floor - in a single action, while permitted critical flows continue.Read against the guidance's own vocabulary:Isolation points stop being physical locations someone must find and become documented policy constructs, executable in secondsGraduated isolation stops being a sequence of emergency change requests and becomes a severity dial with pre-defined, pre-tested consequences at each levelAuthorization and triggers become access controls and automation logic rather than a phone tree - the kill switch is API-addressable, so SIEM, SOAR, and EDR tooling can trigger containment the moment detection confidence crosses a thresholdTesting stops being an annual disruption and becomes routine: because isolation is policy, you can exercise it, observe what breaks, fix the dependency, and re-run - the iterative loop the guidance says partial testing never achievesOne boundary worth stating plainly: CI Fortify asks for two capabilities - isolating vital systems quickly, and operating in that isolated state for an extended period. A kill switch is a decisive answer to the first, compressing containment from hours of improvisation into seconds of execution - and those first hours usually decide whether an incident is an outage or a catastrophe. Sustained fully disconnected operation is an architecture and operations planning question that no single control resolves. Whether it is achievable is something every operator has to verify against their own environment - the identity services, historians, and licensing dependencies that only surface when you actually exercise the boundary - not against a reference architecture. Where should OT operators start?The sequence CI Fortify prescribes is the right one, and&nbsp;modern device segmentation accelerates each step: automatic discovery and classification to identify vital systems and expose the connection map you didn't know you had; identity-based policy to define isolation points without re-architecting the network; severity-based kill switch policies to make graduated isolation executable; and routine, low-risk testing to find dependencies before an adversary does.The agencies have told operators, in plain language, to be ready to disconnect. The organizations that fare best won't be the ones with the thickest isolation binder. They'll be the ones for whom isolation is a button that has already been tested.Ready to see what pre-engineered isolation looks like in your environment?&nbsp;Request an OT architecture workshop to map your vital systems, connections, and isolation points against the CI Fortify model.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Hidden Threat in Your Software Development Lifecycle: Why Self-Hosted Runners Need Zero Trust]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/hidden-threat-your-software-development-lifecycle-why-self-hosted-runners</link>
            <guid>https://www.zscaler.com/blogs/product-insights/hidden-threat-your-software-development-lifecycle-why-self-hosted-runners</guid>
            <pubDate>Tue, 11 Aug 2026 07:36:20 GMT</pubDate>
            <description><![CDATA[The modern software delivery pipeline is a marvel of speed and automation, but it is also one of the most attractive and vulnerable attack surfaces in the enterprise.&nbsp;Highlighting this risk, Sonatype’s State of the Software Supply Chain 2026 report tracked more than 454,600 new malicious packages introduced into open-source registries in a single year—representing a staggering 75% year-over-year surge.&nbsp;To gain speed, customize build environments, and access resources locked inside private environments, enterprises prefer self-hosted GitHub Runners over GitHub hosted Runners. By running these build nodes inside their own cloud or on-premise data centers, organizations believe they are reclaiming control. After all, the code stays within their security perimeter, and expensive build minutes are offloaded to domestic, highly optimized infrastructure.But this shift introduces a dangerous paradox. While self-hosting keeps code-level assets localized, it creates a massive, often invisible outbound security risk. The minute a self-hosted runner spins up, it is placed in a highly privileged network position. If a runner is compromised—whether via a compromised third-party package (dependency confusion), a malicious pull request, or an exploited software vulnerability in a build tool—the entire internal network is exposed.&nbsp;For security teams, the hard truth is clear: self-hosted GitHub Runners have quietly become the largest blindspot.&nbsp; Why Traditional Firewalls Fail to Secure Self-Hosted GitHub Runners &amp; SDLCLet us try to understand why it becomes so difficult to secure self-hosted runners and SDLC with traditional network security. During a standard code build execution, a runner needs to perform a dizzying array of outbound network operations. It must reach out to:GitHub Cloud to poll for jobs and report status.Public package registries (npm, PyPI, Maven, NuGet) to pull down dependencies.SaaS communication platforms like Slack to post build updates.Internal private repositories like JFrog Artifactory &amp; Confluence.ITSM tools like ServiceNow to initiate change requestsFaced with this highly dynamic behavior, traditional network security tools that rely on firewalls fall apart to secure the GitHub Runners exposing the software development life cycle workloads to attacks. Here are the top reasons:1. Firewalls Stall Developer VelocityDevelopers rely on security teams to modify firewall rules so that self-hosted runners can connect to the internet and internal private networks. However, because security teams operate under strict compliance frameworks, every firewall change requires risk assessments, approvals, and change management tickets that take days or weeks, choking developer velocity and slowing time-to-market.2. The Lateral Movement HighwayIf an attacker compromises a runner (for example, by submitting a malicious pull request that executes arbitrary shell commands inside the workflow), they inherit the runner's network permissions. Because the runner sits inside your private VPC and has wide-open egress, the attacker can scan the local subnet, move laterally to adjacent database segments, or query local metadata services to harvest highly privileged IAM role credentials.3. Exploitation of Implicit TrustWith unrestricted outbound HTTPS access, an attacker who has compromised a runner can easily exfiltrate source code, proprietary build artifacts, or harvested secrets to an external command-and-control (C2) server. Because the traffic is encrypted and destined for port `443`, traditional perimeter-based security doesn’t flag it.4. Exposure of secretsCI/CD pipelines run on secrets—API keys, database passwords, and cloud access tokens. If a runner is over-privileged at the network layer, any script running within the pipeline can access these secrets and send them out to an arbitrary endpoint on the internet, completely bypassing data loss prevention mechanisms.&nbsp; The Solution: Zero Trust for Self-Hosted GitHub RunnersTo overcome these critical security flaws without sacrificing developer velocity, organizations must shift away from legacy, network-centric perimeters and adopt a zero trust architecture. Zscaler Zero Trust Cloud (ZTC) is a cloud-native platform built specifically on zero trust principles to revolutionize security across the software development life cycle (SDLC).&nbsp;Here is how Zscaler Zero Trust Cloud addresses the core limitations of traditional firewalls to secure self-hosted runners:1. ZTC hides self-hosted GitHub Runners from the network, effectively shielding them from public discovery and preventing targeted exploits.&nbsp;2. Instead of placing the GitHub Runner on a shared private network where a compromise could expose adjacent systems, ZTC establishes secure, 1-to-1 connections. These connections are verified based on workload identity and context-aware policy rather than permissive network segments.&nbsp;3. ZTC eliminates implicit trust by providing cloud-scale TLS inspection for all outbound GitHub Runner traffic. Any encrypted outbound commands destined for an attacker’s command-and-control (C2) server are blocked in real time by URL filtering.4. ZTC delivers robust inline data protection by inspecting all outbound traffic directed from the runner to public SaaS apps like Jira, ServiceNow, or Slack. It blocks unauthorized data exfiltration, ensuring that highly privileged build secrets never leave the pipeline unauthorized.&nbsp; Deep Dive: Securing the GitHub Runner’s EcosystemSecuring a self-hosted runner requires a dual-pronged approach: safeguarding its communication with the public internet (SaaS and public registries) and controlling its access to internal, highly sensitive private resources. ZTC excels at both.1. Public SaaS &amp; Registry Access: Blocking ExfiltrationZTC continuously monitors all outbound traffic whenever GitHub Runners interact with public applications like ServiceNow or Slack. The traffic is routed from a service endpoint to Zero Trust Exchange via Zero Trust Gateway. ZTC provides cloud-scale TLS inspection and inline data protection. It ensures that the GitHub workloads remain entirely hidden from the public internet.2. Private Resource Access: Isolating the Crown JewelsDuring the code review, testing and deployment phases, runners must inevitably connect to private internal resources, such as artifact repositories (like JFrog Artifactory or Confluence), or internal databases.&nbsp;Traditionally, this meant placing the runner in the same network segment as these sensitive assets, or configuring complex router ACLs and internal firewalls. If an attacker compromised the runner, they had an open pathway to probe your internal infrastructure.ZTC enforces least-privilege access allowing only 1-to-1 interactions based on workload identity and security policies. There are 2 scenarios:2.1. When the private apps are hosted in the same region:&nbsp;Under this scenario, the private application VPC is located within the same cloud region as the GitHub Runner VPC. Traffic originating from the GitHub Runner is directed to the Zero Trust Gateway via service endpoint / intercept, where local inspection is conducted before granting access to the private application.Figure: Secure connectivity to private apps when they are hosted in the same region2.2. When the private apps are hosted in different regions, availability zones (AZ), or cloud:In scenarios where the private application VPC and the GitHub Runner are distributed across distinct cloud providers, regions, or AZs, traffic travels from a service endpoint through the Zero Trust Gateway to the Zero Trust Exchange prior to private application access being authorized.Figure: Secure connectivity to private applications when it is hosted in a different region&nbsp; Key Benefits of implementing ZTCBy moving away from traditional network security, organizations unlock key advantages:1. Protect software development from discovery and attacksZTC shields your critical development environments from discovery, preventing targeted exploits and pre-empting costly cyberattacks before they can begin. The self-hosted GitHub Runners are concealed from the open internet at every communication point.2. Prevent and contain supply chain attacks by malicious codeAttackers upload malicious packages with identical names to internal ones but higher version numbers, tricking build runners into automatically installing the compromised versions. ZTC prevents GitHub runners from pulling such malicious packages. Should a GitHub runner become compromised, ZTC automatically intervenes to block any unauthorized attempts to connect to private applications.3. Protect secrets, tokens &amp; private keysZTC prevents unauthorized data extraction, ensuring that sensitive organizational information, API keys, and cloud credentials cannot be silently siphoned out, while simultaneously blocking unauthorized or unsanctioned external connections.4. Empower developer velocityZTC eliminates operational bottlenecks associated with firewall configuration updates. It provides faster, secure connectivity between GitHub Runners and public or private applications, removing friction from software development pipelines.&nbsp; Conclusion: Secure Your SDLC with ZTCSelf-hosted GitHub Runners are essential for modern engineering velocity, but leaving their network access wide open with traditional security architecture is a risk your enterprise cannot afford to take. Compromised pipelines are the ultimate backdoor into production environments.By transitioning to Zscaler Zero Trust Cloud, you can eliminate the operational headache of firewall maintenance, protect your private VPC from lateral movement, and ensure that every outbound connection from your CI/CD environment is verified, secure, and authenticated.&nbsp;To learn more, visit Zscaler Zero Trust Cloud.]]></description>
            <dc:creator>Salim Zia (Senior Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust Connectivity for Private AI Apps/Models: Who Can Actually Reach Them?]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zero-trust-connectivity-private-ai-apps-models-who-can-actually-reach-them</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zero-trust-connectivity-private-ai-apps-models-who-can-actually-reach-them</guid>
            <pubDate>Mon, 10 Aug 2026 16:33:26 GMT</pubDate>
            <description><![CDATA[The enterprise AI landscape is shifting fast. While public discourse has centered on ChatGPT, Copilot, Grok, Mythos, and the race to adopt SaaS AI tools, a quieter but equally significant trend is underway: organizations are deploying private AI models inside their own data centers. Whether it's a fine-tuned model trained on internal documents, a private inference server running at the edge, or an agentic AI pipeline connected to proprietary knowledge bases, enterprises are betting that keeping AI on-premises solves their biggest concerns about data sovereignty, regulatory compliance, and sensitive IP protection.They're right that self-hosting eliminates many of the third-party data risks inherent in cloud AI. But in solving one problem, many organizations are inadvertently creating another: they're securing the model itself, while leaving access to it dangerously wide open. VPN Was Not Built For ThisHere's a scenario that plays out more often than most security teams would like to admit. A team of data scientists or developers needs access to an internal AI inference endpoint. IT provisions VPN access to that network segment, the team connects, and work begins. Simple, fast, done.Except that VPN access doesn't grant access to one resource. It grants access to everything on that network segment. The AI inference server, adjacent application servers, internal APIs, file shares: all of it becomes reachable the moment a user authenticates to the VPN. The model may be locked down, but the blast radius of a compromised credential, a misconfigured client, or insider misuse is enormous.This is the fundamental flaw in the “VPN to on-prem AI” model: it conflates network access with application access. A VPN authenticates a device and drops it onto a segment of the corporate network. It knows nothing about whether that specific user should be interacting with a particular AI model or any of the internal resources connected to it. In an AI context, those questions are exactly the ones that matter.The risks compound quickly. Shadow AI infrastructure is a growing concern: developers spin up self-hosted models on unmanaged GPU workstations, teams deploy unauthorized MCP servers to connect AI agents to internal tools, and rogue AI applications proliferate without security review. These environments often run with no authentication at all, discoverable by anyone already on the network.&nbsp;Even properly managed AI servers can become data exfiltration tools: a malicious actor, or simply an overly curious insider, can use natural language to extract and summarize sensitive information from across a flat network segment that the VPN trusts implicitly. Traditional DLP tools aren’t built to catch that. The VPN logs tell you who connected. They tell you nothing about what the model was instructed to do. Access to AI Is an Identity ProblemSecuring on-premises AI infrastructure is not fundamentally a network problem. It's an identity problem. The core question isn’t “Is this device on the corporate network?” It's “Is this person, with this device posture, authorized to access this specific AI resource right now, and only this resource?”That shift in framing changes everything. If identity is the control plane, then access to every component of your AI environment should be governed at the application level, by policy tied to who the user is. A data scientist in the research team should be able to reach the models scoped to their work. A finance analyst should reach only the AI resources relevant to their role. Neither should see the other’s environment, and neither should be able to traverse to adjacent infrastructure they have no business touching.This is zero trust applied to AI: least-privilege access, identity-verified at every connection, with no implicit trust granted simply because a user is on the network. How Zscaler Approaches ThisZscaler Private Access (ZPA) is purpose-built for exactly this problem, and its architecture maps directly onto the requirements of securing on-premises AI infrastructure.ZPA operates on a “segment of one.” Rather than placing a user on a network and trusting them to behave, ZPA brokers a direct, encrypted connection between the authenticated user and the specific application they are authorized to reach, and nothing else. The internal AI environment is never exposed to the internet, and it is never reachable simply because someone has network access. Lateral movement becomes structurally impossible: a user connected to an AI inference endpoint cannot see, scan, or reach anything else on the segment.The mechanics matter here. A lightweight App Connector deployed next to your AI infrastructure makes only outbound connections to the Zscaler Zero Trust Exchange. There are no inbound open ports. The AI environment is invisible to the public internet and unreachable from the broader corporate network without explicit, identity-based authorization. A compromised credential doesn’t become a skeleton key.At the moment of access, ZPA validates both user identity (through your existing identity provider such as Okta or Azure AD), and device posture. Is this a managed device? Is the OS patched? Is the endpoint agent running?&nbsp;ZPA also brings visibility to AI apps that security teams may not even know exist. Using ZPA’s application-type classification capabilities, organizations can automatically identify AI applications running in their environment without requiring traffic decryption. Those apps can then be tagged as sanctioned or unsanctioned.&nbsp;Unsanctioned AI applications, including unauthorized MCP servers or shadow AI deployments, can be blocked immediately while app owners are engaged to bring them into compliance or decommission them. For sanctioned applications, only after identity and device posture checks pass does a connection get brokered, scoped only to what that user is permitted to reach.But secure connectivity and Zero Trust Access is not the full the picture. Once a user or an AI agent is connected, what are they actually sending to the model? Zscaler AI Guard extends protection into the session itself, inspecting prompts and responses in real time to block prompt injection attacks, prevent sensitive data from being submitted to the model, and stop confidential information from leaking in model outputs. Combine that with ZPA’s segmentation capabilities and Zscaler’s deception technology, which can lure and expose unauthorized access attempts with decoy resources, and the result is a layered security story that covers discovery, access control, content inspection, and threat detection in one platform.Together, this means a complete audit trail of who connected and when, what the AI model was asked, and what it returned. In a world where regulatory frameworks are beginning to demand documented access controls and usage logs for AI systems, that auditability is quickly becoming a compliance requirement. The Bottom LineRunning AI on-premises is the right choice for organizations that need to keep sensitive data, proprietary models, and confidential IP firmly within their own control, out of the hands of third-party AI providers. But the security gains from self-hosting are quickly negated if access to that AI infrastructure is governed by the same broad, implicit-trust network access model that zero trust was designed to replace.Identity-based, application-level access, enforced by architecture rather than policy documents, is how you close that gap. Zscaler makes this possible.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Private Access That Scales With Your App Catalog]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/private-access-scales-your-app-catalog</link>
            <guid>https://www.zscaler.com/blogs/product-insights/private-access-scales-your-app-catalog</guid>
            <pubDate>Thu, 06 Aug 2026 18:37:18 GMT</pubDate>
            <description><![CDATA[As your private app environment grows, the real challenge isn’t creating secure access. It’s keeping access fast and manageable while the number of internal apps keeps climbing. ZPA Application Scaling is a built-in capability that lets&nbsp;ZPA support very large private app catalogs by sending user devices running Zscaler Client Connector (ZCC) a smaller “parent domain” list, and letting the ZPA cloud confirm the exact app and policy decision only when it’s needed.In other words: ship the index, not the entire catalog. That’s the core idea and it’s what makes large-scale private access stay smooth as you grow. Why App Growth Creates Scaling PressureIn a large enterprise, application growth is normal:Business units add new internal appsTeams create new environments and hostnamesAcquisitions bring in whole new sets of domains“Temporary” systems stick aroundSecurity teams don’t want growth to create a new kind of work: bigger configs, heavier client updates, and more time spent managing app definitions.The capability goal here is to keep the experience consistent even as the number of private apps grows. What ZPA Application Scaling ChangesZPA Application Scaling changes what ZPA sends to ZCC so you can publish and control access to far more private apps without making the client heavier. Instead of sending ZCC a full list of all private app definitions, ZPA sends a smaller list of parent domains (TLD+1 domains like acme.com).A clean mental model I like to use to think about this is: Don’t hand every device the full corporate directory. Give it the index and look up details when someone actually asks. How it WorksZPA sends ZCC a short list of parent domains. Example: ZCC receives acme.com, not 1.acme.com through 10.acme.com.When a user goes to something under that domain, ZCC asks ZPA: “Is this a private app we publish, and what should happen?”ZPA evaluates policy and DNS and returns a decision (allow, block, or bypass).ZCC caches the result so repeat access is fast. If the destination isn’t a private app, ZCC routes it based on your forwarding setup (through ZIA or directly to the internet). What Customers Get: Bigger Scale, Lighter Clients, Easier Operations1) It supports much larger app catalogsWith Application Scaling, customers can expand from roughly 6,000 applications to approximately 100,000 applications per tenant. That matters because it turns “app growth” into a normal operational event and not a scaling project.2) It keeps the client lighter as you growBecause ZCC receives less configuration data, you typically improve:Startup timePolicy download sizeDevice resource usage3) It supports modern ways to organize access at scaleApplication Scaling is also the foundation for advanced segmentation features like:Pattern MatchMultimatchMetadata TaggingAnd the overview is explicit that future ZPA enhancements will depend on Application Scaling being enabled, so enabling it is also a way to stay aligned with the platform’s direction. More than Scale: A Foundation for What’s NextWith Application Scaling enabled, ZPA supports up to 100,000 application segments per tenant. But this is not just about supporting larger environments. Application Scaling is also a foundational prerequisite for several current and upcoming capabilities, including Policy Modernization, B2B Federation, and Increased Access Policy Limits. Going forward, Application Scaling is expected to be a standard prerequisite for most new ZPA features that depend on enhanced scalability and a modernized policy architecture, so enabling it helps you take advantage of capabilities available today and stay ready for what’s coming next. What this Looks Like for Customers TodayZPA Application Scaling is how ZPA stays simple and fast when your private app environment stops being “a few important apps” and becomes “the full internal universe.” It does that with one clean shift: ZCC carries a small index of parent domains, ZPA confirms the exact destination and policy decision when needed, and ZCC caches the result.&nbsp;For customers today, ZPA Application Scaling is mostly invisible, in a good way. Users keep connecting to the same private apps, but the system is built to stay fast and manageable as the private app catalog grows. The practical difference shows up behind the scenes: ZCC carries a smaller “index” of domains, ZPA confirms the exact destination and policy in the cloud when needed, and ZCC caches the result. The outcome is that customers can expand from thousands of apps toward ~100,000 apps per tenant without turning app growth into bigger client payloads, slower startup, or a new operational ceiling.&nbsp;Current ZPA customers don’t need to do anything day-to-day and there’s no user workflow change. If you want to ensure Application Scaling is enabled for your tenant, the next step is to open a backend support ticket. Once your environment meets the&nbsp;standard prerequisites (like supported component versions), Zscaler will turn the feature on for you.* If you’re new to Zscaler and evaluating private access for a large application environment,&nbsp;ask your Zscaler account team for a ZPA demo and an overview of Application Scaling.*Roadmap note: A dedicated per-platform setting for Application Scaling is planned for a future release (expected after February 2027). For now, enablement is handled via a backend support ticket.]]></description>
            <dc:creator>Sanjog Sahu (Senior Technical Marketing Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler Integrates With OpenAI Cyber Models to Secure the AI-Enabled Endpoint]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zscaler-integrates-openai-cyber-models-secure-ai-enabled-endpoint</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zscaler-integrates-openai-cyber-models-secure-ai-enabled-endpoint</guid>
            <pubDate>Thu, 06 Aug 2026 16:30:07 GMT</pubDate>
            <description><![CDATA[Zscaler Endpoint AI Security will use OpenAI's cyber models to connect risks across AI tools, developer environments, browsers, software, and packages, helping defenders understand what matters and what to address first.Today, OpenAI and Zscaler are expanding their cybersecurity initiatives with the launch of Zscaler Endpoint AI Security. By mapping how various conditions on the endpoints combine into viable attack paths, this capability allows security teams to target and prioritize their highest-impact remediations.AI is transforming the modern enterprise endpoint. As employees increasingly rely on AI assistants, coding agents, browser extensions, and connected services to drive productivity, they also introduce new complexities of configurations, permissions, and connections that security teams must navigate.While traditional endpoint controls deliver essential visibility into vulnerabilities, malware, and policy violations, Zscaler Endpoint AI Security adds a crucial layer of context. By analyzing how distinct conditions interact across workflows, it helps defenders move past disjointed findings to see a clear, accurate picture of real-world risk. Connecting signals across the modern endpointZscaler Endpoint AI Security dynamically evaluates device and user risk using security-relevant information available on managed endpoints. It examines:AI agents, assistants, and their configurationsIDEs, configurations, and installed extensionsBrowsers, security settings, and installed extensionsSystem and software configurationsPython, npm, and other software packagesOpenAI's cyber models help analyze relationships across these signals and identify potential paths to compromise. The assessment can show how a sequence of conditions may contribute to credential exposure, unauthorized remote access, persistence, or data exfiltration.For example, a developer may follow a routine setup step for a trusted repository, such as installing its software packages. If that process has privileges to execute repository-controlled code on a device that has access to the source code and developer credentials, then permissive security settings may turn a normal workflow into a path for credential exposure, persistence, or data loss. Zscaler Endpoint AI Security helps teams identify the combined exposure and helps to focus remediation on the controls that can break the potentially vulnerable path. Leverage visibility into AI-enabled workflows to neutralize the attack chainAI assistants and agents now sit alongside developer tools, browsers, extensions, and software packages in everyday enterprise workflows. Depending on how they are configured and authorized, AI agents can interact with files, applications, and external services, call local tools, run scripts, and invoke workflows that rely on third-party dependencies. Capabilities that were once concentrated on developer workstations are now reaching a much broader set of enterprise users.In practical terms, AI is giving more users access to developer-like workflows. Even when users do not write code themselves, these workflows can introduce similar execution paths, dependencies, permissions, and supply chain risks across more of the endpoint fleet.Some of the most consequential risks do not originate from just one AI agent, package, extension, or configuration in isolation. They usually emerge from their combined workflows and relationships. An agent may have access to business data, rely on a package with unexpected behavior, connect to an external service, and operate on a device with permissive controls. Individually, those conditions may appear manageable. Together, they may form a credible path to code execution, credential exposure, persistence, unauthorized remote access, or data loss.By applying cybersecurity reasoning to this endpoint context, the assessment can help customers:Identify high-impact risks that are difficult to recognize through isolated configuration checksUnderstand how AI tools and developer workflows affect endpoint exposurePrioritize remediation based on credible attack pathsGive security teams clearer context for investigationStrengthen governance across extensions, packages, software, and AI toolsFor red teams and defenders, Zscaler Endpoint AI Security provides a focused starting point for investigation. It complements red team assessments by connecting current, endpoint-specific conditions into a detailed attack chain. Security teams now have visibility to how an initial opportunity could lead to execution, and the path of execution that could expose credentials or other valuable access, where persistence may be possible, and which controls could interrupt the sequence.This context helps red teams prioritize validation around the attack paths most relevant to the device. It also gives defenders a detailed remediation plan. The resulting report goes beyond listing separate weaknesses by explaining how one condition may enable the next, what the potential impact could be, and where the chain can be broken.The goal is not to add another stream of alerts. It is to help security operations, endpoint engineering, red teams, and risk teams focus on the findings most likely to affect the organization. Advancing AI-powered defense togetherZscaler Endpoint AI Security builds on the broader collaboration between OpenAI and Zscaler. Zscaler participates in OpenAI's Trusted Access for Cyber program, which helps verified defenders access advanced cyber capabilities with safeguards that scale alongside model capability.Through this initiative, OpenAI brings advanced cybersecurity reasoning designed to support legitimate defensive work, while Zscaler brings enterprise security expertise, endpoint context, and the Zscaler Zero Trust Exchange platform. Together, the companies are helping customers understand how conditions across a rapidly expanding endpoint attack surface can combine into detailed attack paths, then turn that understanding into practical protection.To learn more or request a demo, contact Zscaler at zscaler.com/request-a-demo.]]></description>
            <dc:creator>Shourya Pratap Singh (Director, Software Engineering)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler Integrates With Claude Inference Hooks to Scale AI While Addressing Risks]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zscaler-integrates-claude-inference-hooks-scale-ai-while-addressing-risks</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zscaler-integrates-claude-inference-hooks-scale-ai-while-addressing-risks</guid>
            <pubDate>Wed, 05 Aug 2026 16:47:01 GMT</pubDate>
            <description><![CDATA[Zscaler and Anthropic redefine AI Security with Policy Enforcement. This transformative integration delivers unified Zero Trust enforcement directly inside Claude via inference hooks, eliminating fragmented AI governance and stopping data loss before it happens. Adversaries have already weaponized AI. Defenders are still arguing about consoles.Today, Zscaler and Anthropic are redefining AI security with a transformative integration that delivers Zero Trust policy enforcement directly inside Claude. One policy, defined once in the Zscaler platform, enforced natively at the model layer, on every Claude Enterprise touchpoint, from day one. No parallel governance stack, gaps, or waiting on infrastructure rollouts.&nbsp; Enforcement at the speed of the interactionLegacy approaches inspect messages, but today’s threats live in conversations. Data doesn't leave the enterprise in one prompt. It is exposed turn by turn: a schema here, sample rows there, extraction logic to finish the job. Message-level controls are structurally blind to it. AI Guard evaluates the full conversation as it develops and enforces policy in real time, before exposure happens, not in next week's audit report.Zscaler supplies the policy, checks, and intelligence. Claude inference hooks executes the enforcement so policy can move at the speed of the model. Anthropic built Claude to participate. We built the policy engine it participates with. If you're a Zscaler customer, your existing policies are the starting point and there's very little standing between you and turning this on. If you're not yet, this might be the most approachable first conversation we've ever been able to offer.&nbsp; Zero fragmentationNow, AI Guard provides easy governance of the AI you sanctioned. Zscaler Internet Access hunts down and exposes everything else including embedded and shadow AI. Together, they deliver what fragmented point products never will: complete visibility and unified enforcement across the entire AI attack surface, powered by a platform processing hundreds of billions of transactions a day. The future of AI governanceAs we gear up for a week at Black Hat, we can’t help but notice the industry is splitting into two camps: vendors with products for observability, and provider solutions built to enforce your policy natively. This release by Anthropic plants a firm flag in the second camp. CISOs walking the showroom floor this week should be looking for the same from every provider they trust with their data. Learn more about Claude inference hooks and Zscaler’s integration here.]]></description>
            <dc:creator>Ashwin Kesireddy (VP, Product Management – AI Security)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Health360: The Answer to the Question, &quot;Is My Zscaler Deployment Healthy?&quot;]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/health360-how-healthy-is-my-zscaler-deployment</link>
            <guid>https://www.zscaler.com/blogs/product-insights/health360-how-healthy-is-my-zscaler-deployment</guid>
            <pubDate>Wed, 05 Aug 2026 12:20:12 GMT</pubDate>
            <description><![CDATA[Over time, cybersecurity platforms typically expand to include more products, admin interfaces, and dashboards. So, while their breadth of functionality increases, it often leaves their customers with important questions about the overall health of their security platform deployment, such as:How do I understand my overall adoption of the platform, including what I'm entitled to and how much of it I'm actually utilizing?How do I keep pace with the platform’s growth&nbsp;and stay compliant with best practices that keep everything running well?How do I get a bird's-eye view of all connectors like client connectors, app connectors and tunnels in my environment to confirm they're operating properly?How do I proactively know that the services I depend on are resilient and performing within the agreed SLOs?Answering those questions usually requires stitching together dashboards, reports, spreadsheets, and institutional knowledge, but that takes a lot of time. Fortunately, at Zscaler, Health360 solves that problem.&nbsp;The Power of Zscaler’s PlatformZscaler holds an architectural advantage when it comes to understanding deployment health.&nbsp;The Zero Trust Exchange serves as an intelligent switchboard for customer traffic—brokering every connection between any entity and any destination. That produces telemetry of a volume and quality that no bolt-on monitoring tool can replicate. It lets us see how well customers have deployed Zscaler, gain unique insights into components&nbsp;around Zscaler (ISPs, network paths, apps, and more), and baseline individual deployments against what we observe across our entire cloud.Health360 is a new platform capability (included for free in&nbsp;Experience Center) that takes advantage of this unique architecture to show customers their full deployment health in an objective, intuitive, and quantitative fashion—scored, trended, and paired with prescriptive remediation steps. Health360 is not a troubleshooting tool or a risk quantification tool—Zscaler has purpose-built products for both of those needs (ZDX for the former and&nbsp;Risk360 for the latter). Instead, Health360 tells you whether your Zscaler deployment is performant, resilient, and mature.&nbsp;The Three Pillars of HealthHealth360 organizes the answer to "is my deployment healthy?" into three pillars. The first—best practices—is about architectural hygiene: have you deployed the platform correctly, completely, and effectively? The other two pillars—connectors health and services health—are about operational health: is everything running well right now, and trending in the right direction?That ordering is deliberate. A well-architected deployment will, more often than not, operate in a healthy fashion. Customers should get the architecture right first, then monitor the operation of the platform continuously.Pillar 1: Best PracticesThe first pillar answers the most fundamental questions about your Zscaler investment:What products are you entitled to?&nbsp;How is utilization trending?&nbsp;And—the question behind those questions—how effectively have you deployed them?Health360 offers a single, self-serve, portfolio-level view of each product's deployment status, entitlement, and utilization. Executives can see at a glance how much of the purchased portfolio is live and delivering value. Admins can see where deployment gaps exist. And renewal conversations start from shared, objective data rather than manually assembled snapshots.That deployment and utilization information tells you&nbsp;what you've deployed. Best practices then tell you&nbsp;how effectively&nbsp;you’ve done so. That matters because a best practice you followed at initial deployment may quietly erode as suppliers change, teams rotate, and configurations accumulate—not to mention, Zscaler continuously adds new features that improve stability, resilience, and performance. With this pillar, Health360 operationalizes the collective experience of Zscaler's Professional Services and Customer Success teams (across thousands of deployments) to continuously evaluate your tenant’s configurations. Two examples illustrate the range:Tunnel resilience: If you forward traffic over GRE or IPSec, Zscaler has always advised that each office location should have a redundant pair of tunnels pointed at different Zscaler data centers, with IP SLA or health monitoring enabled. It’s simple in principle, but across dozens of locations, multiple ISPs, and equipment from different suppliers, it&nbsp;becomes difficult. Now, the tunnel best practice check evaluates every location against redundancy, monitoring, and capacity criteria and shows you which sites fall short.Double-tunneling and load-balancer entropy: If you tunnel inside a tunnel—encapsulating traffic within a GRE/IPSec envelope—the inner flows can lack the entropy our load balancers need to distribute them. So, your traffic pins to the same worker node(s), producing performance issues that are hard to diagnose even for our support teams. Health360 detects double-tunneling and suboptimal load distribution and flags affected locations for you—unlocking visibility that you would otherwise lack.This pillar also includes peer benchmarking, letting you see how you compare to organizations of similar sizes and industries, and offers flexibility to exclude best practice checks that don't apply to your deployment—your score reflects your reality because no two environments are the same.In the LA release, this pillar ships with v1 of the Adoption Dashboard (per-product deployment, entitlement, and utilization) and the first batch of 15-20 resilience and performance best practices focused on ZIA and Client Connector. ZPA practices will fast-follow shortly after LA. We will continue adding best practices on a regular basis, targeting 50+ across all products by GA later this calendar year. At that time, the Adoption Dashboard will also add per-product best practice evaluation to show how effectively you deployed each individual product.Pillar 2: Connectors HealthZscaler offers different connectors for specific traffic-forwarding use cases: GRE/IPSec tunnels for traditional site-based forwarding, Client Connector as the preferred path for user traffic, App Connector for outbound connections for private app access, and Zero Trust Branch and Cloud Connectors for extending zero trust to branches and workloads. Large enterprises typically run several of these at significant scale, and need a consolidated method of seeing how the whole fleet is performing.Connectors health provides that unified view. Rather than answering "which connector is down?" (a triage question), it answers "how is my fleet performing today?" (a general health question). It evaluates each connector type across availability, performance, and capacity, with drill-downs when something needs attention.In the LA release, connector and edge health covers:GRE/IPSec tunnels: Availability and capacity metrics across all locationsClient Connector: Health signals spanning software issues, tunnel and networking issues, and user disabling of services—and for customers who have ZDX entitled and configured, Client Connector health is also enriched with insights surfaced from ZDX telemetry, including device health and ZDX scoresInsights on App Connector health, covering availability and capacity, will fast-follow shortly after LA, while Zero Trust Branch and Cloud Connector health will follow in subsequent phases as we approach GA later this calendar year.Pillar 3: Services HealthEven a perfectly architected and healthy deployment depends on services beyond your direct control, including Zscaler's own infrastructure, your ISPs, and the apps your users consume. The services health pillar gives you a contextual view of how these services are performing for your traffic specifically.This begins with Zscaler's own infrastructure, where we are committing to a level of transparency that is rare in the industry, showing:Which Zscaler data centers are processing your trafficWhich traffic-steering mechanisms are directing traffic to those data centersWhat latency Zscaler is adding to your traffic, and if it is within our SLOsWe can offer this level of granularity because of the confidence we have in the reliability and performance of our multitenant infrastructure. No other vendor offers this level of visibility, but we believe it is exactly what customers need if they are to trust a cloud security platform.In the LA release, services health launches with China Connectivity insights, one of the most consistently requested items from our global customers. For whatever&nbsp;China Premium SKU you purchased, you will see your current bandwidth utilization as well as the health of that connectivity—with no support ticket required. On the path to GA, we plan to extend services health to cover ZIA cloud health and enhanced visibility into ZIA Private Service Edges.&nbsp;What Ships in July and the March to GATo make the scoping unambiguous, here is the release picture in one place:PillarJuly LA ReleaseUpcoming GA (H2 CY26)Best PracticesAdoption Dashboard v1: platform overview with per-product deployment, entitlement, and utilization; first 15-20 resilience and performance practices for ZIA and Client ConnectorZPA practices shortly after LA; regular additions to 50+ practices across all products; peer benchmarking; per-product best practice evaluation in the Adoption DashboardConnectors HealthGRE/IPSec tunnels (availability, capacity); Client Connector (software, tunnel/networking, user-disablement issues)App Connectors shortly after LA (availability, capacity); Zero Trust Branch and Cloud Connectors in later phasesServices HealthChina Connectivity health and bandwidth utilizationZIA cloud health and ZIA Private Service Edge enhanced visibility; broader service coverage toward GAHealth360 will develop iteratively. Between LA and GA, we will regularly add support for additional best practices, connectors, and services, which we will prioritize based on feedback from early customers.&nbsp;&nbsp;Get StartedThe health of your Zscaler deployment shouldn't be a quarterly conversation or a support escalation. It should be a number you can see, a trend you can track, and a list of actions you can take every day in Experience Center.If you’d like to get started with Health360, you can:Watch our webinar to see Health360 in action and walk through each pillar in detail.&nbsp;Sign up for the limited availability (beta) release by contacting your Zscaler Sales Engineer or Technical Success Manager.&nbsp;]]></description>
            <dc:creator>Manpreet Chadha (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Products Are Getting Smarter. Enterprise Transformations Are Getting Harder.]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/why-zero-trust-needs-continuous-planning</link>
            <guid>https://www.zscaler.com/blogs/product-insights/why-zero-trust-needs-continuous-planning</guid>
            <pubDate>Tue, 04 Aug 2026 20:56:57 GMT</pubDate>
            <description><![CDATA[Cloud-delivered services have reduced infrastructure requirements, automated software updates, and introduced capabilities that once required months of engineering effort. Features that previously demanded custom integrations or extensive operational overhead are now available through native platform capabilities.At the same time, customers report enterprise transformations have become considerably more challenging. If that's true for you, you're in good company. The task to meet today’s demands is not small.&nbsp;Gartner’s advice is clear: for successful cross-technology transformation in the autonomous era, organizations must, “Translate (their) vision into a clear target state. Specify what success looks like, using (their) strategic vision and BTE drivers to set measurable future goals. Outline capabilities, risk posture and business outcomes (they) want to achieve. This clarity ensures your roadmap is both ambitious and realistic, and resonates with executive stakeholders who require measurable results.”Outlining capabilities, risk posture and business outcomes is no longer contained to successfully deploying a single security product. Organizations are modernizing connectivity, adopting AI, protecting data, securing workloads, segmenting applications, improving user experience, integrating security operations, and evolving governance models inside geopolitical fragmentation and quantum-accelerated threats simultaneously. Every initiative introduces new planning and design decisions that influence the technologies, teams, and operational processes around it. This broader challenge is reflected in Forrester's recently published 2026 Predictions for Technology and Security:“THE RACE TO TRUST AND VALUE”&nbsp;In 2026, the era of volatility continues, challenging CIOs and CISOs to lead with precision, resilience, and strategic clarity. The Al hype period is over, and the pressure to deliver real, measurable results from secure Al initiatives will intensify - while the margin for error continues to shrink. Geopolitical pressures and security risks will continue to command attention, making 2026 a year to focus on outcomes that align to business goals and build trust across the business. Tech and security leaders will be called upon to recalibrate investments under tighter financial scrutiny and governance, navigating increasingly complex geopolitical and economic risks.&nbsp; The shift from implementing products to orchestrating cross-technology changeTraditional consulting engagements were designed around discrete implementation projects. A deployment begins, configuration work is completed, documentation is delivered, and the engagement ends. That model works well when technology remains relatively static and separated.Modern Zero Trust environments rarely remain static and are interconnected. It’s a prerequisite.Business priorities change. New capabilities become available. Applications move to the cloud. AI introduces entirely new data protection requirements. Security operations mature. Teams reorganize. Acquisitions introduce new infrastructure. Every change creates new opportunities to optimize, but it also creates new dependencies that must be evaluated alongside the existing environment.Planning and design have become continuous disciplines rather than one-time project activities.This shift is changing the role of technical expertise. The organizations realizing the greatest value from their Zero Trust investments are not necessarily deploying more technology. They are making better decisions about when to introduce new capabilities, how to integrate them with existing investments, and which changes create the greatest operational value. They continuously validate assumptions, revisit earlier design decisions, and align technical priorities with changing business objectives rather than treating architecture as something that is completed once.Experience matters because every environment is different, but successful transformations consistently follow common patterns. The problem of secure AI adoptionEnabling AI securely is no longer a question of deploying a single product. Organizations must balance identity, browser security, data protection, policy enforcement, governance, and user experience while enabling employees to adopt new tools responsibly.&nbsp;Gartner recently emphasized that, “AI deployments that run ahead of business strategy risk technical capability without strategic coherence."&nbsp;Similar patterns exist across Zero Trust modernization, application segmentation, data protection, and security operations optimization. Each initiative spans multiple technology domains and requires decisions that extend well beyond any individual product.&nbsp;In their Cybersecurity Roadmap: The CISO’s Guide to Business Results, Gartner reports that, “By 2028, 80% of CISOs will face a board-level mandate to connect cybersecurity investments to tangible business outcomes.”The complexity is rarely found within the technology itself. It emerges at the intersection of technologies, business priorities, and operational realities.The differentiator will not be how quickly new products are deployed, but how effectively they are integrated into an operating model that can continuously adapt to changing requirements. Zero Trust is no longer a destination. It is an ongoing transformation that benefits from continuous planning, thoughtful design, and operational refinement as business and technology continue to evolve.Leading organizations are responding by changing how they approach transformation itself.“Cybersecurity is the foundation for our digital world. It is at the heart of trust and will allow society to fully benefit from the transformations enabled by new technologies like AI and quantum. But it’s not something one can do on their own. We have to come together, share intelligence globally and&nbsp;develop the skills equal to emerging risks."&nbsp;Michael Miebach, Chief Executive Officer, Mastercard&nbsp;&nbsp;Source: The World Economic Forum's Global Cybersecurity Outlook 2026To meet these pressures, organizations have evolved from treating planning as a phase that concludes before implementation begins, they are building continuous planning into the operating model. Architecture decisions are revisited as new capabilities become available. Policies are refined as business requirements evolve. Design assumptions are validated before major changes are introduced into production. Operational feedback is incorporated into future planning cycles, creating an environment that improves over time rather than remaining fixed after deployment. Why coordinated planning is the key to successThis is one of the reasons enterprise security organizations are increasingly measuring success differently. Instead of evaluating projects solely by deployment milestones, they are asking broader operational questions:&nbsp;Are teams aligned around the same objectives?Can new capabilities be adopted without introducing unnecessary operational overhead?Are policies becoming simpler over time instead of more complex?Can future changes be introduced with confidence because previous decisions were documented, validated, and understood?These questions extend beyond individual products. They measure the maturity of the overall Zero Trust operating model.Organizations “lacking access to security skills, resources and awareness are perennially targeted by countless bad actors. The actual capability gap lies not just in technologies, but in people: in the professionals needing more training and support."&nbsp;Illena Armstrong, President, Cloud Security Alliance&nbsp;Source: The World Economic Forum's Global Cybersecurity Outlook 2026Three questions every Zero Trust transformation leader should askWho provides the expertise to validate our cross-technology planning and design decisions, helping us develop the technical&nbsp;decision-making skills equal to emerging risks?Can our security operating model continuously adapt while maintaining policy and security excellence or does it run ahead of business strategy, risking technical capability without strategic coherence?Are we streamlining security implementation to reduce risk and maximize value through shared cross-technology responsibility?Security technology never stands still. Neither should your Zero Trust strategy.&nbsp;Read this data sheet to explore Zscaler Advanced Services, expert-led, proactive consulting subscription designed to help you continuously mature your Zero Trust strategy in a rapidly evolving security landscape.&nbsp;]]></description>
            <dc:creator>Leah Travers (Principal Portfolio Manager, Customer Success)</dc:creator>
        </item>
        <item>
            <title><![CDATA[On-Prem Data Security in the AI Era: Why It’s Time to Modernize with DSPM]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/prem-data-security-ai-era-why-it-s-time-modernize-dspm</link>
            <guid>https://www.zscaler.com/blogs/product-insights/prem-data-security-ai-era-why-it-s-time-modernize-dspm</guid>
            <pubDate>Tue, 04 Aug 2026 16:30:12 GMT</pubDate>
            <description><![CDATA[For all the momentum around AI, cloud, and SaaS transformation, much of the enterprise’s most sensitive data still lives on premises.It sits across file shares, NAS environments, legacy repositories, and private data centers. It includes regulated data, intellectual property, archived records, and operational content that businesses still depend on every day.This data has not gone away, but in many organizations, the way it is secured has not kept up.Why data security has become a bigger problem in the AI eraAs sensitive data is indexed, analyzed, summarized, and moved across automated workflows, the risks tied to on-premises repositories become harder to ignore. If security teams do not understand what sensitive data they have, where it lives, and who can access it, AI can amplify exposure at scale.Why on-prem data security still mattersOn-prem data often remains in place for good reason:Compliance and regulatory requirementsLatency and performance considerationsCost and operational constraintsBusiness continuity and legacy application dependenciesIn saying that, these environments are often shaped by years of organic growth, shifting ownership, and inconsistent access controls. Sensitive files may be duplicated across shared drives, buried in outdated directories, or exposed through nested permissions that no one has reviewed in years.That creates a dangerous mismatch: high-value data protected by aging security approaches. Why legacy approaches fall shortMany organizations have made progress securing cloud and SaaS environments, but on-prem data security often still relies on older tools and fragmented processes.Common challenges include:Limited visibility:&nbsp;Teams often do not know where sensitive data lives or who can access itFragmented controls:&nbsp;On-prem, cloud, and SaaS data are often managed through separate toolsLegacy scanning models: Older approaches can be slow, infrastructure-heavy, and difficult to scaleClassification gaps: Pattern-based detection often struggles with unstructured data and can create false positives or false negativesPerformance concerns: Large repositories can make full scans disruptive or impracticalCompliance pressure: Teams must secure sensitive data while meeting evolving privacy and regulatory requirements Why the AI era raises the stakesThese challenges become more serious when on-prem data starts flowing into AI-driven workflows.A file may begin in an on-prem repository, but then be:Accessed by a remote workerShared through a SaaS applicationIndexed by an AI assistantSummarized by a generative AI toolUsed downstream in automated workflowsAt each step, exposure can grow, meaning&nbsp;data can flow like water.Many legacy tools are built to monitor the repository, not the broader data journey. That means security teams can lose visibility once data moves beyond the original environment or is accessed in new ways.In the AI era, this gap matters more. Sensitive data is no longer static: it is increasingly mobile, connected, and operationalized.What modern on-prem data security should look likeThe future of on-prem data security is not just about better scanning. It is about making risk easier to understand and faster to act on.Modern teams need:Smarter discovery and scanning that can handle large, complex repositoriesMore accurate classification for sensitive structured and unstructured dataIdentity-aware risk analysis that connects sensitive data to actual access exposureUnified posture visibility across on-prem, cloud, SaaS, and AI-related environmentsFaster time to value with less operational overheadIn other words, security teams need more than inventory. They need answers:Which data is sensitive?Which repositories are overexposed?Which users create the greatest risk?What should we fix first? How Zscaler DSPM helps secure on-prem dataZscaler DSPM helps organizations modernize on-prem data security by bringing together data discovery, classification, access visibility, and risk prioritization in a broader posture management framework.With Zscaler DSPM, organizations can:Discover&nbsp;sensitive&nbsp;on-prem data&nbsp;at&nbsp;scale across file shares and enterprise repositoriesClassify&nbsp;data&nbsp;more accurately&nbsp;with modern techniques that go beyond simple pattern matchingUnderstand&nbsp;exposure in context by connecting sensitive data with identity and permission analysisPrioritize&nbsp;the riskiest issues&nbsp;first by surfacing combinations of sensitive data, overpermissioned access, and critical repositoriesSupport hybrid data protection strategies with visibility across on-prem, cloud, SaaS, and AI-related environmentsStrengthen compliance efforts across privacy and regulatory frameworksReduce operational complexity through a more consistent and streamlined approach to data securityThe greater value is strategic: Zscaler DSPM helps unify on-prem data security under a broader data security posture management approach.This matters because most enterprises cannot move all sensitive data to the cloud overnight. They need a way to secure data where it lives today while building toward a more consistent future-state architecture. Zscaler DSPM helps bridge that gap.See it in actionThe fastest way to understand your on-prem data risk is to assess it in your own environment. If you’re a current Zscaler customer, reach out to your account representative to learn more.&nbsp;New to Zscaler?&nbsp;Connect with one of our Zscaler DSPM experts to evaluate your on-prem estate and see how DSPM can help uncover sensitive data, identify exposure, and prioritize the risks that matter most.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.]]></description>
            <dc:creator>Mahesh Nawale (Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust Branch Is Now Available in FedRAMP Moderate and High]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zero-trust-branch-now-available-fedramp-moderate-and-high</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zero-trust-branch-now-available-fedramp-moderate-and-high</guid>
            <pubDate>Mon, 03 Aug 2026 06:01:23 GMT</pubDate>
            <description><![CDATA[Civilian federal agencies and public sector organizations do not deliver mission outcomes from a single headquarters. A great deal of work happens across field offices, regional hubs, public-facing service centers, labs, depots, and temporary sites that stand up fast when priorities change.But branch security has not kept pace. Many agencies are still managing a mix of firewalls, VPNs, MPLS, NAC, and traditional SD-WAN that was built for a different era. That legacy model creates three recurring problems: expanding attack surface, growing operational overhead, and too much implicit trust inside and between sites. In a world where ransomware spreads fast and agencies support more devices than ever, that combination is difficult to sustain.Today, we are announcing that&nbsp;Zscaler Zero Trust Branch is available in FedRAMP Moderate and High. This milestone helps civilian agencies extend the Zscaler Zero Trust Exchange to distributed locations to secure internet access with Zscaler Internet Access (ZIA), secure private application access with Zscaler Private Access (ZPA), and reduce lateral movement inside sites with device segmentation. Accelerating TIC 3.0 for the Modern Branch&nbsp;For federal agencies, this availability provides a direct path to meeting CISA’s Trusted Internet Connections (TIC) 3.0 Branch Office Use Case. By moving security to the edge, Zscaler Zero Trust Branch enables the local breakout architecture patterns defined by CISA. This allows branch users to securely access the web and agency-sanctioned CSPs directly, ensuring policy parity with the main campus without the latency and complexity of backhauling traffic. What Zero Trust Branch isZscaler Zero Trust Branch securely connects and segments your branches and campuses without the complexity ofVPNs or overlay routing. It enables zero trust access from users and OT/IoT devices to applications based on yourorganization’s security policies. By combining the power of Zscaler’s industry-leading Zero Trust Exchange platformwith an integrated Branch Appliance deployed in branches and campuses, organizations can embrace a secure accessservice edge (SASE) framework, segment critical OT/IoT devices and enable a café-like branch.Zero Trust Branch replaces complex, hardware-heavy branch designs with a simpler approach: connect the site to the Zscaler Zero Trust Exchange and enforce policy in the cloud. It is designed for zero-touch provisioning, aligning with TIC 3.0’s emphasis on automated configuration management. You define a site, activate the appliance, and it establishes secure outbound connectivity to the Zero Trust Exchange.From there, agencies can apply consistent ZIA and ZPA policies by location, fulfilling TIC 3.0 segmentation architectures. This approach effectively isolates networks and limits lateral movement. Use cases agencies can put to workUse case 1: Secure internet and SaaS access from every location (ZIA)Branches need direct access to the internet and SaaS applications, but legacy designs often force a tradeoff between performance and consistent security. With Zero Trust Branch, site traffic can be forwarded to ZIA for cloud-delivered inspection and policy enforcement, scoped by location.Where this helps:Regional offices and public-facing service centers that need consistent web controlsSmall field sites that need enterprise-grade protection without enterprise-grade complexityTraining facilities and shared workspaces where user populations change frequentlyUse case 2: Replace VPN sprawl with least-privilege access to private apps (ZPA)Site-to-site VPNs and routed overlays tend to connect more than intended. They expand access, complicate audits, and increase blast radius. With Zero Trust Branch and ZPA, agencies can provide access to private applications based on policy, rather than extending network trust to broad subnets.Where this helps:Field offices that need access to specific mission applications, not entire networksTemporary and surge locations that need fast, tightly scoped connectivityPartner and contractor-connected environments where least privilege is non-negotiableUse case 3: Contain incidents by stopping lateral movement inside the siteMany branch incidents escalate because once a device is compromised, attackers move east-west across the local network. Branches also contain devices that cannot run agents or be managed like standard endpoints.Zero Trust Branch supports device segmentation by acting as a DHCP server to discover devices and place each device into a network of one using a /32 approach when possible, with support for variable subnet lengths when needed. Administrators can tag devices and write policy so only required communications are allowed, while everything else is blocked by default.Where this helps:Citizen-facing service centers with shared workstations, printers, and kiosksRegional offices where one compromised endpoint should not reach peer systemsHigh device-density sites where VLAN-based segmentation becomes hard to maintainZero Trust Branch also supports a Ransomware Killswitch concept. Policies can be color-coded, and during suspicious activity, teams can quickly tighten enforcement to reduce blast radius and limit lateral spread.Use case 4: OT and IoT segmentation in civilian agency facilitiesOT and IoT are now part of the civilian agency footprint: cameras, badge systems, kiosks, building management, environmental sensors, and specialized devices that are hard to patch and must stay online. These systems are often essential to facility operations, but they can also become an easy pivot point when they share space with user networks.Zero Trust Branch helps agencies discover these devices, group them with tags, and enforce least-privilege communications so OT and IoT can operate without becoming a lateral movement path.Where this helps:Public-facing facilities with kiosks, cameras, and mixed device populationsAdministrative buildings with physical security and building management systemsLabs and specialized sites where equipment has limited patch windowsUse case 5: SD-WAN modernization with simpler operationsZero Trust Branch can be deployed in one-arm mode alongside an existing SD-WAN, or in gateway mode to terminate multiple internet links and load balance traffic.Unlike traditional approaches, Zero Trust Branch establishes outbound tunnels to the Zero Trust Exchange and does not rely on publicly exposed routes at each site. That reduces what attackers can discover and target and supports a cleaner branch model.Where this helps:Remote and rural field sites that need resilient connectivity across multiple internet linksAgencies modernizing from MPLS and site-to-site VPNs toward simpler, cloud-first connectivityLocations with limited on-site IT that need standardized operations and faster troubleshootingUse case 6: Private apps hosted at the branch, without adding infrastructureSome agency locations still host local applications or services. But not every site has servers available to run additional components.With Zero Trust Branch, each appliance can run an App Connector, supporting ZPA access to branch-hosted applications without adding separate infrastructure and without shifting back to inbound access models.Where this helps:Small offices and clinics that need access to branch-hosted systems but have no virtualization footprintSites with legacy applications that cannot move to the cloud yet, but still require least-privilege accessTemporary or space-constrained locations where adding servers is not practical The bottom line&nbsp;With Zero Trust Branch available in FedRAMP Moderate and High, civilian agencies can modernize how they secure distributed locations with a policy-driven model that is easier to roll out, easier to operate, and built to reduce lateral movement. It is a practical path away from firewall sprawl and VPN complexity, and toward consistent security outcomes across the places where government work actually gets done.Want to learn more about Zero Trust Branch? Contact our sales team and we’ll walk through the capabilities and your specific requirements.]]></description>
            <dc:creator>Sean Connelly (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[No Hacker Required: How the World&#039;s First Autonomous AI Breach Makes the Case for Deception]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/worlds-first-autonomous-ai-breach-makes-case-for-deception</link>
            <guid>https://www.zscaler.com/blogs/product-insights/worlds-first-autonomous-ai-breach-makes-case-for-deception</guid>
            <pubDate>Fri, 31 Jul 2026 04:36:42 GMT</pubDate>
            <description><![CDATA[One of the scariest hacks we’ve ever seen wasn’t even a hack – it was an AI model so determined to look good on a test that it broke out of its sandbox and hacked a production system. No human involved. No ill intent meant.We’re not in Kansas anymore.On July 21,&nbsp;OpenAI disclosed that during an internal evaluation of its models’ cyber capabilities, run deliberately without the guardrails that typically block high-risk activity, a combination of its models broke out of a sandboxed environment, looking for answers so it could score well on a performance review.&nbsp;The models found and exploited a zero-day in the software proxy meant to contain them, escalated privileges, moved laterally until they reached a node with internet access, then chained stolen credentials and further zero-days into a remote-code-execution path on the production infrastructure of Hugging Face, a popular online platform and community for artificial intelligence and machine learning—eventually reaching a production database. The objective wasn't espionage or extortion. The models were trying to cheat the benchmark test by stealing the answer key.aAn agentic system, optimizing for a narrow goal, taught itself to break containment and breach a live production system to achieve success. Imagine the power of that capability in off-the-shelf models when adversaries point them at nefarious tasks. Why this incident is different from everything before itSecurity teams are accustomed to classifying threats by technique, tool, or actor. The Hugging Face incident doesn't fit any of those frames cleanly, and that's precisely what makes it a turning point.The Cloud Security Alliance,&nbsp;in its initial post-mortem of the incident, authored by more than 50 contributing CISOs and security practitioners, is unambiguous: this incident is the first publicly documented case of a fully autonomous attack. Not semi-autonomous. Not human-directed with AI assistance. This system set its own sub-goals, adapted in real time to bypass defenses, and operated with machine speed and persistence that overwhelmed the manual operations designed to stop it.That distinction matters because traditional attacks are bound by human deliberation. They follow patterns. Agentic attacks are objective-driven: the agent decides what to do next, not a person. And critically, agents don't require malicious intent to cause catastrophic damage. An agent with an underspecified goal and excessive authority can treat your critical infrastructure as a stepping stone simply because it's the most efficient path to accomplishing its task. Intent is no longer the signal you're looking for.The CSA's observations from the Hugging Face team also surfaced something defenders need to internalize about how these attacks look in telemetry. The reconnaissance showed up as low-confidence probes that – look at individually – all fell below escalation thresholds. The activity ran for roughly three days before it forced a response. And because agents can operate in bursts of activity punctuated by regular pauses as the system calls out to a model, agentic attack traffic can appear nearly identical in telemetry to legitimate agentic platforms your teams are running. The signal was there, but it was indistinguishable from noise. Why your detection stack was slow to workLet’s map this kill chain against the tools in your SOC.The initial escape used a zero-day. By definition, no signature for it existed in any detection database an hour earlier. Signature-based detection had nothing to match against.The lateral movement used valid, stolen credentials and legitimate-looking actions. To a behavioral engine, that's the same ambiguity you face every day: is this an intruder, or an engineer running a new script? You can't confidently automate containment or isolation on a probabilistic event.And all of it happened at machine speed. Traditional correlation-based detections were built to accumulate evidence over minutes and hours. By the time they surface a high-confidence alert, an agentic adversary is already several steps past you.&nbsp; Why deception is the signal that survivesDeception is different because it provides protection that is independent of tooling or any given vulnerability.A decoy doesn't need a signature. It doesn't need to decide whether behavior is malicious. It has one property: no legitimate user has any reason to touch it. When an adversary – including a well-meaning AI model – interacts with a decoy identity, credential, or file on an endpoint, the resulting alert isn't something that needs a deeper look. It's a confirmed threat. No triage needed. No investigation needed. Someone who shouldn't be there or is doing something they shouldn’t do just announced themselves.Against an agentic adversary, that signal becomes decisive. The quality that makes AI agents dangerous is also their weakness. They're exhaustive by design. The Hugging Face models didn't tiptoe; they probed every path they found, escalated everywhere they could, and used every credential they collected. An agent operating that way in a deception-instrumented environment faces three choices, and loses on all of them:Move fast and thorough – it interacts with a decoy, firing off a high-fidelity alert.Slow down to be careful – it forfeits the very speed that was its advantage.Try to be smart and map the terrain first – the mapping itself triggers the decoys.The CSA post-mortem makes this point explicit. Because agents cannot easily distinguish valid credentials or systems from honeypots, deploying “fake identities, credentials, package registries, datasets, honey APIs, and honey clusters” simultaneously slows attackers and surfaces the high-confidence indicators that low-signal reconnaissance never would. In a deception-instrumented environment, the exhaustive nature of agents is a liability. Deception is a key recommendation from the CSA. Twice.Before the Hugging Face incident, the Cloud Security Alliance already recognized the crucial role of deception technology. In its "AI Vulnerability Storm: Building a Mythos-ready Security Program" strategy briefing from April, prompted by Anthropic’s overview of Mythos, the CSA cited the need to deploy deception within 90 days among its 11 Priority Actions, rating the risk of going without deception as HIGH and warning of significant exposure within 45 days if the capability is absent. (To learn more about those 11 recommendations and how Zscaler can help you meet them,&nbsp;read this whitepaper).Now, in the direct aftermath of the world's first fully autonomous production breach, the CSA has published its Hugging Face post-mortem, and deception makes the list of top responses again. The guidance didn't soften after a real incident – on the contrary, it became much more specific.The post-mortem calls out deception across three distinct timelines, each with escalating scope:Start this month:&nbsp;Test rapid recovery and deploy deception controls. Verify that critical workloads can be rebuilt from known-good images, at scale. In parallel, deploy detective deception capabilities including monitored credentials, honeypots, and decoy datasets.Start this quarter: Deploy stack-wide deception technology. Implement honeytokens, decoy egress paths, and fake datasets. The CSA is specific about what "good" looks like: these decoys must be indistinguishable from production assets, any interaction with them must route to immediate containment, and you must maintain a decoy inventory to cleanly separate real impact from fabricated artifacts during a live investigation.As a core defensive principle:&nbsp;Deploy deception technology liberally. Reconnaissance in the Hugging Face incident showed up as low-confidence probes that individually fell below escalation thresholds, exactly the kind of signal traditional detection architectures are built to discard. The CSA recommends deploying fake identities, credentials, package registries, datasets, honey APIs, and honey clusters to both slow attackers and surface the high-confidence indicators that everything else misses.The CSA closes its deception recommendation with this:&nbsp;"This incident validates the findings of our previous work on the Mythos-ready security program. We must adapt and integrate new controls for this new agentic technology stack, extend current security stack capabilities to these agents,&nbsp;reprioritize previously nice-to-have controls such as cyber deception, and adapt proven controls to machine speed and attacks at scale, tailored for autonomous execution." This “attack” was exactly what the CSA guidance was written forThe Hugging Face incident resulted from an autonomous system, moving faster than any human responder, defeating signatures and blending into legitimate activity, right up until the moment it touched something it was never supposed to see. Now we can see what we’re up against.Modern deception blankets your entire environment with tripwires – across network, identity, cloud, endpoint, and the AI infrastructure adversaries want to find. Every path an AI-orchestrated attack explores has a chance of being a trap. An agent that probes everything will eventually probe the wrong thing – and probably sooner rather than later. Your detection stack was built for a slower era. Deception was built for this AI era. And the threat isn’t hypothetical any more.Protect yourself.&nbsp;Learn more about&nbsp;Zscaler Deception.]]></description>
            <dc:creator>Keith Do (Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What’s New in GovCloud: July 2026 Zscaler Product Updates]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-july-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-july-2026-zscaler-product-updates</guid>
            <pubDate>Thu, 30 Jul 2026 21:02:05 GMT</pubDate>
            <description><![CDATA[Between mission demands, operational tempo, and evolving compliance requirements, keeping up with every product release can easily slip down the priority list. Here is a curated roundup of notable Zscaler GovCloud updates from July, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include Zero Trust Branch availability on a FedRAMP High cloud, enhanced DLP logging and channel-level engine controls in ZIA, business continuity improvements for ZPA, and the new Network Intelligence dashboard in ZDX. Zero Trust Branch, FedRAMP High Cloud Available (Limited Availability)Zscaler 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, Zscaler launched a FedRAMP High-impact level cloud (ztbranchgov.net) for Zero Trust Branch in Limited Availability. This is a significant milestone for agencies and mission partners operating in high-impact environments that require the most stringent security controls. The new cloud includes various features and enhancements to support these demanding requirements.For full Zero Trust Branch release notes:&nbsp;https://help.zscaler.us/zero-trust-branch/release-upgrade-summary-2026 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 focus on expanding DLP visibility and control, giving admins more precise, time-bound policy enforcement and the ability to reduce noise by scoping DLP engines to specific channels.HighlightsEnhanced Web Logs: Added Support for DLP Policy Actions and Justification Messages: Admins can now filter and view logs for DLP policy actions and DLP confirmation messages. New filters and columns (DLP Policy Action and DLP Confirmation Message) have been added to Web Insights Logs and Endpoint DLP Insights Logs, improving audit readiness and incident investigation workflows.File Type Control Policy Rule Expiration: Admins can now set an expiration date for File Type Control policy rules, providing more granular, time-bound control over file type enforcement policies. This is useful for temporary exceptions or time-limited operational windows.Ability to Select Channels for DLP Engines: Custom and predefined DLP engines can now be scoped to apply only to specific channels (e.g., Endpoint DLP, DSPM), reducing noise from engines being applied to channels unnecessarily. This option is available when creating, editing, or cloning a DLP engine under Policies &gt; Data Protection &gt; Common Resources &gt; DLP Dictionaries &amp; Engines &gt; DLP Engines.For full ZIA release notes:&nbsp;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 business continuity improvements for multi-cloud log streaming and a recommended software update with refreshed RPM packages for supported platforms.HighlightsBusiness Continuity Update: Improvements to LSS-based Log Streaming in Business Continuity now support log streaming across multiple Private Clouds. This helps organizations maintain observability and compliance logging even during failover or multi-cloud operating scenarios.Manager Software Updates: A recommended update (Manager software version 26.54.4) was released, including updated App Connector and Private Service Edge RPM packages for Red Hat Enterprise Linux 8.x and 9.x, and a Private Cloud Controller RPM package for Red Hat Enterprise Linux 9.x. Packages are downloadable from the Zscaler repository.For full ZPA release notes:&nbsp;https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Digital Experience (ZDX)Zscaler Digital Experience (ZDX) provides visibility into end-user device health, application performance, and network path quality. For federal teams managing distributed endpoints across agencies and field locations, ZDX helps identify and resolve experience issues before they impact productivity or mission delivery.This month's ZDX update introduces a new Network Intelligence dashboard that brings organization-wide network health visibility into a single view.HighlightsNetwork Intelligence Dashboard: The new Network Intelligence dashboard provides a high-level visualization of your organization's network. ZDX runs Cloud Path probes to analyze and identify anomalies in network health, allowing teams to understand underlying network issues across the organization. Admins can also configure alert rules to automatically receive notifications for Network Intelligence events, enabling faster response to connectivity disruptions.For full ZDX release notes:&nbsp;https://help.zscaler.us/zdx/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.]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Lethal Trifecta Is Everything Zero Trust Was Built to Stop]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/lethal-trifecta-zero-trust</link>
            <guid>https://www.zscaler.com/blogs/product-insights/lethal-trifecta-zero-trust</guid>
            <pubDate>Mon, 27 Jul 2026 20:57:30 GMT</pubDate>
            <description><![CDATA[A security leader I follow dropped a post last week that I haven’t been able to shake. Over the past month, they had sat through discovery calls with more than thirty vendors, every single one selling something called “AI security.” Each of them was asked the same plain question: how does your product stop the lethal trifecta?Almost nobody recognized the term. One or two could actually engage with it. Everyone else went quiet. Let’s be honest about what that tells you. If the vendors selling you “AI security” can’t name the central attack pattern of the agentic era, you have a problem—and it’s not their problem.I’ve been chewing on this for a while, because the lethal trifecta is the photographic negative of the most prominent game-changing mindset: that trust should never be assumed. It has to be earned, verified, and earned again. That idea has a name, zero trust, and over the last decade it went from radical to obvious. The lethal trifecta is what happens when we throw all of that away.So let’s start at the beginning. What is the Lethal Trifecta?The term came from the same person who named prompt injection (which is not a coincidence).Simon Willison coined “lethal trifecta” in June 2025. If that name sounds familiar, it should: he’s also the engineer who gave us “prompt injection” He named that one after SQL injection deliberately, because the underlying flaw is identical: mixing trusted and untrusted content in the same execution context.His observation about the trifecta is almost embarrassingly simple. An AI agent becomes a loaded weapon pointed at your own data the moment it combines three capabilities:Access to private data: your inbox, customer records, source code, file shares.Exposure to untrusted content: anything an attacker can get in front of the model, an email it reads, a web page it browses, a support ticket it ingests.The ability to communicate externally: sending an email, calling an API, posting to a URL.Any one of these alone is fine. Two of them, and you’re usually still okay. Put all three in the same agent, in the same context window, and you’ve built a machine an attacker can hijack with nothing more than a cleverly worded sentence buried in a web page.No malware. No exploit. No CVE. Just text that the model obeys without question, because to the model, your instructions and the attacker’s instructions look exactly alike.Think of it as the fire triangle for the AI era: heat, fuel, oxygen. Remove any one and the fire goes out. Keep all three present and combustion is only a matter of time. We already have examples. The “EchoLeak” vulnerability in Microsoft Copilot was a textbook trifecta exploit: a poisoned input quietly steered an agent with data access toward exfiltration, with zero user action required. It happened in the wild, not in a lab. The trifecta is zero trust inverted, point for pointHere’s what stopped me cold, and why I think you need this framing specifically.Zero trust is a discipline of decomposition. You take a request and you break it apart. Who is this identity? Is it verified right now? Does it have least-privileged access to this resource, for this action, in this moment? Deny by default. Segment everything. Assume breach and treat every actor, every packet, accordingly.The lethal trifecta is what happens when all of that collapses back into a single, undifferentiated blob of implicit trust.The agent isn’t verified per request: it’s granted standing, persistent reach over whatever its tools can touch. It doesn’t operate under least privilege either; it inherits the union of every privilege every connected tool holds. Breach is never assumed, good faith is. Data, input, and egress don’t stay apart: they dissolve into one shared context where private data, attacker-controlled text, and an open outbound channel all swim together.Look at it point for point:Verifying every request vs. granting one standing, implicit trust.Least privilege vs. aggregating maximum privilege.Assuming a breach vs. assuming good faith.Segmenting and denying by default vs. merging everything and allowing by default.Zero trust was our answer to the inevitable collapse of the architecturally unsound network perimeter. The lethal trifecta is the same lesson at the data and agent layer.The trifecta is hiding in your data lineage right nowHere’s what makes this genuinely unsettling: you don’t have to build an exotic agent to assemble the trifecta. Any data store that’s broadly accessible and feeds a model, whether as training data or live retrieval context, already has all three legs by default.Walk through it with me.A shared vector database or knowledge corpus holds sensitive material the model can surface. Access to private data: present. It’s used to answer users and increasingly takes actions for them based on the corpus and tools connected. External communication: present. And because almost anyone can write to it, every document sitting in that corpus has to be treated as a potential instruction, not passive data. That’s the last leg of the trifecta, switched permanently on.The moment a corpus is writable by people you don’t fully trust, the content loaded into it is untrusted input, and inside most retrieval systems, untrusted input is executable. The public web scraped into a training set is the purest version of this: untrusted content at planetary scale, poured straight into the model’s foundation.This is exactly what the ConfusedPilot research demonstrated. Working in Professor Mohit Tiwari’s SPARK Lab at UT Austin, the Symmetry team showed that an attacker needs nothing more than the ability to drop a file into a corpus that a RAG system like Microsoft 365 Copilot references. The poisoned document gets retrieved. The model folds its contents into the prompt. The attacker steers the answer. As Tiwari put it: “the attack is as easy as uploading a file, and the defense is hard.” Worse, the effect can linger even after the malicious file is deleted.You cannot tell a poisoned record from a legitimate one by reading it. They look identical. The only thing that separates them is who can access it and who has changed it.Strip away provenance and every row in your corpus is equally suspect. Which means you’re forced to leave the untrusted-content leg on for everything, all the time. That reframes the whole problem. Cutting a leg of the trifecta in a retrieval system is, concretely, a data-lineage problem. If you can attribute every record to a trusted source and a trusted writer, you can quarantine it, down-rank it, or refuse it. If you can’t, you’re handing your output to whoever had ‘write’ access to your data. Prompt filtering matters, but sadly, it’s not enoughLet’s be honest about the first instinct here, because it’s the wrong one.The first thing most teams do is reach for prompt inspection: intercept each input, classify the malicious ones, block them before they reach the model. This matters. A strong prompt protection layer should be table stakes for anyone putting agents into production, and it raises the cost of an attack considerably.Why filtering prompts isn’t a defensive strategyNo classifier catches everything. An adversary who can try a thousand variations only needs one to land. Inspection narrows the opening. It does not close it.The layer that closes it is structural. It’s the one Willison himself points to: cut a leg. Make it architecturally impossible for all three capabilities to coexist in one trusted context. Don’t let the agent reach private data. Or don’t let it see untrusted content. Or don’t let it exfiltrate.For most real-world agents, the most practical leg to sever is the relationship between data and egress: tightly governing what data an identity (human or agent) can actually reach, and where it’s allowed to send it.That should sound familiar. It’s Zero Trust, applied to a single pillar: the data itself. The trust boundary has moved again with AI, and it’s sitting on your data planeZscaler operationalized zero trust for the network. Then extended it to identity. The lethal trifecta is the signal that the next place to apply these same principles is the data plane.The perimeter has moved again. It’s now the data an agent can reach, and the path by which that data can leave.You can’t cut a leg of the trifecta you can’t see. That’s the work we’re focused on at Zscaler in AI Security: bringing the same zero-trust rigor we applied to traffic and identity down to the data layer. Mapping precisely which identities and agents can touch which sensitive data. Closing the exfiltration path before an attacker goes looking for it. Symmetry’s AI access graph was built for exactly this question, and folding it into Zscaler’s zero-trust platform feels less like an acquisition than a homecoming.What this means for you right nowIf you’re a CISO or security leader evaluating AI security vendors, or building agentic systems yourself, here’s the practical read-out.Ask every vendor the trifecta question: If they don’t recognize the term, that tells you something important about how deeply they’ve thought about agentic security and engaged with the wider industry. The vendors who can’t engage with the foundational attack pattern of the era they’re supposedly securing are selling you a label, not a solution.Audit your retrieval pipelines for all three legs: Don’t just ask “is this agent secure?” Ask: does it have access to private data? Does it ingest untrusted content? Can it send information outside your environment? If the answer to all three is yes, you have a live trifecta, regardless of what security tooling is layered on top.Treat data lineage as a security control: Provenance isn’t a compliance checkbox. It’s the mechanism that lets you distinguish a legitimate record from a poisoned one. If you can’t attribute data to a trusted source and trusted writer, you cannot cut the untrusted-content leg, full stop.Think structurally, not just defensively: Prompt filtering is necessary. It is not sufficient. The durable fix is architectural: enforce least privilege at the data layer, segment agent capabilities, and make exfiltration paths explicit so you can govern them.Zero trust taught us never to assume. The lethal trifecta is what assumption looks like when we forget. Let’s not forget.Learn how Zscaler closes the enforcement gap to prevent prompt injection.&nbsp;]]></description>
            <dc:creator>Claude Mandy (Chief Evangelist)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Autonomously Hide, Segment, and Shield: Private App Defense for the AI Era]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/autonomously-hide-segment-and-shield-private-app-defense-ai-era</link>
            <guid>https://www.zscaler.com/blogs/product-insights/autonomously-hide-segment-and-shield-private-app-defense-ai-era</guid>
            <pubDate>Fri, 24 Jul 2026 13:42:52 GMT</pubDate>
            <description><![CDATA[Attackers don’t need more zero-days. They need time. Frontier AI just gave it back to them by compressing the work it takes to find targets, map paths, and turn weaknesses into breaches. If your defense still assumes you’ll be able to patch before they act, you’re defending yesterday’s timeline. Frontier AI Changed the Economics of Attacking ApplicationsFrontier AI did not invent exploitation. It changed the cost of it.&nbsp;A lot of what used to slow attackers down, like reconnaissance, pathfinding, testing variations, and chaining smaller weaknesses into impact, can now be automated and repeated at scale. That shift matters because most enterprises still defend application risk with an operating model built for a slower cycle:&nbsp;Find the issuePrioritizePatch&nbsp;Add compensating control when things get urgentThat playbook still matters, but frontier AI is compressing attacker timelines so aggressively that the gap between knowing and fixing has become a first-class attack surface.&nbsp; A Protection-First Operating Model: Hide Applications, Segment Access, Then Block the ExploitMost enterprises still run vulnerability responses like a fire drill. A critical issue drops, teams scramble to triage, figure out exposure, coordinate changes, and patch as quickly as they can. Meanwhile, attackers do not wait. They scan, probe, and iterate. AI makes that loop even tighter.So the real question becomes simple: What do you do in the window between “we know there’s a vulnerability” and “we fixed it”?The answer is not to bet everything on patch speed. Patching is essential, but it is also constrained by reality: uptime requirements, testing, dependencies, and change control. If your only plan is “patch faster,” you are committing to a race you cannot always win.What works better is a protection-first operating model that assumes the remediation window will exist and builds resilience around it:Hide the applications so it is harder to find and targetSegment application access so reachability stays limited to only those who are permitted&nbsp;Block exploitation inline&nbsp;so attempts fail while remediation catches upThat is how you fight frontier AI: reduce the attacker’s options, their ability to move, and the chance that any reachable weakness turns into a breach. Step 1: Hide Applications with ZPA&nbsp;Most organizations still have too many “private” applications that are not truly private. They may be behind a VPN or a firewall, but they are still discoverable to anyone who lands on the network or gets a foothold through a vendor connection, a compromised device, or stolen credentials.In a frontier AI world, that discoverability is a problem. AI makes it easier to enumerate targets and quickly determine what is worth attacking.Zscaler Private Access (ZPA) supports a different default: reduce exposure by making applications invisible to the internet and inherently harder to discover and harder to directly target.The practical outcome is that attackers have fewer obvious doors to knock on. They spend more time guessing and less time exploiting. Step 2: Segment Application Access with Autonomous User-to-App Segmentation&nbsp;Hiding helps, but it is not enough. Some access still has to exist. Users still need to get to critical apps, contractors still need limited access, and third parties still need to connect.This is where most environments break down. Once someone is “in,” they can often reach far more than they should. And once an attacker has reachability, frontier AI helps them do what attackers always want to do: move.Autonomous User-to-App Segmentation changes the shape of that problem by narrowing reachability to exactly what is required. Access becomes specific, intentional, and easier to govern over time.It helps you answer a question that matters more than ever: If an attacker gets a foothold, what can they reach next?Done well, segmentation turns “next” into “not much.” Step 3: Block the Exploit with Autonomous App ShieldEven with strong access controls, some applications must remain reachable. That is the business. And in a frontier-AI world, “reachable” can turn into “targeted” fast.This is exactly why we introduced&nbsp;Zscaler Autonomous App Shield. The customer and partner response at Zenith Live was a clear signal: teams are tired of treating application protection like a periodic project or an emergency workstream. They want protection that is continuous, intelligent, and fast enough to keep up with how attacks actually happen now.Autonomous App Shield is a fundamentally new approach to protecting private applications, built into the Zscaler platform customers already use. The idea is straightforward:&nbsp;your applications should be defended continuously, with protections that adapt as quickly as the applications and threats change.Here’s what makes it different in practice:It never stops looking. App Connectors continuously and safely assess private applications, their behavior, characteristics, and exposure points. Not a quarterly scan. Not an annual pen test. An always-current view of real risk that updates as fast as the application changes.It thinks before it protects. Instead of the “apply everything everywhere” approach that can hurt performance and flood teams with noise, the Zscaler cloud reasons about each application individually. It determines which protections that specific app actually needs, then applies only those.It learns from the whole world. Autonomous App Shield draws on global threat intelligence across Zscaler’s customer base. When a new technique shows up anywhere, including zero-day exploitation patterns, that insight can inform protections broadly. Defenses sharpen over time instead of going stale.It moves at the speed of your pipeline.&nbsp;When developers ship a new release, protection adapts automatically. No re-tuning sessions. No policy review meetings. No security team bottleneck between DevOps and production.The window between “vulnerability exists” and “vulnerability is protected” shrinks from weeks to moments, without waiting for a human workflow to catch up. In a negative time-to-exploit era, that is what it takes to fight AI with AI: autonomous defense that can discover, decide, and deploy at the same speed the adversary operates. Why This Operating Model Works Against Frontier AI&nbsp;Yes, you still want to patch fast. That will always matter. The problem is treating patch speed as the only reactive control, especially now that frontier AI can help attackers find, test, and iterate on exploits in parallel.This operating model works because it gives you a layered system that holds up even when remediation takes time:Hide applications (ZPA)&nbsp;so attackers have fewer targets to discover and fewer obvious places to start.Segment application access (Autonomous User-to-App Segmentation) so a foothold does not automatically become broad reachability or lateral movement.Block the exploit (Autonomous App Shield) so even when something is reachable and a vulnerability exists, exploit attempts are stopped while you fix the root cause.Patching closes the hole, but these layers reduce the odds an attacker can find it, reach it, or successfully exploit it in the first place. That’s how you stay protected in the window between “we know” and “we fixed it,” even against AI-accelerated attackers.That layered approach is exactly what the Zscaler Lateral Threat Bundle brings together: reduce discoverability, reduce reachability, and reduce exploit success, using the platform you already rely on. To learn more about the Lateral Threat Bundle&nbsp;contact your sales representative.&nbsp;]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[How to Find Which ISP is Slowing Down Your Users]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/how-find-which-isp-slowing-down-your-users</link>
            <guid>https://www.zscaler.com/blogs/product-insights/how-find-which-isp-slowing-down-your-users</guid>
            <pubDate>Wed, 22 Jul 2026 22:19:42 GMT</pubDate>
            <description><![CDATA[Every network operations team eventually faces the same scenario: a wave of tickets from users in one region complaining that "everything is slow." Your internal network looks healthy, your monitoring tools show green, and yet users are frustrated. The problem is almost always somewhere you can't directly see — a last-mile ISP, a transit carrier, or a routing change at a peering point.This is the core problem ZDX Network Intelligence was built to solve. In this post, we'll walk through exactly how to identify which ISP or specific hop is responsible when user experience degrades. Why traditional tools can't answer "which ISP?"Network monitoring tools were designed for a world where IT controlled the network end-to-end. In that world, you could see every link, every router, and every hop traffic crossed. In today's world — hybrid workforces, SaaS apps, zero trust architectures — that's no longer how traffic flows.Most user traffic now leaves the corporate perimeter immediately and traverses networks you don't own: the user's home ISP, an intermediate carrier, the SaaS provider's edge. Traditional network monitoring tools go silent the moment traffic leaves your control. Synthetic monitoring tells you a probe location can reach the app, but not whether your actual user can. Application monitoring tells you the app is performing, but not whether the path to it is.The result is what we hear constantly from NetOps teams: "We can prove our network is fine, but we can't prove anything else." How ZDX Network Intelligence sees what other tools can'tZDX takes a different architectural approach. Because ZDX is delivered through the Zscaler Zero Trust Exchange — the same cloud that secures user traffic — every user's session naturally flows through Zscaler's inline cloud. That gives ZDX a vantage point inside the user's actual path, not just at fixed probe locations.Every five minutes, the Zscaler Client Connector launches lightweight cloud probes that collect telemetry — latency, packet loss, jitter — along the user's exact route to each monitored application. Machine learning baselines this data continuously and flags deviations. The result is end-to-end visibility from the user's device, across last-mile ISPs and intermediate ISPs, through the Zscaler cloud, to the destination application.Step 1: Identify where the problem is concentratedWhen tickets start coming in, the first question is whether the problem is widespread or localized. Open the ZDX Network Intelligence dashboard for a global view of network performance. Routes are color-coded by severity — red for critical, yellow for minor — so problem areas are visible at a glance.Filter by region, department, or location to narrow the scope. If users in São Paulo are reporting slowness but users in Frankfurt aren't, you've immediately confirmed it's a regional issue rather than a global one — and you can stop wasting time investigating systems that don't matter.Step 2: Drill into BGP Autonomous SystemsOnce you've localized the problem, the next question is which ISP or carrier is involved. ZDX aggregates probe telemetry by BGP Autonomous System Number (ASN), which is how the internet actually organizes itself. Each ISP, transit carrier, and major network operates one or more ASNs.Click into the affected region and ZDX shows you the BGP ASNs your users' traffic is crossing. Each ASN displays its observed latency, packet loss, and contribution to user experience scores. The ASN at the top of the latency chart is your suspect.For example, if users in São Paulo show heavy latency on a transit carrier's ASN that they don't normally cross, you've found the routing change that's causing the problem.Step 3: Drill into specific hops and routersASN-level analysis tells you which carrier; hop-level analysis tells you which specific routers and links inside that carrier are the problem. ZDX lets you drill from BGP AS down to individual hops within that AS, showing per-hop latency and packet loss.This is where the investigation gets concrete. You might find that a single peering point between two carriers is dropping 8% of packets, or that a specific router is adding 90ms of unexpected latency. With this level of detail, you have evidence to escalate to the carrier with — not just a complaint that "something is slow."Step 4: Use Peer Impact Analysis to confirm scopeBefore escalating to a carrier, you want to know: is it just my organization affected, or are others seeing the same thing? ZDX Peer Impact Analysis answers this directly. It shows whether other Zscaler customers traversing the same ISP path are experiencing the same anomaly.If the dashboard shows three other Zscaler customers on that link are affected, the issue is widespread and external. You have strong evidence the carrier is the source — not your network, not your security stack, not the application. That changes the conversation completely. Instead of arguing internally about whose fault it is, you have data to go to the carrier with.This is a capability unique to ZDX. No other DEM tool can give you cross-customer visibility into shared internet paths because no other tool sits at this scale on the inline cloud.Step 5: Reroute through a better-performing pathZDX doesn't just diagnose — it gives you the data to fix the issue. Network Intelligence benchmarks packet loss and latency across the ISPs serving your users and highlights better-performing paths. With the data in hand, you can configure ZIA to route users to a better-performing Zscaler data center, bypassing the underperforming ISP.This is one reason customers report up to 98% faster issue detection and resolution with ZDX — because finding the issue and fixing it happen on the same platform, in the same workflow. A real example: Careem's NetOps workflowCareem operates across 14 countries with thousands of remote customer service representatives. Before ZDX, when CSRs reported slowness, the NetOps team had to investigate manually — often spending hours determining whether the issue was internal or with the CSR's home ISP.CIO and CISO Peeyush Patel describes the change: "Using ZDX we can rule out our network in minutes and focus the CSR's attention on their internet connectivity issue. Sometimes, we can suggest settings that will help. On other occasions, we can empower individuals to get a resolution from their ISP by providing them with information generated by ZDX, including intuitive visual diagrams and reports."The result for Careem: a 62% reduction in mean time to resolve, supporting a doubling of the customer service workforce on the same InfoSec team. Set custom alerts for proactive detectionThe five steps above describe reactive investigation — what to do when tickets come in. The bigger ROI of Network Intelligence is proactive detection. Set custom alert thresholds for latency, packet loss, or ZDX Score deviation, and ZDX notifies you when ML-baselined behavior shifts before users notice.Alerts route to email, IM, ServiceNow, and other ticketing systems via webhook, so they slot into the workflow your NetOps team already runs. What's nextIf you found this useful, check out the&nbsp;ZDX webpage for more information on deeper capabilities, including multipath visualization, real user monitoring, and Device Score and Remediation.&nbsp;See Network Intelligence in action against your own environment.]]></description>
            <dc:creator>Cynthia Tu (Sr. Product Marketing Manager, DEM)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Extending Zero Trust to the Browser: A New Frontier for Enterprise Security]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/extending-zero-trust-browser-new-frontier-enterprise-security</link>
            <guid>https://www.zscaler.com/blogs/product-insights/extending-zero-trust-browser-new-frontier-enterprise-security</guid>
            <pubDate>Fri, 17 Jul 2026 16:57:36 GMT</pubDate>
            <description><![CDATA[Every major shift in enterprise technology has forced security to evolve. Mainframes centralized control. Client-server architectures pushed security toward the endpoint. Cloud and SaaS transformed the network into a policy enforcement point, while the rise of hybrid work made identity foundational to modern security.Today, another shift is underway. The browser has become the central hub of productivity and a critical new frontier for enterprise security.Employees use browsers to authenticate, collaborate, access business-critical applications, interact with generative AI (GenAI), and handle an organization's most sensitive information. What was once simply a window to the internet has quickly and quietly become one of the primary places where work happens.That does not make the network, the endpoint, identity, or application security any less important. It makes the security architecture around modern work more important.The browser does not operate in a silo. Every interaction depends on the infrastructure around it: the connection that delivers the application, the identity and posture of the user and device, the content that reaches the browser, the code that executes within it, and the data moving through each session. Each creates a different security challenge, and no single control can address them all.As the browser becomes more central to how work gets done, Zero Trust must extend deeper into it while strengthening the layers around it. A Growing Attack SurfaceAttackers have always followed wherever work goes. As applications moved to the cloud, attackers shifted their focus from data centers to SaaS. As work expanded beyond corporate offices, they adapted to distributed users and unmanaged devices. Today, as more work happens through the browser, attackers are evolving again.The rise of GenAI is accelerating this shift. Employees are not simply consuming information in the browser anymore. They are creating it, transforming it, and sharing it through browser-based AI applications. Every prompt, upload, and response creates new considerations for security and data protection.At the same time, the browser itself presents a uniquely challenging environment to secure. Modern browsers are among the most complex software platforms ever built, often compared in complexity to operating systems. They execute code from constantly changing and often untrusted sources, manage identities and authenticated sessions, support extensive ecosystems of extensions, render dynamic applications, and increasingly mediate interactions with AI.Attackers are taking advantage of that complexity. Adversary-in-the-middle attacks can hijack authenticated sessions. Browser-in-the-browser techniques can manipulate users with convincing fake interfaces. Malicious extensions and client-side attacks can operate inside the browser, where traditional network and endpoint controls may have limited visibility.This does not mean existing security controls have become obsolete. Quite the opposite. It means modern enterprises need defense in depth more than ever.The goal is not to move security from the network into the browser. It is to extend security all the way into the browser. Modern Browser Security Requires Defense in DepthThe industry's growing focus on browser security is encouraging. Enterprise browsers are emerging. Browser extensions have evolved into meaningful security controls. Browser isolation continues to mature, and browser-native protections for AI and web-based threats are advancing rapidly.But these technologies should not be viewed as competing answers to the same question. They solve different parts of a much larger problem.Modern browser security begins before content ever reaches the browser. Known threats, malicious destinations, and clearly suspicious activity should be stopped upstream through cloud-delivered security and advanced threat protection. Content that cannot be fully trusted should be isolated so active web content cannot directly reach the endpoint. And because sophisticated attacks can still emerge inside the browser itself, organizations need browser-native visibility and protection to detect what may evade upstream controls.These layers are complementary, not optional alternatives.At Zscaler, this defense-in-depth approach starts with&nbsp;Zscaler Internet Access (ZIA) and advanced threat protection to stop known threats and suspicious activity before they reach the user. Our Cloud Browser Isolation capabilities provides another layer of defense for questionable destinations, high-risk content, and sensitive applications by separating active web content from the endpoint. And our&nbsp;industry-first Browser Detection and Response (BDR) extends detection, investigation, and response into the browser itself, helping identify browser-native attacks that traditional network and endpoint tools were never designed to see.Each layer addresses a different point in the attack path. Together, they provide protection before content reaches the browser, while it is being rendered, and as the user interacts with it.That is what defense in depth should look like for the modern web. Securing the Browser and Securing Access Through ItThere is another important distinction that is often lost in the browser security conversation.Securing the browser itself and securing access to enterprise applications through the browser are related challenges, but they are not the same problem.The first is about protecting the browser as an execution environment. Organizations need to protect users from malicious content and browser-native attacks, detect suspicious extensions and client-side activity, and control how sensitive data is handled. This is where cloud-delivered threat prevention, isolation, browser-native protection, and in-browser data controls work together.The second challenge is about connectivity and access.When a user opens a private enterprise application in a browser, the browser is ultimately the rendering engine. The more fundamental security question is whether that user and device should be connected to the application in the first place.This is where Zero Trust Network Access (ZTNA) becomes critical.With&nbsp;Zscaler Private Access (ZPA), users connect directly to authorized applications based on identity, device posture, policy, and context without being placed on the network or exposing the application to the internet.&nbsp;Privileged Remote Access extends this model to sensitive administrative and third-party access, helping organizations provide secure access without the complexity and risk of traditional network-based approaches.Once access is granted, browser controls can add another layer of protection around the interaction itself. Sensitive data can be protected, risky actions can be controlled, and browser-native threats can be prevented.The distinction matters. ZTNA secures access to the application, while browser security protects the user’s interaction with the application and helps prevent the application itself from being exploited.&nbsp;Modern Zero Trust requires both. One Architecture, Multiple Ways to Secure the BrowserNo two enterprises have exactly the same users, devices, applications, or access requirements. Even within a single organization, the right browser experience can vary significantly by user and use case.That is why we did not begin with the assumption that every customer should adopt the same browser. We began with the principle that every customer should be able to extend Zero Trust into the browser in the way that best fits the business.That philosophy is reflected in Zscaler’s&nbsp;Zero Trust Browser, which can be deployed in three ways, depending on what best fits the customers needs: Cloud Browser Isolation, Browser Extension, and Enterprise Browser.The Zero Trust Cloud Browser Isolation provides a powerful layer of protection for high-risk web content, sensitive cloud applications, unmanaged devices, and other scenarios where active content should be separated from the endpoint.For organizations that want to extend protection into the browsers employees already use, the Zero Trust Browser Extension brings browser-native security directly into the existing user experience. With industry-first Browser Detection and Response (BDR), organizations gain another line of defense inside the browser to detect and respond to threats that may evade upstream network and endpoint controls.And for organizations or user populations that require a fully managed browsing environment, the Zero Trust Enterprise Browser provides a purpose-built Chromium browser with Zero Trust security integrated into the experience. It gives customers another powerful option for securing modern work without requiring them to build a separate security architecture around the browser.These form factors are not about forcing an enterprise to choose a single approach for every user. An organization may use isolation for one workflow, browser extensions for its broader workforce, and a purpose-built enterprise browser for specific users or use cases.The form factor can change. The security architecture should work together. The Power of Zscaler's Zero Trust ArchitectureThis is where we believe the browser security conversation needs to go next.The future will not be defined by one security control replacing another. Network security does not become less important because the browser has become more important. ZTNA does not become less important because organizations deploy browser-native controls. An enterprise browser does not eliminate the need to stop threats before they reach the user.Each layer has a distinct job to do.Zscaler Internet Access and advanced threat protection stop known threats and suspicious activity before they reach the browser. Cloud Browser Isolation contains content that should not be trusted. Browser Detection and Response, delivered through our Browser Extension and Enterprise Browser, provides visibility and protection inside the browser against threats that can evade upstream controls. Zscaler Private Access provides Zero Trust connectivity to private applications without exposing them to the network. Data protection helps safeguard sensitive information as it moves across applications and through user interactions. And the Enterprise Browser provides a purpose-built, fully managed experience for the users and use cases that need it.The value is not simply in having each of these capabilities.The value is in how they work together.Modern enterprises are a mix of cloud and legacy applications, managed and unmanaged devices, employees and third parties, internet and private application access, and increasingly, human and AI interactions. Security architectures must be able to protect that complexity without forcing every user, application, or workflow into the same model.Security should adapt to the enterprise, not force the enterprise to adapt to security. The Next Chapter of Zero TrustWe are excited about the availability of the Zero Trust Enterprise Browser because it represents an important expansion of how customers can extend Zero Trust to modern work.But the larger story is not about adding another browser to the market.The browser is a critical new frontier for enterprise security, and securing it requires defense in depth. Threats must be stopped before they reach the user. Questionable content must be isolated. Attacks that emerge inside the browser must be detected and stopped. Private applications must be protected with Zero Trust connectivity. Sensitive data must remain protected throughout the interaction.No single control can do all of this alone.The next chapter of Zero Trust is not about replacing the security architecture that came before the browser. It is about extending that architecture further, from the network and the application all the way to the browser interaction itself.That is the future we are building toward.Every layer doing the job it does best.Every layer working together.And Zero Trust extending wherever work happens.To learn more about Zscaler’s Zero Trust Browser, visit our&nbsp;website or&nbsp;contact your sales representative.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Standardizing SSL Key Logging: A Step Forward for Secure Diagnostics]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/standardizing-ssl-key-logging-step-forward-secure-diagnostics</link>
            <guid>https://www.zscaler.com/blogs/product-insights/standardizing-ssl-key-logging-step-forward-secure-diagnostics</guid>
            <pubDate>Thu, 16 Jul 2026 07:39:11 GMT</pubDate>
            <description><![CDATA[Transport Layer Security (TLS) is the backbone of secure communications on the modern Internet. But as with any secure system, diagnostics and observability remain critical, especially when troubleshooting complex failures in encrypted traffic. For years, developers and analysts have relied on a loosely defined environment variable, SSLKEYLOGFILE, to capture session secrets for use in tools like Wireshark. While powerful, this practice has long lacked a formal specification. This created ambiguity, interoperability challenges, and, most concerningly, opportunities for misuse. That is now changing. From Convention to Standard: Formalizing SSLKEYLOGFILE The IETF TLS working group has completed work on a new specification, now published as RFC9850, titled&nbsp;"The SSLKEYLOGFILE Format for TLS". This document defines a consistent, machine-readable format for logging key material used in TLS connections. It introduces a standard structure, explicit labels, and even provisions for future extensibility through a new IANA registry. Historically, the SSLKEYLOGFILE convention emerged without a clear formal definition. Implementations varied in how they handled line formats, which secrets were emitted, and how tools consumed them. This lack of consistency created friction during cross-platform diagnostics and limited support for newer TLS capabilities. By standardizing the format, this new specification improves interoperability across implementations, reduces ambiguity for tooling, and introduces guardrails that are especially critical as TLS evolves. Designed for the Future: Supporting ECH and Extensibility One of the key advantages of the new format is its support for emerging features like Encrypted Client Hello (ECH). ECH is a major step toward improving privacy in TLS, encrypting sensitive metadata previously exposed in plaintext. Supporting ECH in diagnostic tooling requires precise, up-to-date key export mechanisms, something ad hoc conventions could not reliably provide. The introduction of an IANA registry for key log line labels is another noteworthy development. As TLS continues to evolve, this registry enables future additions (such as new key types, protocol variants, or session metadata) to be integrated cleanly, without breaking existing tools or requiring bespoke conventions. Diagnostic standards must keep pace with protocol innovation, and this design reflects that imperative. The Dual Edge of Diagnostics: Visibility vs. Exposure While the ability to log TLS secrets is essential for deep traffic diagnostics, it also represents a significant security risk. Once exported, these secrets allow for full decryption of encrypted sessions. It’s a powerful capability that, if misused, undermines the core confidentiality guarantees of TLS. Unfortunately, such misuse is not theoretical. There are well-documented cases where SSLKEYLOGFILE was inadvertently left enabled in production systems, causing session keys to be written to disk, sometimes in environments with lax access controls. In more troubling cases, the mechanism has been used deliberately to extract sensitive data by insiders or malicious actors. Organizations need visibility, but they also need safeguards. Zscaler's Approach: Detecting Dangerous Diagnostics At Zscaler, we recognize the importance of diagnostic tools and the critical need to secure them. Our Data Loss Prevention (DLP) technology is uniquely positioned to identify and respond to the misuse of key logging mechanisms, both in data at rest and in data in motion. On user endpoints, Zscaler endpoint DLP can detect contents that match the standardized SSLKEYLOGFILE structure, including legacy and newly standardized formats, even when obfuscated or renamed. This helps security teams catch misconfigurations early or detect attempts to exfiltrate key material for malicious use. Zscaler's Data Security Posture Management (DSPM) extends this protection to cloud environments and on-premises storage. By scanning data stored across SaaS platforms, public cloud and on-premises storage, DSPM can identify files containing TLS session secrets, regardless of naming conventions or file type. This enables security teams to locate and remediate sensitive diagnostic artifacts that may have been uploaded to collaborative environments or left unintentionally exposed in cloud storage. To further reduce risk, Zscaler's in-line DLP engine natively integrated into our cloud proxy monitors traffic in real time. It can detect outbound transfers of SSLKEYLOGFILE entries via file uploads and other web and non-web exfiltration channels including email. When such transfers are detected, policies can be enforced to block the action, alert administrators, or initiate an investigation workflow. Together, these capabilities form a layered defense against the accidental or malicious exposure of TLS session keys ensuring that powerful diagnostic mechanisms remain under organizational control and are never turned into a threat vector. A Model for Secure Observability The formalization of SSLKEYLOGFILE is more than just a housekeeping exercise. It exemplifies a broader principle: that standards should extend not only to protocols, but also to how we observe and debug them. In a world increasingly dependent on encrypted transport, secure diagnostics are essential, and they must be done responsibly. Zscaler supports this evolution. We believe organizations should embrace standard diagnostic practices and adopt detection and prevention strategies to ensure those tools are not turned against them.]]></description>
            <dc:creator>Yaroslav Rosomakho (Chief Scientist)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Empower Security Teams to See More and Respond Faster to Modern Threats with Zscaler Endpoint Context]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/empower-security-teams-extend-visibility-endpoint-context</link>
            <guid>https://www.zscaler.com/blogs/product-insights/empower-security-teams-extend-visibility-endpoint-context</guid>
            <pubDate>Wed, 15 Jul 2026 23:29:35 GMT</pubDate>
            <description><![CDATA[Modern security operations teams are under pressure from every direction: Attacks are moving faster, adversaries are blending into normal activity more effectively, and defenders are being asked to make better decisions with less time and less certainty. Adding to that challenge is a growing new threat vector: AI-assisted attacks.Threat actors are already using AI to improve the speed, scale, and sophistication of their campaigns. One of the most visible examples is AI-generated malware and script development, where attackers use AI tools to:Accelerate code creationModify payloadsRefine phishing kitsGenerate variants designed to help evade traditional detection methodsCombined with common tactics like abusing legitimate system tools or introducing threats via USB, Bluetooth, or AirDrop, AI provides attackers new ways to expand reach while reducing effort.For network and security operations professionals, it’s no longer enough to see that a suspicious connection occurred or that a firewall event was triggered.&nbsp;Security teams need to know what on the endpoint actually caused that network activity. A trusted browser? An unsigned binary?&nbsp;A vulnerable application? A suspicious process using legitimate system tools to hide malicious intent?This is the problem Zscaler Endpoint Context solves: it enhances security efficacy by bringing together endpoint, network, identity, and cloud telemetry to reveal the application and process behind endpoint activity.&nbsp;By extending endpoint intelligence into the Zscaler Zero Trust Exchange, it helps organizations improve visibility, enrich detections, strengthen policy enforcement, and accelerate incident response. For operations teams, that means fewer blind spots, faster investigations, and more confidence in deciding what should be trusted—and what should not. Why Endpoint Context Matters NowSecurity teams have long had access to network logs, DNS activity, firewall alerts, and web traffic events. But those signals alone often don’t tell the full story. In many cases, teams can see traffic leaving the endpoint without seeing the process, application, code-signing status, or risk profile behind it.That lack of context slows down investigations and creates opportunities for attackers to hide in plain sight. Fileless techniques, living-off-the-land activity, trojanized applications, and suspicious scripts often look benign at the network layer until endpoint context is added. Without that deeper view, analysts are forced to pivot manually across multiple tools just to answer a simple question:&nbsp;What generated this traffic?Zscaler Endpoint Context closes that gap with richer intelligence about the applications running on endpoints and makes that context actionable across investigation, response and policy.&nbsp; Deep application visibility across endpointsZscaler Endpoint Context provides detailed visibility into applications on supported endpoints, including Windows and macOS systems. It helps teams identify what is running in the environment and assess whether that software should be trusted.Key details include:Application and product nameNumber of devices where the application appearsFile hash information such as SHA256Code-signing certificate statusVersion detailsParent directory or path informationRisk and threat classificationVulnerability information, including CVEsFor security teams, this helps reveal vulnerable, unsigned, suspicious, or unmanaged software that might otherwise go unnoticed. Context-aware policy enforcement across the Zero Trust ExchangeA major strength of Zscaler Endpoint Context is that it does more than improve visibility. It also helps organizations act on that visibility.Endpoint-derived intelligence can inform policy decisions across security controls such as:TLS/SSL inspection and policyZero Trust FirewallDNS securityIntrusion preventionAdvanced Threat ProtectionThis allows teams to move from broad, static controls to more adaptive enforcement based on the application behind the activity. For example, security teams can differentiate trusted application behavior from suspicious process-driven traffic and apply policy accordingly. More granular detections with application and process contextThe addition of endpoint context makes detections more useful and more actionable. Instead of seeing only a network event, analysts can understand the process and application details behind it.Enriched context can include:Application nameApplication typeThreat typeApplication risk levelCode-signing statusParent pathCommand-line argumentsExecution-related identifiersThis helps analysts quickly determine whether activity is associated with legitimate software, a trojanized application, a suspicious script, or an abused native tool. Enriched logging for SIEM and SOC workflowsZscaler Endpoint Context also strengthens downstream operations by enriching security logs and making that data available for analysis and automation. Zscaler Nano Streaming Service (NSS) can feed enriched data into log workflows, including web, firewall, and DNS logs, as well as application inventory-style telemetry.This gives SOC teams several advantages:Less manual pivoting during investigationsBetter correlation between endpoint and network eventsMore effective detections in SIEM platformsImproved SOAR automation with richer fieldsFaster mean time to detect and respondFor mature security programs, this operational efficiency is a major benefit. Block Out-of-band File-based Threats with Cloud SandboxModern threats do not always arrive through standard inline inspection paths. Files can enter the environment through:USB devicesBluetoothAirDropOther local or removable media channelsCustomers with Advanced Cloud Sandbox help address monitor for and eliminate the blind spots out-of-band file transfers can create. Unknown files introduced through these channels can be intercepted and analyzed before they are allowed to execute or move freely.This is important because many organizations have invested heavily in inline protection while still facing risk from local or offline file introduction points. JA4 Fingerprinting for Unmanaged DevicesBy using TLS fingerprinting techniques, Zscaler can help identify devices and applications, improve anomaly detection, and strengthen visibility even when an endpoint agent is not available. This extends security value to environments where conventional endpoint controls are difficult or impossible to deploy.JA4 fingerprinting improves visibility and detection for unmanaged assets such as:IoT devicesOT systemsBYOD endpoints Empower your security operations to be more effectiveZscaler Endpoint Context links endpoint processes to network activity, a critical capability as attackers use AI to enhance threats. By correlating endpoint, network, identity, and cloud data, it complements EDR/XDR solutions to fill visibility gaps.This context allows security teams to see the application behind every connection, assess its risk, and make smarter real-time decisions. Teams get the intelligence needed to strengthen protection across all endpoints, detect threats faster, and enforce policies with greater precision.Learn more:&nbsp;schedule a demo with our product experts today.]]></description>
            <dc:creator>Brendon Macaraeg (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[When Attackers Wield Frontier AI: How to Keep Your Private Apps Unbreachable]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/when-attackers-wield-frontier-ai-how-keep-your-private-apps-unbreachable</link>
            <guid>https://www.zscaler.com/blogs/product-insights/when-attackers-wield-frontier-ai-how-keep-your-private-apps-unbreachable</guid>
            <pubDate>Wed, 15 Jul 2026 20:36:44 GMT</pubDate>
            <description><![CDATA[Autonomous Application Shield helps protect private applications during the gap between vulnerability disclosure and patching by continuously assessing exposure and automatically applying app-specific protections in the Zscaler cloud.What you get:Reduce exposure time&nbsp;Stop one-size-fits-all policy noiseStay protected as apps changeFor decades, application security has rested on a single, unspoken assumption: when a vulnerability is disclosed, defenders get a head start. Time to triage, time to test, time to patch. That grace period shaped every scanner, every ticketing workflow, every patch-Tuesday ritual in the industry.That assumption is now dead&nbsp; and we have the data to prove it.According to Mandiant's M-Trends 2026 report, the mean time to exploit a vulnerability has fallen to&nbsp;negative seven days. Read that again. On average, attackers are now exploiting vulnerabilities&nbsp;before a patch publicly exists. In 2018, defenders had roughly 63 days between disclosure and exploitation. By 2024, that window had collapsed to zero. Today, it has inverted entirely. Exploits remain the number one initial infection vector for the sixth consecutive year.This is not a gradual trend defenders can outrun with better process. It is a structural break and AI caused it. The AI Inflection PointFrontier AI models have fundamentally changed the economics of exploitation. In order to craft exploits it used to require elite skills, expensive tooling, and weeks of manual effort, all of it is now available to anyone with a subscription and a few dollars of compute. Modern models can analyze a newly disclosed CVE, understand the vulnerable code path, generate a working exploit, and even&nbsp;chain multiple vulnerabilities together into sophisticated attack sequences in hours, not weeks. The barrier to entry hasn't just dropped. It has evaporated.Some of this acceleration was underway before LLMs emerged using exploit kits and commercial vulnerability research had been compressing timelines for years. But AI turned a trickle into a flood. Every organization running private applications is now facing an adversary population that is larger, faster, and cheaper to equip than at any point in history.Meanwhile, the defender's side of the equation hasn't moved. Enterprise patch cycles still run on human timelines which includes testing windows, change control boards, maintenance schedules. The median enterprise needs weeks to patch even critical, known-exploited vulnerabilities. When exploitation happens at machine speed and remediation happens at meeting speed, the math simply doesn't work.Patching remains necessary. But it can no longer be sufficient. A Market Waking Up to the ProblemThe application security market senses this shift. Organizations have invested heavily in scanners, code analysis, and vulnerability management platforms and yet those investments share a common architecture:&nbsp;find the problem, file a ticket, wait for a human. Every one of those tools ends its job precisely where the real race begins.At the same time, the applications themselves are moving faster than ever. CI/CD pipelines push changes daily. New APIs appear with every sprint. Configurations drift. Each release quietly reshapes the attack surface, and static security policies, the one-size-fits-all protection profiles most organizations rely on,&nbsp; fall further behind with every deployment.The result is a widening gap between two speeds: the speed at which risk is created, and the speed at which protection is applied. Closing that gap is the defining application security challenge of the AI era. It cannot be closed by hiring more analysts or running more scans. It can only be closed by making protection itself autonomous.That is exactly what we built. Introducing Zscaler Autonomous Application ShieldAt Zenith Live, we announced Autonomous Application Shield and the response from customers and partners told us everything about how urgently this problem needs solving.Autonomous Application Shield is a fundamentally new approach to protecting private applications, built directly into the Zscaler platform you already use. The concept is simple to state and profound in its implications:&nbsp;your applications should be defended continuously, intelligently, and at machine speed.Here's what makes the technology genuinely exciting:It never stops looking: App Connectors continuously and safely assess your private applications, their behavior, their characteristics, and their exposure points. Not a quarterly scan. Not an annual pen test. A living, always-current understanding of every application's actual risk profile, updated as fast as your applications change.It thinks before it protects. Rather than blasting every application with every available control, the "apply everything everywhere" approach that degrades performance and drowns teams in false positives, the Zscaler cloud reasons about each application individually. It determines which protections&nbsp;this specific application actually needs, and applies only those. Stronger security and better application performance, from the same decision.It learns from the whole world. Autonomous Application Shield draws on global threat intelligence from across Zscaler's worldwide customer base. When a new attack technique emerges anywhere including zero-day exploitation that insight flows into the protection engine everywhere. Machine learning continuously tunes policies against each application's observed traffic and attack telemetry, so defenses sharpen over time instead of going stale.It moves at the speed of your pipeline. When your developers ship a new release, protection adapts automatically. No re-tuning sessions, no policy review meetings, no security team bottleneck standing between DevOps and production. Security evolves as rapidly as the applications it protects.The net effect: the window between "vulnerability exists" and "vulnerability is protected" shrinks from weeks to moments without a human in the loop, and without a patch in sight.Identify - Detect - Respond - Protect in a matter of minutes!&nbsp; Fighting AI with AIThe uncomfortable truth of the negative-Time-to-Exploit era is that human-speed defense has been structurally outpaced. The only credible answer to AI-accelerated attacks is AI-driven, autonomous protection defense that discovers, decides, and deploys at the same speed the adversary operates.That's not a distant vision. It's shipping. Join the Early Access ProgramAutonomous Application Shield is now open for early access, and spots are limited. To learn more, register for our latest webinar. Early access customers get hands-on experience with the technology, direct input into the roadmap, and a head start on an entirely new security operating model.The patch window has inverted. The organizations that thrive in what comes next won't be the ones that patch fastest, they'll be the ones whose applications defend themselves.Talk to your Zscaler representative today to request a demo and secure your place in the Early Access Program.]]></description>
            <dc:creator>Megha Tamvada (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Demystifying Key Exchange: From Classical ECDHE to a Post-Quantum Future]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/pqc-modern-cryptographic-key-exchange-deep-dive</link>
            <guid>https://www.zscaler.com/blogs/product-insights/pqc-modern-cryptographic-key-exchange-deep-dive</guid>
            <pubDate>Tue, 14 Jul 2026 23:25:37 GMT</pubDate>
            <description><![CDATA[In the digital world, the secure exchange of cryptographic keys is the foundation upon which all private communication is built. It’s the initial, critical handshake that allows two parties, like a user’s browser and a web server, to establish a shared secret and communicate securely over the untrusted expanse of the internet.As the quantum computing era approaches, the very mathematics underpinning our traditional key exchange mechanisms are facing an existential threat. This spurred the development of new, quantum-resistant algorithms. This blog post provides a deep dive into how modern key exchange works, from the trusted classical methods to the emerging post-quantum standards, and explores how Zscaler leverages hybrid key exchange to bridge the gap. The Components of Modern Key ExchangeAt a high level, a secure key exchange protocol must achieve the following:Confidentiality:&nbsp;&nbsp;The established key must be a secret shared only between the two communicating parties. An eavesdropper should not be able to determine the key.Authentication: In many cases (like with TLS), the parties must be able to verify each other's identity to prevent man-in-the-middle attacks. This is typically handled by digital certificates and is complementary to the key exchange itself.Forward Secrecy: The compromise of a long-term secret (like a server's private key) should not compromise the security of past session keys. This ensures that previously recorded encrypted traffic cannot be decrypted. Classical Key Exchange: The Reign of ECDHEFor the better part of a decade, the gold standard for key exchange on the web has been&nbsp; Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). It is a cornerstone of Transport Layer Security (TLS) and is responsible for securing trillions of connections daily. How Key Exchange Works:The Foundation: Elliptic Curve Cryptography (ECC): Instead of using very large prime numbers like traditional Diffie-Hellman, ECDHE uses the mathematical properties of elliptic curves. ECC offers the same level of security as older methods but with significantly smaller key sizes, making it faster and more efficient—a crucial advantage for mobile and IoT devices.The Handshake: Both the client and the server agree on a common elliptic curve and a starting point on that curve (the "generator").The "Ephemeral" Nature: This is where forward secrecy comes from. For each new session, both the client and server generate a new, temporary (ephemeral) key pair consisting of a private key (a random number) and a public key (a point on the curve).The Exchange:&nbsp;The client and server exchange their public keys.The Shared Secret:&nbsp;Each party then uses its *own* private key and the *other* party's public key to perform a calculation. Due to the magic of elliptic curve mathematics, both the client and the server independently arrive at the exact same point on the curve—this becomes their shared secret.Session Encryption: This shared secret is then used to derive the symmetric encryption keys that will encrypt all data for the remainder of the session.Even if an attacker were to steal the server's long-term private key years later, they could not use it to derive the ephemeral session keys from past traffic. The Quantum Threat and Post-Quantum Key Exchange: ML-KEMThe security of ECDHE relies on the difficulty of the "elliptic curve discrete logarithm problem." For a classical computer, this is an incredibly hard problem to solve. But for a sufficiently powerful quantum computer, Shor's algorithm&nbsp; makes it trivial because it can factor large integers into prime numbers with extreme efficiency.This has led to a new field of cryptography:&nbsp;Post-Quantum Cryptography (PQC). The goal is to create algorithms that are secure against attacks from both classical and quantum computers.After a multi-year competition, the U.S. National Institute of Standards and Technology (NIST) selected a suite of algorithms for standardization. For key exchange, the primary choice is the&nbsp;Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM), formerly known as CRYSTALS Kyber. How Key Encapsulation Mechanism (KEM) Works:Unlike the interactive exchange in Diffie-Hellman, a KEM works slightly differently:The server generates a public and private key pair based on the mathematical difficulty of problems in crystal-like structures called lattices.The server sends its public key to the client.The client uses the server's public key to generate two things: a shared secret and a "ciphertext" that encapsulates (or wraps) that secret.The client sends this encapsulating ciphertext back to the server.The server uses its private key to "decapsulate" the ciphertext, revealing the exact same shared secret that the client generated.Now both parties have the secret, and an eavesdropper, even one with a quantum computer, cannot solve the underlying lattice math to discover it. The Real World: Hybrid Key Exchange (ECDHE + ML-KEM)We are in a transitional period. While powerful quantum computers are not yet widely available, the threat of "harvest now, decrypt later" is very real: adversaries can record sensitive encrypted data today and store it, waiting for the day they have access to a quantum computer to break it.To counter this, the industry is moving towards a hybrid approach. Zscaler has implemented this by combining the battle-tested classical algorithm with a next-generation post-quantum one.How Zscaler's Hybrid Implementation Works:Zscaler’s Zero Trust Exchange acts as an intelligent switchboard for connections. When a client initiates a TLS connection, it sends a "ClientHello" message advertising its capabilities.Dual Key Generation: In a hybrid key exchange, the client and server perform&nbsp;both an ECDHE key exchange and an ML-KEM key encapsulation simultaneously.Two Secrets are Better Than One:&nbsp;This process results in two independent shared secrets: one from ECDHE and one from ML-KEM.Concatenation for a Single Master Key: These two secrets are then concatenated (combined end-to-end) to create the final master secret for the session.Deriving Session Keys: This robust, hybrid master secret is then used to derive the encryption keys for the session traffic.The security of this approach is immense. To break the encryption and read the data, an attacker would have to break&nbsp;both the classical ECDHE algorithm and the post-quantum ML-KEM algorithm. This "belt and suspenders" model provides a powerful guarantee: the connection is at least as secure as the classical cryptography we trust today, and it is also protected against the quantum threats of tomorrow. This allows organizations to safely transition to a post-quantum world without compromising on current security. Conclusion: Two Worlds, One GoalClassical key exchange is the workhorse of today, securing trillions of connections with proven, efficient software. But the road ahead will be a hybrid one. We can expect to see Post-Quantum Cryptography (PQC)—new algorithms resistant to quantum attacks—securing our communications and critical software-dependent transactions. For security and networking practitioners, understanding the new paradigm is no longer optional—it's essential for securing today’s data against future quantum-based attacks.Learn how Zscaler can help your organization prepare for the quantum future with our&nbsp;quantum resources or&nbsp; watch our on-demand webinar where our product experts walk you through how Zscaler uses hybrid key exchange in service of decrypting and inspecting quantum-encrypted traffic with ML-KEM.&nbsp;]]></description>
            <dc:creator>Brendon Macaraeg (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Prompt Injection Explained: How It Works, Why It Matters, and Practical Mitigations]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/prompt-injection-explained</link>
            <guid>https://www.zscaler.com/blogs/product-insights/prompt-injection-explained</guid>
            <pubDate>Tue, 14 Jul 2026 17:57:40 GMT</pubDate>
            <description><![CDATA[A prompt injection attack is a cyberattack that manipulates a generative AI (GenAI) system into following an attacker's instructions instead of its intended rules, because the model cannot reliably separate instructions from data written in natural language. It matters now because enterprises are connecting these models to tools, agents, and sensitive data, which turns a bad answer into an unauthorized action.&nbsp;Prompt injection is the defining GenAI risk: Unlike traditional injection attacks, there is no reliable way to separate trusted instructions from untrusted language inside a prompt.LLMs are uniquely susceptible: Attackers can influence model behavior not only through user input, but also through retrieved documents, web content, and other external data treated as context.Enterprise exposure amplifies the threat: When AI is connected to chatbots, RAG systems, developer tools, APIs, and autonomous agents, a single compromised prompt can lead to data exposure or unauthorized action.The business impact is immediate: Successful prompt injection can bypass policy, leak sensitive data, disrupt workflows, and erode customer trust.Defense requires layered controls: Because there is no single fix, organizations need governance, least-privilege access, content inspection, tool safeguards, and strong monitoring to reduce risk at every stage.&nbsp; What is prompt injection?Prompt injection is an attack where someone crafts input that causes a GenAI system to follow the attacker's instructions instead of the developer's intended rules. The model cannot distinguish legitimate instructions from malicious ones. That gap is the vulnerability, and the OWASP Top 10 for LLM Applications ranks it as the number one risk for large language model deployments.When prompt injection succeeds, consequences follow predictable paths:Policy bypass: This produces unsafe, off-limits, or misleading outputExposure of sensitive data: This happens when the model accesses sensitive data through its context or toolsUnauthorized actions: These get triggered through tool calls or agent workflowsPrompt injection vs. traditional injectionTraditional injection attacks exploit structured input fields and predictable syntax or categories where parameterized queries and output encoding provide reliable defenses. Prompt injection exploits natural language instead, which has no fixed grammar a parser can enforce, so those defenses don't apply.&nbsp;Prompt injectionTraditional injection (SQL, XSS)Attack surfaceNatural language input and any untrusted content the model processesStructured input fields with defined syntaxTargetModel behavior, tool calls, and agent actionsDatabase queries and application logicWhy it persistsNo parser can separate instructions from data in natural languageParameterized queries and input sanitization address most cases&nbsp;5 key termsThe comparison above explains why prompt injection sticks around. These are the specific patterns it produces:Jailbreak: A prompt designed to override a model's built-in safety constraintsPrompt leakage: An attack that extracts the model's system prompt, revealing developer-set policies and guardrailsData exfiltration: Any technique that causes the model to output sensitive information from its context or connected sources. This overlaps heavily with prompt leakage, the difference is usually just what gets pulled outTool and function abuse: Manipulating a model into calling external tools or APIs with altered parameters or unauthorized targetsIndirect injection (Trojan instructions): Malicious instructions hidden inside retrieved content the model processes as trustedMost real incidents combine two or three of these at once: an indirect injection that triggers a jailbreak, or a prompt leak that sets up more targeted tool abuse. The patterns behind every prompt injection attackEach pattern below targets a different point in the system, from a single conversation to a multi-step agent chain, and each needs a different detection and containment approach.Direct prompt injection: Attackers type payloads directly into the conversation (e.g., "ignore previous instructions") to override safety rules, aiming to generate banned content, expose hidden system prompts, or extract chat history.Indirect prompt injection: Attackers hide instructions in external resources the model retrieves (like web pages, emails, or RAG documents) to silently steal data, hijack the conversation mid-flow, or redirect users to malicious links.Tool and plugin abuse: Insecure system configurations, such as excessive tool permissions, missing endpoint restrictions, or lack of user confirmation, allow injected prompts to trigger unauthorized actions like file transfers or external API calls.Agentic abuse: Multi-step autonomous agents can carry a single injected instruction across an entire workflow. This risk is multiplied by broad system permissions, unsupervised web access, and a lack of human approval gates for critical actions. The places prompt injection shows up mostPrompt injection is not confined to one type of application. Any surface that accepts free text or pulls in untrusted content, whether typed by a user or retrieved automatically, carries the same underlying exposure.Chatbots: Customer-facing chatbots, internal productivity assistants, and HR or IT helpdesk bots all accept free-text input, making them natural targets for direct injection. Customer-facing bots carry the highest exposure, while internal bots see less traffic but often hold broader access to sensitive enterprise systems.RAG systems: Retrieval-augmented generation (RAG) pipelines pull documents into the model's context at query time, so a single poisoned knowledge base document gets treated as trusted content, producing confident, authoritative-sounding wrong answers, leaked snippets, and instructions that carry forward into later processing.Enterprise search and summarization: Email summarizers, meeting note generators, and document copilots process untrusted content at scale with minimal review, so one compromised email in a summarization batch can alter output or redirect users to malicious resources.Developer workflows: Code completion tools (GitHub Copilot, Cursor, Codeium), ticket summarization integrations (Jira, ServiceNow), and continuous integration/continuous delivery (CI/CD) assistants trust external content by default, so a poisoned code comment or crafted issue description can inject instructions that ship straight into production. What a successful attack actually costsPrompt injection creates four categories of business harm:Data loss and sensitive data exposure: Prompts, model responses, or tool calls can leak confidential information outside the organizationFraud and unauthorized action: Injected instructions can trigger tool calls, payments, or system changes that no one in the business approvedCompliance failure: PII, PCI, PHI, and other regulated data can move through AI systems without the controls, handling, or auditability those frameworks requireBrand and reputation damage: Public chatbot failures or customer-facing AI missteps can create visible trust issues and force the business to walk back harmful or inaccurate commitmentsWhat to log for investigationsBy the time a chain like this reaches its final stage, the damage is already done. Catching it early, ideally at the first step, where untrusted content enters the model's context, gives you more options. You can warn the user, block the tool call, or roll back before anything leaves the environment. None of that is possible without records showing what happened at each stage, in order.&nbsp;&nbsp;Every AI-enabled application should capture:User identity, application name, full prompt, and responseRetrieved sources for RAG queries with document identifiersTool calls with tool name, parameters, and destinationPolicy decision and enforcement action takenA single missing field, no retrieved-source ID on a RAG query, no destination on a tool call, is often the difference between closing an investigation in an afternoon and reopening it three times. Every gap logging surfaces has a matching control that closes it. Mitigation checklistThese seven domains correspond to where each attack pattern gets stopped.Control domainActionsGovernance and access controlsDefine which GenAI applications the organization sanctions and which it blocksApply role-based access with least-privilege principles to every AI toolLimit tool and plugin availability by group, restricting high-risk integrations to approved teamsPrompt and content controlsClassify prompts by risk level and enforce visibility policies on AI content flowsDetect and block high-risk patterns including jailbreak markers and exfiltration intentEnforce acceptable-use policies through content moderation on inputs and outputsData protection controlsInspect prompts and uploads inline using&nbsp;data loss prevention (DLP) before content reaches AI servicesBlock sensitive data exfiltration through response scanningApply redaction and tokenization for sensitive fields where full content is not requiredIsolation and containmentRoute risky GenAI interactions through&nbsp;browser isolation to prevent data leakage via copy, paste, and downloadBlock clipboard and file transfers to unsanctioned AI applicationsTool and agent safety controlsMaintain tool allowlists restricting calls to approved domains and APIsValidate parameters and encode outputs before tool responses reach the modelRequire human-in-the-loop confirmations for high-impact actionsScope tool permissions to minimal datasets and foldersApply rate limits and anomaly detection on tool call frequencyRAG-specific controlsRestrict retrieval sources to allowlisted domains and apply trust scoringScan documents during ingestion for embedded instruction patternsFilter retrieval results to prevent sensitive content from entering model contextEnforce citation display so users can verify which sources informed each answerSegment knowledge bases by sensitivity level to prevent cross-contaminationMonitoring, audit, and responseMaintain a centralized audit trail capturing every prompt, response, and tool callAutomate coaching and policy reminders for users who trigger violationsFollow a structured incident playbook: contain, investigate, revoke compromised access, and tune policies&nbsp; How Zscaler closes the enforcement gapPrompt injection mitigation fails when security policies exist only on paper. Zscaler addresses that inline, where every prompt, response, and tool call passes through inspection before it reaches the model. AI Asset Management eliminates the blind spot that lets shadow AI bypass governance, discovering AI across the environment, sanctioned applications, embedded software as a service (SaaS) AI, developer tooling, agent platforms, and model context protocol (MCP) servers. AI Access Security governs who reaches which AI tools based on identity, role, and context, with inline DLP inspection on prompts and uploads before sensitive data leaves the organization.AI Red Teaming and AI Guardrails close the loop between testing and enforcement. Continuous adversarial testing identifies exploitable weaknesses in system prompts, agent behaviors, and tool integrations. When testing surfaces a vulnerability, automated policy generation translates the finding into runtime detection rules covering jailbreaks, prompt injection, PII leakage, and off-topic behaviors.Request a custom demo to see how Zscaler secures your AI environment, or read the ThreatLabz 2026 AI Security Report for the latest research on AI-native threats.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Accelerating Post-Quantum Readiness Timelines: A New Executive Order on Securing Against Advanced Cryptographic Attacks]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/accelerating-post-quantum-readiness-timelines-new-executive-order-securing</link>
            <guid>https://www.zscaler.com/blogs/product-insights/accelerating-post-quantum-readiness-timelines-new-executive-order-securing</guid>
            <pubDate>Tue, 14 Jul 2026 03:56:57 GMT</pubDate>
            <description><![CDATA[The Quantum Threat Is No Longer HypotheticalOn June 22, 2026, the President signed two Executive Orders signaling that the quantum era is rapidly approaching and demands action. The first, “Securing the Nation Against Advanced Cryptographic Attacks” (EO 14412), accelerates the federal government’s migration to post-quantum cryptography. The second, “Ushering in the Next Frontier of Quantum Innovation” (EO 14413), establishes a whole-of-government quantum strategy covering research, commercialization, supply chain resilience, and workforce development.EO 14412 sets a clear deadline: federal agencies must migrate their most sensitive systems to post-quantum cryptography (PQC) for key establishment by December 31, 2030, and to PQC for digital signatures by December 31, 2031. The EO also directs the Federal Acquisition Regulatory (FAR) Council to propose a rule requiring covered federal contractors to comply with National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS), including PQC algorithms, by December 31, 2030. Every agency must designate a PQC Migration Lead within 30 days of the signing.Underlying these EOs is a well-documented threat called "Harvest Now, Decrypt Later" (HNDL): Nation-state actors are actively exfiltrating and storing encrypted government and enterprise data today, with the intent to decrypt it once sufficiently powerful quantum computers become available. The data being harvested—from credentials, intellectual property, to national security information—can have a shelf-life of decades.The question for every government agency and enterprise security team is no longer whether to migrate; it is how and how fast. The Legislative and Standards FrameworkThe Cybersecurity EO (14412) sits within a broader legislative and technical framework that organizations must navigate:The Quantum Computing Cybersecurity Preparedness Act (P.L. 117–260)This law, enacted in December 2022, requires federal agencies to inventory their cryptographic assets to know what encryption is in use, where it lives, and which systems are most at risk from a quantum attack. You cannot migrate what you cannot see.OMB M–26–15: Execution of the Migration to Post-Quantum CryptographyTwo days after EO 14412 was signed, OMB issued&nbsp;Memorandum M-26-15, translating the EO’s deadlines into a five-phase migration framework. Agencies must submit PQC Migration Plans to OMB within 120 days. The memo calls for automated cryptographic inventory and discovery tools, integration of PQC into Zero Trust architectures, and coordination with FedRAMP-authorized cloud service providers on shared PQC migration responsibilities. M-26-15 treats PQC as a foundational dependency for a durable Zero Trust architecture, reinforcing that organizations cannot achieve a mature zero-trust posture without quantum-resistant cryptography.NIST PQC StandardsNIST has finalized&nbsp;FIPS 203, which standardizes ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), a quantum-resistant algorithm for key establishment. This is the standard that addresses the EO's nearer-term 2030 deadline and is the foundation for Zscaler's current PQC capabilities. NIST has also finalized standards for post-quantum digital signatures, which address the EO's 2031 deadline.Taken together, these requirements create a clear operational mandate. The next question is which security architectures can deliver PQC capabilities at the scale and speed these timelines demand.&nbsp; Where Zscaler Stands: A Purpose-Built ResponseLong before the EO was signed, Zscaler invested in building post-quantum cryptography capabilities that address key establishment requirements at the center of the EO’s nearer-term 2030 deadline and the operational realities that agencies and enterprises face. Here is how Zscaler's platform responds to the key establishment requirements that take effect first.PQC Visibility - Know Your Cryptographic PostureAddresses: Quantum Computing Cybersecurity Preparedness Act | EO Requirement: Cryptographic inventory &amp; risk assessmentThe first step to PQC compliance is understanding your current cryptographic footprint, identifying every system, application, and connection that relies on classical key establishment and digital signatures that will eventually be vulnerable to quantum attacks.OMB M-26-15 acknowledges that manual inventory processes are insufficient at federal scale. Zscaler's inline architecture addresses this directly: it provides automated, continuous cryptographic discovery based on actual traffic, giving organizations ground-truth visibility into cryptographic capabilities across users, devices, and specific transactions.&nbsp;Zscaler launched its PQC Visibility Report, a dedicated dashboard within the Zscaler Zero Trust Exchange that gives security teams a real-time view of:Which users and devices are initiating TLS connections with PQC key establishmentUse of legacy TLS protocol versions that cannot adopt PQCWhere classical key establishment remains in use and is most exposedTraffic breakdowns across the enterprise to help prioritize migration effortsAll the relevant information is readily available in the detailed transaction logs and can be streamed through Zscaler's Nanolog service at any scale. This enables organizations to build a Cryptographic Bill of Materials (CryptoBOM), a structured inventory of all encryption dependencies across the enterprise. In partnership with HCLTech, Zscaler now offers service-led crypto-discovery engagements to help enterprises create and operationalize their CryptoBOM as the foundation for a full PQC migration roadmap.Zscaler's PQC Visibility Report gives organizations the ground-truth inventory that both the Preparedness Act and M-26-15 require as the foundation for migration.&nbsp;Inline PQC Inspection - Protect Traffic in MotionAddresses: EO Requirement: Transition of high-value assets and high-impact systems to PQC for key establishment | Standard:&nbsp;NIST FIPS 203 (ML-KEM)In February 2026, Zscaler became the first Security Service Edge (SSE) provider to launch full inline PQC traffic inspection, a breakthrough that redefines what enterprise and government security infrastructure can do.How It WorksThe Zscaler Zero Trust Exchange sits inline between users and the internet, acting as a "quantum-safe intermediary" or Crypto-Translator:Decrypt: Zscaler intercepts and decrypts inbound TLS traffic, including traffic protected by quantum-safe key establishment (ML-KEM / FIPS 203 hybrid with ECDHE)Inspect: Full deep content inspection is applied: threat detection, data loss prevention, URL filtering, and policy enforcementRe-encrypt: Traffic is re-encrypted using the appropriate algorithm before being forwarded to its destination. Zscaler uses quantum-safe key establishment with the servers that support such capability.This architecture solves one of the thorniest challenges in enterprise PQC migration: legacy server compatibility. Many backend servers and SaaS applications have not yet adopted PQC key establishment. Zscaler's Zero Trust Exchange bridges this gap, establishing a PQC-secured connection with the modern client while maintaining a compatible classical TLS connection with the legacy server. This means organizations can begin protecting their users from HNDL attacks today, without waiting for every server and application in their ecosystem to be upgraded.TLS 1.3 and Hybrid Key ExchangeZscaler's inline inspection engine supports hybrid PQC key establishment, combining classical Elliptic-Curve Diffie-Hellman with Ephemeral Keys (ECDHE) with ML-KEM (FIPS 203). The hybrid approach is widely recognized as more safe and prudent compared to direct migration to pure PQC, since it offers defense-in-depth: compromising a properly implemented hybrid scheme requires an attacker to break both the classical and PQC algorithms. It provides full compatibility with modern web browsers (Chrome, Edge, Firefox, Safari) and follows the current recommendations of the Internet Engineering Task Force (IETF).OMB M-26-15 recognizes hybrid architecture as a valid transitional model and specifies TLS 1.3 as the foundation for deploying PQC at the network level, with a January 2, 2030 adoption deadline for all agencies.Upcoming: Crypto Policy ProfilesNot all PQC requirements are the same. IETF recommends hybrid key exchange, which pairs ML-KEM with classical ECDHE for broad compatibility across the public internet. NIST's CNSA 2.0 suite, on the other hand, calls for pure ML-KEM in national security systems, removing the classical component entirely.Zscaler is developing Crypto Policy Profiles that will give security teams granular control over which cryptographic standard is enforced, and where. Administrators will be able to define policies that require hybrid key exchange for general enterprise traffic while mandating pure ML-KEM for connections that fall under CNSA 2.0 requirements. Policies can be scoped by user group, application, data classification, or compliance regime.For federal customers operating under both the EO's 2030 deadline and CNSA 2.0 guidance, this flexibility is essential. It allows a single platform to satisfy divergent cryptographic mandates without forcing a one-size-fits-all approach across the organization. Why the Zero Trust Architecture Is the Right FoundationZscaler's&nbsp;PQC capabilities are natively embedded in the Zscaler Zero Trust Exchange, the world's largest security cloud. This architectural advantage matters for PQC migration:Inline by design: Every user connection passes through Zscaler, meaning PQC inspection is applied universally without endpoint agents or network re-architecture.Scalable at cloud speed: The Zero Trust Exchange processes hundreds of billions of transactions per day, providing the throughput required to handle the computational overhead of PQC algorithms without degrading user experience.Policy-driven:&nbsp;Security teams can enforce quantum-safe TLS requirements selectively, scoping by user, group, application, or data classification to enable a phased and controlled migration.Unified visibility:&nbsp;A single pane of glass for both classical and quantum-safe traffic means no blind spots during the transition period.Cryptographic agility: PQC research remains an active topic and NIST is working on standardizing additional algorithms. Zscaler cloud always adopts the latest security guidelines to ensure that customers do not need to worry about unexpected disruptions if the recommended approach to PQC changes. The Bottom Line: Act Now, Don't Wait for 2030The 2030 deadline may feel distant, but the HNDL threat is happening right now. Data being transmitted over channels established with classical key exchange today is being harvested by adversaries who are betting that quantum computers will be ready before organizations are. Every day of delay puts additional data at risk.Zscaler's message to government agencies and enterprises is straightforward: you don't have to wait to get protected. The tools to see your cryptographic exposure, inspect quantum-safe traffic inline, and secure your network fabric are available today. The path to PQC compliance runs through Zero Trust, and Zscaler is ready to walk that path with you.To learn more about Zscaler's Post-Quantum Cryptography solutions, request a PQC Readiness Assessment, or explore the PQC Visibility Report in your Zscaler tenant. A future blog entry will cover PQC migration recommendations specific to FedRAMP and Department of War organizations.]]></description>
            <dc:creator>Jose Padin (VP, Solutions Consulting, US Public Sector)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Why Do F1 Teams Need Cybersecurity, and How Is AI Changing the Threat Landscape?]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/f1-cybersecurity-ai-threats</link>
            <guid>https://www.zscaler.com/blogs/product-insights/f1-cybersecurity-ai-threats</guid>
            <pubDate>Thu, 09 Jul 2026 19:10:53 GMT</pubDate>
            <description><![CDATA[An F1 car doesn’t just burn fuel, it burns data.&nbsp;Across a race weekend, hundreds of onboard sensors generate hundreds of gigabytes of telemetry, and that stream moves constantly, from car to garage, garage to trackside systems, trackside to factory, factory back to the pit wall. The competitive edge lives inside those packets, which is why rivals, criminal groups, and even nation-state actors all have reasons to want in. The story here isn’t “sports security”, it’s modern enterprise security with a stopwatch. F1 runs one of the most exposed data environments in professional sportsWhat is actually at riskOnce you picture F1 as a traveling engineering lab, the risk becomes obvious. Modern teams operate on live feedback loops: measure, decide, adjust, repeat. Telemetry isn’t “nice to have”, it’s the blueprint of the car while it’s still being drawn.Teams protect:Live telemetry streams that reflect aerodynamic configuration, tire strategy signals, engine tuning trends, and even driver biometrics transmitted from car to trackside systems and back to the factory in near real time.Proprietary software and analytics that turn raw sensor output into decisions, e.g., setup recommendations, race simulations, and reliability predictions.Business data on the same rails: sponsor financials, contract information, internal planning, and operational documents that travel with the team.Global operational sprawl: teams compete across 20+ countries in a season. Each venue introduces new networks, new physical access opportunities, and new jurisdictions, meaning the threat profile shifts every few weeks.The crown jewels aren't a single database. They're the services, identities, and workflows that move data through the system. That's where attackers focus. Why third-party access makes it worseA typical F1 team isn’t a closed system, it’s an ecosystem: dozens of technology vendors, suppliers, and partners, each providing critical capability. Every integration is also an exposure point, and each vendor relationship can quietly extend the attack surface beyond the team’s direct line of sight.This matters because any savvy threat actor or group won’t hack a team “head-on”, so to speak. They will instead:Find the softest adjacent party (supplier, partner, contractor).Leverage their access or data flows.Land inside the team’s environment with legitimate-looking credentials, sessions, or trusted connections.Trackside teams operate in temporary, fast-moving environments where security takes a backseat to speed. Contractors, media, and sponsors need system access for hours or days, creating short-term exposures.As such, “We’ll tighten it up later” is liable to become a habit, and these habits compound. The threats are the same ones targeting every enterpriseIP theft, ransomware, and social engineeringBehind the speed, glamour, and heavy competition, the threat categories facing F1 look familiar to any security practitioner:IP theft has a long history in motorsport culture; engineers walking out with sensitive material is simply the human version. The digital version never sleeps: credentials reused, cloud shares misconfigured, data copied quietly, and access granted “temporarily” that becomes permanent.Ransomware becomes especially dangerous when time is the weapon. An enterprise can survive hours of downtime with financial loss and angry stakeholders, but a race team locked out of key systems hours before qualifying faces a different kind of pressure: pay fast, or lose the weekend.Social engineering thrives on routine and relevance. Race calendars, travel patterns, sponsor announcements, and internal schedules create a rich template for spear phishing. Traveling staff connecting from airports and hotels add exposure risk due to credentials and sessions can be intercepted or tricked, then carried back into more sensitive environments.Get the 2026 Zscaler ThreatLabz Phishing and Initial Access Report here. AI as an attack toolAI doesn’t create new human weaknesses, it industrializes them.Attackers can now:Generate highly convincing phishing content at speed, tuned to race-weekend timing, internal language, and real sponsor context.Use audio/video deepfakes to impersonate team principals or sponsor stakeholders, exploiting “voice trust” at near-zero cost.Run automated discovery and scanning to locate exposed systems faster than teams can respond—especially in temporary or rapidly changing race-weekend networks.This is the part many organizations don’t want to admit: an attacker’s workflow is getting closer to “push button, get campaign” than ever before, driving security teams to defend at scale or get buried. How AI and zero trust work together on defenseWhat AI does on the security sideAt F1 telemetry scale, AI earns its keep by helping security teams see patterns and drift quickly, especially across distributed environments.AI can help by:Establishing baselines of “normal” behavior across trackside systems, factory connectivity, and cloud endpoints, and flagging meaningful deviations fast.Tracking not just human users, but non-human identities too: automated pipelines, service accounts, and AI agents that increasingly act like “users” on the network.Correlating risks that don’t look severe in isolation but become dangerous in combination: misconfigurations, exposure, and overprivileged access.But there’s a limitation worth saying out loud: AI detection becomes noisy when the environment is messy. Fragmented identity, inconsistent segmentation, and unclear ownership create false positives, and alert fatigue is how a good tool can get ignored. Why perimeter security fails here and what replaces itPerimeter security assumes there’s a stable “inside”, but F1 doesn’t have one. It’s global, partner-heavy, and built on fast-changing environments, meaning the moment you connect from a circuit in Singapore or a hotel in Austin, a “trusted location” becomes a myth.Zero trust replaces the assumption with verification:Verify every sessionVerify every user and every deviceGrant least-privilege accessContinuously re-evaluate trust as conditions changeThis approach scales beyond motorsport; any enterprise with hybrid cloud, remote teams, and third-party access is living the same reality, just with fewer cameras pointed at it. How Zscaler protects valuable F1 data and secures the use of AIA partnership like Zscaler and Aston Martin F1 makes sense because the problem statement is clear: protect high-value data in a high-speed, high-change, high-adversary environment, while AI use accelerates across the workforce and development workflows.Built on the Zscaler Zero Trust Exchange, Zscaler’s AI Security portfolio operates as consistent, scalable controls across every user, app, and data path, rather than isolated add-ons.Zscaler AI Access Security helps teams discover which AI apps are being used (including shadow AI), control access by user/group, extract and classify prompts/responses, and prevent sensitive data loss with inline DLP and content moderation.Zscaler AI Guardrails (AI Guard) bring inline inspection to AI interactions to block prompt injection and jailbreak-style attacks, stop data loss with DLP programs and predefined dictionaries, and filter outputs, all while providing dashboards and real-time alerting for visibility into AI use.Zscaler Automated AI Red Teaming supports continuous testing of AI systems from build to runtime using predefined probes, custom probes, and custom dataset uploads, with multi-modal testing (text, voice, images, documents). It also tracks and remediates issues via integrations like Jira and ServiceNow, and maps findings to frameworks (e.g., NIST AI RMF, OWASP LLM Top 10, MITRE ATLAS).Zscaler AI Asset Management (AI-SPM) focuses on getting a 360-degree view of AI models, agents, services, and connected data assets (datasets, vectors), then correlating risks like misconfigurations, exposure, entitlements, and poisoning risk, with guided remediation and compliance alignment (e.g., NIST AI RMF 600-1, EU AI Act, HIPAA, GDPR).In F1, you don’t win by securing one laptop. You win by securing the system of work; users, vendors, apps, AI tools, models, data, and the pathways between them.Schedule a custom demo of Zscaler AI Security today.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Beyond Alert Fatigue: Architecting Next-Gen Data Security with Zscaler Workflow Automation]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/beyond-alert-fatigue-architecting-next-gen-data-security-zscaler-workflow</link>
            <guid>https://www.zscaler.com/blogs/product-insights/beyond-alert-fatigue-architecting-next-gen-data-security-zscaler-workflow</guid>
            <pubDate>Wed, 08 Jul 2026 15:22:34 GMT</pubDate>
            <description><![CDATA[If you ask a&nbsp;data loss prevention (DLP) analyst about their daily operational challenges, alert fatigue is typically top of mind. As organizations expand their footprint across cloud applications, endpoints, and enterprise email, the volume of data protection incidents has skyrocketed.&nbsp;Legacy "block and log" architectures rely heavily on manual triage and force security teams to chase down end-users to ask,&nbsp;"Did you mean to share this, and what is the business justification?"True data protection should not rest solely on the shoulders of the IT or SOC department. Security must be democratized.With&nbsp;Zscaler Workflow Automation, organizations can transform how they process data security incidents.&nbsp;Workflow Automation integrates directly with&nbsp;Zscaler Internet Access (ZIA)&nbsp;and&nbsp;Endpoint DLP to shift triage responsibility back to the data owners, automate tedious exception management, and help security professionals focus on genuine insider threats and exfiltration attempts.Here is a deep dive into the technical capabilities that make this shift possible.&nbsp; Decentralizing triage: The end-user justification workflowWorkflow Automation can engage the end-user in real time without relying on an IT intermediary. When an inline DLP policy is triggered, the system seamlessly captures the incident, protects sensitive trigger data and evidence via granular role-based access control (RBAC), and initiates an automated outreach workflow.Rather than generating a static alert in a SIEM, the platform leverages multi-channel notification templates to reach the user where they work, such as via Slack, Microsoft Teams, or email.The notification delivers an end-user justification questionnaire. Administrators can build, clone, customize, and translate these survey templates to support a global workforce.&nbsp;Fig 1: The end-user justification questionnaire allows users to identify why a transaction should be allowed.&nbsp;Depending on the user's interactive response, the automation engine routes the incident dynamically:Auto-remediation of false positives or mistakes: If the user realizes they made an error and cancels the transfer, the incident is tagged and closed automatically.Manager escalation: By mapping users to their direct managers via your identity provider, workflows can route specific justifications to a manager for secondary approval.Analyst enrichment: If the action triggers a high-severity threshold, the user's justification and context are appended to the event. Zscaler natively integrates with ITSM platforms like ServiceNow and Jira to automatically create enriched tickets so analysts have immediate forensic context.&nbsp;Zero-touch IT: Automated exception managementHistorically, when an end-user had a valid, urgent business need that conflicted with a DLP policy, the operational friction was immense. It required submitting an IT ticket, waiting for a security admin to manually carve out a policy exception (often IP- or URL-based), and setting calendar reminders to revoke that exception later to prevent policy bloat.Zscaler Workflow Automation significantly reduces this manual labor. When a workflow prompts the user for context and the request is approved via predefined acceptable criteria or through a designated approver,the system manages the exception dynamically.&nbsp;Fig 2: Workflow modelling notifies the user, gets their response, and then notifies the manager. With this feature, managers can create an exception with automated closing in the end, so that no DLP team member needs to get involved in the process.The transaction is permitted and fully logged with its business justification, without requiring manual changes to the underlying DLP policies. Your baseline security posture is clean, and your network and endpoint policies remain clutter-free.Frictionless email security: Automated quarantine releaseEmail remains a primary vector for accidental data exposure, but managing email quarantines is a massive time sink. Traditionally, if an outbound email hit a sensitive data rule, it was sent to quarantine, triggering a helpdesk ticket. An administrator then had to manually review the email evidence and release it.Zscaler fundamentally changes this via its advanced incident details interface. For incidents where the source DLP type is&nbsp;Email, admins can manually use the “Release Email Quarantine” action to deliver the message to&nbsp;all intended recipients, or selectively release it to&nbsp;specific recipients directly from the platform.While the advanced incident details interface is valuable for admins, the true game-changer is the "Enable Email Quarantine Release for End Users" capability found in the Advanced Account Settings.When enabled, the IT burden is reduced. If an email is quarantined, the user receives an immediate notification explaining the policy violation. They are then presented with a workflow asking for justification.&nbsp;Once the user&nbsp; provides an acceptable business reason, or obtains integrated manager approval, they can release their own quarantined message. The system then automatically releases the email to the MTA for delivery.&nbsp;Zero IT tickets, zero manual review, and zero delays to critical business communications. Engineering a self-healing security postureData security should not be synonymous with business bottlenecks or SOC burnout. By leveraging Zscaler Workflow Automation, security architects can build a highly responsive, self-remediating DLP architecture.By integrating custom workflows directly into platforms like Slack and Teams, fully automating exception management, and empowering end-users to manage their own email quarantines under controlled conditions, you reduce the manual labor that historically has been tied to data protection.&nbsp;The result is a more resilient organization, a reduced incident queue, and a security team empowered to focus on true threat hunting.To learn more about how Zscaler can help with your next-generation data security,&nbsp;read the product datasheet and&nbsp;request a demo. FAQsWhat is DLP alert fatigue and how does Zscaler Workflow Automation solve it?&nbsp;DLP alert fatigue occurs when security teams are exposed to such a high volume of data loss prevention alerts that it becomes difficult to identify which incidents require immediate attention. When alerts are repetitive, low risk, or missing clear business context, analysts become desensitized to them over time. This slows investigation and increases the chance that critical alerts are overlooked.Zscaler Workflow Automation helps solve this by automatically enriching, prioritizing, and routing DLP incidents so security teams can spend less time sorting through noise and more time responding to meaningful risk. Additionally, automated workflows can handle incidents without the need to manually review or handle them. The automation enables the DLP team to focus on things that really matter, by separating out noise.This improves efficiency, speeds up response, and helps teams make more consistent decisions.&nbsp;How does Zscaler Workflow Automation automate DLP incident triage?Zscaler Workflow Automation helps automate DLP incident triage by reducing the manual effort required to investigate and route alerts. It can enrich incidents with relevant context, apply decision logic, trigger approvals, assign actions, and direct each case to the appropriate team or workflow. This allows organizations to handle routine incidents efficiently while ensuring higher risk events receive a faster response.&nbsp;Can end users release their own quarantined emails in Zscaler?&nbsp;Yes, organizations can enable end users to release their own quarantined emails through Zscaler Workflow Automation. This can be configured in a controlled way so only certain messages qualify for self release, while more sensitive cases can still require additional review or approval. This approach helps improve user experience without giving up administrative oversight.&nbsp;What is the difference between automated exception management and traditional DLP policy exceptions?&nbsp;Traditional DLP policy exceptions are typically static changes made directly within policy, and they can remain in place longer than intended if they are not actively reviewed. Automated exception management is a more dynamic and controlled approach. It enables organizations to allow a specific action under defined conditions, often for a limited time and with approval and audit tracking.&nbsp;&nbsp;How does Zscaler Workflow Automation integrate with Slack, Microsoft Teams, Jira and ServiceNow for data security incident management?&nbsp;Zscaler Workflow Automation integrates with Slack, Microsoft Teams, Jira, and ServiceNow to help organizations manage data security incidents through the platforms their teams already use. It can send notifications, request approvals, collect responses, update records, and keep incident handling aligned across key stakeholders. With Zscaler, organizations can accelerate response times and create a more consistent and auditable incident management process.&nbsp;&nbsp;&nbsp;&nbsp;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.]]></description>
            <dc:creator>Michael Schneider (Principal Specialist Solution Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[SSE Architecture Explained: How SSE Enables Zero Trust]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/sse-architecture-explained-how-sse-enables-zero-trust</link>
            <guid>https://www.zscaler.com/blogs/product-insights/sse-architecture-explained-how-sse-enables-zero-trust</guid>
            <pubDate>Mon, 06 Jul 2026 22:25:03 GMT</pubDate>
            <description><![CDATA[A&nbsp;security service edge (SSE) architecture consolidates network security tooling and technologies. It continuously verifies that least-privileged access control is applied to every user session, and applies those access control policies across every physical location.&nbsp;SSE also enables zero trust enforcement at scale. Security service edge enforces the "never trust, always verify" principle by analyzing every access request in real time. Once an access request is analyzed, SSE requires explicit user authentication and device posture validation before it grants access to a single resource. What is an SSE architecture?An SSE architecture is a cloud security framework that combines secure web gateway (SWG), cloud access security broker (CASB), and zero trust network access (ZTNA) into a single policy engine. The framework also includes the deployment models, traffic flows, control points, integrations, and operational choices that your organization makes to deliver those SSE capabilities.SSE architectures steer traffic from endpoints, branch sites, or cloud workloads to the nearest point of presence (PoP). At the PoP, SSE applies identity- and context-aware policy.SSE platforms evaluate multiple signals to allow, block, inspect, or broker access. These signals include user identity, device posture, content, application, and risk. SSE platforms also offer TLS/SSL inspection, malware scanning, and inline or API-based SaaS controls. Why are SSE architectures important?SSE architectures consolidate&nbsp;SWG,&nbsp;CASB, and&nbsp;ZTNA policy engines, data classification layers, and management consoles into one solution. With SSE, security teams can define and enforce consistent policy across all traffic types.SSE architectures move the enforcement point away from the corporate perimeter to the cloud itself. Traffic inspection, threat detection, and access control happen in globally distributed PoPs. As a result, policies are enforced at the edge, where users are. Security teams can respond faster to threats, and users experience less latency. Core SSE componentsSSE architectures include two elements: a&nbsp;complete SSE platform and core operational components. These core components include:SSE componentWhat it doesIdentity and access control planeIntegrates with IdP/SSO, maps both users and groups to policy, and enables identity- and context-based enforcement.Identity contextConnects each request to a verified user with context including policy group information, MFA status, and risk signals.Device posture contextEvaluates devices’ security and compliance states, including information about their managed vs. unmanaged status, OS or patch level, encryption, and EDR status.Cloud-delivered enforcement layer and inline inspectionSteers traffic to the nearest PoP and creates a distributed inspection and enforcement fabric. This fabric terminates connections, scales easily, and applies policy close to users.API-based controlsProvide continuous SaaS hygiene by protecting data at rest in SaaS apps.&nbsp;Inline controlsStops threats and data exfiltration during user access.Threat protection stack&nbsp;Includes malware and phishing protection, content scanning, and integrations for EDR/XDR, SIEM, and SOAR.&nbsp;Traffic steering and connectivity&nbsp;Includes endpoint agents, proxy auto-configuration (PAC) files, explicit proxies, tunnels from branches, and cloud or workload connectors to route traffic into the SSE platform.Telemetry, logging, and analytics&nbsp;Prepares real-time logs and reporting for visibility, alerting, incident response, and compliance or audit requirements.&nbsp; &nbsp;How AI enhances SSE architecturesAI and machine learning shift&nbsp;SSE architectures away from static and rule-based policies to a dynamic and predictive approach. AI in SSE addresses issues like zero-day attacks, noisy alerts, and suspicious activity.Inline threat protection uses machine learning models and behavioral analysis to detect novel threats like&nbsp;phishing attacks.AI discovers and classifies data in real time. Machine learning models trained on your company’s data patterns cut down on false positive alerts.User and behavior analytics (UEBA)&nbsp;learns what baseline activity looks like in your environment. It can detect behavior that rule-based policies miss, like abnormal data transfers or suspicious access patterns.SSE continuously updates each user’s risk score&nbsp;and automatically adjusts user permissions based on behavior, device health, and login history. If the risk score increases, SSE revokes access or requires reauthentication.AI reviews traffic logs&nbsp;and recommends policy changes based on real-world usage and risk. How does SSE enable zero trust? A step-by-step overviewSSE enforces&nbsp;zero trust principles through a combination of its integrations and its SWG, CASB, and ZTNA functionality.&nbsp;Here's what SSE does in real time when a user requests access to an app:Verify user identity.&nbsp;When a user requests access to an application, SSE uses its integration with an IdP to authenticate that user via MFA.Assess device posture.&nbsp;SSE checks the user’s device for any health or compliance issues. For example, if the device has an out-of-date OS or lacks necessary patches, SSE will block or restrict that device’s access.Enforce least-privileged access.&nbsp;SSE checks the user’s role, device type, and location to enforce the correct access policy.Replace traditional network access with ZTNA.&nbsp;Rather than placing the user on a broader network, SSE establishes a ZTNA connection directly to the application.Inspect all traffic inline.&nbsp;SSE implements TLS/SSL inspection on all traffic. The platform scans encrypted and unencrypted traffic for malware, phishing, and policy violations.&nbsp;Apply inline threat prevention.&nbsp;SSE blocks malicious content, unauthorized SaaS apps, and other threats before they reach the user or application.Control cloud and SaaS app activity.&nbsp;SSE manages how users engage with sanctioned and unsanctioned cloud apps. For example, SSE can restrict Salesforce access to the sales team or limit Google Drive files to read-only for contractors.&nbsp;Monitor user behavior.&nbsp;The platform includes user and entity behavior analytics (UEBA) and logging capabilities, which identify what normal behavior looks like. SSE catches deviations from the norm like bulk data downloads and logins from different countries.Change or revoke access based on real-time risk.&nbsp;When SSE detects anomalous behavior, it immediately takes action to isolate the threat.Complete audits and implement incident response.&nbsp;SSE collects telemetry across traffic, users, and applications to create an audit trail. Your security team uses this data to program automated responses, investigate incidents faster, and update policies. What zero trust outcomes does SSE help deliver?Security service edge delivers the following zero trust outcomes:&nbsp;Least-privileged access:&nbsp;Users and apps get access to only what they need, and nothing more.Continuous verification: Uses identity, risk, and device posture signals to reverify access.Reduced attack surface: Applies consistent web and SaaS controls and uses ZTNA to reduce the risk of lateral movement.Consistent policy applied everywhere:&nbsp;The same rules apply whether users are at the office or working remotely.Threat prevention applied at the edge:&nbsp;Inspects traffic, blocks malware, and proactively identifies risky behavior.Improved visibility and auditability:&nbsp;Unified logging and analytics make investigation and compliance reporting faster and easier. SSE: The first step in your zero trust journeyZero trust assumes that no one inside or outside of your network should be trusted by default. It takes time to move towards zero trust, and for most organizations&nbsp;SSE represents an accessible starting point for that evolution.&nbsp;As you mature your zero trust architecture and SSE program, you'll find that deploying&nbsp;secure access service edge (SASE) is a natural next step.&nbsp;Bringing together networking and security using a&nbsp;SASE model makes zero trust possible for scaling teams. Zero trust demands continuous verification and policy enforcement, and SASE delivers the unified infrastructure needed to make that possible.&nbsp;&nbsp;&nbsp;Ready to learn more about Zscaler SSE?Download the 2026 Gartner Magic Quadrant for SSE to learn why Zscaler was named a Leader.Request a demo to see how Zscaler protects against AI-driven threats.]]></description>
            <dc:creator>Julia Benson (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[SecOps for the AI Age: Detecting and Responding to AI‑Related Incidents]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/secops-for-ai-incidents</link>
            <guid>https://www.zscaler.com/blogs/product-insights/secops-for-ai-incidents</guid>
            <pubDate>Thu, 02 Jul 2026 21:06:09 GMT</pubDate>
            <description><![CDATA[AI-related incidents don’t look like traditional security alerts, which means&nbsp;SOC teams can’t rely on signature-based detections, structured logs, or legacy playbooks alone. Effective response depends on treating prompts, model outputs, connectors, and agent activity as security events that can be inspected, classified, correlated, and contained.&nbsp;AI incidents create a new detection gap: Threats such as prompt injection, sensitive data exposure,&nbsp;shadow AI, and agentic misuse move through conversational interfaces and unstructured text, making them largely invisible to traditional SOC tooling.Inline inspection is now foundational: SOC teams need prompt and response inspection, AI-specific telemetry, and cross-layer correlation across identity, endpoint, browser, network, and SaaS activity to detect AI-driven risk in context.The first 15 minutes matter most: Analysts need to quickly determine scope, intent, exposure, and available evidence so they can distinguish deliberate attacks from accidental misuse and prevent spread into downstream systems.Containment must be targeted, not disruptive: The goal is to neutralize the threat through controls like DLP, session restrictions, access policies, runtime guardrails, and integration isolation—without shutting down approved AI tools the business depends on.AI incidents travel through conversational interfaces, hide inside unstructured text, and bypass every signature-based detection running today, leaving no structured artifacts for traditional security operations to catch. The coverage gap lives in how security operations collect and classify signals in the first place.100% of AI systems tested had at least one critical vulnerability. The median time to first critical failure was 16 minutes.&nbsp;— ThreatLabz 2026 AI Security Report, ZscalerFrom prompt-layer indicators to cross-layer correlation to targeted containment, each step redefines what the SOC monitors, how analysts investigate, and where controls apply. Content classification replaces pattern matching. Behavioral context replaces known-bad indicators. The operating model changes because the threat surface has. AI incidents are redefining the SOCAI-related security incidents defy every detection rule your security operations center (SOC) already runs.Traditional SOC workflows depend on structured, parseable signals: signature matching, IP reputation scoring, endpoint telemetry. Each assumes a defined attack surface with known indicator patterns. AI incidents break that assumption. They originate inside conversational interfaces, move through model inference pipelines, and propagate across agentic tool chains calling external APIs without human oversight, none of which produces a file hash to match or a known-bad IP to block.The National Institute of Standards and Technology AI Risk Management Framework (NIST AI RMF) identifies inline inspection of AI inputs and outputs as a foundational control, recognizing that without visibility into what enters and leaves a model, organizations cannot assess risk, respond to incidents, or demonstrate governance. In practice, that means treating every prompt and response as a security event with a classification, an owner, and a policy attached. Without that inspection layer in place, AI-layer threats pass through every existing control unexamined. What counts as an AI-related incident?An AI-related security incident is any security event that involves an AI system, or the data, outputs, and decisions connected to it, in a way that puts confidentiality, integrity, availability, safety, or acceptable use at risk. These incidents can originate in an AI component, pass through it, or directly target it or its supporting supply chain, leading to business, operational, regulatory, or customer harm.The boundary between a traditional security event and an AI-related incident comes down to where the incident originates. AI-related incidents stem from, pass through, or target an AI component, and they cover a wider range of event types than traditional security controls were built to handle:Data exposure via prompts, model outputs, or file uploads to AI servicesPrompt injection against enterprise AI tools or customer-facing AI applicationsModel evasion and adversarial inputs designed to bypass safety controlsModel drift or degradation causes unsafe or inaccurate decisions over timePolicy violations and unacceptable use of AI services by authorized usersUnauthorized AI access, including shadow AI discovery across the organizationA seventh category is emerging fast. AI supply chain and dependency risk covers compromised models, vulnerable agents, malicious Model Context Protocol (MCP) servers, and insecure development environments that create exposure before a single prompt is sent.The Coalition for Secure AI (CoSAI) AI Incident Response Framework identifies these supply chain threats as a distinct and growing category requiring dedicated response procedures. AI incidents vs. traditional security alertsAI incidents involve conversational context, non-human interaction patterns, and protocols that transaction-based security controls were not designed to inspect. Prompt classification, identifying intent, data type, and risk level within the prompt itself, becomes a core detection capability.DimensionTraditional alertAI-related incidentSignal sourceFirewall, EDR, SIEM, network tapPrompt logs, model inference telemetry, AI gateway, browser activityInspection methodSignature match, IOC lookup, behavioral ruleContent classification, prompt analysis, output evaluationData formatStructured logs, defined fieldsUnstructured conversational text, variable-length outputsTriage requirementMatch against known playbookAssess intent, context, data sensitivity, and model behaviorCore detection capabilityPattern recognitionPrompt and response classificationUnderstanding how AI incidents differ from traditional alerts shapes what you look for in telemetry. Common AI detection patterns in telemetryAI-related incidents leave traces across telemetry layers that most SOC teams treat as separate streams. Recognizing them requires knowing which layer to look in and what an anomaly looks like when the signal is unstructured conversational text rather than a log entry.Prompt-layer indicators:&nbsp;Look for override strings ("ignore previous instructions"), role-play prompts designed to extract restricted information, sensitive label targeting by data classification or project name, and rapid sequential prompts testing boundary conditions (prompt spraying).Data loss indicators in GenAI usage: DLP policy hits on outbound prompts are the primary signal. Also watch for file upload attempts to AI services and model responses that echo previously submitted confidential content.Access and posture indicators: Monitor for unsanctioned AI applications surfaced through traffic analysis or CASB logs, bulk prompt submission, off-hours usage, and policy bypass attempts through alternative access paths.Model health and behavior indicators:&nbsp;For privately hosted AI, track hallucination spikes, safety-filter trigger rates, accuracy drift against ground-truth datasets, and anomalous output formatting suggesting injection success or model compromise.Cross-layer telemetry correlation: No single stream tells the full story. Correlating AI-layer signals with endpoint, identity, network, and SaaS telemetry lets&nbsp;security operations&nbsp;prioritize by context rather than alert score, catching the incidents that would be invisible in any single stream. Triage questions for the first 15 minutesWhen an AI-related alert fires, the first 15 minutes determine whether the response stays contained or escalates. Unlike traditional incidents where triage follows a known playbook, AI incidents require analysts to assess conversational context, data sensitivity, and model behavior simultaneously. Work through these four areas in order.Scope and impactStart by establishing what is involved and how far the exposure may have reached.Which application, model, or agent is involved, and is it public-facing, internal, or embedded?Which users are affected, and what data types were in the prompts or outputs?Did sensitive data move into the AI system, out of it, or both?Attack vs. accidentDetermine whether this is a deliberate exploit or an unintentional policy violation.Do the prompts show injection characteristics such as instruction-override language or encoded payloads?Were there repeated attempts with variations, suggesting deliberate boundary testing?Does correlated activity from the same user appear in other security tools?Exposure window and persistenceUnderstand how long the exposure lasted and whether it has propagated beyond the initial event.Could prompts or outputs have entered the model's training data or chat history?Were any responses downloaded, exported, or forwarded externally?Did the AI system trigger downstream actions in connected systems or APIs?Evidence and loggingConfirm you have what you need to investigate, contain, and document.Are full prompt and response logs available for the affected sessions?Can you recover user identifiers, session tokens, and timestamps?Did existing policies take automated action, and what was enforced?With scope, intent, and evidence established, the next step is neutralizing the threat without taking down everything around it. Containment options without shutting down AIThe instinct during an AI incident is to block everything. Shut down the service, revoke all access, sort it out later. That approach punishes every user for one incident. Targeted containment neutralizes the specific threat while preserving legitimate AI use.Access controls: Block the specific unsanctioned application while leaving approved AI services operational. Restrict access by group or department to limit blast radius, and apply conditional access policies based on real-time risk.Session controls: Deploy browser isolation for AI interactions involving sensitive data. Require step-up authentication for high-risk services and apply time-bound restrictions scoped to the incident window.Data controls:&nbsp; Enforce inline DLP on all prompts and file uploads. Prompt classification identifies sensitive content before it reaches the model, and content moderation policies flag or block outputs that violate organizational policy.Private AI controls:&nbsp; Runtime guardrails enforce output safety at the inference layer. Prompt hardening reduces the attack surface for injection attempts, and adversarial testing runs continuously, not just at initial deployment.Deception and managed services: Deception-based controls seed AI environments with high-fidelity decoys that trigger on adversarial probing, producing high-confidence alerts with minimal false positives. Managed detection and response (MDR) and managed threat hunting extend SOC capacity when internal resources are constrained.Immediate actions when an AI incident is detectedSpeed matters, but sequence matters more. Execute these steps in priority order.Preserve all prompt and response logs before any session cleanup or rotationIsolate the affected AI system from downstream integrations and data storesRevoke or restrict access for the involved users, sessions, or API keys at the policy layerNotify the application owner, data owner, and incident response leadDocument every action, decision, and assumption in real timeOpen a formal incident ticket referencing preserved evidence Operationalizing agentic SecOps with ZscalerConsolidating telemetry across prompt, identity, endpoint, and SaaS layers into a unified analyst view is what lets response outpace the threat. Dynamic dashboards and automated workflows reduce mean time to detect and contain, and continuous threat exposure management (CTEM) surfaces model drift and posture degradation before incidents escalate. When internal resources are constrained, managed detection and response (MDR) through Red Canary and managed threat hunting extends SOC capacity with specialized AI threat expertise.Getting there requires a platform that connects those layers rather than adding to the tool sprawl. Zscaler covers the full AI lifecycle on a single platform built for enterprise scale, from AI Asset Management and Secure Access to AI through AI Red Teaming and runtime guardrails. Request a demo or talk to a Zscaler AI security specialist to operationalize your AI incident response, and download the ThreatLabz 2026 AI Security Report for the latest threat intelligence on AI-related attacks.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[When To Choose SSE vs. SASE: A Decision Framework for Security Leaders]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/when-choose-sse-vs-sase-decision-framework-security-leaders</link>
            <guid>https://www.zscaler.com/blogs/product-insights/when-choose-sse-vs-sase-decision-framework-security-leaders</guid>
            <pubDate>Thu, 02 Jul 2026 17:09:36 GMT</pubDate>
            <description><![CDATA[Secure access service edge (SASE) is an architectural approach that brings together cloud-delivered security and wide-area networking capabilities. Security service edge (SSE) represents the security component of that architecture and commonly includes secure access service edge (SWG), cloud access security broker (CASB), and zero trust network access (ZTNA).&nbsp;SASE, which encompasses all the features of SSE plus SD-WAN capabilities, is often viewed as the desired end state. But launching a&nbsp;full SASE implementation takes considerable resources, and many enterprises find that starting with SSE is a great first step towards unifying their security and networking functions. What is SSE designed to solve?SSE addresses security in a perimeterless world by managing remote access, SaaS app sprawl, and web-based threats without the latency associated with legacy systems.Transitioning to SSE helps organizations solve the following problems:Legacy, perimeter-based security tooling&nbsp;wasn’t designed for a distributed workforce. SSE enforces controls from the edge, applying consistent access policies and threat protection independent of user location.Traditional VPNs grant excessive, broad network access and introduce lateral movement risk. SSE replaces or augments VPNs with ZTNA to enforce identity- and context-based access.Shadow IT and SaaS sprawl introduce unknown risks. SSE uses&nbsp;CASB features to identify SaaS app usage, monitor risk, and enforce policies for app access and data handling.Remote users are vulnerable to&nbsp;web-based malware and phishing. SSE enforces consistent web security policies for any user or location.Sensitive data can leak through uploads, sharing links, SaaS apps, and unmanaged devices. Inline inspection and data loss prevention (DLP) reduce exfiltration risks across all access paths.Routing traffic through centralized inspection points increases&nbsp;latency and complexity. SSE delivers cloud-based policy enforcement closer to the user, so traffic doesn’t need to be routed through a central data center. By converging networking and security into a single architecture,&nbsp;SASE helps address the following problems:&nbsp;Tooling sprawl introduces unnecessary complexity. SASE consolidates fragmented point products into a single architecture.Enforcing policies consistently across a global enterprise becomes nearly impossible with point products. SASE eliminates enforcement gaps by applying consistent security policies across locations, users, and cloud environments.It’s hard to get visibility into your operations, networking, and security. SASE brings connectivity and security controls under unified management, which removes monitoring blind spots and speeds up troubleshooting.Security teams struggle to scale with traditional networking and security solutions, which are limited by their appliance-based architectures. SASE is cloud native and helps security services scale with rapid business growth.&nbsp; What are the key differences between SSE and SASE?&nbsp;SSESASEScopeIncludes security services like CASBs and SWGs, but excludes networking services.Brings together security and networking services into one solution.Goals of deploymentStreamlined security services for distributed workforces, without the operational lift required to rearchitect existing networking infrastructure. Designed for organizations that need to secure their remote workforce, but can’t rearchitect their entire WAN.Consistently delivered security and networking for remote workforces. Requires that organizations have the time, resources, and flexibility to modernize their architecture in a phased approach.Operational differencesDriven by security teams, with minimal disruption to existing networks.Deployment is broader in scope because it integrates WAN transformation and requires co-ownership by both security and networking teams.Use case examplesA SaaS company in the healthcare industry faces pressure from the board to reduce its ransomware risk. The security team knows that its legacy VPN is a major source of risk, and they need to find a more secure solution as soon as possible.A global manufacturing organization has an upcoming WAN refresh and wants to standardize remote connectivity for their distributed workforce. The organization has consistent M&amp;A activity and the security team needs a solution that can easily integrate new infrastructure and onboard new users.&nbsp; When to start with SSEYou’ll want to begin with an SSE implementation when:You’re frustrated with your VPN.&nbsp;If your VPN has performance issues, scaling problems, or operational overhead concerns, you’ll want to prioritize a faster SSE adoption over a more comprehensive SASE implementation.&nbsp;VPN issues are typically an access or security problem, and SSE’s ZTNA capabilities can replace or reduce reliance on your legacy VPN. With SSE, you can fix VPN issues without waiting for a complete WAN redesign.There’s pressure to reduce your ransomware risk. SSE is also a good choice if there’s organizational pressure to reduce your exposure to&nbsp;ransomware.&nbsp;SSE lets you move to identity- and context-based access on the application level without needing to wait for a broader SASE implementation. With SSE, you can tighten access controls quickly.&nbsp;Your SD-WAN or WAN is “good enough.”&nbsp;If you have long-lived carrier contracts, a stable branch topology, or no organizational appetite to rearchitect your WAN, SSE can plug into your existing WAN.&nbsp;Your organization is cloud and SaaS-heavy, and you need improved security today.&nbsp;Implementing SSE is a great first step towards simplifying your security stack and consolidating your web, SaaS, and private app controls into a single cloud service. With SSE, you can streamline how you protect SaaS data, implement least-privileged access, and secure your remote workforce in one platform.Once you implement SSE, you can move towards a more complete SASE architecture when it’s right for your organization.&nbsp; When to prioritize SASEIf you’re deciding whether or not you want to start with SSE or move straight into SASE, you’ll want to choose SASE when:&nbsp;You’re already doing a WAN refresh.&nbsp;If you’re approaching an MPLS renewal, redesigning your branch footprint, or planning an SD-WAN overhaul, it’s more efficient to modernize networking and security at the same time.&nbsp;You need consistent policy delivery across branches, users, and cloud workloads.&nbsp;If your current approach creates security policies based on where traffic originates, adopting a SASE framework will help standardize policy enforcement, reduce policy drift, and align performance and security outcomes.&nbsp;SASE is especially useful for organizations with branch-heavy footprints, like in the retail, finance, or manufacturing sectors.&nbsp;You want a single platform and need a simplified rollout strategy.&nbsp;If your organization has many locations that require a repeatable rollout model, SASE is the best option. A single platform will help you deploy and maintain consistency across sites at scale, improve troubleshooting, and simplify management of networking and security stacks.&nbsp; Can you do SSE now and SASE later?Yes. Many organizations first adopt SSE for its inline security benefits, and continue to use their existing WAN or SD-WAN. Then, when a planned WAN refresh or broader network modernization project comes up, those organizations use that as an opportunity to move into a&nbsp;full SASE implementation.&nbsp;With a&nbsp;phased convergence approach, organizations get the risk reduction benefits sooner while giving their networking and security teams time to create the larger convergence plan. Choosing the right vendor for SSE and SASEAs you plan out your organization’s security and networking future, keep in mind that not all SSE and SASE platforms will work with you each step of the way. You’ll need to find a vendor that delivers comprehensive&nbsp;SSE capabilities on a unified architecture. And that vendor must be able to help you scale into a&nbsp;complete SASE implementation when your organization is ready.Whether you’re securing your remote workforce today with SSE or converging your networking and security over time, you’ll need a vendor that understands the&nbsp;path to SASE.&nbsp;&nbsp;Want to learn more about Zscaler SSE and SASE?Download the 2026 Gartner Magic Quadrant reports for SSE and SASE.&nbsp;Request a demo to see Zscaler in action.&nbsp;]]></description>
            <dc:creator>Julia Benson (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[An AI Agent That Can’t See the Whole Path Is Just a Faster Way to Be Wrong]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/ai-agent-can-t-see-whole-path-just-faster-way-be-wrong</link>
            <guid>https://www.zscaler.com/blogs/product-insights/ai-agent-can-t-see-whole-path-just-faster-way-be-wrong</guid>
            <pubDate>Wed, 01 Jul 2026 18:16:39 GMT</pubDate>
            <description><![CDATA[For the IT leader who owns the service desk — and the escalation queue that never empties.The pitch landing in your inbox right now is some version of this: put an autonomous agent on top of your monitoring stack, and it will correlate everything, find root cause, and drain your queue. The agent is the hero. Buy the agent.Here’s the uncomfortable part. The agent is not the only problem, and correlation was never your bottleneck. Statistical correlation across signals has been a shipping feature in this category for the better part of a decade, and it did not empty anyone’s queue. What’s new in the current wave is real — an agent can now form a hypothesis, pull the telemetry that would confirm or kill it, and chain those steps until it converges, instead of running one canned correlation rule. That’s a genuine capability shift.But it changes nothing if the agent is reasoning over a partial view of the path. Point a fluent reasoning engine at one segment of a multi-domain problem and it will hand you a confident, well-argued, completely wrong root cause — at machine speed, with a paragraph of justification.&nbsp;Human uncertainty at least escalates with a question mark attached. A partial-view agent escalates with a period. Fluency is not the same thing as being right, and the failure mode of these systems is confident wrongness, not silence.So the variable that actually decides whether agentic operations works for you isn’t the model. It’s field of view. And almost no monitoring stack has it. A worked traceConsider a scenario that defines the operational drain on a modern service desk: a sudden influx of tickets from a branch office reporting that "everything is slow." This is the classic "seam" incident. Because the problem lives between domains, the triage process traditionally triggers a serial chain of escalations—the network team checks their pipes, the app team checks their servers, and the ticket ping-pongs for days while productivity stalls.This friction is exacerbated when teams rely on disparate tools, each with its own data definition. For the Service Desk, Network, and App teams to effectively collaborate, they must agree on a common source of truth. When teams use different tools, the correlation process itself becomes a point of failure, as each tool views the same event through a different lens. When an agent and the human teams reason over the same shared telemetry, correlation and elimination become accurate, standardized tasks rather than points of contention.In this environment, the managerial outcome is dictated entirely by the agent’s field of view across these silos:&nbsp;A&nbsp;Device-Only View sees a healthy laptop and a strong signal. Lacking visibility into the transport or the backend, the agent is forced to guess. It hands the service desk a confident—but wrong—recommendation to escalate to the application team.An Application View sees the application responding normally. It exonerates the app and points the finger back at the local network. The result is a stalemate that ensures the ticket stays open.&nbsp;A&nbsp;Full-Path View changes the operational strategy. By seeing the device, the Wi-Fi contention, the ISP path, and the application response simultaneously, the agent can perform parallel elimination. It identifies the exact point of friction—a local interference issue—at minute one.This isn't just a faster way to find a root cause; it is a way to stop escalations before they happen. When an agent has a complete aperture, it converts a complex, multi-day investigation into a resolved issue at the service desk level. The intelligence of the model is secondary to the visibility of the path; without that path, the agent is simply automating the same guessing game that exhausts your team and inflates your MTTR.Same model. Same reasoning ability. The only difference between the right answer and three days of inter-team blame is whether the agent could see all four segments simultaneously. That is the whole argument. The intelligence was never the constraint; the aperture was. The real machine-speed advantage isn’t speed of correlation — it’s parallel eliminationHere’s the mechanic worth understanding, because it’s the one that survives scrutiny. A human troubleshoots serially: check the wireless, rule it out, check the ISP, rule it out, check the app. Each step is gated on the last, and each step costs a context switch and often a different tool and a different person. That serial chain is most of your mean-time-to-resolution, and most of your escalations — every handoff is a place where someone runs out of visibility and passes the ticket.A full-path agent doesn’t troubleshoot faster in the sense of doing the same serial steps quicker. It runs the hypotheses&nbsp;in parallel — coverage, contention, last-mile, peering, backend, device resource — and for each one queries the specific telemetry that would confirm or refute it, then prunes the tree in a single pass. The advantage isn’t that it correlates quickly. It’s that it eliminates concurrently what a human can only eliminate in sequence, and it never loses visibility at a handoff because there is no handoff. That only works if the evidence for every branch is in reach. Branches the agent can’t see don’t get pruned — they get guessed. Why this is deployable now: gate autonomy on the right axisThe objection you’ll raise next is the correct one: an agent that’s right most of the time still acts wrong some of the time, and “most of the time” is not a number you bet production on. Agreed. The answer isn’t a better confidence score. It’s gating autonomy on three axes at once — confidence, reversibility, and blast radius:High confidence, reversible, contained → let it act. Recommending a channel redistribution, surfacing a tunnel-bypass candidate, flushing a cache. If it’s wrong, you roll it back in seconds and nothing downstream noticed.Touches a user’s machine, touches many users at once, or can’t be cleanly undone → the agent does everything up to the commit, then hands a human the decision. Killing a hung process on someone’s endpoint, a failover, a config push to a production path. Note that “kill a process” sits on the human-commit side even though it’s technically reversible — blast radius isn’t only how many users are affected, it’s whether the person on the other end loses work they can’t get back. The agent builds the case; a human owns the commit.Reversibility and blast radius are properties you can reason about in advance and encode as policy. Confidence alone isn’t — it’s the axis vendors wave at because it’s the easiest to put on a slide. Build the gate on all three and you get an agent that does the investigation grunt work autonomously and stops at exactly the line where being wrong gets expensive. That’s not “deploy and forget.” It’s the only version that’s honest about the failure mode. What it does to your teamIt removes the part of L1 and L2 work that was never judgment in the first place — the serial elimination, the tool-hopping, the “I’m not sure so I’ll escalate” reflex. What’s left is the part that was always the actual job: validating the agent’s reasoning, catching the case where it’s confidently wrong, encoding domain logic the agent doesn’t have yet, and fixing the visibility gaps that cap what it can do. The honest framing isn’t “the agent replaces triage.” It’s “the agent makes triage a reasoning job instead of a fetching job,” which is a better job and a harder one to staff for badly. Monday morningDon’t evaluate an agent yet. Measure your field of view first, because that number is the ceiling on anything an agent can do for you.Pull your last 20 escalations that bounced between two or more teams — the network-versus-app ping-pong tickets specifically. For each one, ask a single question:&nbsp;at the moment of triage, could any one pane of glass have shown all the segments of the path at once? Not “did someone eventually figure it out” — could the full path have been seen in one view at minute one.Count them. The ones where the answer is yes are the tickets an agent could actually resolve, because the evidence was reachable. The ones where the answer is no would have produced the same confident wrong guess from an agent that they produced from a human — faster, and with better grammar.That ratio is your agentic-operations ceiling. If most of your seam tickets fail the test, your problem isn’t that you lack an agent. It’s that you lack the view, and buying an agent first just automates the guessing. Fix the aperture, then give the agent something worth reasoning over.The question to take into your next vendor conversation isn’t “how smart is your agent.” It’s “show me the one view where it sees the entire path.” If they can’t, the intelligence on top doesn’t matter. See what full-path looks like in practiceEverything above is a design principle: an agent is only as good as the path it can see, and only as safe as the actions it’s allowed to take unsupervised. That principle is the entire premise behind Zscaler Digital Experience — end-to-end visibility across device, local network, ISP, and application from a single inline vantage, with the reasoning and remediation built on top of that view rather than bolted onto a partial one.Ultimately, the agent is only as powerful as the view it has. When you combine full, end-to-end path visibility with the reasoning capability of a modern agent, you stop guessing and start resolving. The agent ceases to be a liability that escalates at machine speed and becomes a force multiplier that eliminates failure points in parallel—turning the resolution from a multi-day ping-pong match into a single, automated pass. That is the true solution: when the agent has the full aperture, the war room becomes an unnecessary relic of the blind-spot era.See how it works&nbsp;]]></description>
            <dc:creator>Rohit Goyal (Sr. Director, Product Marketing - ZDX)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Five Eyes Cyber Agencies Signal a New AI Security Consensus: “We Must Act Now”]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/five-eyes-cyber-agencies-signal-new-ai-security-consensus-we-must-act-now</link>
            <guid>https://www.zscaler.com/blogs/product-insights/five-eyes-cyber-agencies-signal-new-ai-security-consensus-we-must-act-now</guid>
            <pubDate>Tue, 30 Jun 2026 19:04:08 GMT</pubDate>
            <description><![CDATA[On 22 June 2026, the cybersecurity agencies of Australia, Canada, New Zealand, the United Kingdom, and the United States (collectively known as the Five Eyes) issued a call for action titled&nbsp;“The AI Shift in Cyber Risk: Why Leaders Must Act Now.”AI-enabled cyber threats are significant enough for the Five Eyes governments to appeal directly to leaders of organisations to take immediate action. They recommend leaders embed cybersecurity into core business strategy before AI further accelerates the advantage for attackers. The statement captures the urgency clearly:&nbsp;“AI is not a future consideration – it is already here. It lowers barriers for malicious actors and increases the speed and complexity of attacks, shrinking the window between vulnerability discovery and exploitation ever more quickly.”&nbsp;In this new threat environment, the first priority is to reduce the number of reachable targets, because organizations cannot assume they will always identify and patch vulnerabilities before attackers find and exploit them. The Five Eyes therefore recommend organizations reduce their attack surface as the most important action. The Convergence of Government Guidance and Security ResearchThe Five Eyes agencies recommend five practical actions:Reduce attack surface.Accelerate patching processes.Address legacy systems.Review and strengthen identity and access controls.Prepare for incidents before they happen.These recommendations closely align with the lessons identified in Antrophic’s&nbsp;Zero Trust for AI Agents framework and in Zscaler’s own research. As noted in our&nbsp;preliminary security research published on Anthropic Mythos and OpenAI GPT 5.5,&nbsp;these systems are becoming increasingly effective at tasks traditionally associated with offensive cyber operations, including reconnaissance, vulnerability discovery, and operational scaling. AI does not just replace human attackers. Rather, it dramatically increases their efficiency. The Five Eyes agencies are addressing this trend from a policy perspective with their guidance mapping to security researcher’s findings.&nbsp; The Five Eyes Five Actions Organizations Should Take Now1.&nbsp;Reduce Attack Surface“Limit unnecessary system access and external connectivity. Challenge whether systems need to be exposed at all and isolate those that do not.”&nbsp;&nbsp;The agencies place attack surface reduction first for a reason. Every exposed application, unmanaged asset, open network path, and implicit trust relationship creates an opportunity for attackers. AI increases the likelihood that these opportunities will be discovered and exploited quickly. The most straightforward risk reduction step is therefore to eliminate internet exposureOrganizations should focus on:Eliminating unnecessary internet exposureRestricting network connectivityReducing implicit trustImplementing application segmentationProviding access based on identity rather than network locationZscaler helps organizations reduce attack surface by eliminating direct exposure of applications and services to the internet, connecting users securely to applications rather than extending network access.2. Accelerate Patching Processes“AI is shortening the time between vulnerability discovery and exploitation. Delays in patching increase risk, especially for operational systems with long update cycles. Prioritise security updates accordingly to manage risks.”&nbsp;The agencies note that AI is shortening the time between vulnerability discovery and exploitation.However, most organizations do not suffer from a lack of vulnerability data. They suffer from a lack of prioritization.Security teams increasingly need to understand which vulnerabilities create meaningful exposure and which do not. Effective remediation requires context around exploitability, asset criticality, and exposure pathways rather than simply counting vulnerabilities.Organizations that combine exposure management with risk-based prioritization are better positioned to focus resources where they matter most.Zscaler helps security teams understand which vulnerabilities are genuinely reachable and exploitable, enabling organizations to focus remediation efforts on the risks most likely to impact the business.3.&nbsp;Address Legacy Systems“Unsupported systems are easy targets. They are not just technical debt, they are strategic liabilities.”&nbsp;Many critical systems were designed for an era that assumed trusted networks and predictable threats. They often lack support for modern authentication, visibility, segmentation, and monitoring capabilities.While modernization remains the ultimate objective, organizations can reduce risk immediately by isolating legacy environments, restricting access, and limiting unnecessary connectivity. Zscaler enables organizations to apply modern access controls and segmentation around legacy environments, reducing risk while modernization programs are underway. By isolating unsupported systems, restricting access, and preventing lateral movement, organizations can protect critical assets without the cost and disruption of immediate large-scale replacement. This approach also delivers measurable ROI by reducing reliance on legacy firewalls and other appliance-based infrastructure, lowering operational complexity and cost over time.&nbsp;4.&nbsp;Review and Strengthen Identity and Access Controls“Limit who can access critical systems. Enforce strong authentication and regularly review permissions.”&nbsp;The Five Eyes crucially lead with “Limit who can gain access to critical systems” in this section. In practice, this means shifting from broad, implicit access to a model where every user, device, AI agent and session is explicitly verified before reaching sensitive resources. Least-privilege access ensures any user or AI agent receives only the minimum level of access required to perform roles. As AI enhances phishing campaigns, credential theft, and social engineering attacks, organizations can no longer rely on network location as proof of trust.Strong identity controls should include:Multi-factor authenticationLeast-privilege accessContinuous verification&nbsp;Device posture assessmentRegular permission reviewsThe goal is not simply to authenticate once. It is to continuously validate trust throughout every interaction. Zscaler’s identity-centric approach ensures access only to the applications and resources needed, based on continuously evaluated risk and context.5.&nbsp;Prepare for Incidents Before They Happen“Test response plans, train and prepare teams, and assume breaches will occur. Focus on fast containment and recovery.”&nbsp;The agencies explicitly advise organizations to assume breaches will occur throughout the guidance not just under this action. This reflects a broader shift from prevention-focused security toward resilience-focused security. No organization can prevent every attack. The objective is to limit the impact of successful attacks through containment, visibility, response readiness, and recovery planning.Organizations that assume compromise are often better positioned to withstand it. Zscaler’s segmentation, visibility, and policy enforcement capabilities help organizations contain incidents, limit lateral movement, and reduce operational impact when breaches occur. Using AI to Defend Against AIThe Five Eyes agencies emphasize, in a standalone section of the guidance, the importance of using AI to strengthen defense.This reflects a simple reality: attackers are already benefiting from AI-enabled capabilities. Defenders must do the same. This is an area where Zscaler has been investing heavily. As AI evolves from chat interfaces to autonomous agents capable of accessing enterprise data, invoking tools, and interacting with other agents, organizations need visibility and control over how those systems operate.&nbsp;As outlined in our recent blog,&nbsp;How Zscaler Secures the Agentic AI Era with Zero Trust, organizations should apply the same principles that have proven effective for users and workloads.&nbsp;Zscaler’s complete Zero Trust platform for Agentic AI helps organizations understand what AI systems can access, govern interactions between AI agents and enterprise resources, protect sensitive data, and reduce the risk of unintended or unauthorized actions. As organizations increasingly use AI to defend against AI, securing AI itself becomes an essential component of cyber resilience.AI can help organizations:Discover vulnerabilities earlierPrioritize remediation effortsDetect anomalies fasterAccelerate investigationsImprove response timesReduce analyst workloadOrganizations that fail to adopt AI-enabled security capabilities risk creating an asymmetry that favors attackers. A Policy Signal Worth Paying Attention ToFive Eyes statement reinforces principles that security leaders have been discussing for years: reduce exposure, strengthen identity, limit trust, build resilience, and prepare for compromise.&nbsp;The difference is the urgency in which the message is being conveyed and the speed in which leaders of organizations must now act. The message from both policymakers and practitioners is clear. The organizations best positioned to succeed will not necessarily be those that simply patch the fastest. They will be the ones that expose the least, trust the least, and recover the fastest.Zscaler can help organizations turn this call for action into immediate action by reducing exposure, enabling zero trust, and strengthening resilience.&nbsp;]]></description>
            <dc:creator>Adam Dobell (Head of Government Affairs, APJ)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What’s New in GovCloud: June 2026 Zscaler Product Updates]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-june-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-june-2026-zscaler-product-updates</guid>
            <pubDate>Tue, 30 Jun 2026 13:03:32 GMT</pubDate>
            <description><![CDATA[Keeping pace with product releases while balancing mission priorities, operational demands, and compliance obligations is no small task. To help, here is a curated roundup of notable Zscaler GovCloud updates from June, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include AI/ML detection source visibility for ZIA traffic, IPSec security enhancements aligned to FedRAMP and FIPS requirements for Zero Trust Branch, new device health monitoring capabilities in ZDX, and expanded DLP collaboration scoping for Microsoft Teams.&nbsp; 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 focus on expanding visibility into AI-driven threat detection, strengthening data loss prevention for collaboration platforms, and continuing to refine governance controls for generative AI usage.HighlightsSupport for AI/ML Detection Source: The Zscaler Admin Console now provides visibility into the AI/ML detection source for Internet &amp; SaaS (ZIA) traffic. This gives security teams greater transparency into how threats are identified, supporting more informed policy decisions and audit responses.Support for Collaboration Scope for Microsoft Teams: When creating a DLP rule for Microsoft Teams, administrators can now define the collaboration scope as External, Internal, or Any to scan messages and attachments in channels containing external, internal, or any (internal or external) members. This enables more targeted data protection aligned to organizational boundaries and mission-partner communication flows.Policy Level Gen AI Prompt Configuration: Customers can capture end user prompts for generative AI applications from the Cloud Application Control policy. This allows granular control of Gen AI prompt configuration and supports tighter governance as Gen AI adoption grows across teams and roles.For full release notes:&nbsp;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 authentication flexibility for dual-stack environments and a new Private Service Edge release focused on stability and operational improvements.HighlightsAuthentication Settings Update: The Zscaler Admin Console now supports selecting an alternative authentication SP host for an IdP in authentication settings. The alternative authentication SP hosts support dual-stack environments for use with IPv4 and IPv6 infrastructure and application support, helping agencies manage environments transitioning to IPv6 while maintaining backward compatibility.Private Service Edge Version 26.53.4: An update was released for Private Service Edge for Private Access (ZPA) that includes bug fixes, optimizations, and version enhancements.For release notes:&nbsp;https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Digital Experience (ZDX)Zscaler Digital Experience (ZDX) provides visibility into end-user device health, application performance, and network path quality. For federal teams managing distributed endpoints across agencies and field locations, ZDX helps identify and resolve experience issues before they impact productivity or mission delivery.This month's ZDX updates introduce new reporting and dashboard capabilities that give IT and operations teams broader insight into device health trends across the organization.HighlightsDevice Events Reports: Device Events reports are now available in the ZDX Admin Portal, providing aggregated insights into common system and software crashes. This helps teams identify recurring issues and prioritize remediation efforts across the fleet.Device Health Dashboard: The new Device Health dashboard provides a comprehensive view of struggling devices across an entire organization, department, user group, or location. This supports faster identification of systemic issues and more proactive endpoint management at scale.For more information:&nbsp;https://help.zscaler.us/zdx/release-upgrade-summary-2026 Zero Trust Branch (ZTB)Zscaler 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 updates focus on strengthening cryptographic controls and enhancing DNS security to align with federal compliance requirements.HighlightsSupport for DNSSEC: Zero Trust Branch now includes DNSSEC support for DNS traffic in both resolver and proxy modes, enhancing security and reliability for DNS resolution at branch locations. This helps protect against DNS spoofing and cache poisoning attacks.IPSec Security Enhancement: IPSec configurations have been updated to align with FedRAMP and FIPS requirements by enforcing IKEv2 and strengthening cryptographic controls where supported. This includes FIPS 140-3 approved ciphers for encryption, secure key exchange mechanisms, and enhanced practices for pre-shared key generation and rotation, helping agencies maintain compliance while securing branch connectivity.ZTB release notes:&nbsp;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 platform maintenance improvements, more granular safe process controls, and reduced false positives for cloud decoy deployments.HighlightsCloud Deception Enhancement: The health check function app for Cloud Deception with Azure was upgraded to Node.js v24.x. Administrators must run the deployment script to sync the latest code and runtime configuration.Support for Detection Types and Subtypes in Safe Processes: Landmine agents for Windows and macOS endpoints now support defining safe processes at a granular level based on detection types and subtypes. This reduces alert noise and helps teams fine-tune detection sensitivity without sacrificing coverage.Updates to GCP Decoy Deployment: An update was released for Terraform user agent configuration that reduces false positive events during Google Cloud Platform (GCP) decoy deployments, improving signal quality for security operations teams.Full release notes:&nbsp;https://help.zscaler.us/deception/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.]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[SSE Components Explained: SWG, ZTNA, CASB, and How They Work Together]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/sse-components-explained-swg-ztna-casb-and-how-they-work-together</link>
            <guid>https://www.zscaler.com/blogs/product-insights/sse-components-explained-swg-ztna-casb-and-how-they-work-together</guid>
            <pubDate>Mon, 29 Jun 2026 22:12:17 GMT</pubDate>
            <description><![CDATA[Security service edge (SSE) is a cloud-delivered security framework that consolidates web filtering, zero trust network access, and cloud data protection into a unified, policy-driven architecture.&nbsp;As remote work and SaaS adoption dissolve traditional network perimeters, legacy solutions like&nbsp;VPNs can’t keep up. That’s where SSE comes in.SSE shifts security from the data center to the edge and provides unified security that scales with your business.&nbsp;This post breaks down the three core components of SSE: secure web gateway (SWG), zero trust network access (ZTNA), and cloud access security broker (CASB). We’ll explain each component’s role in your security stack and show how these services converge into a cohesive security layer that protects every user regardless of location. What does a SWG do?&nbsp;Secure web gateways give visibility into threats hidden in HTTPS connections. Most modern threats don't arrive in plaintext. According to&nbsp;Zscaler ThreatLabz research, 86% of threats, including malware, phishing, drive-by downloads, and ransomware, are delivered over encrypted HTTPS traffic.&nbsp;Without TLS/SSL inspection, which decrypts, inspects, and re-encrypts traffic in real time, these threats pass through undetected. That's what makes an SWG a critical first line of defense in any web security strategy.SWG core capabilitiesSWG solutions include the following capabilities:&nbsp;&nbsp;TLS/SSL inspection: Decrypts and inspects HTTPS traffic to surface threats hidden in encrypted connections.URL filtering: Scans traffic and blocks access to malicious websites based on URL categorization.In real time web content inspection: Identifies and blocks malware, ransomware, and exploits.Cloud sandboxing: Detonates suspicious files in an isolated environment to analyze behavior before users can access those files.User and access policy enforcement: Enforces role-based internet access policies by user, group, and device.Advanced threat protection: Flags zero-day threats, phishing risks, and&nbsp;command-and-control (C2) traffic. What does ZTNA do?&nbsp;Zero trust network access operates on the "never trust, always verify" principle. It grants users least-privileged access to private applications while hiding them from the public internet.&nbsp;Traditional VPNs grant broad network access once a user authenticates. ZTNA takes a different approach. It continuously verifies identity, device health, and context throughout every session, which eliminates the lateral movement risk that makes VPN-based architectures a persistent target.&nbsp;Zscaler ThreatLabz research findings reinforce this urgency: 70% of organizations lack visibility into AI-enabled threats traversing VPNs, and 54% struggle with lengthy patch windows for critical vulnerabilities.ZTNA core capabilitiesZero trust network access includes the six following core capabilities:&nbsp;Location-agnostic policy enforcement:&nbsp;Applies policies consistently regardless of user location.Identity and device verification: Continuously authenticates and validates user identity, behavior, device health, and context before and during each session.Application-level microsegmentation: Users see only the specific apps that they're authorized to use. Private applications are hidden from the public internet.AI-driven policy automation: Machine learning-powered analysis suggests microsegmentation rules, detects anomalies, and auto-adjusts privileges to prevent policy sprawl.Least-privileged enforcement:&nbsp;Grants the minimum access necessary for a user to complete a task.&nbsp;Full session inspection: Inspects sessions inline for&nbsp;data loss prevention (DLP), threat detection, and compliance logging. What does a CASB do?A cloud access security broker is a security checkpoint between users and SaaS applications. It provides visibility into SaaS app usage and enforces security policies.As SaaS apps and AI have risen in popularity, data breaches are now more frequent and more expensive. In 2025, the average data breach cost $4.44M, according to&nbsp;IBM’s 2025 Cost of a Data Breach Report. CASB helps organizations control shadow IT, ensure compliance, and protect sensitive data across all cloud services.&nbsp;CASB core capabilitiesHere are seven core capabilities to look for in a CASB solution:Shadow IT discovery:&nbsp;Provides visibility into all cloud app usage across the organization and surfaces&nbsp;shadow IT risks.&nbsp;SaaS access control: Enforces granular, least-privileged access to cloud apps.App governance and compliance: Enforces data security policies and generates reports to help maintain compliance with regulatory frameworks.Threat protection: Identifies and mitigates risks like compromised accounts, insider threats, and anomalous user behavior.Encryption and tokenization: Encrypts or tokenizes sensitive data that is stored in or transmitted through cloud apps.Data loss prevention (DLP): Prevents unauthorized data transfers between cloud apps.Multimode capabilities:&nbsp;Includes both inline and API-based functionality.An aside: What is multimode CASB?Multimode CASB includes both inline and out-of-band CASB functionality. Inline CASB intercepts traffic inline and enforces security policies in real time, whereas API-based CASB connects directly to cloud platforms to protect cloud data.Without a multimode approach to CASB, enterprises can’t get visibility or control over data at rest in the cloud. They also can’t block threats or enforce policies in real time. How SWG, ZTNA, and CASB work together in an SSE platformWhen SWG, ZTNA, and CASB work together in one SSE platform, they use a unified architecture, which includes a single policy engine and shared identity context. This architecture allows security teams to apply policy consistently across all users and traffic types:SWG secures the web-bound traffic users generate.ZTNA secures the private applications users need to access.CASB secures the SaaS and cloud environments where users collaborate.A single policy engine simplifies security enforcementInstead of maintaining separate rule sets for web traffic, private application access, and cloud app usage, administrators define policies once and then enforce them everywhere. Identity, device posture, location, data classification, and risk signals all feed into the same decision-making framework within the SSE platform.&nbsp;Let’s go through an example of how this works in practice. If a contractor logs in remotely from an unmanaged device, SSE’s single policy engine will:Direct ZTNA to grant limited access to only the specific private app that contractor is authorized to access,Instruct SWG to restrict the contractor’s web browsing and block risky sites, andTells CASB to enforce read-only policy on any cloud storage apps so that the contractor can’t upload or download sensitive files.&nbsp;And if the contractor’s risk profile changes mid-session, the policy engine can dynamically adjust controls without administrator input.&nbsp;Shared identity context enables granular decision-makingSWG, ZTNA, and CASB can work from a shared identity context that includes information about the user’s group memberships, their real-time risk score, and their device posture.&nbsp;Because these technologies use the same context signals, the SSE platform can leverage that shared context to make granular and adaptive decisions that go beyond “allow” and “deny.”For example, a user who accesses a SaaS app from a managed and compliant device can be granted full read and write access. But the SSE platform will restrict that same user to read-only access with blocked download abilities if they sign into the same SaaS app using an unmanaged personal device.&nbsp; Why a platform approach to SSE mattersSecurity service edge is a powerful tool against modern threats like&nbsp;AI-driven attacks.By moving away from fragmented point solutions and embracing a unified SSE platform, organizations can use one architecture to secure everything from web traffic to private application access and SaaS applications.Zscaler powers this transformation through the AI-powered, cloud native&nbsp;Zero Trust Exchange. By partnering with Zscaler, enterprises can confidently adopt SSE, replace their legacy security appliances, simplify their security stack, and address emerging AI risks.&nbsp;&nbsp;&nbsp;Ready to learn more about SSE?Download the 2026 Gartner Magic Quadrant report for Security Service Edge (SSE) and see why Zscaler was recognized as a Leader.Request a demo to see Zscaler SSE in action.&nbsp;]]></description>
            <dc:creator>Julia Benson (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[AI in Cybersecurity: Key Benefits, Real Risks, and How to Manage Both]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/risks-and-benefits-of-ai-in-cybersecurity</link>
            <guid>https://www.zscaler.com/blogs/product-insights/risks-and-benefits-of-ai-in-cybersecurity</guid>
            <pubDate>Fri, 26 Jun 2026 19:36:49 GMT</pubDate>
            <description><![CDATA[What Is AI in Cybersecurity?&nbsp;AI in cybersecurity is the use of artificial intelligence in security operations that helps organizations detect threats, protect sensitive data, and respond to incidents by analyzing large volumes of activity, recognizing patterns, and automating decisions, so security teams can reduce risk and defend at greater speed and scale.&nbsp;AI is becoming central to cybersecurity because it helps defenders move faster and scale more effectively, but those gains only hold if organizations manage the new risks AI brings with it.&nbsp;AI improves security operations: It helps teams detect threats faster, prioritize incidents more accurately, reduce alert fatigue, and strengthen data protection at scale.AI also creates new risks: Prompts, embedded AI features, developer tools, third-party models, and integrations can introduce data leakage, prompt injection, shadow AI, supply chain risk, and compliance gaps.Managing AI requires lifecycle controls: Effective programs combine visibility into AI use, access governance, inline protection for prompts and responses, continuous testing, and compliance mapping.Success depends on balancing benefit with control: Organizations get the most value from AI when they treat it as a full lifecycle security issue, not just another tool to deploy.&nbsp; Why AI Is Becoming Central to Security WorkModern enterprise environments produce too much telemetry for humans to process manually, and adversaries have started operating at machine speed. AI helps by automating analysis and accelerating response across environments that change faster than static rules can keep up with.&nbsp;At the same time, the widespread adoption of generative AI and AI agents has created a new category of entry points: prompts, plugins, browser-based tools, embedded AI in SaaS, and developer toolchains. Those interaction paths create opportunities for data exposure, policy violations, and model manipulation, even when the rest of the environment looks locked down. The Benefits of AI in CybersecurityAI's impact on security tends to concentrate in a few areas: faster detection, sharper prioritization, better coverage, and less analyst burnout.Faster detection and response at scale: AI can sift through large datasets, identify anomalies, and help teams respond before dwell time compounds the damage. In high-volume environments with distributed workforces and cloud-first stacks, where security events are constant, this is where the difference gets felt.Detection for threats that have no signature: Static rules catch known patterns. AI systems identify behavioral deviations, which makes them better suited for novel phishing variants, new malware behaviors, and subtle account abuse. As attackers increasingly use AI to improve reconnaissance and craft more convincing lures, behavioral detection becomes harder to skip.Reduced alert fatigue: AI helps security teams stay focused by filtering low-signal noise, clustering related events, and enriching incidents with context before analysts ever touch them. The result isn't fewer threats, it's less time wasted before reaching the ones that matter.Smarter data protection: AI doesn't just create data risk; with proper controls, it can enforce data security more precisely than rule-based systems alone. Organizations using AI-driven policy can detect sensitive data in motion, reduce oversharing into AI tools, and catch inadvertent leakage through prompt inputs and model outputs, which matters as more employees use GenAI daily.Fighting AI with AI: Threat actors are operating with automation and speed. Defenders need detection and enforcement that can run at the same velocity, particularly for inline decisions where a few milliseconds determines whether a prompt gets blocked or sensitive data leaves the organization. Traditional Cybersecurity vs. AI-Enhanced CybersecurityTraditional controls still matter. What changes with AI is not the goal of security, but the operating model: instead of relying primarily on static logic and manual review, organizations can use adaptive analysis and automation to keep pace with faster, noisier, and more distributed environments.&nbsp;Traditional CybersecurityAI-Enhanced CybersecurityDetection approachLeans on signatures, fixed rules, and known indicators to identify threatsUses pattern recognition and behavioral analysis to surface suspicious activity, including unfamiliar attack pathsSpeed and scaleBecomes harder to sustain as telemetry volume, users, apps, and cloud services growProcesses large volumes of activity continuously and helps teams act faster across changing environmentsAlert handlingOften requires analysts to sort through high volumes of low-context alerts by handClusters related signals, adds context, and helps prioritize incidents with higher likelihood and impactAdaptabilityPerforms best against threats that resemble patterns defenders have already seenBetter suited to detecting subtle misuse, novel phishing tactics, and emerging behaviors without a clean signature&nbsp; The Risks of AI in CybersecurityAI-related risk isn't one category. It spans technical attacks, data exposure paths, user behavior, and governance failures, and it surfaces anywhere in the AI lifecycle, from training through runtime.Data leakage through prompts, responses, and integrations: Sensitive data leaves organizations through prompt text pasted into GenAI tools, file uploads, model outputs that echo restricted content, and transcripts retained in unexpected places. The data path is frequently non-obvious. A user might only ask a question, but the downstream tool chain may store or route that content to third parties.Shadow AI: Employees adopt AI tools faster than security teams can review them. That leaves unknown vendors, inconsistent policy enforcement, compliance exposure for regulated data, and fragmented visibility into what's being shared and where. You cannot govern what you cannot see.Prompt injection and jailbreaks: Generative AI systems can be manipulated through crafted inputs designed to override instructions, extract sensitive information, or coerce the model into taking unsafe actions. The risk escalates when AI is connected to tools that execute real workflows, such as API calls, record modifications, or automated pipelines.Model integrity failures: Even a fully patched environment can harbor a compromised model. Poisoning during training or fine-tuning, backdoors in model artifacts, and adversarial inputs designed to produce incorrect outputs are all threats that sit outside traditional vulnerability management. Infrastructure hygiene doesn't fix a corrupted model.AI supply chain risk: Enterprises now depend on open-source model repositories, third-party plugins, and external inference APIs. That creates transitive risk: your security posture becomes partly dependent on upstream providers and components you don't control directly.Compliance and governance gaps: AI introduces new accountability requirements: acceptable use policies, auditability across model interactions, documentation of decisions, and alignment to frameworks that are still being written. Without a governance layer, organizations end up with inconsistent controls, unclear ownership, and no reliable way to demonstrate compliance. How to Manage Both Sides: Five Core ControlsThe most effective organizations treat AI security as a lifecycle discipline, not a perimeter problem. That typically means combining five things:&nbsp;Visibility into AI apps, models, agents, datasets, and data flowsAccess control governing which tools people can use and howInline protection that inspects prompts and responses in real timeContinuous testing to surface failures before attackers find themGovernance mapping to both regulatory frameworks and internal standards. Zscaler's approach to AI security aligns to this model across four phasesDiscover: Before risk can be reduced, organizations need visibility: which AI services, models, and agents are deployed, what data they touch, and where misconfigurations or risky entitlements exist. AI Security Posture Management (AI-SPM) provides that 360-degree view, including shadow AI detection and guided remediation.Govern: User-based governance turns unmanaged AI usage into an enforceable program. Organizations can discover which AI apps are active, allow or block access by user or group, control interactions including copy-paste behavior, and apply inline controls to reduce data loss through prompts.Protect: Runtime guardrails reduce risk at the moment prompts and responses happen. Zscaler AI Guard operates as an inline inspection layer, blocking prompt injection attempts and jailbreaks, applying DLP policies to prevent data loss, filtering inappropriate content, and providing real-time alerts for enforcement testing. Many AI risks, particularly leakage and injection, happen during normal daily usage, not during obvious attacks.Prove: AI systems change frequently, and so do the frameworks organizations are measured against. Automated red teaming runs continuous, high-scale tests across the AI lifecycle, maps discovered issues to frameworks including MITRE ATLAS, NIST AI RMF, OWASP LLM Top 10, and the EU AI Act, and tracks remediation in tools like Jira and ServiceNow. The goal is moving from "we think we're compliant" to "we can demonstrate it."AI Is a Force Multiplier for Both SidesAI makes security faster, broader, and more scalable. It also increases complexity, introduces new attack surfaces, and creates new paths to data loss and policy failure. The organizations that come out ahead treat it as a lifecycle security problem from the start: building visibility into their AI landscape, enforcing access before adoption runs ahead of governance, protecting at the point of interaction, and continuously testing what they've built. Waiting until those controls are urgent is a pattern that tends to prove expensive.Discover Zscaler AI Security&nbsp;]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[From Launch to Leadership: Zscaler AI Protect Raises the Bar for AI Security]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zscaler-ai-protect-raises-the-bar-for-ai-security</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zscaler-ai-protect-raises-the-bar-for-ai-security</guid>
            <pubDate>Thu, 25 Jun 2026 22:27:47 GMT</pubDate>
            <description><![CDATA[OverviewSix months ago, we launched Zscaler AI Protect, the industry's first platform built to secure AI from the ground up. At that time, enterprise AI was accelerating fast. Today, it's moving faster still.The pace of change is the point. What took years in traditional security cycles is happening in months with AI. That's why we didn't wait. At Zenith Live 2026, just six months after the initial launch, we're shipping a wave of enhancements to AI Protect that deepen coverage, sharpen controls, and close the gaps that matter most to security teams right now.Here's what's new. AI Asset Management: See Everything That's Running AISecurity teams can't protect what they can't see. AI has spread far beyond sanctioned tools; it's embedded in SaaS traffic, running in cloud environments, and baked into developer codebases. These enhancements give you the full picture.Support for 2,900+ AI Apps: Shadow AI is already in your organization. With visibility across the broadest AI app catalog in the industry, you'll see every tool in use, sanctioned or not.Public Cloud Agent Scanning: AI agents are spinning up across AWS, Azure, and GCP faster than any team can manually track. Automatic discovery and assessment means nothing slips through your cloud footprint.Source Code Scanning: AI i s being written into your applications right now. Risky AI usage and exposed model logic in agentic codebases gets caught before it ever reaches production.AI Code Runtime Scanning: Some threats only emerge when code is actually running. Monitoring agentic code in live environments catches what pre-deployment scans can't.AI Attack Surface Analysis: You can't defend what you haven't mapped. Get a continuous, comprehensive view of every AI asset, connection, and exposure, before an adversary finds it first.Together, these capabilities answer the question every CISO is asking: what AI is actually running in my environment, and where am I exposed?&nbsp; Secure Access to AI: Deeper Controls, Built for How AI Actually WorksKnowing what's running is only half the battle. These enhancements give your security and compliance teams the precision to control how AI is actually used—without slowing down the business.Multi-Turn Prompt Inspection: AI conversations aren't single exchanges. Evaluating the full context across multiple prompts catches risks that a single-turn view would miss entirely.Replay Prompt &amp; Response Activity: Investigations and audits demand the full picture, not snapshots. Every AI interaction is captured and replayable, exactly as it happened.Runtime Protection Enforcement: Policies that only kick in after the fact aren't protection; rather, they're documentation. Enforcement at the moment of interaction stops risk before it lands.Auto-Remediation Policies: Not every violation needs a human in the loop. Detected violations are acted on automatically, reducing response time and freeing your team for higher-stakes work.Anthropic &amp; OpenAI Compliance APIs: Your users are already working in ChatGPT and Claude. Native support for both compliance APIs means your policies follow them there without custom engineering.Bring Your Own Detector: Every organization defines sensitive content differently. Enforce your own detection models natively, so the platform works with your risk profile, not a generic one.Integration with Zscaler Private Access: AI risk doesn't stop at the public cloud boundary. Extending controls to private applications and internal workloads makes your Zero Trust policy truly end-to-end.Visibility without control is just observation. These capabilities turn insight into enforcement across every AI interaction, every environment, every user.&nbsp; Secure AI Infrastructure and Apps: From Deployment to TrustVisibility and access controls address how AI is used. This third layer addresses whether the AI itself can be trusted; and for teams responsible for hardening AI infrastructure, it's where the most consequential new capabilities live.Onboarding Agent: Every new AI tool is a potential risk vector, and manual assessments can't keep pace. The full risk evaluation process is automated, so your team can clear new tools in hours, not weeks.MCP Red Teaming: The Model Context Protocol (MCP) is the emerging standard for agentic AI communication, and it's already being targeted. Automated adversarial testing directly against your MCP servers finds weaknesses before an attacker does.Prompt Hardening Service: Prompt injection is one of the most common and damaging ways to manipulate AI behavior. Systematic hardening at the service level reduces your exposure before it can be exploited.Compliance Heat Map: Governance gaps are easiest to fix before they become incidents. A visual, always-current view of your AI governance posture shows you exactly where you're strong and where to focus next.Deploy fast. Trust what you deploy. That's what this pillar is built for.&nbsp; The Bigger PictureAI Protect launched in January 2026 with a clear thesis: securing AI requires a purpose-built platform, not retrofitted tools. Sixteen new capabilities later, that thesis isn't just holding—it's compounding.Enterprises don't need to choose between AI speed and AI security. They need a platform that makes that trade-off obsolete. That's what we've built, and it's available now.Ready to see it in action? Learn more and schedule a demo.]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Hardening Federal Networks for the Mythos Era: What the AI Executive Order and BOD 26-04 Demand Now]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/hardening-federal-networks-mythos-era-what-ai-executive-order-and-bod-26-04</link>
            <guid>https://www.zscaler.com/blogs/product-insights/hardening-federal-networks-mythos-era-what-ai-executive-order-and-bod-26-04</guid>
            <pubDate>Thu, 25 Jun 2026 22:21:30 GMT</pubDate>
            <description><![CDATA[On June 2, 2026, the White House signed Executive Order (EO) 14409, "Promoting Advanced Artificial Intelligence Innovation and Security," directing urgent defensive hardening of federal civilian, defense, and intelligence networks. Eight days later, CISA issued Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk,” consolidating previous vulnerability remediation guidance into a single, risk-prioritized framework with a three-calendar-day remediation timeline for the most critical vulnerabilities. On June 12, Commerce Secretary Lutnick imposed emergency export controls on certain Anthropic models, restricting access of foreign organizations and individuals due to the models' cyber capabilities. Three policy actions in ten days represent the fastest policy response to an AI capability in U.S. history. Federal civilian CISOs should read them together, because together they tell a clear story: the government believes Mythos-class models have the potential to fundamentally enhance adversaries’ cyber capabilities, and it is demanding that federal networks be hardened accordingly. The urgency is not limited to the United States. On June 22, the leaders of all five Five Eyes cyber security agencies issued a&nbsp;joint statement calling AI-driven cyber risk a matter requiring immediate action. Their message was direct: "The timeline is not years, it is months."&nbsp;Their first recommended action for leaders: reduce your attack surface. Why Mythos Changes the CalculusMythos-class AI can autonomously discover zero-day vulnerabilities, chain multiple low-severity flaws into high-impact exploits, and generate working attack code at machine speed. These same capabilities, applied defensively, can identify and remediate vulnerabilities at a speed that was previously impossible. The policy question, and the operational challenge, is whether defenders can harness them faster than adversaries.Congressional correspondence documented that Mythos identified "thousands of high-severity zero-day vulnerabilities in every major operating system and every major web browser," with more than 99% remaining unpatched as of April 2026. BOD 26-04 acknowledges this directly, stating that "cyber threat actors exploit unpatched vulnerabilities, and their use of AI may further narrow the time defenders have to react between patch release and possible exploitation." CISA noted that only 26% of Known Exploited Vulnerabilities (KEV) catalog vulnerabilities were fully remediated by organizations in 2025, and remediation timelines are getting longer, not shorter.&nbsp;That gap between the remediation timeline BOD 26-04 demands and the pace most organizations actually achieve is the problem the directive was written to close, and it is the gap that architectural defenses must fill when patching alone cannot keep pace. What the EO and BOD Are Really Asking ForThe media coverage of this Executive Order has focused heavily on the voluntary framework for government review of frontier AI models. That debate matters, but it is not the part of the EO that will change how federal agencies operate in the next 90 days.The operational core of EO 14409 is a call to action: harden your network defenses now. The EO directs CISA to issue Binding Operational Directives to expedite cyber defense of civilian federal systems, establish AI-enabled defensive programs, and facilitate access to cybersecurity tools for agencies, state and local authorities, and critical infrastructure operators.&nbsp;That call to action rests on a foundation of Zero Trust doctrine that has been building across administrations for five years since the Solarwinds campaign demonstrated the dangers of attackers moving laterally across networks. EO 14028 directed agencies to adopt Zero Trust architecture in 2021. OMB M-22-09 set specific implementation goals across five pillars in 2022. The DoD Zero Trust Strategy set target-level implementation for all 58 components. EO 14306 selectively revised prior cybersecurity mandates in 2025 but left the Zero Trust directive untouched. The National Cyber Strategy for America, released in March 2026, explicitly calls for Zero Trust, cloud transition, and AI-powered cybersecurity solutions across federal networks. EO 14409 builds directly upon that foundation, and BOD 26-04 enforces it.BOD 26-04 is the first implementing directive under the EO, and its structure makes a direct, measurable case for one of Zero Trust's core tenets: start with reducing your attack surface. The directive prioritizes vulnerability remediation across four variables: asset exposure, KEV status, exploit automation, and technical impact. The most aggressive timeline, three calendar days including forensic triage, applies to publicly exposed assets running known exploited vulnerabilities where exploitation is automatable and yields total control. For context, as noted in a CISA&nbsp;blog post released alongside the BOD, the Verizon 2026 DBIR found the median time to full KEV remediation last year was 43 days. Three days against a 43-day median. That is the gap BOD 26-04 was written to close.The incentive structure is explicit: if your asset is not publicly exposed, the remediation timeline extends. One valid mitigation under the BOD is to remove the system from the internet entirely, which shifts the asset's exposure classification and buys the agency more time to remediate. The message from BOD 26-04 is clear: shrink what is exposed, or prepare to patch at a pace that most agencies cannot sustain today. That is the operational translation of Zero Trust in a Mythos-class threat environment.&nbsp;BOD 26-04 applies to Federal Civilian Executive Branch agencies. But the EO's scope is broader. Section 2(a) directs the Committee on National Security Systems to prioritize the cyber defense of national security systems within 30 days, and Section 2(b) directs the Secretary of War to do the same for Department of War information systems on the same timeline. Implementing guidance from the Department of War should be expected to follow, and defense agencies and contractors should be preparing now rather than waiting for that guidance to arrive. How Federal Agencies Should RespondZscaler's participation in Project Glasswing has given us direct experience with how Mythos-class models find and exploit vulnerabilities. These six steps reflect what we have learned, aligned to the requirements of EO 14409 and BOD 26-04.1. Minimize your attack surface. This is the single highest-leverage action an agency can take, and it is the action most directly rewarded by BOD 26-04's remediation framework. Every internet-facing application and open port is now a liability measured in calendar days. Remove what does not need to be exposed. Make applications invisible to unauthorized users. Eliminate exposed VPNs, gateways, and firewall management interfaces. As our CEO Jay Chaudhry wrote in April: "Legacy security was built on the hope that we could outrun the attacker. In an era of AI-driven exploits, that race is over." Under BOD 26-04, the Zero Trust principles federal agencies have been implementing for five years determine how fast you have to patch. The Five Eyes cyber security agencies' joint statement, issued on June 22, 2026, leads with the same principle: "Challenge whether systems need to be exposed at all and isolate those that do not."2. Implement Zero Trust access best practices. Reducing the attack surface is the first step. The second is ensuring that all traffic traversing the network is inspected and verified. That means inspecting all traffic, including encrypted communications (Transport Layer Security, or TLS, inspection), so that threats hidden in encrypted channels do not pass through uninspected. It means isolating web browsing sessions for risky or uncategorized sites so that malicious content never reaches the endpoint. And it means continuously verifying the identity and posture of every user and device before granting access to any application. Mythos-class threats are designed to evade traditional defenses. Inline inspection that applies threat detection to all traffic, encrypted or not, catches what legacy perimeter tools miss.3. Minimize the impact of breach. Even with a reduced attack surface and strong access controls, agencies must assume that determined adversaries will gain initial access. The goal is to contain the blast radius. Place users on segmented networks. Enforce application-level segmentation so that a compromised endpoint cannot reach unrelated systems. Deploy decoy environments that force attacker interaction on your terms, exposing adversary presence early and increasing their cost at every stage. The Cloud Security Alliance's Mythos&nbsp;strategy briefing, reviewed and signed off by more than 80 CISOs, identified deception as one of the highest-priority capabilities organizations should deploy.4. Get visibility into AI assets. The EO directs agencies to secure their networks in a frontier AI threat environment, but you cannot secure what you cannot see. Agencies are adopting AI applications, models, and development tools faster than governance boards can review them. Some of those tools carry data-sharing obligations to foreign intelligence services. A discovery assessment of all AI applications and data pipelines, including shadow AI, running across the enterprise is the starting point for informed governance decisions about what to allow, what to restrict, and what to remove.5. Discover, prioritize, and fix vulnerabilities. BOD 26-04 is, at its core, a vulnerability management directive. It demands that agencies prioritize remediation using four risk variables and remediate on timelines as short as three calendar days. Mythos-class models are generating vulnerability discoveries at a pace that will overwhelm traditional scan-and-patch workflows. Risk-based prioritization is not just good practice; under BOD 26-04, it is the only way to manage the volume. Agencies need unified visibility across the full vulnerability inventory, including third-party and cloud environments, to execute on that.6. Conduct continuous red teaming. Mythos-class models do not run a scan and stop. They reason across attack paths, chain vulnerabilities, and adapt. Defensive testing must match that cadence. Continuous automated adversarial testing of systems, applications, and AI models identifies weaknesses before adversaries exploit them. This is not a quarterly exercise. In a Mythos-class threat environment, red teaming is an ongoing operational function.The policy direction set by EO 14409 and BOD 26-04 is unambiguous: the federal government has concluded that Mythos-class AI has changed the threat environment, and it expects agencies to respond with urgency. The enforcement mechanism is live. The agencies and organizations that act on these steps now, rather than waiting for the next directive, will be the ones best positioned to defend their networks and continue their missions in the months ahead.]]></description>
            <dc:creator>Ryan Gillis (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Salesforce-Klue Incident: How Zscaler Protects SaaS Data]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/salesforce-klue-incident-how-zscaler-protects-saas-data</link>
            <guid>https://www.zscaler.com/blogs/product-insights/salesforce-klue-incident-how-zscaler-protects-saas-data</guid>
            <pubDate>Thu, 25 Jun 2026 17:00:10 GMT</pubDate>
            <description><![CDATA[A recent Salesforce security&nbsp;advisory highlighted a growing challenge facing security teams: the risks posed by trusted third-party SaaS applications.The advisory disclosed unusual activity involving the Klue Battlecards application, a third-party integration that connects to Salesforce using OAuth permissions. While the issue was not caused by a vulnerability in Salesforce itself, it serves as another reminder that attackers increasingly target trusted SaaS integrations rather than the SaaS platforms they connect to.&nbsp;The rise in SaaS supply chain security attacksOver the past few years, incidents involving vendors such as&nbsp;Gainsight and&nbsp;Salesloft Drift have demonstrated how attackers can abuse trusted application relationships to gain access to sensitive enterprise data. Rather than attacking the SaaS platform directly, attackers target connected applications that already possess authorized access.For security teams, the challenge is rarely the SaaS platform itself. The challenge is understanding which third-party applications have access to business-critical data, what permissions they have been granted, and how quickly organizations can assess exposure when an incident occurs.The Salesforce-Klue incident is a good example of why visibility into SaaS integrations has become an essential part of&nbsp;modern SaaS security.&nbsp;What role did OAuth play in the Salesforce-Klue incident?OAuth was the trust mechanism that allowed the Klue Battlecards application to access Salesforce data on behalf of authorized users. When organizations connect third-party applications to Salesforce, they typically grant OAuth permissions that allow those applications to access specific Salesforce resources and APIs. If a connected application becomes compromised, attackers may be able to abuse those existing permissions to access sensitive data through legitimate channels without exploiting a vulnerability in Salesforce itself.Figure 1. Salesforce-Klue Attack PathFigure 1. OAuth enables third-party applications to access SaaS platforms on behalf of users. While this simplifies integrations, it also creates a trust relationship that attackers can exploit if a connected application becomes compromised.In the Salesforce-Klue incident, Salesforce reported unusual activity involving the Klue Battlecards application and subsequently disabled the integration. While the complete details of the attack have not been publicly disclosed, the incident highlights a broader security challenge: organizations often have limited visibility into the third-party applications connected to their SaaS environments, the permissions those applications have been granted, and the data they can access.This is why third-party application governance has become a critical component of&nbsp;SaaS security. Security teams need visibility not only into the SaaS platform itself, but also into the ecosystem of connected applications that may have access to sensitive business data.&nbsp; How to discover the Klue integration in your environmentThe first challenge during any OAuth-related incident is determining whether the affected application exists in your environment.The screenshot below shows how Zscaler SaaS Security discovers the Klue Battlecards integration connected to Salesforce and provides visibility into its permissions, access level, and risk profile.Figure 2. Klue Battlecards Integration Discovered by Zscaler SaaS SecurityFigure 2. Zscaler SaaS Security provides visibility into the Klue Battlecards integration, including access type, permissions granted, and overall risk profile.As shown in Figure 2, security teams can immediately identify:The connected applicationPlatform association (Salesforce)Access typeRisk scorePermission scopeOAuth permissions grantedMost importantly, teams can quickly determine whether they are potentially affected when incidents like this are disclosed.The Klue integration, for example, shows permissions such as Full Access, API Access, Refresh Tokens, Offline Access, and User Data Access. Understanding these permissions is critical because they help security teams assess the potential impact of a compromised application and determine the appropriate remediation actions.&nbsp; How Zscaler provides visibility and accelerates incident response timesWhen incidents like this are disclosed, security teams immediately need answers to a few critical questions:Do we have the affected application installed?Which users authorized it?What permissions were granted?Does it have access to sensitive data?What is the potential blast radius?Can we quickly revoke access if necessary?Without centralized visibility, answering these questions can take hours or even days.Zscaler SaaS Security continuously discovers and inventories third-party applications, OAuth integrations, browser extensions, and SaaS add-ons connected across major SaaS platforms. It provides visibility into more than 150,000 third-party add-ons and integrations, helping organizations understand exactly which applications have access to their SaaS environments.&nbsp;Managing SaaS application permission sprawl and exposureOne of the most common challenges with OAuth-connected applications is permission sprawl.Applications often accumulate permissions over time or retain access long after they are needed.Zscaler SaaS Security helps organizations identify:Overprivileged applicationsDormant applicationsPotentially harmful applicationsUnsanctioned third-party integrationsThis allows security teams to proactively reduce their attack surface before attackers exploit trusted connections.Beyond discovering risky applications, organizations also need to understand exposure. Which users authorized the application? What data can it access? How significant is the potential impact?Zscaler Unified SaaS Security correlates applications, users, posture findings, and data exposure to provide a more complete understanding of risk. This helps security teams quickly assess blast radius and prioritize remediation efforts.&nbsp;Why continuous monitoring mattersThe Salesforce-Klue incident is another reminder that SaaS security is not a one-time activity.Applications evolve. Permissions change. Risk profiles increase.What may have been considered a low-risk integration a year ago may represent a significantly different risk today.Zscaler SSPM continuously monitors SaaS environments for posture changes, risky configurations, and configuration drift, helping organizations identify new exposures to reduce risk of security incidents.&nbsp;Final ThoughtsThe Salesforce-Klue incident reinforces an important lesson: attackers increasingly target trusted third-party applications rather than the SaaS platforms themselves.Organizations need visibility not only into SaaS configurations, but also into the applications, permissions, users, and data connected to those platforms.When a security advisory is released, security teams should be able to immediately answer:Do we have the affected application?What permissions does it have?Which users authorized it?What data can it access?How quickly can we respond?With&nbsp;Zscaler SaaS Security, organizations can discover third-party applications, assess risk, understand exposure, and rapidly respond when incidents occur, all from a single platform.&nbsp;To learn more about how Zscaler can help your organization respond to incidents like Salesforce-Klue,&nbsp;request a demo.&nbsp;&nbsp;FAQWhat happened in the Salesforce-Klue security incident?&nbsp;The Salesforce-Klue incident involved attackers compromising Klue's integration infrastructure and stealing OAuth tokens used to connect customer Salesforce environments to the Klue Battlecards platform. According to public reporting, the attackers used those tokens to access Salesforce data through legitimate APIs, resulting in data exposure at multiple organizations, including several cybersecurity firms. Salesforce subsequently disabled the Klue integration after detecting unusual activity and stated that the issue was limited to the Klue application connection rather than a vulnerability in the Salesforce platform itself.What is an OAuth-based SaaS supply chain attack, and why is it so dangerous?&nbsp;In an OAuth-driven supply chain attack, adversaries exploit the trust established between a SaaS environment and a connected third-party tool. Bad actors use existing authorized credentials to compromise an application and navigate through legitimate API channels to harvest sensitive enterprise information. In this way, bad actors don’t need to target the primary SaaS infrastructure directly.How can organizations find out if the Klue Battlecards integration is connected to their Salesforce environment?&nbsp;Organizations can review connected applications within Salesforce or use a SaaS security solution such as Zscaler SaaS Security to discover OAuth-connected applications. Continuous visibility into third-party integrations helps security teams quickly identify whether applications like Klue Battlecards are present and assess their associated risks.What permissions does the Klue Battlecards Salesforce integration use, and why do they matter?&nbsp;The Klue Battlecards integration can be granted permissions such as API Access, Full Access, Refresh Tokens, Offline Access, and User Data Access. These permissions matter because they determine what data an application can access and the potential impact if the application becomes compromised.How should security teams respond when a third-party SaaS integration is compromised?&nbsp;Security teams should immediately identify affected applications, review granted permissions, determine which users authorized the integration, assess potential data exposure, and revoke access if necessary. Organizations should also investigate related activity, rotate credentials where appropriate, and evaluate the overall blast radius of the compromise.]]></description>
            <dc:creator>Niharika Sharma (Staff Product Manager - CASB PM)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Agentic AI Threat Model: Prompt Injection, Context Poisoning, and Agent Behavior Drift]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/agentic-ai-threat-model-prompt-injection-context-poisoning</link>
            <guid>https://www.zscaler.com/blogs/product-insights/agentic-ai-threat-model-prompt-injection-context-poisoning</guid>
            <pubDate>Thu, 25 Jun 2026 16:55:34 GMT</pubDate>
            <description><![CDATA[OverviewAn agentic AI threat model is a security framework for understanding how autonomous AI systems can be manipulated, misled, or drift out of policy as they interact with tools, data sources, memory, and enterprise systems.Agentic AI changes the security equation by extending risk beyond model outputs to the full chain of decisions, actions, and connected systems an agent can influence.Agentic AI expands the attack surface: Unlike traditional LLMs, agentic systems use tools, persistent context, multi-step workflows, and delegated permissions to take actions across enterprise environments.Three threats define the core risk: Prompt injection, context poisoning, and agent behavior drift each operate at different phases of the AI lifecycle and require different controls.Security has to span the full lifecycle: Effective protection starts at build time with adversarial testing and prompt hardening, continues at deployment with discovery and posture assessment, and extends into runtime with guardrails, DLP, and access controls.Operational maturity depends on visibility and continuous enforcement: Organizations need monitoring, remediation workflows, and phased implementation to keep AI systems aligned with policy as environments, permissions, and behaviors change. What are the three core agentic AI threats?The three core agentic AI threats are prompt injection, context poisoning, and agent behavior drift. They are difficult to address as a set because they emerge at different stages of the agent lifecycle (runtime, data ingestion, and ongoing operation) and each requires a different kind of control. A runtime guardrail may help stop injection, for example, but it will not catch poisoned data already sitting in a knowledge base or an agent that has gradually drifted outside policy.Prompt injection: Attackers embed hidden instructions in user inputs, retrieved documents, or tool outputs, causing the agent to treat malicious directions as legitimate and potentially override its intended behavior.Context poisoning: Malicious or corrupted content is introduced into the agent’s data sources during ingestion, then retrieved later as if it were trustworthy, making the attack persistent and difficult to trace.Agent behavior drift: Over time, model updates, feedback loops, or policy changes can shift an agent away from its expected behavior, weakening safety, permissions, or workflow alignment without triggering obvious alerts. How agentic AI attacks lead to real outcomesThe damage maps to four categories security teams already track:Data exposure: A compromised agent exfiltrating protected health information (PHI), payment card industry (PCI) data, source code, or confidential documents does not look like a breach in progress. It looks authorized. The agent is operating within its granted permissions, and existing controls have no reason to flag it.Unsafe actions: A drifted agent approves transactions it should deny, executes destructive operations, or violates policies. Broader permissions mean broader blast radius.Tool misuse: An agent tricked into calling unauthorized APIs or forwarding sensitive data through integrations operates within its technical capabilities. The abuse hides inside legitimate patterns.Compliance failures: Regulators do not distinguish between human error and agent error. EU AI Act obligations, HIPAA breach notification rules, and GDPR disclosure requirements apply regardless of whether an autonomous system or a person caused the exposure.&nbsp; How to secure agentic AI at the build phase&nbsp;Most agentic AI vulnerabilities are cheaper to catch before deployment than after, which is why the build phase is the right place to address system prompt weaknesses, governance gaps, and adversarial exposure before any of them reach production.Automated adversarial testing for agentic systems: Manual red teaming cannot cover the combinatorial space of tool calls, context sources, and multi-step workflows. Automated adversarial testing runs continuous probes against system prompts, tool-selection logic, and data access paths at a pace that matches deployment cycles. Findings tie to specific vulnerabilities and feed directly into remediation workflows.Prompt hardening and design controls: Hardening starts at the system prompt layer, where the most reliable fix is structural separation between instruction context and user-supplied content. Input validation catches known injection patterns before they reach the model. From there, tool-call policies restrict which APIs an agent can invoke based on request context, and permission boundaries enforce least-privilege access at every workflow step.Governance and compliance mapping: Governance mapping done post-deployment is remediation. Done at build time, it’s considered prevention. Running adversarial test probes against OWASP LLM Top 10, NIST AI Risk Management Framework (AI RMF), EU AI Act requirements, and MITRE ATLAS generates two outputs simultaneously: a vulnerability record and a compliance artifact. Security teams get both from the same testing cycle without running a separate audit process. What deploy-phase controls need to coverA clean build does not guarantee a clean deployment. New connectors get added, permissions expand during sprints, and AI features activate inside SaaS platforms that were approved before those features existed. Deploy-phase controls establish the governed baseline that makes everything in the runtime layer enforceable.AI discovery and posture assessment: Security teams cannot protect AI assets they cannot see. Continuous discovery identifies shadow AI, unsanctioned models, embedded SaaS AI, developer-built agents, and MCP servers, while assessment classifies each asset by data sensitivity, permissions, and compliance risk.Risk assessment and posture: Posture assessment goes beyond inventory to identify misconfigurations, excessive permissions, vulnerable RAG frameworks, and exposed data pipelines. Continuous monitoring tracks changes over time and measures them against the established baseline.Remediation workflows: Effective posture management depends on turning findings into action. Prioritized alerts, guided remediation, least-privilege access controls, and integrations with ITSM, DLP, and DSPM platforms help teams close gaps quickly and consistently. What runtime controls catch that build and deploy missBuild and deploy phases reduce the attack surface. Runtime controls handle what gets through anyway, which in a sufficiently complex agentic environment will always be something.AI runtime protection guardrailsDetectors evaluate every prompt and response inline for injection attempts, jailbreak patterns, personally identifiable information (PII) leakage, source code exposure, and content violations, blocking malicious interactions before the agent acts.Policy enforcement adapts to adversarial testing findings. When build-phase testing identifies a new vulnerability pattern, that pattern translates into a runtime detection rule. The loop between testing and enforcement closes automatically.Enterprise AI usage controlsAccess policies determine which users and roles reach which AI applications. DLP inspection scans prompts and responses for PII, PHI, PCI data, and proprietary source code. Content moderation catches off-topic, toxic, restricted, and competitive content before it reaches users or exits the organization.Controls extend to embedded AI inside SaaS platforms and developer environments. As new AI features activate inside already-approved SaaS platforms, they surface in live traffic alongside shadow AI that was never formally sanctioned. Integrated development environments (IDEs), coding assistants, and agent platforms that connect to MCP servers face the same data exposure risk as standalone AI applications. 30-day implementation planOrganizations that skip to policy enforcement before they have full visibility end up tuning controls against an incomplete picture. Those that automate before their policies are stable automate the wrong behavior at scale.Days 1–7: Visibility baseline: Discover all AI apps, models, agents, MCP servers, and embedded SaaS AI in use, then classify them by data sensitivity, permissions, and compliance risk to establish a baseline.Days 8–14: First guardrails and enforcement: Apply protections to the highest-risk assets first by enabling runtime protection, DLP inspection, zero trust access controls, and blocking unsanctioned AI apps.Days 15–21: Automated testing and policy mapping: Run adversarial testing on internal AI apps and agents, map findings to relevant regulations, and feed confirmed issues directly into runtime guardrails.Days 22–30: Operationalize and remediate: Turn the program into a continuous process with posture monitoring, connected remediation workflows, and drift detection for agent behavior, permissions, and performance. Monitoring signals that traditional tools were not built to readAgentic AI systems generate signals that traditional monitoring tools were not built to interpret. Agent action trails, traffic flows, prompt patterns, and posture drift each surface a different category of risk, and missing any one of them leaves a blind spot that the others cannot compensate for.Agent activity and action trails: Every agent action generates a record. Tool calls, data retrievals, permission exercises, and workflow executions produce audit trails that surface anomalous patterns in action sequences before consequences become visible.AI traffic flows: Monitor the volume and direction of prompts and responses across AI applications. Track which data sources agents query, which tools they invoke, and which external services they contact. Unexpected flows surface shadow AI and unauthorized integrations.Risky prompt patterns and response signals: Certain prompt structures correlate with injection attempts, jailbreak techniques, and data extraction methods. Response signals like unexpected tool invocations, out-of-scope data returns, and content violations indicate active exploitation or drift.AI posture drift over time: Track permission scope, configuration state, data access patterns, and compliance alignment continuously. Compare current posture against established baselines. Drift detection catches the slow erosion that point-in-time assessments cannot.&nbsp; How Zscaler enables secure AI adoptionMost security vendors solve one slice of the agentic AI problem. Zscaler covers the full lifecycle on a single cloud native platform built on the Zero Trust Exchange™, from build-phase adversarial testing through deploy-phase posture management to runtime enforcement. The three capabilities below map directly to the build, deploy, and runtime controls covered in this article.&nbsp;Discover: AI Asset Management: Eliminates AI visibility gaps by discovering and inventorying AI assets, mapping model lineage with AI-BOM, and continuously assessing posture with AI-SPM. Risk-prioritized findings support guided remediation, least-privilege enforcement, and compliance.Control: AI Access Security: Prevents sensitive data exposure with zero trust access controls, inline DLP inspection, and granular policies across generative AI apps, embedded SaaS AI, agents, and developer tools.Protect: AI Red Teaming and AI Guardrails: Connects continuous adversarial testing to runtime enforcement by turning discovered vulnerabilities into real-time guardrails without manual policy creation.The Cloud Security Alliance's Agentic AI Risk Profile (CSA, 2025) documents the same threat categories covered here, confirming that the qualitative risk differences between agentic and traditional AI systems are recognized across the industry, not just a single-vendor framing. Organizations running agentic AI in production need controls that map to recognized frameworks, and that requires platform coverage across the full lifecycle.Request a demo to see how Zscaler secures AI from build to runtime, and download the ThreatLabz 2026 AI Security Report for the latest data on AI-driven threats and enterprise exposure.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
    </channel>
</rss>