<?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/mx/blogs/feeds/product-insights</link>
        <description>Latest news and views from the leading voices in cloud security and secure digital transformation.</description>
        <lastBuildDate>Wed, 12 Aug 2026 23:49:23 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>es-mx</language>
        <item>
            <title><![CDATA[Introducing Zscaler Zero Trust Gateway for Google Cloud]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/introducing-zscaler-zero-trust-gateway-google-cloud</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/when-prepare-disconnect-becomes-official-guidance-what-ci-fortify-means-ot</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/hidden-threat-your-software-development-lifecycle-why-self-hosted-runners</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/zero-trust-connectivity-private-ai-apps-models-who-can-actually-reach-them</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/private-access-scales-your-app-catalog</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/zscaler-integrates-openai-cyber-models-secure-ai-enabled-endpoint</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/zscaler-integrates-claude-inference-hooks-scale-ai-while-addressing-risks</link>
            <guid>https://www.zscaler.com/mx/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 (Zscaler)</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/mx/blogs/product-insights/health360-how-healthy-is-my-zscaler-deployment</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/why-zero-trust-needs-continuous-planning</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/prem-data-security-ai-era-why-it-s-time-modernize-dspm</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/zero-trust-branch-now-available-fedramp-moderate-and-high</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/worlds-first-autonomous-ai-breach-makes-case-for-deception</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/what-s-new-govcloud-july-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/lethal-trifecta-zero-trust</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/autonomously-hide-segment-and-shield-private-app-defense-ai-era</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/how-find-which-isp-slowing-down-your-users</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/extending-zero-trust-browser-new-frontier-enterprise-security</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/standardizing-ssl-key-logging-step-forward-secure-diagnostics</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/empower-security-teams-extend-visibility-endpoint-context</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/when-attackers-wield-frontier-ai-how-keep-your-private-apps-unbreachable</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/pqc-modern-cryptographic-key-exchange-deep-dive</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/prompt-injection-explained</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/accelerating-post-quantum-readiness-timelines-new-executive-order-securing</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/f1-cybersecurity-ai-threats</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/beyond-alert-fatigue-architecting-next-gen-data-security-zscaler-workflow</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/sse-architecture-explained-how-sse-enables-zero-trust</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/secops-for-ai-incidents</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/when-choose-sse-vs-sase-decision-framework-security-leaders</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/ai-agent-can-t-see-whole-path-just-faster-way-be-wrong</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/five-eyes-cyber-agencies-signal-new-ai-security-consensus-we-must-act-now</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/what-s-new-govcloud-june-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/sse-components-explained-swg-ztna-casb-and-how-they-work-together</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/risks-and-benefits-of-ai-in-cybersecurity</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/zscaler-ai-protect-raises-the-bar-for-ai-security</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/hardening-federal-networks-mythos-era-what-ai-executive-order-and-bod-26-04</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/salesforce-klue-incident-how-zscaler-protects-saas-data</link>
            <guid>https://www.zscaler.com/mx/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/mx/blogs/product-insights/agentic-ai-threat-model-prompt-injection-context-poisoning</link>
            <guid>https://www.zscaler.com/mx/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>
        <item>
            <title><![CDATA[Transforming Mission Partner Data Exchange: Moving Past the Networks]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/transforming-mission-partner-data-exchange-moving-past-networks</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/transforming-mission-partner-data-exchange-moving-past-networks</guid>
            <pubDate>Mon, 22 Jun 2026 18:13:09 GMT</pubDate>
            <description><![CDATA[Mission outcomes increasingly depend on how quickly teams can share the right data with the right people across organizations, classifications, and operating environments. Speed matters, but speed alone is not the goal. The real measure is speed and accuracy, because decision advantage collapses when information is delayed, unavailable, or untrustworthy.That reality is why our recent webinar focused on a simple but important conclusion: connecting networks to shared data is not scalable and has not achieved the desired mission requirements for decades. We have tried variations of the same approach for years, including reframing "mission partner networks" as "mission partner environments." The labels change, but the underlying problem remains.The mission does not require more network plumbing. That approach has produced a surplus in technical debt with diminishing returns. What the mission requires is secure mission partner data exchange.In the session, I put it plainly: if mission partner data exchange is the objective, then we should design for the objective directly rather than building ever more complex networks and hoping they can finally deliver on the goals while ignoring the lessons learned of the past. From user experience to operational impactTraditional partner connectivity routes traffic through layers of network zones and security stacks. Each layer might serve a valid purpose in isolation, but the cumulative effect on operations is predictable and measurable. Onboarding timelines stretch from hours to weeks. Every change requires coordinated firewall exceptions across multiple administrative boundaries. Troubleshooting a single broken session means tracing a packet across dozens of security zones and their respective network authorizing officials. The user feels it as latency and frustration. The mission feels it as lost tempo.This is especially problematic for mission partner operations, which are not static. They are dynamic, distributed, and rapidly lose predictability in contested conditions. Yet network security architectures assume the opposite: stable routes, long planning cycles, tightly controlled endpoints. Those are the conditions that make risk management appetizing for Authorizing Officials. Those assumptions break when partners, locations, and mission requirements shift at the speed of war. Cybersecurity impactsNetwork-centric sharing also increases exposure. When every endpoint, application, or machine entity is reachable simply because it sits "on the network," the attack surface grows with every new connection, route, and workaround. Scale that exposure across the number of protocols in use, and you are looking at billions of permutations of reachability. That combinatorial complexity is exactly what the next generation of AI-driven threats is designed to exploit. Adversarial models thrive on attack surfaces too vast for human defenders to reason about.The result is a permanent tension between "make it accessible" and "keep it secure." Over time, the architecture becomes harder to govern, and it becomes easier for adversaries to find a path in. Data-centric operations demand a Policy Enforcement PointIf data is the center of gravity for modern maneuvers, then the architecture must enforce security at the point where data is accessed, not at the network boundary where traffic happens to flow. This is where Zero Trust introduces a critical concept: the Policy Enforcement Point, or PEP.A PEP brokers every connection across any network. It does not depend on where the user sits, what network they traverse, or which administrative domain owns the application. It makes access decisions based on identity, device posture, and policy context per session, continuously. That architectural requirement is what makes data truly the center of gravity rather than just a talking point.The stakes are operational. When data integrity fails, when information is manipulated, corrupted, or made unavailable, leaders make decisions on a false picture. In a mission partner environment, that risk compounds across every organization sharing the exchange. Confidentiality, integrity, and availability are not abstract principles. They are operational outcomes. They are what keep decisions grounded in reality and keep momentum from being derailed by uncertainty, misinformation, or compromised systems. Moving past the network with a Zero Trust overlayA data-centric Zero Trust approach changes the question from "How do I connect these networks?" to "How do I securely enable access to specific applications and data based on identity and policy?"This is where the concept of an overlay becomes useful. The overlay is a consistent control layer for access and policy enforcement, independent of where users, apps, or partners reside. The intent is not to ignore networks. Networks still exist and they still matter. The point is to abstract secure access entirely away from the network's function of interconnecting things. Networks still move packets, but they no longer decide who gets to reach what.In the webinar, we discussed the overlay in terms of two complementary capabilities.First, there is the persistent aspect. These are the pieces you want always available, no matter where operations occur. Identity and analytics should both have a persistent presence: identity because every access decision starts there, and analytics because you cannot govern what you cannot observe. The persistent overlay also encompasses the access policy framework, shared services that multiple organizations require, and the logging platforms that provide continuous situational awareness, all with consistent policy applied regardless of where operations occur.Second, there is the episodic aspect. These are the capabilities you need to bring up quickly and bring down quickly for a specific mission or timeframe. Think forward-deployed users, new mission applications, partner access, or short-lived services that are essential in the moment but should not become permanent fixtures over time.The only architecture that credibly supports both persistent and episodic assets in a single overlay is a full proxy-based Policy Enforcement Point. Because every session terminates at the PEP rather than passing through as mixed network traffic, you can onboard or remove any asset without altering the underlying network fabric. Partners and applications connect to the overlay, not to each other. That is what makes rapid integration operationally safe rather than operationally reckless.Separating persistent and episodic capabilities helps teams combine governance with agility. It supports mission tempo without sacrificing the consistency required for defensible security. A practical rollout path: Overlay + Identity + Visibility = Agile adoption of users and applicationsA Zero Trust transformation does not need to be theoretical. The webinar outlined a pragmatic progression that works for mixed audiences, from leadership to implementers.Establish the overlay. Define how access decisions will be made and enforced, and how partners will be brought into a consistent model.&nbsp;Integrate an identity provider. Access decisions start with identity, so identity is not an afterthought.&nbsp;Instrument early with visibility and logging. If you move fast without visibility, you accumulate risk faster than you can manage it.&nbsp;Onboard applications and users with clear policies. Focus on least privilege and explicit access paths to the apps and data people need, all while isolating the attack surface of every onboarded asset, enforcing granular attribute-based access control (ABAC) policies, defending against threats inline, and feeding enriched analytics that enable rapid pivoting when conditions change.That third point, visibility, is often the difference between success and frustration. Visibility is not optional because it is how you verify what is happening and why. It is also how you detect drift as policies evolve and as partners and missions change.For implementers, this translates into practical questions: Are we seeing who is accessing which applications, from where, and under what policies? Are we capturing enough detail to identify risky patterns or misconfigurations quickly? For leaders, it translates into confidence: Can we demonstrate that access is controlled, monitored, and auditable as partner participation expands? Partner access without expanding the attack surfaceMission partner exchange becomes even more complex when you do not control the partner device. In the webinar, we discussed scenarios where a mission partner arrives with their own endpoint. You may have legitimate concerns about posture, patching, or the possibility of infection. At the same time, the partner still needs access to specific mission applications or datasets.This is where a data-centric overlay with policy-based control becomes an operational advantage. The goal is to grant access to what is needed, and only what is needed, without making applications broadly reachable and without relying on fragile network exceptions.We also talked about controls that reduce exposure in higher-risk scenarios, including isolation. The point is not to treat partners as adversaries, but to design for reality. When you assume variability in endpoint trust, you reduce the chance that one weak link becomes an operational disruption. Imagine the power of browser isolation in those kinds of environments: a partner can see and interact with mission data in an application, but nothing ever downloads to their endpoint, and nothing from their endpoint can reach back into the information environment. Watch the webinar on demandThe concepts outlined here are the surface. The webinar provides a full architecture walkthrough with data flow diagrams and deployment sequences. If you want a deeper look at the overlay model, how to think about persistent and episodic capabilities, and how to approach mission partner data exchange without relying on brittle network connectivity models, watch the webinar on demand: Transforming Mission Partner Data Exchange: Moving Past the Networks.Photo Credit: U.S. Army photo by Pfc. Hector Blanco]]></description>
            <dc:creator>Patrick Perry (Public Sector Field CTO)</dc:creator>
        </item>
        <item>
            <title><![CDATA[AI Security Guidelines for Employees: An Acceptable‑Use Policy You Can Enforce, What to Include &amp; How to Enforce It]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/ai-security-guidelines-for-employees</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/ai-security-guidelines-for-employees</guid>
            <pubDate>Mon, 22 Jun 2026 17:26:09 GMT</pubDate>
            <description><![CDATA[Enforcing safe AI use across a workforce requires four things working together:&nbsp;Governance: Clear policies defining which tools, data, and use cases are permittedEmployee guidance: Training that translates policy into daily behaviorTechnical controls: Inline enforcement of data protection, access, and monitoringOngoing oversight: Regular reviews as tools, regulations, and risks evolve&nbsp;A published policy creates accountability. These four layers make it enforceable.&nbsp;IntroductionAn effective AI acceptable-use policy (AUP) should answer a few fundamental questions:Which AI tools can employees use?What information can and cannot be shared with those tools?Which use cases are approved, restricted, or prohibited?How should employees validate AI-generated outputs before acting on them?What controls exist to detect and prevent policy violations?The questions above are only as useful as the controls behind them. What should an AI acceptable-use policy include?A strong AI acceptable-use policy establishes clear expectations for employees while giving security teams a foundation for enforcement. Effective guardrails scale across different tools, teams, and use cases: broad enough to cover the full AI surface and specific enough to enforce.Scope: What tools and environments are covered?One of the most common policy gaps is failing to clearly define what qualifies as an AI tool. Many organizations focus on public chatbots while overlooking AI functionality embedded throughout their technology stack.An AI AUP should cover:Public GenAI applications and chatbotsEmbedded AI assistants in productivity and collaboration platformsDeveloper AI tools and coding assistantsAI-powered browser extensions and pluginsInternal AI applications and modelsAutonomous agents and workflow automations connected to enterprise systemsRather than categorizing tools based solely on vendor or application type, consider the level of access each tool has to enterprise data. A chatbot with access to customer records may present greater risk than a public AI tool used for generic brainstorming.Roles and responsibilitiesAI governance cannot be owned exclusively by security teams, and policies that treat it that way tend to fail at the operational level. Employees need clear guidance on what is acceptable, managers need to know when to escalate, and legal and compliance stakeholders need to be looped in early enough to shape policy. Data owners in HR, Finance, and Engineering understand the sensitivity of their information better than any central team does.The reason to define this ownership explicitly is not organizational tidiness. When an exception request comes in, or a violation occurs, or a new AI tool appears in traffic that nobody approved, the response depends on knowing exactly who decides, who investigates, and who updates the policy. Ambiguity at that moment is where governance programs stall.Core policy sectionsWhile every organization’s policy will differ, most enforceable AI AUPs include several foundational components.Approved and unapproved tools: Employees should know which AI tools are authorized for business use and how to request approval for new technologies. Ambiguity often leads to shadow AI adoption and inconsistent risk management.Prompting and content handling requirements: Define expectations for prompts, uploads, generated outputs, and file sharing. Employees should understand how to handle both information sent to AI systems and content received from them.Identity and access requirements: Establish requirements for single sign-on (SSO), multifactor authentication (MFA), managed devices, approved accounts, and other controls designed to reduce unauthorized access risks.Logging and audit requirements: Document what activity must be logged, how long records should be retained, and what information may be required for investigations, audits, or compliance reporting.Enforcement and escalation procedures: Define how policy violations will be handled, including escalation paths, remediation expectations, and disciplinary considerations when appropriate.Training and acknowledgment: Employees should receive regular training on AI risks, acceptable use expectations, and evolving policy requirements. Annual acknowledgments help reinforce accountability and demonstrate governance maturity. What data must not be shared with AI toolsMost AI security incidents start with an employee pasting internal information into an AI tool without considering how that data may be processed, retained, or reused on the other side.The categories below follow a red-yellow-green framework. Red data should never enter a public or unsanctioned AI system under any circumstances. Yellow data requires safeguards before use. Green data carries low enough risk that most organizations permit it under standard policy.Red list: Data that should never be shared with public or unsanctioned AI toolsCertain categories of information create an unacceptable level of risk when shared with unapproved AI services. These data types should be explicitly prohibited unless a documented exception exists and appropriate controls are in place.Examples include:Credentials and secretsRegulated and protected informationEmployee informationCustomer informationLegal and business-sensitive informationSecurity informationIntellectual property and source codeYellow list: Data that may be used with safeguardsNot all internal information requires a complete prohibition. Some content may be appropriate for AI-assisted workflows when safeguards reduce the likelihood of exposing sensitive information.Examples include:Internal documents that have been appropriately redactedNon-sensitive project summariesDe-identified examples used for writing, analysis, or training purposesApproved development use cases operating within sanctioned environmentsBefore sharing any internal information with an AI system, evaluate whether it is necessary for the task and whether adequate protections exist.Green list: Generally safe for standard AI useLow-risk activities using approved tools and public or non-sensitive information can typically proceed under standard policy without additional review.Examples include:Brainstorming and ideation using publicly available informationDrafting generic content that does not require confidential inputsSummarizing non-sensitive documents, meeting notes, or research materialsTranslation of non-sensitive content using approved toolsMinimum de-identification requirementsMany employees assume removing a name is enough to anonymize information. In practice, de-identification requires a more deliberate approach.Before sharing information with an approved AI system, employees should:Replace names, account numbers, and other direct identifiers with placeholdersRemove unnecessary customer, employee, or business-specific detailsEliminate unique contract terms, locations, or references that could reveal identityUse representative excerpts instead of full reports, spreadsheets, or database exportsIt’s important to recognize that de-identification reduces risk, and it does not guarantee anonymity. Security teams should establish clear standards for when de-identified information is acceptable and when additional controls are required. Approved tools and safe usage patternsAn AI policy should do more than tell employees what they cannot do. It should also define approved ways to use AI safely and productively. Providing clear guidance helps reduce shadow AI adoption, encourages consistent behavior, and enables employees to benefit from AI without introducing unnecessary risk.Approved tools policyEmployees should use approved corporate AI tools whenever possible. Approved tools have typically undergone security, legal, compliance, and procurement reviews. They may also include contractual protections, data-handling commitments, logging capabilities, and other safeguards that are not available with consumer-grade services.Organizations should establish a documented process for requesting new AI tools. Without a clear approval process, employees often resort to unauthorized solutions when existing tools do not meet their needs.Policies should also prohibit the use of personal AI accounts for work-related activities unless explicitly approved. Personal accounts can create visibility, retention, and governance challenges that make enforcement difficult.Safe usage patternsNot every AI interaction carries the same level of risk. Organizations can often approve low-risk activities while restricting more sensitive use cases.Examples of generally acceptable activities include:Brainstorming with public information: Employees can use AI to generate ideas, explore concepts, create outlines, or support planning activities that rely solely on public information.Drafting generic content: AI can help create first drafts of emails, presentations, documentation, or communications that do not require confidential inputs.Summarizing non-sensitive information: Employees may use approved AI tools to condense lengthy reports, meeting notes, or research materials that do not contain protected information.Translation assistance: Approved AI tools can support translation of non-sensitive content when business needs require multilingual communication.Development assistance in approved environments: Developers may use approved coding assistants to accelerate tasks such as debugging, documentation, testing, and code generation, provided they follow established policies governing source code and intellectual property.The key principle is simple: The lower the data sensitivity, the lower the associated risk.Prompt hygiene rulesPrompt hygiene is one of the most effective ways to reduce AI-related data exposure. Even when employees use approved tools, poor prompting practices can increase organizational risk. Employees should follow several core guidelines:Do not include sensitive information unless the use case has been approved.Replace identifiers with placeholders whenever practical.Share only the information necessary to complete the task.Avoid uploading raw files unless policy permits the activity.Review prompts before submission to ensure unnecessary information has been removed.Small changes in prompting behavior can significantly reduce the likelihood of exposing sensitive data while still allowing employees to benefit from AI-assisted workflows. How to validate AI outputsOrganizations often focus on what employees enter into AI systems while paying less attention to what comes out. That gap creates its own category of risk. For example, inaccuracies, unsupported claims, insecure code, compliance issues, and biased recommendations can all surface in responses that appear entirely credible. Employees who act on AI outputs without verification are making decisions on unaudited information.Output validation checklistBefore relying on AI-generated content, employees should verify:Accuracy: Confirm factual claims, statistics, technical recommendations, and references against authoritative sources.Confidentiality: Ensure outputs do not expose customer data, proprietary information, or other protected content.Compliance: Review content for legal, regulatory, or policy concerns, especially in regulated industries and customer-facing communications.Security: Evaluate code, scripts, configurations, and technical recommendations for vulnerabilities, unsafe practices, or malicious content. AI-generated code should never be considered production-ready without review.Bias and fairness: Check for discriminatory language, unfair assumptions, or recommendations that could create ethical, legal or reputational risks.High-risk scenarios requiring human reviewSome use cases should always require human oversight, including:Legal agreements and policy languageHR decisions and performance-related communicationsFinancial reporting, forecasting, and pricing decisionsCustomer communications in regulated industriesSecurity guidance, scripts, configurations, and remediation recommendationsMedical or health-related contentIn these cases, AI may assist with drafting or analysis, but humans should make the final decisions.Citation and traceability requirementsOrganizations should establish expectations for documenting AI-assisted work and retaining records when required for audits, investigations, or compliance purposes.Depending on the use case, employees may need to:Retain supporting sources and citationsDocument prompts and outputs used in regulated processesFollow disclosure requirements for AI-assisted contentPreserve records needed for audits, investigations, or legal reviewMaintaining traceability improves accountability and makes it easier to validate decisions and investigate issues when they arise. How to enforce and audit AI acceptable-use policyCreating an AI acceptable-use policy is only the first step. To be effective, organizations must enforce it consistently across users, applications, and data while maintaining visibility into AI activity and risk.Translate policy into enforcement controls: Convert policy statements into specific technical and administrative actions based on risk. Clearly define what is allowed, warned, restricted, isolated, or blocked, while also documenting exception workflows and assigning ownership for updates, approvals, enforcement decisions, and long-term governance accountability.Monitor AI usage and policy violations: Build monitoring that shows not only which AI tools employees use, but whether those tools are approved, what data is being shared, and which violations happen most often. Pair violation data with sanctioned adoption trends so teams can identify gaps in tooling, training, or policy clarity.Respond to AI-related incidents: Handle AI incidents through existing security, privacy, and data protection processes to ensure consistency and speed. Investigate what was shared, which service was involved, the potential exposure and compliance impact, and what immediate steps are needed to contain further unauthorized use.Maintain audit readiness: Keep clear, accessible records that demonstrate AI governance is active and enforceable in practice. This includes approved application inventories, policy histories, training completion, exception approvals, activity logs, enforcement actions, and evidence of regular reviews to support internal oversight and external regulatory inquiries.Continuously improve policy effectiveness: Treat AI governance as an ongoing program that adapts to changing technologies, business needs, and regulatory expectations. Regularly review new use cases, violation patterns, employee feedback, and emerging requirements so policies and controls stay useful, relevant, and aligned with real-world adoption. How Zscaler maps policy to controlsPolicy documents create accountability, and technical controls make that accountability real. Most AI governance programs break down at exactly that transition, when the underlying platform was not built to inspect AI traffic, classify prompt content, or apply context-aware decisions at the session layer.Aligning policy requirements with enforcementEffective enforcement depends on context. Security teams need visibility into who is using AI services, what data is involved, and whether activity aligns with policy. Controls can then be applied based on identity, application risk, data sensitivity, and business requirements. Common enforcement objectives include:Verifying user identity and contextApplying risk-based policiesMonitoring AI activityProtecting sensitive dataSupporting investigations and auditsExample capability areasOrganizations often look for capabilities that support both AI adoption and governance. Zscaler addresses each layer of the enforcement challenge through four capability areas:&nbsp;AI Asset Management: Gives security teams visibility into the full AI footprint: approved applications, shadow AI, embedded AI in Software-as-a-Service (SaaS) platforms, developer tooling, and autonomous agents. You cannot enforce a policy against tools you cannot see.AI Access Security: Applies zero trust access controls to AI SaaS, embedded AI in enterprise platforms, and developer environments, with inline inspection of prompts, responses, and file uploads. Allow, warn, restrict, and block decisions are applied based on user identity, device posture, and data sensitivity — at the session layer, not just the URL.AI Red Teaming: Continuously tests internally built AI applications against real adversarial conditions: prompt injection, jailbreaks, context poisoning, and data leakage. It identifies exploitable weaknesses before they reach production.AI Guardrails: Translates red teaming findings directly into runtime protection policies, closing the loop between testing and enforcement. Detectors run continuously against production AI interactions, covering jailbreak attempts, prompt injection, and sensitive data leakage.&nbsp;The Zero Trust Exchange™Every capability above runs on the Zscaler Zero Trust Exchange™ platform, which applies zero trust principles to AI interactions by continuously verifying identity, evaluating context, and enforcing policy at the session layer. Organizations get a unified enforcement layer across the full AI lifecycle, from shadow AI discovery through runtime protection, without adding point solutions that create new visibility gaps.To see how Zscaler maps these controls to your environment, visit zscaler.com/ai-security.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust, Zero Downtime: Ensure Security and Compliance Through Outages and Disruptions]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/zero-trust-zero-downtime-ensure-security-and-compliance-through-outages-and</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/zero-trust-zero-downtime-ensure-security-and-compliance-through-outages-and</guid>
            <pubDate>Sat, 20 Jun 2026 06:56:20 GMT</pubDate>
            <description><![CDATA[IntroductionIn the world of IT, Disaster Recovery (DR) and Business Continuity (BC) are often framed as "uptime" metrics. But for US organizations—especially those in Finance, Healthcare, and those governed by the Securities and Exchange Commission—the real challenge isn't just staying online; it's also staying compliant.Regulatory mandates like HIPAA, FINRA, and SOX—alongside frameworks like NIST and SOC 2—do not pause during a crisis. In fact, many organizations inadvertently create their biggest compliance "gap" during a failover event by relaxing security controls to "keep the business running." Compliance frameworks themselves have evolved to address these gaps. For example, older iterations of&nbsp;NIST 800-53 (Contingency Planning) were centered on the simple availability of operations. Today, the focus has shifted toward maintaining the appropriate security posture at all times.&nbsp; The Compliance Matrix: Specific Controls for BC/DRCompliance is no longer about having a "plan in a binder." Modern US frameworks and regulations require proof of Technical Controls that remain active during a disruption.Regulation / FrameworkSpecific ControlThe RequirementWhat Auditors Look ForNIST 800-53CP-2 &amp; CP-7 (Contingency Planning)"Provide controls at the alternate processing site that are equivalent to those at the primary site."Evidence that the alternate site provides information security safeguards equivalent to the primary site.ISO 27001Annex A.17 (Information Security Continuity)"...requirements for the continuity of information security management in adverse situations."Verification that information security is embedded in BC processes and not downgraded during a disaster.SOC 2Security &amp; Availability Trust Services Criteria"The system is protected against unauthorized access and available for operation as committed."Evidence that systems remain protected (Security) while remaining accessible (Availability) during a disruption.HIPAA (Healthcare)§ 164.308(a)(7) Contingency Plan"...procedures to enable continuation of critical business processes for protection of the security of ePHI."Establish procedures to enable continuation of critical business processes for protection of ePHI while operating in emergency mode.FINRA (Finance)Rule 4370 (Business Continuity Plan) Regulatory Notice 20-08"Address (1) Data back-up and recovery... (2) All mission critical systems..."Requirement to address "Data backup and recovery" and "Mission-critical systems" with secure access.FFIEC (Banking)Appendix J (Resilience)"...ensure the alternate site has security and privacy controls commensurate with those of the primary site."Verification that third-party resilience is tested and that the "Alternate Site" mirrors the primary security posture.&nbsp; The "Compliance Gap" in Traditional DR StrategiesMost third-party backup solutions used by enterprises (backup VPNs, backup firewalls, or a third-party cloud security solution) fail compliance controls because they are treated as "secondary" silos. This can lead to:- Policy Drift (ISO/NIST Violation): Security policies on DR hardware are often months out of date compared to production, failing the requirement for "equivalent safeguards."- Audit Blind Spots (SOC 2 Violation): Legacy DR systems often lack integrated logging. If your audit trail goes dark during a 48-hour recovery window, you cannot prove the integrity of your data.- The "Emergency Mode" Trap (HIPAA/FINRA): To ensure connectivity, teams often grant open access to the Internet and broad network access at the DR site, directly violating least privilege requirements, risking loss of sensitive information or exposing the network to external threats. Reduce the Risk of Non-Compliance with Zscaler Business Continuity CloudUnlike legacy third-party backup solutions for securing Internet and private access, the Zscaler Business Continuity Cloud (BCC) ensures rapid recovery without compromising Zero Trust policies or compliance mandates. Fully managed and completely isolated from Zscaler’s primary cloud infrastructure, Business Continuity Cloud provides customer-dedicated data and control plane functionality in "last-known good" and "read-only" states. This eliminates the operational burden of maintaining complex, insufficient in-house disaster recovery infrastructure, allowing your team to focus on maintaining business operations rather than the outage.&nbsp;The Zscaler solution provides specific technical controls that map directly to your regulatory and framework requirements:1. Requirement: "Equivalent Safeguards" (NIST / FFIEC)The Control: You meet the requirement for "equivalent safeguards" by default because the policy engine and enforcement remain while in business continuity mode.The Zscaler Advantage: The Zscaler BCC solution is both physically and logically distinct from the Zero Trust ExchangeTM platform, guaranteeing a fully redundant environment. Policies are synced with the Zero Trust Exchange and maintained in a read-only state within the BCC instance. A private control plane helps ensure that critical security controls and granular access policies are enforced even when in business continuity mode.2. Requirement: "Continuous Auditability" (SOX / SOC 2)The Control: You provide a continuous audit trail via log streaming, ensuring that logs from the disaster recovery period are indistinguishable from normal operations.The Zscaler Advantage: Visibility is often the first thing lost during an outage. The Zscaler solution continues to stream logs directly to your Security Information and Event Management (SIEM) system during a disruption, providing an audit trail that is indistinguishable from normal operations for private applications.3. Requirement: "Emergency Mode Security" (HIPAA / ISO 27001)The Control: This satisfies the requirement for a "secure transition," ensuring that security is deeply embedded in the continuity process rather than added as a manual, secondary step.The Zscaler Advantage: Zscaler BCC maintains existing security policies and application connectivity without the need for separate rules, multiple logins, or additional endpoint agents. User sessions are seamlessly transferred and maintained during the transition to business continuity mode. By eliminating the need for users to re-authenticate or install additional software, you remove the "human error" risk factor during a crisis. Conclusion: Not Just Continuity, But Security and Peace of MindFor the modern enterprise, Business Continuity and Disaster Recovery are no longer just "IT Infrastructure" problems—they are legal and risk mandates.Legacy, multi-vendor setups were built for an era where "uptime" was the only metric.In the era of strict oversight and evolving privacy laws, how you remain secure is just as critical as if you stay online. Architecting a resilient security strategy that honors data sovereignty is what separates true Zero Trust from mere connectivity.Read this&nbsp;solution brief&nbsp;to learn more about Zscaler Business Continuity Cloud.For a tailored discussion:&nbsp;[Sign-up to Chat with an Expert]&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>Ganesh Vellala Umapathy (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Why SAP User Experience Starts with End to End Visibility]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/why-sap-user-experience-starts-end-end-visibility</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/why-sap-user-experience-starts-end-end-visibility</guid>
            <pubDate>Fri, 19 Jun 2026 22:07:06 GMT</pubDate>
            <description><![CDATA[For enterprises worldwide, RISE with SAP is so much more than a cloud migration initiative. It is a business transformation effort designed to modernize operations, improve agility, and support future growth. But transformation success is not measured only by migration milestones or infrastructure changes. It is also measured by the experience of the people who rely on business critical SAP apps every day.Can employees access these applications reliably? Can the business stay productive throughout change? These questions matter even more as SAP environments become more distributed as part of a phased transformation from on-prem to cloud.Today, SAP applications often span SAP-managed environments, hyper scalers, SaaS-based services, and enterprise-managed infrastructure. At the same time, users connect to these apps from corporate offices, branch locations, home networks, managed devices, and third-party endpoints. As a result, delivering a seamless user experience is far more complex than it used to be.When users report slowness or lagging transactions, the cause is rarely obvious. The issue may begin on the endpoint, within the local network, across the internet path, or in the environment delivering the SAP application. Without end-to-end visibility, IT teams are often left jumping between disconnected tools to determine what happened and who needs to act. In RISE with SAP environments, that complexity makes digital experience visibility essential.User Experience Is a Critical Factor in Business TransformationBusiness leaders expect transformation initiatives to improve efficiency, resilience, and productivity. But even when systems are technically available, suboptimal user experience can quickly undermine confidence in the outcome. If users encounter delays, login issues, or inconsistent application performance, the transformation may still feel foiled from the business perspective.&nbsp;A user’s SAP experience is shaped by every layer between the employee and the application. Slow page loads, delayed workflows, or transaction failures may not originate in SAP itself. They can also stem from endpoint resource constraints, weak Wi-Fi, packet loss, DNS delays, internet routing problems, or degraded application responsiveness.That is especially important in RISE with SAP environments, where security and operational responsibility is often shared. SAP may manage parts of the environment, while enterprise IT remains responsible for user access, productivity, and overall business continuity. When issues arise, multiple teams may need to collaborate, including endpoint, network, cloud, service desk, and SAP operations teams. The challenge is not just detecting a problem. It is determining where the problem exists so the right team can respond quickly.Why Fragmented Visibility Creates ChallengesMost organizations already have monitoring tools in place. The problem is that those tools often provide visibility into individual components rather than the full user experience. Application teams may see availability indicators. Network teams may see transport metrics. Endpoint teams may see device health. But when those signals are separated, troubleshooting becomes slower and more difficult. Teams have to manually correlate partial data, compare perspectives, and escalate across organizational boundaries to find the likely source of an issue.In shared-responsibility SAP environments, that lack of context creates delays, increases operational friction, and makes it harder to maintain a consistent user experience. What organizations need instead is a way to see SAP digital experience across the entire path—from user to application.End-to-End Visibility Improves SAP TroubleshootingSo a more robust approach is to monitor a SAP user’s digital experience across three connected layers:Endpoint device health, including CPU, memory, disk, and Wi-Fi conditions.Network and path performance, including latency, packet loss, and hop counts.Application experience, including performance, availability, and uptime.When these signals are correlated, IT teams gain a clearer understanding of how users are actually experiencing SAP applications. Instead of assuming every issue starts in the application, they can identify whether degradation is more likely tied to the device, the network path, or the application delivery environment. By narrowing the source of a problem faster, teams can reduce mean time to resolution, minimize unnecessary escalations, and improve coordination across groups.From Reactive Support to Proactive OperationsEnd-to-end digital experience visibility also enables a more proactive operating model. By continuously monitoring endpoint, network, and application signals, organizations can identify emerging issues earlier and address them before they disrupt users. This helps IT teams prioritize what matters most, reduce support burden, and protect the performance of business-critical SAP workflows.For organizations running core processes on SAP, that kind of proactive visibility can make a meaningful difference. It helps ensure that transformation is not just happening at the infrastructure level, but being felt positively by users who depend on SAP systems every day to run the business.Closing the Visibility Gap&nbsp;So to sum up, as organizations advance their RISE with SAP transformation strategies, monitoring approaches need to evolve as well. This is where Zscaler Digital Experience (ZDX) can help. ZDX provides end-to-end visibility across the full path from user device to application, correlating endpoint health metrics, network path performance, and application responsiveness in a single view. With insight into device health, local connectivity, internet path behavior, and application uptime, IT teams can identify performance issues faster, isolate root causes more accurately, and reduce time spent troubleshooting across disconnected tools.For RISE with SAP environments, that means greater visibility across shared-responsibility domains, faster resolution of user-impacting issues, and a more proactive approach to maintaining a consistent digital experience. Ultimately, a great SAP user experience is shaped not only by where SAP applications are migrated, but also by how reliably users can access them to get business-critical work done.&nbsp;To learn more about how Zscaler enables comprehensive SAP security across users and their experience, data, and workloads, download a copy of the Zscaler for SAP Security solution brief.&nbsp;]]></description>
            <dc:creator>Prateeksha Nagar (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[How Zscaler Secures Agentic AI: Zero Trust Platform for AI Agents, Endpoints, and MCP]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/how-zscaler-secures-the-agentic-ai-era</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/how-zscaler-secures-the-agentic-ai-era</guid>
            <pubDate>Thu, 18 Jun 2026 16:57:24 GMT</pubDate>
            <description><![CDATA[OverviewAI just crossed a threshold that changes everything for security teams.For two years, the enterprise AI story was about productivity. Faster research, smarter writing, better decisions. That was the warm-up. What's here now is categorically different: AI agents that don't just generate answers; they take action.They query your databases, call your APIs, trigger workflows, move data across systems, spawn sub-agents and much more They do all of this at machine speed, with identities that are ephemeral, permissions that are often over-broad, and behavior that most security tools were simply never built to see.At Zenith Live 2026, we announced exactly what enterprises need to govern this new reality: the industry's first complete Zero Trust platform for Agentic AI.Not a proof of concept. A deployable architecture built on the Zero Trust Exchange™ that already processes 750 billion transactions a day. Why Traditional Security Models Are Not Enough Against Agentic ThreatsLegacy security was designed around humans: known identities, predictable access patterns, static directories. AI agents break every one of those assumptions.An agent may carry valid credentials, act on a legitimate user's behalf, and interact with approved systems. This can pose a serious risk if it's over-permissioned, loosely governed, or invisible to your security stack. The challenge isn't just what an agent can access—it's what it's allowed to do once access is granted.Anthropic recently made this point directly in their Zero Trust for AI Agents framework: perimeter-based defenses cannot keep pace with AI-accelerated threats. Their conclusion aligns with ours: Zero Trust isn't just relevant for the agentic era, it's the only model built for it.Zscaler has successfully demonstrated for years how Zero Trust works at scale for users, branches, and cloud workloads. We're now extending that same architecture, with new purpose-built capabilities, to AI agents.Here's what we launched at Zenith Live. Zscaler AI BrokerAI agents communicate with each other and with enterprise data through emerging protocols like MCP (Model Context Protocol) and A2A (Agent-to-Agent). Most security tools can't see these channels at all.AI Broker sits inline on these communications, enforcing fine-grained access controls across every agent interaction. The integrated Agent Registry gives your team a clear, governed view of what each agent is permitted to access and enforces it in real time. No more black-box agent activity.&nbsp; Zscaler AI Access GraphThis is the visibility layer that makes everything else possible. Powered by our acquisition of Symmetry Systems, AI Access Graph maps how identities, AI applications, and data sources connect across your enterprise in real time. It surfaces over-privileged access before it becomes a breach, tracks data lineage across every channel, and integrates directly with the&nbsp;Zero Trust Exchange so you can move from insight to enforcement in the same platform. When an agent touches your data, you'll know exactly who authorized it, what it accessed, and where that data went.&nbsp; Zscaler Endpoint AI SecurityYour endpoints are already running AI whether IT knows about it or not. AI-powered IDEs, local models, browser plugins, developer extensions are the layers that legacy endpoint tools were never designed to inspect.Endpoint AI Security reaches into exactly those layers to detect AI-related threats, enforce policies, and stop risks that traditional EDR solutions miss entirely. It's Zero Trust enforcement at the device level, for the AI era.&nbsp; Major Enhancements to Zscaler AI ProtectBuilding on AI Protect, launched in January 2026, we're also shipping significant new capabilities across all three pillars:AI Asset Management: Now discovers embedded AI in SaaS and internet traffic, identifies AI agents and MCP servers in public cloud environments, scans agentic codebases for risk, and extends visibility to AI activity on endpoints.Secure Access to AI: Prompt extraction controls now cover 2,900+ GenAI apps, with full conversational views, Anthropic and OpenAI Compliance API support, and intent-based guardrails for multi-turn agent conversations.Secure AI Infrastructure and Apps: New AI red teaming for MCP servers, a standalone prompt hardening service, and compliance heat maps to strengthen AI governance across your environment.To learn more about these capabilities, read our dedicated blog here.&nbsp; The Bottom LineEnterprises don't need to slow down their AI adoption. They need security infrastructure that can keep pace with it.AI agents are a new class of digital actor: autonomous, fast, and capable of operating at a scope and scale that humans can't match. Governing them requires the same Zero Trust discipline that transformed how we secure users and cloud workloads. It just needs to be applied with more precision, coverage, and urgency.This is what Zscaler has built, and it's available now.&nbsp;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[What the ThreatLabz 2026 Phishing and Initial Access Report Means for the Public Sector]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/what-threatlabz-2026-phishing-and-initial-access-report-means-public-sector</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/what-threatlabz-2026-phishing-and-initial-access-report-means-public-sector</guid>
            <pubDate>Wed, 17 Jun 2026 14:28:20 GMT</pubDate>
            <description><![CDATA[It only takes one click. One convincing credential page, one well-timed lure impersonating a trusted agency workflow, and an attacker gains the initial access needed to move from inbox to identity to impact.&nbsp;That reality sits at the center of the&nbsp;ThreatLabz 2026 Phishing and Initial Access Report. While overall phishing volume in the Zscaler cloud fell 20% year over year, the campaigns that remain are more targeted, more AI-powered, and harder to distinguish from legitimate activity. ThreatLabz identified 413,524 AI-generated site instances across the analysis period, flagging 9% as malicious. These were produced by platforms like Manus AI, BlackBox AI, and Anything AI that allow attackers to spin up high-fidelity phishing infrastructure in minutes rather than days.For public sector defenders, the implications are direct. Government services, healthcare operations, and education environments all depend on digital trust, and attackers are exploiting that trust at every layer: AI-generated content, brand impersonation, credential theft, encrypted delivery channels, and real-time session hijacking that defeats traditional MFA. A single successful lure can still lead to account takeover, data exposure, service disruption, and loss of public trust.&nbsp;The data tells three distinct stories across government, healthcare, and education, but the underlying shift toward targeted, high-conversion initial access is consistent across all three.This blog post summarizes the key ThreatLabz report takeaways for the teams protecting government services, healthcare operations, and education environments. Government saw a 50% surge in phishing attacksPhishing attack attempts against the government sector jumped 50% year over year, one of the largest sector increases reported. With 138.5 million phishing hits in 2025, government ranked as the third-most targeted industry overall in the Zscaler cloud.That increase reflects how threat actors are turning public trust into an initial access opportunity. Citizens expect to interact with government agencies online, whether they are paying taxes, accessing benefits, renewing licenses, or resolving administrative issues. Attackers exploit that expectation by impersonating official services and creating workflows that feel legitimate.ThreatLabz researchers saw this play out in a campaign impersonating Brazilian government services. Attackers used AI-powered site builders, including DeepSite AI and BlackBox AI, to create convincing replicas of official portals. They paired those sites with SEO poisoning and guided users through a process that mirrored a real public service interaction before requesting payment through a trusted instant payment system. This is the new template for government-targeted phishing: AI-generated, workflow-aware, and designed to pass every human trust test.The&nbsp;IRS has similarly warned about impersonation scams that use email, SMS, and QR codes to mimic official communications and direct users to fraudulent portals designed to steal credentials and financial data.Government agencies need to protect the full citizen-facing experience, not only the inbox. That means detecting lookalike domains and fake portals, inspecting web and encrypted traffic, reducing exposure across public-facing services and applications, and applying identity controls that can stop credential theft from becoming account takeover. Healthcare recorded lower phishing volume, but consequences remain highAmong tracked sectors, the healthcare industry saw comparatively lower phishing hit counts in the Zscaler cloud in 2025, along with 1.58 million encrypted attack hits. By volume alone, the sector may look less exposed than higher-ranking industries.But for healthcare security teams, a convincing login page or trusted brand impersonation can turn a lower-volume campaign into a direct path to credentials, sessions, and application access that puts patient care at risk. With 95.2% of all phishing activity now delivered over encrypted channels, campaigns that reach healthcare users are already bypassing legacy defenses that don't inspect TLS traffic.These stakes make brand impersonation especially relevant. Microsoft and Google remained the top two most-imitated brands in the report, and both are common entry points into the cloud productivity and collaboration environments healthcare users rely on every day.&nbsp;As highlighted in the report, adversary-in-the-middle (AiTM) and browser-in-the-middle (BiTM) phishing kits are also designed to capture credentials&nbsp;and MFA tokens during the active login flow, turning a single click into session-level compromise regardless of whether MFA is enabled.For healthcare organizations, lower phishing volume changes the scale of the problem, not the stakes. The priority is stopping credential capture, session theft, and malicious redirects before a single successful lure becomes access to patient data and clinical operations. Education phishing fell sharply, but encrypted attacks kept risk in viewPhishing attempts against education organizations dropped 65.6% year over year. The sector lost more absolute phishing volume than any other tracked industry in the Zscaler cloud.The risk, however, has not disappeared. Education experienced roughly 1.6 billion encrypted attack hits in the past year, representing 6% of encrypted attack activity in the Zscaler cloud. For schools and universities, that contrast matters. Lower phishing volume in the inbox can coexist with significant malicious activity moving through TLS sessions, web traffic, cloud applications, and authentication flows, all channels where traditional email security has no visibility.The report also analyzes how attackers probe exposed entry points outside the inbox. ThreatLabz recorded 89.9 million hostile interactions with external decoys in just six months, underscoring the scale of reconnaissance against internet-facing assets. Education environments with broad public-facing infrastructure (portals, LMS platforms, federated authentication systems) present a large reconnaissance target.A drop in phishing volume should be treated as a positive signal, not proof that initial access risk is declining. Education teams need visibility across the activity that follows or bypasses the phish, including encrypted traffic, authentication flows, SaaS usage, browser behavior, and compromised credential use. What public sector security teams should do nowAcross government, healthcare, and education, the report's findings point to a consistent set of priorities for reducing initial access risk:Inspect encrypted traffic consistently. With 95.2% of phishing delivered over TLS, any gap in SSL/TLS inspection is a blind spot attackers will exploit. Inline inspection must cover web, SaaS, and cloud application traffic, not just email.&nbsp;Deploy phishing-resistant authentication. AiTM and BiTM kits defeat legacy MFA in real time. Transitioning to FIDO2-based, phishing-resistant credentials removes the most reliable path from click to session compromise.&nbsp;Reduce application exposure. Before the first lure is sent, attackers are already mapping your environment. Minimize discoverable attack surface by making applications invisible to the internet and enforcing identity-based access only after verification.&nbsp;Monitor for AI-generated phishing infrastructure. AI site builders are compressing the time from campaign ideation to live phishing page to minutes. Detection must account for rapidly rotating, high-fidelity lookalike domains and portals, not just known-bad indicators.&nbsp;Extend visibility beyond the inbox. Phishing is the entry point, but initial access is won in browsers, authentication flows, SaaS sessions, and encrypted channels. Security teams need visibility and control across the full path from lure to compromise.A Zero Trust architecture that verifies every connection, inspects encrypted traffic inline, minimizes exposed attack surface, and enforces least-privilege access provides the most effective foundation for disrupting the attacker's path at every stage, from reconnaissance through credential theft to lateral movement. Learn more: ThreatLabz 2026 Phishing and Initial Access ReportThese public sector findings are part of the broader ThreatLabz analysis of how phishing and initial access tactics are evolving in the AI era.&nbsp;Download the full report for the complete dataset, real-world attack chain walkthroughs, and actionable guidance for reducing initial access risk across government, healthcare, and education environments.]]></description>
            <dc:creator>Adam Ford (Chief Technology Officer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Prevent AI-Powered Cyberattacks With Deception Technology]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/prevent-ai-powered-cyberattacks-deception-technology</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/prevent-ai-powered-cyberattacks-deception-technology</guid>
            <pubDate>Tue, 16 Jun 2026 19:16:35 GMT</pubDate>
            <description><![CDATA[Deception technology is a security technique that seeds decoys such as fake files, AI agents, LLM APIs, and network segments into an enterprise’s environment. These decoys can then trap attackers who attempt to infiltrate the network in an AI-powered cyberattack.Legitimate users never engage with decoys, so any interaction with a decoy produces an immediate, high-fidelity signal of a breach.&nbsp;Deception technology turns an enterprise’s systems into a trap for would-be attackers.&nbsp;The&nbsp;Cloud Security Alliance (CSA) recommends that all enterprises implement deception capabilities immediately because of&nbsp;emerging AI security risks. AI-powered attackers can execute a full kill chain in minutes, but traditional tools like EDR, SIEM, and XDR can’t flag these attacks fast enough.&nbsp;Deception technology solves this problem by generating immediate, high-fidelity alerts that can stop sophisticated threats like AI-augmented cyberattacks.This post will walk through how deception technology works, why it’s different from traditional tools, and how it can prevent cyberattacks. How does deception technology work?&nbsp;Deception technology follows these steps to prevent cyberattacks:Security teams deploy fake assets including decoy servers, AI chatbots, AI training data, and endpoints. From the perspective of a bad actor, these decoys are indistinguishable from legitimate resources.An attacker gains initial access. Then, they look for valuable targets in the network.The attacker finds and interacts with a decoy asset. For example, they click a lure document, use a honey token, or log in with fake credentials.The deception solution produces a deterministic, high-fidelity alert.Security teams monitor attacker behavior.&nbsp;Deception solutions gather threat intelligence such as attacker TTPs, the types of data and systems being targeted, and if the bad actor is a solo threat or part of a larger campaign.The bad actor is slowed down and misdirected&nbsp;as they explore misleading information being fed to them via the deception solution. This information includes fake credentials, bogus network maps, and dead-end file paths.Security teams continue to gather threat intelligence.&nbsp;The attacker’s actions are logged and analyzed so that the enterprise can strengthen its defenses in the future.Integrations with SIEM, SOAR, and endpoint security tools trigger automated responses,&nbsp;such as isolating the bad actor’s device, revoking access tokens, or blocking suspicious IPs before they can access real assets.Post-incident analysis&nbsp;uses information from the bad actor’s actions to help patch vulnerabilities, update threat models, and refine the deception layer further.Deception uses active defense techniques to engage, mislead, and manipulate attackers within the network. Active defense flips the power dynamic of a cyberattack.&nbsp;By shifting from a defensive to an offensive posture, enterprises can respond more quickly and decisively to threats. They can monitor attacker techniques in real time, gather valuable threat intelligence, and remain confident that no legitimate resources are at risk.Why traditional defenses struggle to protect against AI-powered attacksTraditional defenses like signature-based and behavior-based tools (think: EDR, SIEM, and XDR) correlate events and generate probabilistic alerts. These correlations can take hours or days to produce, but modern AI-powered attacks move across the kill chain within minutes.AI-orchestrated attacks also probe environments at scale. For example, recent research from&nbsp;ThreatLabz recorded 89.9M interactions with external decoys in only six months.Traditional environments struggle to keep up with both the speed and volume of these probes. Tools like web application and API security solutions have a 45% false positive rate according to&nbsp;ESG, and these tools won’t generate an alert in&nbsp;91% of identity attacks.Unlike traditional defenses, deception technology produces immediate, deterministic alerts. It doesn’t rely on signatures or behavior baselining, and it doesn’t produce noisy alerts that require manual triage. Deception can therefore respond quickly and confidently in high-stakes, rapidly-developing situations like AI-powered cyberattacks. How deception protects against modern AI-accelerated threatsDeception surfaces malicious activity at each stage of the kill chain, from the minute a bad actor probes the perimeter to when they move laterally across the network to interact with endpoints,&nbsp;Active Directory, and cloud environments.&nbsp;Deception seeds each of these layers with decoys, lures, and breadcrumbs to&nbsp;protect against AI-powered attacks like APTs, ransomware, insider threats, fileless attacks, and supply chain exploits.&nbsp;Let’s walk through some examples of how deception stops attacks.Counters AI-orchestrated attacksAI agents can enumerate networks, harvest credentials, and move laterally in environments much faster than humans. EDR, SIEM, and other traditional tools can’t correlate events fast enough to identify these attacks in real time.&nbsp;Bad actors program their AI agents to thoroughly review all resources, which means those agents will inevitably probe a decoy. Deception technologies with agentic attack deception will then alert on the probe and disrupt that AI agent in-real-time.Detects lateral movement before ransomware executesOnce bad actors breach the network, they move laterally by escalating privileges and identifying high-value targets like file servers, backup systems, and domain controllers. Then, they deploy ransomware.Deception puts resources like fake Active Directory objects, decoy file shares, and lure credentials strategically so that bad actors must encounter those decoys as they move laterally. Any interaction with those decoys generates an immediate alert and triggers automated containment procedures before any ransomware can execute.Protects GenAI infrastructureAs enterprises deploy GenAI infrastructure like LLMs,&nbsp;RAG pipelines, and AI APIs, bad actors probe this infrastructure for vulnerabilities. Attacks targeting AI infrastructure include everything from prompt injection to model scraping, poisoning of training data, and exfiltration of sensitive information from vector databases.&nbsp;GenAI infrastructure deception deploys resources like decoy LLM chatbots, fake AI APIs, and honey tokens inside RAG pipelines and vector stores. Bad actors trying to manipulate or extract data from GenAI systems are funneled into these traps, which cause the deception solution to generate an alert.&nbsp; How deception supports zero trustThe speed of AI-powered attacks makes deception a critical component of any enterprise’s security strategy. For example, AI has dramatically accelerated phishing attacks and&nbsp;ThreatLabz recently identified over 37k AI-generated site instances as malicious. With AI, bad actors can quickly create high-fidelity fake sites, apps, and other lure infrastructure to leverage in a phishing attack.&nbsp;Enterprises should pair deception technology with zero trust to counter these threats.&nbsp;Zero trust minimizes the attack surface via identity verification, least-privileged access, and continuous validation. But zero trust can’t guarantee that a bad actor with compromised credentials won’t breach the environment, which is where deception comes in.Deception identifies bad actors who’ve slipped through the cracks and then manipulates them to gather the threat intelligence that security teams need to harden their defenses.&nbsp;Together, zero trust and deception create a defense-in-depth strategy in which access is tightly controlled at every entry point, and any attacker who still manages to breach the environment will walk into a trap.&nbsp;Interested in learning more about deception?See how&nbsp;Zscaler Deception prevented ten real-world cyberattacks.]]></description>
            <dc:creator>Julia Benson (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust for AI Agents: Governing Identity, Access, and Action at Enterprise Scale]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/zero-trust-for-ai-agents-built-for-whats-next</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/zero-trust-for-ai-agents-built-for-whats-next</guid>
            <pubDate>Tue, 16 Jun 2026 17:04:05 GMT</pubDate>
            <description><![CDATA[IntroductionFor the last two years, most enterprise AI conversations have focused on productivity. Faster research. More accurate writing. Better assistance for employees. That was the opening chapter.What comes next is more consequential: AI that does not just generate output, but takes action.AI agents are beginning to access applications, use tools, retrieve data, trigger workflows, and act on behalf of users. As Anthropic notes in its Zero Trust for AI Agents white paper, agentic systems introduce a different trust surface because they can “interpret goals, select tools, and execute multi-step operations.” ¹ That shift matters. Once AI moves from answering questions to operating inside the business, the challenge is no longer just how to use AI productively. It is how to govern systems that can act with speed, autonomy, and reach.That is why this moment does not call for a new security theory. It calls for applying the right one with more discipline. Zero Trust was built for environments where trust cannot be assumed. That is exactly why it is the ultimate answer to securing agentic-powered enterprises of the future.As AI agents gain autonomy, enterprises need a proven security model for governing access, action, and trust.&nbsp; How do AI agents change the nature of risk?An AI assistant that summarizes a document creates one kind of risk. An AI agent that can query a database, update a ticket, call an API, move data between systems, or trigger a downstream workflow creates another.The difference is agency.When AI moves from generating content to taking action, security teams have to think beyond model outputs and prompt controls. They have to think about operational behavior: what the agent can access, what it can do with that access, what tools it can invoke, what systems it can interact with, and how those actions are governed in real time. That is why agent security is not just an AI discussion. It is an architecture discussion.Any entity that can access business systems, interact with sensitive data, or take action across workflows must be governed accordingly. It needs a verified identity. It needs tightly scoped permissions. Its actions need to be constrained. Its behavior needs to be visible and traceable. And its communications with applications, data, tools, and other agents need to be controlled in real time.This is not a side issue within AI. It is a trust, access, and control problem at enterprise scale. How do you adopt AI without letting risk outpace governance?This is where customer conversations are heading now:How does Zero Trust apply to AI agents?Are AI agents just another application risk, or something fundamentally different?What changes when AI can take action instead of just generating content?How should enterprises think about access for nonhuman actors?How do we enable AI innovation without creating uncontrolled risk?These are the right questions because agentic AI changes the operating environment.Agents may use valid credentials. They may interact with approved systems. They may appear to be carrying out legitimate business functions. Yet they can still create risk if they are over-permissioned, loosely governed, or allowed to operate too broadly across the environment with too little visibility. That is where older trust models start to break down.If the architecture still assumes that being on the network, inside the environment, or behind a security boundary is enough to justify access, then AI agents are not just another use case. They are a stress test for the limits of implicit trust. Zero Trust starts with the right premiseZero Trust is not a feature or a repackaged legacy control. It is a battle-tested security model built for environments where trust must be continuously earned and verified, which is exactly why it fits in the age of AI agents. An agent may have a valid identity, act on a user’s behalf, and use approved tools, but that still should not translate into broad or persistent trust. Every connection must be explicitly verified, every access decision evaluated in context, every privilege tightly scoped, and every action visible and governable. That is not a new doctrine; it is the proven model for governing what comes next.&nbsp;In the age of AI agents, access control must evolve into action controlThe key question is no longer just what an identity can access, but what an agent is allowed to do once access is granted. That means defining and enforcing guardrails around:&nbsp;Which tools an agent can invokeWhich tasks it can performThe condition under which it can act how often it can operateWhether it can delegateWhen human approval is requiredIdentity still matters, but identity alone is not enough. Enterprises also need runtime governance, behavioral guardrails, and full traceability. If an organization cannot tie an agent’s action back to the policy, context, tool, and authority that permitted them, it does not have meaningful control.&nbsp; What comes next demands stronger controls, not softer onesIn an AI-driven environment, controls that merely add friction without materially reducing exposure are not enough. Machine-speed actors are far less constrained by inconvenience than humans are, which makes architectural security more important than ever. The stronger model is built on verified identity, short-lived credentials, tightly scoped access, controlled tool use, continuous inspection, and architectures that reduce exposure in the first place. That is the core of secure AI agent adoption:PrincipleWhy it mattersVerifiable identity for every agentIf an agent can act inside the business, it cannot operate as an anonymous or loosely governed process.Specific, least-privileged accessAgents should get access only to the apps, data, and workflows required for a defined task.Constrained action, not open-ended autonomyApproved access does not mean unlimited permission to act, invoke tools, or move dataContinuous visibility and traceabilitySecurity teams need to know what the agent did, what it touched, and what policy allowed it.&nbsp;Architecture that reduces exposureThe fewer reachable paths and exposed services, the less opportunity for machine-speed abuse.&nbsp; The path forwardEnterprises do not need to lower their standards to move faster with AI. They need a security model that can keep pace with how the business is actually changing.That means moving beyond perimeter-era assumptions. It means treating agent security as an architectural issue, not a feature checklist. It means reducing attack surface, eliminating unnecessary exposure, and making every access decision explicit. And it means applying Zero Trust the way it was meant to be applied: as a durable model for environments where trust must be earned continuously.AI agents are changing how work gets done. They should also clarify what secure adoption really requires. Not a bolt-on control. Not a repackaged legacy model. But a proven architecture for governing what comes next.The timing of Anthropic’s publication is not coincidental, it is confirming. As the industry’s leading voices in responsible AI development signal that Zero Trust is the right framework for the agentic era, Zscaler is proud to show what that framework looks like in practice. At ZenithLive ‘26 last week, we unveiled the industry’s first complete Zero Trust platform for Agentic AI; not a roadmap, not a proof of concept, but a proven architecture built for this moment. What Anthropic describes as the right model, Zscaler delivers as&nbsp; a deployable reality. And that is exactly what Zero Trust was built to do.&nbsp;&nbsp;Ready to see the Zero Trust platform for Agentic AI in action? Learn more and schedule a demo.]]></description>
            <dc:creator>Max Messina (Sr. Campaign Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Secure the High Value SAP Data Estate: Why Zero Trust Access is Now a Business Imperative]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/secure-high-value-sap-data-estate-why-zero-trust-access-now-business</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/secure-high-value-sap-data-estate-why-zero-trust-access-now-business</guid>
            <pubDate>Fri, 12 Jun 2026 23:05:12 GMT</pubDate>
            <description><![CDATA[Your Crown Jewels Live in SAP.&nbsp;SAP is where the business keeps its most valuable data. For many organizations, SAP isn’t just&nbsp;a platform. It’s the platform that runs the enterprise. That’s precisely why the security conversation around SAP needs to change.Secure Access and Securing Sensitive Data. Both are Table Stakes.Access remains foundational. But access alone doesn’t stop data loss. In today’s environment, the more consequential question is what happens after an authenticated and authorized user is already inside SAP and sensitive data is in play. How do you prevent that data from being extracted, copied, and moved by people who are already authorized to see it?SAP is a High Value Data Estate.SAP is a distributed data estate. SAP applications support hundreds of business-critical functions. S/4HANA runs across a mix of private cloud, hyperscalers, and data centers. And SAP workflows now include a larger and more geographically diverse population of users: employees, contractors, suppliers, and implementation partners. When access expands and the environment fragments, the old assumption, that SAP is protected by a clearly defined perimeter, stops being true.“Authorized” Doesn’t Mean “Safe”.Many of the most damaging exposures don’t begin with an outside threat actor battering down the door. They begin with legitimate access being misused. Sometimes intentionally, often negligently or accidentally, and frequently enabled by over-permissioning or weak controls around data movement. The user is inside the application and the workflow looks normal, until the data is gone.Implicit Trust Enlarges the Blast Radius.Legacy network-based security breaks down for SAP. VPNs extend the corporate network to users and create implicit trust: once someone is “on the network,” they are treated as more trustworthy. That broad access increases the blast radius of compromised credentials, fails to reflect the realities of modern access, and does little to stop common SAP data-loss paths. To protect sensitive SAP data, the network is the wrong place to anchor trust. Zero Trust shifts the focus from simply who can connect to what they can access and do. Trust is not granted because a user is inside the network. It is continuously evaluated based on identity, device context, and session risk.One High Value SAP Data Estate. Two Very Different Risk Realities.A pragmatic SAP Zero Trust architecture typically uses two access lanes because employees on managed devices and third parties on unmanaged devices present fundamentally different risk profiles. Trying to force both groups through a single access model often creates trade-offs—either slowing the business or introducing unnecessary security exposure.Employees on Managed DevicesFor authorized employees on managed devices, a client-based Zero Trust model can deliver seamless, secure access across SAP environments. In RISE with SAP Private Cloud Edition (PCE), ZPA App Connectors can be natively provisioned within the customer’s RISE environment, establishing outbound TLS connections to the Zero Trust Exchange and eliminating the need for inbound access or public IPs. On the user side, Zscaler Client Connector (ZCC) creates secure connections for SAP traffic, while policy evaluates identity and device posture before granting access only to the specific application requested. The result is user-to-app segmentation that reduces attack surface and helps limit lateral movement.Third Parties on Unmanaged DevicesPartners, contractors, and auditors should not receive broad network access simply to reach SAP. Zscaler’s browser-based Zero Trust access enables third parties to access only the specific SAP applications they are authorized to use, without exposing the broader network. Users authenticate through the organization’s identity provider (IdP), and policy is enforced based on identity and context. Access is brokered through an inside-out connection model that helps keep SAP applications hidden from the internet. For browser-accessible SAP applications, Browser Isolation can add protection for higher-risk users by isolating the session from the endpoint while preserving application-specific access. This helps reduce local storage and caching risk and can limit common exfiltration paths while preserving legitimate access.&nbsp;Across Both Groups: Protect Sensitive SAP Data Based on Risk and ContextRoutine user actions such as export, download, or copy/paste can create significant data-loss risk, if not governed by policy. Data Protection applies policy inline to govern these actions during SAP sessions and reduce the risk of sensitive data leaving controlled environments. On unmanaged devices, this helps prevent SAP data from becoming ungoverned local files. On managed devices, stronger posture signals allow these controls to be applied with greater precision.The Bottom Line: Make SAP Data Failsafe from LossSAP is where the crown jewels reside. If your SAP strategy still depends on trusted networks, trusted endpoints, or perfect user behavior, it is built on assumptions that no longer reflect how today’s modern enterprises operate across cloud migration, third-party access, and hybrid work. Zero Trust replaces those assumptions with controls aligned to how SAP is actually accessed and used today.&nbsp;The goal is not to make SAP harder to access. It is to minimize the likelihood that sensitive SAP data is ever exposed, misused, or lost.]]></description>
            <dc:creator>Prateeksha Nagar (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Why AI Red Teaming Matters for Enterprise Security]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/why-ai-red-teaming-matters-enterprise-security</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/why-ai-red-teaming-matters-enterprise-security</guid>
            <pubDate>Fri, 12 Jun 2026 18:25:48 GMT</pubDate>
            <description><![CDATA[AI red teaming is maturing, and security leaders need to rethink how they test AIGenerative AI is rapidly moving from experimentation to product. AI-enabled applications now support customer interactions, internal workflows, analytics, and automation across the organization. As adoption accelerates, security leaders face a growing challenge: understanding how these systems behave under real-world adversarial conditions.&nbsp;A recent report from Forrester makes it clear that AI red teaming is becoming a necessary security practice, but one that differs significantly from traditional penetration testing and red team engagement. Why AI red teaming is differentAccording to Forrester, AI red teaming blends established offensive security techniques with new testing approaches designed specifically for AI-enabled systems. Traditional red teams focus on infrastructure, applications, APIs, and the SDLC. AI red teaming must also evaluate risks unique to AI, including bias, toxicity, safety failures, data exposure, and unintended behavior.&nbsp;These challenges are compounded by the probabilistic nature of AI. Models retrain, responses vary, and integrations evolve quickly. Static, point-in-time testing loses relevance fast. Given this, Forrester emphasizes the importance of evaluating the entire AI application stack, not just the model itself. A fragmented AI red teaming landscapeOne of the report’s central observations is how fragmented the AI red teaming market has become. Security teams generally encounter two primary approaches:&nbsp;Traditional offensive security providers extending pen testing and red team services to AI-enabled environments. AI and ML security vendors offering continuous, automated prompt-based testingEach approach brings value, but neither is sufficient on its own. Prompt saturation can identify patterns at scale but often lacks context. Manual testing provides depth but struggles to keep pace with rapidly evolving AI systems. Forrester’s conclusion is pragmatic: the most effective AI red teaming programs combine human-led testing with continuous, adaptive, and agentic techniques.&nbsp;This hybrid model more closely reflects real adversary behavior and produces findings that are both actionable and relevant. Why prompt testing alone falls shortPrompt injection and jailbreaks tend to dominate AI security discussions, but Forrester is clear that they represent only part of the overall risk picture. Many of the most significant vulnerabilities exist in systems surrounding AI:&nbsp;Application logic that routes prompts and responsesAPIs and integrations connecting models to enterprise dataSource code repositories and CI/CD pipelinesIdentity, access, and data controls governing AI usageIn short, AI is still software, just software with new failure modes. Red teaming that focuses only on prompts leaves critical blind spots. Early AI red teaming is imperfect but necessaryMany organizations are testing AI systems earlier than they would prefer, often driven by regulatory requirements, audits, or customer scrutiny. Forrester acknowledges that early AI red team engagements may be imperfect, but they still provide value by uncovering systemic issues, informing governance decisions, and demonstrating due diligence.&nbsp;The key shift is moving from one-time assessment to ongoing AI red teaming programs that evolve alongside the technology.&nbsp;From testing to operational AI securityThe Forrester report points to a broader shift: AI red teaming is increasingly connected to how organizations operationalize security day to day. Testing alone is not enough. Security teams need continuous visibility into where AI is being used, how it is accessed, and how risk is introduced across applications, users, and data.&nbsp;As AI becomes embedded into SaaS platforms, custom applications, and internal workflows, the attack surface expands rapidly. Without a consistent way to discover AI usage, assess risks, and enforce controls, many organizations are left stitching together point solutions, each addressing only part of the problem.&nbsp;Forrester highlights how providers such as SPLX are pushing AI red teaming beyond isolated assessments toward scalable, continuous evaluation of AI-enabled systems. This reflects a growing recognition that AI security must be built on foundational security principles; continuous verification, least-privilege access, and strong data protections, rather than implicit trust. Applying zero trust principles to AI securityWhile the report does not frame AI red teaming as a zero trust exercise explicitly, many of its recommendations align closely with zero trust principles. AI systems should not be trusted by default, whether they are public AI services, embedded SaaS features, or internally developed models and agents.&nbsp;Applying zero trust thinking to AI means continuously validating access to AI systems, tightly controlling how AI interacts with enterprise data, and monitoring behaviour across users, applications, and integrations. When paired with continuous AI red teaming, this approach helps organizations reduce risk while still enabling rapid AI adoption.&nbsp;Rather than adding more disconnected tools, security leaders are increasingly looking to unify AI discovery, adversarial testing, and runtime controls, and governance into a cohesive security architecture, one that scales as AI usage grows.&nbsp;What security leaders should do nextAI red teaming is still maturing, but the direction is clear. Based on Forrester’s research, security leaders should:&nbsp;Expand AI testing beyond prompt to include applications, integrations, and data flowsCombine human expertise with continuous, adaptive testing techniquesApply zero trust principles to AI access, data exposure, and runtime behaviourTreat AI red teaming as an ongoing security capability, not a one-time eventAI will continue to move fast. The organizations that succeed will be the ones that can scale AI securely, without increasing complexity and losing visibility.&nbsp;Learn moreDownload the full Forrester report on AI red teaming to explore testing approaches, engagement models, and best practices for securing AI-enabled applications.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The &#039;Easy Button&#039; for Zero Trust B2B Connectivity: Introducing ZPA B2B Federation]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/easy-button-zero-trust-b2b-connectivity-introducing-zpa-b2b-federation</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/easy-button-zero-trust-b2b-connectivity-introducing-zpa-b2b-federation</guid>
            <pubDate>Wed, 10 Jun 2026 12:29:10 GMT</pubDate>
            <description><![CDATA[IntroductionSuccessful organizations rely on strong business partners and robust supply chain ecosystems. Traditionally, enabling secure connectivity across this ecosystem has involved site-to-site VPNs. These network-based B2B connections act as a "digital doorway" for partners, suppliers, and distributors to access internal resources. However, once a partner is "on the network," they often have broad access, creating massive attack vectors. This approach lacks Zero Trust enforcement—offering no user identity and device posture checks, no continuous verification, and no risk-based policies for external users. Furthermore, a traditional network-based approach leaves an organization’s security posture dependent on that of its partners.&nbsp;&nbsp;Organizations can no longer protect themselves by simply securing their own infrastructures since their electronic perimeter is no longer meaningful; threat actors intentionally target the suppliers of more cyber-mature organizations to take advantage of the weakest link.&nbsp; –&nbsp;NIST IR 8276 To address the security risk of the "weakest link," organizations need a model that decouples application access from network access. Zscaler shifts the focus from "network access" to "application access," ensuring that users are granularly connected only to the specific resources they need—and only after their identity and context have been verified.Last year, we extended our Zero Trust Architecture to B2B connectivity with the introduction of&nbsp;ZPA B2B Extranet. This capability represented a paradigm shift in bringing Zero Trust philosophy to business partner connectivity. Since then, many customers have enabled ZPA B2B Extranet to connect with their partners and suppliers, and many organizations also use this capability to accelerate mergers and acquisitions.This approach offers four immediate benefits:1) Elimination of the Attack Surface: Your internal applications remain invisible to the public internet and the partner’s network. There are no listening ports and no discoverable IP addresses.2) Simplified Onboarding: Gone are the days of coordinating complex firewall rules, NAT rules&nbsp; or shipping hardware &nbsp;to a partner's data center. Onboarding now happens at the speed of your business needs.3) Secure bi-directional connectivity: By leveraging Zscaler Zero Trust Exchange as the broker, secure connectivity &nbsp;extends both ways for workloads-to-workload communications.4) Reduced Operational Costs: By eliminating expensive site-to-site VPNs and the overhead of managing disparate &nbsp;IPsec tunnels, organizations can slash connectivity spending while significantly improving their security posture.Today, we are taking the next leap to further simplify B2B connectivity for environments where both entities are Zscaler customers with the brand-new ZPA B2B Federation. Introducing ZPA B2B FederationZPA B2B Federation enables organizations to share application access with external "guest" users from partners or subsidiaries, or those navigating mergers, acquisitions, and divestitures. Simply put, it provides seamless zero trust application access between organizations via ZPA tenant federation.&nbsp;&nbsp; How ZPA B2B Federation WorksOrganizations can enable ZPA tenant federation in three simple steps:Host: The organization that owns the application.Guest: The partner organization whose users require access.Step 1: Establish federation between ZPA tenants using a secure token exchange.Generate an access token to initiate federation with partner or verify access token generated by partner.&nbsp;Control the partner federation status: Active, Pause or Terminate.&nbsp;Step 2: Publish private application segments with your partner tenant.&nbsp;The host defines application segments with specific applications that guest users need access to.&nbsp;Step 3: Enforce Zero Trust access by configuring access policies for each B2B app group.The guest configures the access policy.&nbsp;Host can view the policies defined by partners. &nbsp;Use Cases for ZPA B2B FederationOur design partners intend to utilize ZPA B2B Federation for several critical scenarios such as:&nbsp;- Third-party partner and vendor access: This includes suppliers, contractors, distributors, and agencies—users who do not work for you but need access to specific applications to drive business. Today, connecting these users is often a painful process.- Mergers, Acquisitions, and Divestitures: The day a deal closes, the business expects "Day-1" access. However, IT is often left scrambling to merge networks, Identity Providers (IdPs), and security stacks—a process that typically takes months.- Multi-tenant and MSSP scenarios: Whether you are a service provider managing multiple customer tenants or a large enterprise with segmented business units running their own ZPA tenants, you need a way to share applications securely without collapsing into a single tenant.- Federal and cross-cloud collaboration: Government agencies, defense contractors, and regulated industries often need to share applications across Fed-High, Fed-Mod, and Commercial environments without compromising compliance boundaries. &nbsp;Real-World Impact: Greater Business Agility, Zero Trust Security, and Lower CostsThe combination of Extranet and Federation is a force multiplier for business agility, particularly in the world of Mergers, Acquisitions and Divestitures (M&amp;A&amp;D).- ZPA B2B Extranet is ideal for general B2B connectivity with partners that do not currently use Zscaler.- ZPA B2B Federation is the "Easy Button" for B2B connectivity within Zscaler-to-Zscaler environments.Traditionally, it takes months to integrate the IT environments of two companies. With Zero Trust B2B Connectivity, the "parent" company can provide a "subsidiary" with secure access to ERP or HR systems on day one, without ever merging the underlying networks.The core advantages are clear:1) Security: True Zero Trust for partner connectivity. There is no network access and no lateral movement; applications remain invisible to the internet.2) Speed and Agility: Partner onboarding moves from months to minutes. M&amp;A Day-1 access becomes a reality, and offboarding is as simple as a policy change.3) Cost Savings: Reduce upfront infrastructure costs and the ongoing operational costs of deploying and maintaining VPN concentrators and firewalls.4) User Experience: Users get direct-to-app access with consistent global performance and no clunky VPN clients.5) Operational Simplicity: No more managing complex IP-based rules, routing tables or NAT tables. Set-up secure partner access in just a few clicks. &nbsp;Conclusion: Transform your Business Partner Connectivity and Eliminate Legacy Complexity and Cyber Risk&nbsp;The announcement of ZPA B2B Federation, coupled with the general availability of ZPA B2B Extranet, marks a new era for the Zscaler Zero Trust Exchange. We are moving beyond just securing employees; we are securing the entire ecosystem of business relationships.By removing the friction of legacy hardware, the danger of lateral movement, and the operational burden of managing network infrastructure, Zscaler enables organizations to collaborate faster and more securely than ever before. Your partner ecosystem should be a competitive advantage, not a security liability. With Zero Trust B2B Connectivity, it finally is.Ready to get started? Take the&nbsp;[self-guided product tour] to experience firsthand how easily you can deploy ZPA and set up extranet connectivity for your business partners.Ready to chat?&nbsp;[Sign up now] and our product experts will connect with you to discuss how Zero Trust B2B Connectivity and ZPA B2B Federation can transform your organization’s connectivity]]></description>
            <dc:creator>Ganesh Vellala Umapathy (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Introducing the ZAgent Framework: The Foundation for Autonomous SASE]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/introducing-zagent-framework-foundation-autonomous-sase</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/introducing-zagent-framework-foundation-autonomous-sase</guid>
            <pubDate>Tue, 09 Jun 2026 22:51:32 GMT</pubDate>
            <description><![CDATA[Zscaler is proud to announce the ZAgent Framework, a new architecture that&nbsp;coordinates a fleet of AI agents across the Zero Trust SASE platform so administrators can automate complex tasks through plain natural language.&nbsp;The Admin Experience Is About to Look Very DifferentThe dominant model for enterprise software UI has been stable for decades: you log in, you navigate, you configure, you monitor, you repeat. AI changes the terms of that completely. When an agent can read telemetry, identify an anomaly, trace it to a root cause, and surface a recommended action in seconds, the question stops being "how do I find this in the UI?" and starts being "did the agent already handle it?"We are already seeing three distinct patterns emerge for how humans and AI systems will interact with security infrastructure:&nbsp;First,&nbsp;conversational: humans interacting with their security platform the same way they interact with a colleague, through a natural language prompt in whatever tool they are already using, whether that is a dedicated interface, a Slack channel, or a messaging app.Second,&nbsp;generative UI: when a task is too complex for conversation alone, an agent renders a visualization or workflow on demand, tailored to that specific investigation.Third,&nbsp;fully autonomous: headless agents connecting directly to APIs, CLIs, and machine-readable tools with no human in the loop at all, handling routine configuration, troubleshooting, policy enforcement, and monitoring in the background.&nbsp;Most enterprise security platforms today support none of these patterns well. They were built for a console-first world. Zscaler is building for what comes next. Announcing the ZAgent FrameworkThe ZAgent Framework is Zscaler's architectural foundation for agentic AI operations across the Zero Trust SASE platform. It is the first step toward fully autonomous SASE, a system that administrators can configure, monitor, troubleshoot, and optimize without logging into a traditional interface.At launch, administrators interact with ZAgent through a natural language prompt in the Zscaler Experience Center. Make a request in the chat. The ZAgent orchestrator interprets your intent, routes it to the right agent or combination of agents, and returns one coherent answer, regardless of how many systems worked to produce it. Whether a helpdesk person is looking to troubleshoot a performance issue or a network admin is looking to optimize a segmentation policy, the ZAgent knows where to route the request to deliver the desired outputs.The ZAgent framework delivers multiple benefits to our customers:Reducing resolution time&nbsp;for IT and security issues by comprehending the situational context of a challenge and coordinating specialized agents to resolve it.Simplifying management of the Zscaler environment by streamlining administration through a conversational interface and automated task execution.Improving decision accuracy by correlating context across 500 trillion daily signals and more than 1 trillion AI transactions, reducing false positives and surfacing threats that would otherwise go undetected.Simplifying audit readiness and risk mitigation by centralizing governance and guardrails within the Zero Trust Exchange platform.Expanding team capacity by automating routine investigation, triage, and remediation workflows so that every administrator operates with the depth and speed of a platform expert. Specialized Agents, a Shared Set of SkillsThe ZAgent Framework is organized around two principles: Agents and Skill Groups.Agents are domain-specific AI agents, each trained to operate within a defined area of the Zscaler platform. At launch, the framework covers eight areas across our product portfolio:Internet Access (ZIA)Digital Experience (ZDX)Private Access (ZPA)Zero Trust CloudSecOpsAI SecurityData SecurityZero Trust BranchEach agent is a specialist in its domain, with access to the data and tools it needs to act (and no access to anything it doesn’t need).Skill Groups are the capabilities that turn general-purpose AI into Zscaler product experts. Each agent draws on specialized implementations of core skill groups that include (but are not limited to):Knowledge:&nbsp;Answers questions about products, policies, and configurations.Data:&nbsp;Surfaces insights from platform telemetry and usage data.Troubleshooting:&nbsp;Identifies root causes and recommends or executes remediation.Configuration:&nbsp;Assists with policy setup, segmentation, and platform configuration.Remediation:&nbsp;Takes action to resolve issues.Workflow:&nbsp;Orchestrates multi-step operational tasks.Agents and their skills are activated and orchestrated autonomously by the ZAgent. Administrators don't need to know which agent handled a request or how many collaborated on it. They get the output. And it gets better over time: agents utilize observability to monitor and interpret admin interactions, constantly learning to be able to provide better answers. Governance and ComplianceThe ZAgent Framework is part of the Zero Trust Exchange platform. The framework has the following controls to ensure we meet local governance and compliance requirements.Data Residency Controls: ZAgent Framework data is stored in two geographic regions: United States and European Union (EU), ensuring compliance with regional data sovereignty requirements. Data for every customer’s agent follows stringent controls ensuring isolation and no cross-tenant data leakage. Agent requests and responses are processed and stored within the customer’s designated region.Dynamic Role-Based Access Control: Once a human agent logs in to the admin console, the ZAgent inherits the authenticated human agent’s existing permissions. These permissions are evaluated at run time and access can be fine tuned based on existing permissions for the human agent. This ensures the agent is operating strictly with the same boundaries as the human agent it serves, and cannot access resources, policies, configurations etc., beyond what the human agent’s role permits at any given time.Protection from LLM threats: The agents are protected from threats targeting LLMs, including OWASP Top 10 for LLMs such as Prompt Injections, Training Data Poisoning, and Model Theft. Zscaler is customer zero of&nbsp;AI Guard and Zscaler’s broader AI security portfolio to ensure every AI interaction is secure.AI agentic communication and interaction follows any guardrails and compliance requirements in place within an organization.&nbsp;&nbsp; ZAgent in Action: Two Early ExamplesOur ZAgents already have skills deployed across domains and product areas, and we will be rolling out many more in the coming months. Here are a couple of examples of ZAgent use cases:ZDX Agent:&nbsp;From Complaint to Root Cause in SecondsWhen a user reports a performance issue, the path from complaint to resolution has historically required multiple tools, multiple teams, and significant time. The ZDX Agent's Troubleshooting Skill changes that.An administrator types:&nbsp;"Investigate why users in the Northeast are experiencing degraded application performance." The ZDX Agent builds a multi-step investigation plan, runs it, and returns a summary with findings, supporting evidence, and recommendations in seconds. It rules out endpoints and Wi-Fi and identifies the issue as an ISP problem in the network transit path.The same agent can investigate an individual user. When a user’s performance degrades, the ZDX Agent pinpoints network latency caused by CPU starvation from a video editing process, then brings the administrator into the loop to authorize a remediation job to kill the hung process. The administrator confirms. The action runs. Healthy connectivity is restored.ZPA Agent: Dynamic Insights from Segmentation DataAutonomous User-to-App Segmentation, a powerful component of Zscaler Private Access, uses machine learning to identify and fingerprint applications and generate recommendations for app segments and policies. The ZPA Agent extends that capability.The ZPA Agent lets administrators query segmentation data dynamically, going beyond what is preconfigured in the Experience Center UI. Ask it to show a bar chart of application types across all users and it generates one. Drill into specific application usage by user over time. Tie that output directly to the policies governing access.Down the line, administrators will be able to use ZAgent to configure and monitor these policies autonomously. Why NowSecurity teams are managing more complexity with the same headcount. The administrators responsible for that problem can't afford to spend time on manual workflows that AI can handle.The ZAgent Framework addresses that directly. It is a new architectural layer built for the era of agentic AI, sitting beneath the Experience Center today and extensible to any interface in the future.ZAgent helps ensure the right users have the right access, issues are found and resolved before they become incidents, and your security posture improves without requiring constant manual attention.&nbsp; What Comes NextZAgent will first be accessible through the Zscaler Experience Center. The roadmap extends that same capability beyond the console. Through APIs, CLI workflows, and MCP tools, ZAgent will be able to connect with the AI systems and operational platforms customers already use, including ChatGPT, Claude, ITSM, SIEM, and collaboration tools. You can trigger Zscaler agents from those systems without opening a Zscaler console.Policy management, insight generation, incident response, configuration at scale: all of it driven by agents working on your behalf.Learn more about the ZAgent Framework at zscaler.com, or watch the Zenith Live Day 2 keynotes to see the ZDX, ZPA, and SecOps Agents in action.]]></description>
            <dc:creator>Elie Bitton (SVP, Strategic Development)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler is “Highly Effective &amp; Reliable” in NSS Labs SSE Threat Protection Test]]></title>
            <link>https://www.zscaler.com/mx/blogs/product-insights/zscaler-highly-effective-reliable-nss-labs-sse-threat-protection-test</link>
            <guid>https://www.zscaler.com/mx/blogs/product-insights/zscaler-highly-effective-reliable-nss-labs-sse-threat-protection-test</guid>
            <pubDate>Tue, 09 Jun 2026 16:28:52 GMT</pubDate>
            <description><![CDATA[As threat actors increasingly leverage AI to enhance the speed, scale, and sophistication of their attacks, the methods used to validate cybersecurity controls must evolve at an even faster pace. Point-in-time, manual testing, while once the standard, is no longer sufficient to measure a platform’s resilience against a continuous barrage of automated and evasive threats.This is why Zscaler consistently invests in product improvement driven by independent validation to prove our platform stays ahead of Advanced Persistent Threats. We are thrilled to announce that Zscaler Zero Trust ExchangeTM has been considered a&nbsp;Highly Effective &amp; Reliable cloud-delivered security platform in the&nbsp;Q2 2026 Security Service Edge (SSE) Threat Protection test from NSS Labs. Zscaler’s performance in rigorous third-party testing has set the industry benchmark, once again proving its dominance against the most advanced, AI-driven testing methodology in the industry.Sustaining its leadership under this new wave of testing, the Zscaler Zero Trust Exchange™ platform delivered an overall security efficacy of&nbsp;98.85%. This highly effective score was composed of exceptional results across the most critical protection categories, including a&nbsp;100% resistance rate against sophisticated evasion techniques,&nbsp;98.65% malware block rate, a&nbsp;99.05% exploit block rate, and a false positive accuracy of&nbsp;99.63%. These results provide unequivocal proof that Zscaler delivers superior protection to keep organizations secure. Test MethodologyThe goal of the NSS Labs SSE Threat Protection test was to assess the real-world capabilities and performance of Security Service Edge (SSE) platforms using a substantially updated SSE Threat Protection Methodology. The methodology is designed to measure how effectively a security solution protects users from threats, regardless of their location. The core areas of assessment included:Threat Protection: Evaluating the platform’s ability to effectively block exploits and malware from reaching end-users.Resistance to Evasion: Measuring the platform's resilience against techniques used by attackers to disguise their payloads and circumvent security controls. Key Findings: A Deeper Look at the ResultsZscaler's&nbsp;Highly Effective rating is the result of consistent test results across all major categories. Let’s explore the key findings in more detail.98.65% Malware Block RateThe Result: Tested against&nbsp;4,873 unique malware samples, Zscaler achieved a&nbsp;98.65% block rate, stopping everything from common ransomware strains to advanced, polymorphic threats.The Business impact: A single successful malware infection can lead to devastating consequences, including crippled operations, stolen data, significant financial loss, and lasting brand damage. An effective security platform must not only block known malware but also identify and stop novel, zero-day threats before they can execute.How Zscaler Delivers: This highly effective protection is the result of a powerful defense-in-depth strategy. It starts with full TLS/SSL inspection and is amplified by a suite of AI-powered malware detection engines. Our Advanced Cloud Sandbox quarantines and analyzes unknown threats inline, while the "cloud effect" – derived from processing over 500 billion daily transactions and blocking billions of threats – ensures that a threat seen once is blocked for every other customer instantly.99.05% Exploit Block RateThe Result: Zscaler blocked&nbsp;99.05% of the&nbsp;317 unique exploits tested, which targeted a wide range of applications, protocols, and operating systems.The Business impact: Exploits are the weapons threat actors use to gain an initial foothold, bypass security controls, and move laterally within a network. Preventing the exploit is the most effective way to stop an attack chain before it can even begin. This is especially critical for defending against zero-day attacks that target newly discovered vulnerabilities.How Zscaler Delivers: Zscaler's zero trust architecture inherently reduces the attack surface, making it harder for exploits to find a target. For traffic passing through the platform, our inline Intrusion Prevention System (IPS) and Advanced Threat Protection capabilities work in concert to identify and block exploit attempts in real time, protecting users and systems from compromise.100% Evasions ResistanceThe Result: NSS Labs tested Zscaler against&nbsp;583 different evasion techniques, and the Zero Trust Exchange demonstrated a&nbsp;100% success rate in identifying and blocking the underlying threat.The Business impact: Advanced attackers rarely use off-the-shelf malware; they use obfuscation, compression, and other evasion techniques to sneak their payloads past security defenses. A security control that cannot see through these disguises offers a false sense of security. Resilience to evasion is a key differentiator between basic security and a truly advanced threat protection platform.How Zscaler Delivers: Zscaler’s proxy-based architecture reconstructs all traffic before inspection, allowing our multiple security engines to see and decode even the most complex, layered evasion attempts. We don't just detect that an evasion is being used; we neutralize the evasion and block the malicious payload it was designed to hide.99.63% False Positive AccuracyThe Result: While aggressively blocking threats, Zscaler maintained an exceptional&nbsp;99.63% accuracy rate, correctly identifying legitimate files and traffic.The Business impact: False positives are more than just an annoyance; they erode trust in the security platform and create significant operational drag. When security teams are buried in false alerts, they waste valuable time and may be forced to disable critical security features, inadvertently opening the door to real threats. High accuracy is essential for both strong security and efficient operations.How Zscaler Delivers: The massive dataset flowing through the Zscaler cloud is our greatest strength. We use advanced AI and machine learning models, trained on trillions of signals from billions of daily transactions, to precisely differentiate between malicious and benign traffic. This allows us to maintain the highest level of threat protection without disrupting legitimate business activities. What This Means for Your EnterpriseThriving in the age of AI-driven threats requires investing in security that has been validated by an equally advanced testing methodology. Zscaler has achieved top-tier results in independent testing, and this year's&nbsp;Highly Effective rating against a highly advanced evaluation is our most significant accomplishment yet.These results are not just numbers on a page; they represent peace of mind. They affirm that with Zscaler, your organization is protected by a platform that has been battle-tested against the most sophisticated threats and the most rigorous validation standard in the world. As you navigate the complexities of digital transformation and secure your adoption of AI, Zscaler’s consistent, proven leadership makes it the clear and trusted choice to safeguard your users, data, and applications.Get the Full ReportWe invite you to download the full NSS Labs SSE Threat Protection report for a deeper analysis of Zscaler’s detailed performance, and what it means for your security strategy.[Download the Full Report Here]]]></description>
            <dc:creator>Vinay Polurouthu (Principal Product Manager)</dc:creator>
        </item>
    </channel>
</rss>