Products & Solutions | Blog

How to Find Which ISP is Slowing Down Your Users

Cynthia Tu (Sr. Product Marketing Manager, DEM) — Wed, 22 Jul 2026 22:19:42 GMT

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 ZDX webpage for more information on deeper capabilities, including multipath visualization, real user monitoring, and Device Score and Remediation. See Network Intelligence in action against your own environment.

Extending Zero Trust to the Browser: A New Frontier for Enterprise Security

Joby Menon (SVP, Product Management | Zscaler) — Fri, 17 Jul 2026 16:57:36 GMT

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 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 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 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. 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. 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 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 website or contact your sales representative.

Standardizing SSL Key Logging: A Step Forward for Secure Diagnostics

Yaroslav Rosomakho (Chief Scientist) — Thu, 16 Jul 2026 07:39:11 GMT

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 "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.

Empower Security Teams to See More and Respond Faster to Modern Threats with Zscaler Endpoint Context

Brendon Macaraeg (Sr. Product Marketing Manager) — Wed, 15 Jul 2026 23:29:35 GMT

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. Security teams need to know what on the endpoint actually caused that network activity. A trusted browser? An unsigned binary? 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. 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: 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. 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: schedule a demo with our product experts today.

When Attackers Wield Frontier AI: How to Keep Your Private Apps Unbreachable

Megha Tamvada (Director, Product Management) — Wed, 15 Jul 2026 20:36:44 GMT

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 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 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 negative seven days. Read that again. On average, attackers are now exploiting vulnerabilities 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 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: 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, 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: 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 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! 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.

Demystifying Key Exchange: From Classical ECDHE to a Post-Quantum Future

Brendon Macaraeg (Sr. Product Marketing Manager) — Tue, 14 Jul 2026 23:25:37 GMT

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: 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 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: The client and server exchange their public keys.The Shared Secret: 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 makes it trivial because it can factor large integers into prime numbers with extreme efficiency.This has led to a new field of cryptography: 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 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 both an ECDHE key exchange and an ML-KEM key encapsulation simultaneously.Two Secrets are Better Than One: 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 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 quantum resources or 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.

Prompt Injection Explained: How It Works, Why It Matters, and Practical Mitigations

Matt McCabe (Senior Web Content Writer) — Tue, 14 Jul 2026 17:57:40 GMT

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. 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. 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. 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 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. 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 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 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 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.

ポスト量子暗号への対応期限の前倒し：高度な暗号攻撃に備える新たな大統領令

Jose Padin (VP, Solutions Consulting, US Public Sector) — Tue, 14 Jul 2026 03:56:57 GMT

もはや仮説ではない量子の脅威2026年6月22日、大統領は2つの大統領令に署名しました。これらは、量子時代が急速に近付いており、対策が求められていることを示すものです。1つ目の「高度な暗号攻撃から国家を守る」(EO 14412)は、連邦政府によるポスト量子暗号への移行を加速させます。2つ目の「量子イノベーションの新たなフロンティアを切り拓く」(EO 14413)は、研究、商業化、サプライチェーンのレジリエンス、人材育成を網羅する政府全体の量子戦略を策定するものです。EO 14412では、明確な期限が定められています。連邦政府機関は、2030年12月31日までに最も機密性の高いシステムで使用する鍵確立をポスト量子暗号(PQC)に移行し、2031年12月31日までにデジタル署名もPQCに移行することが義務付けられています。また、この大統領令は連邦調達規制(FAR)評議会に対し、対象となる連邦政府契約者に対して、2030年12月31日までにPQCアルゴリズムを含む米国国立標準技術研究所(NIST)の連邦情報処理基準(FIPS)に順守することを義務付ける規則案を策定するよう求めています。すべての政府機関は、署名から30日以内にPQC移行責任者を任命しなければなりません。これらの大統領令の根底には、「収集しておいて後で復号する」(HNDL)と呼ばれる、広く認識されている脅威が存在します。国家レベルの攻撃者は現在、政府機関や組織の暗号化されたデータを積極的に窃取して保存し、十分な性能を備えた量子コンピューターが利用可能になった時点で復号することを狙っています。収集対象となるデータには、認証情報、知的財産、国家安全保障に関する情報が含まれ、数十年にわたって価値を持ち続ける可能性があります。どの政府機関や組織のセキュリティ部門にとっても、移行するかどうかが問題ではなく、どのようにどれだけ速く移行するかが問われています。法律と基準のフレームワークサイバーセキュリティに関する大統領令(EO 14412)は、組織が対応すべき、より広範な法的・技術的フレームワークの中に位置付けられています。量子コンピューティングサイバーセキュリティ準備法(P.L. 117–260)この法律は2022年12月に制定され、連邦政府機関に対し、暗号資産を把握するためのインベントリーを作成することが義務付けられています。具体的には、どの暗号化が使用されているか、どこに保管されているか、そしてどのシステムが量子攻撃によるリスクに最もさらされているかを把握する必要があります。見えないものは移行できません。OMB M–26–15:ポスト量子暗号への移行の実施EO 14412への署名から2日後、OMBは覚書M-26-15を発行し、大統領令で定められた期限を5段階の移行フレームワークに具体化しました。各政府機関は120日以内にPQC移行計画をOMBに提出しなければなりません。この覚書では、暗号資産の自動インベントリーと検出ツールの導入、ゼロトラストアーキテクチャーへのPQC統合、そしてFedRAMP認可のクラウドサービスプロバイダーとのPQC移行責任を共有するための連携が求められています。M-26-15は、PQCを持続可能なゼロトラストアーキテクチャーの基盤となる要素として位置付けており、耐量子暗号なしでは、組織は成熟したゼロトラスト態勢を実現できないことを強調しています。NISTのPQC規格NISTは、鍵確立に用いる量子耐性アルゴリズムであるML-KEM (モジュール格子ベース鍵カプセル化メカニズム)を標準化したFIPS 203を正式に策定しました。これは大統領令が定める当面の2030年の期限に対応する規格であり、Zscalerが現在提供しているPQC機能の基盤となっています。NISTはまた、大統領令で定める2031年の期限に対応するポスト量子デジタル署名の標準も正式に策定しています。これらの要件を総合すると、明確な運用上の指針が示されています。次の問題は、これらの期限が求める規模とスピードでPQC機能を提供できるセキュリティアーキテクチャーが何なのかということです。 Zscalerの取り組み：目的に合わせた対応大統領令が署名されるはるか以前から、Zscalerはポスト量子暗号技術の構築に投資してきました。これは、大統領令が定める当面の2030年までの鍵確立要件と、政府機関や組織が直面する運用上の現実に対応するためのものです。ここでは、まず施行される鍵確立要件に対して、Zscalerのプラットフォームがどのように対応するのかを解説します。PQCの可視化 - 自社の暗号化態勢の把握対応：量子コンピューティングサイバーセキュリティ準備法 | 大統領令の要件：暗号資産のインベントリーとリスク評価PQCへの準拠に向けた第一歩は、現在の暗号フットプリントを理解することです。従来の鍵確立や、将来的に量子攻撃に対して脆弱になるデジタル署名に依存しているすべてのシステム、アプリケーション、接続を特定する必要があります。OMB M-26-15では、連邦政府規模において手作業によるインベントリーのプロセスは不十分であることが認識されています。Zscalerのインラインアーキテクチャーはこの問題に直接対応します。実際のトラフィックに基づいて暗号を自動かつ継続的に検出し、ユーザー、デバイス、特定のトランザクションにおける暗号化機能を正確に可視化します。Zscalerは、Zscaler Zero Trust Exchange内の専用ダッシュボードとしてPQC Visibility Reportを提供しています。これにより、セキュリティ部門は以下の情報をリアルタイムで把握できます。PQCによる鍵確立でTLS接続を開始しているユーザーとデバイスPQCを導入できない従来のTLSプロトコルバージョンの使用状況従来の鍵確立が依然として使用されており、最も露出している場所移行の優先順位付けに役立つ、組織全体のトラフィックの内訳関連するすべての情報は詳細なトランザクションログで容易に入手可能であり、ZscalerのNanologサービスを通じてあらゆる規模でストリーミングできます。これにより、組織は組織全体のすべての暗号化の依存関係を体系的に整理したインベントリーである、暗号明細書(CryptoBOM)を作成できます。ZscalerはHCLTechと提携し、サービスによる暗号資産検出プロジェクトを提供しています。これにより、組織はCryptoBOMを作成して運用化し、包括的なPQC移行ロードマップの基盤として活用できます。ZscalerのPQC Visibility Reportは、準備法とM-26-15の両方が移行の基盤として求めている、実際のインベントリーを組織に提供します。インラインPQCインスペクション - 転送中トラフィックの保護対応：大統領令の要件：高価値資産と影響の大きいシステムにおける鍵確立をPQCへ移行 | 標準：NIST FIPS 203 (ML-KEM)2026年2月、ZscalerはインラインでのPQCトラフィック検査を完全に提供する初のセキュリティサービスエッジ(SSE)プロバイダーとなりました。これは、組織や政府機関のセキュリティインフラで実現可能なことを大きく変える画期的な機能です。仕組みZscaler Zero Trust Exchangeはユーザーとインターネットの間にインラインで配置され、「量子安全な仲介者」、つまり暗号の翻訳者として以下のように機能します。復号：Zscalerは量子安全な鍵確立(ECDHEと組み合わせたML-KEM/FIPS 203のハイブリッド方式)で保護されたトラフィックを含む、インバウンドTLSトラフィックを傍受および復号します。検査：完全なディープコンテンツインスペクションを適用し、脅威検出、情報漏洩防止、URLフィルタリング、ポリシーの施行を行います。再暗号化：トラフィックは適切なアルゴリズムで再暗号化してから、宛先に転送します。Zscalerはこの機能に対応しているサーバーにおいて量子安全な鍵確立を使用します。このアーキテクチャーは、組織におけるPQC移行で最も難しい課題の1つである、従来のサーバーとの互換性の問題を解決します。多くのバックエンドサーバーやSaaSアプリケーションは、まだPQCによる鍵確立を導入していません。ZscalerのZero Trust Exchangeはこのギャップを解消し、最新のクライアントとPQCで保護された接続を確立しつつ、従来のサーバーと互換性のあるこれまでのTLS接続を維持します。これにより、組織はエコシステム内のすべてのサーバーやアプリケーションがアップグレードされるのを待つことなく、今すぐHNDL攻撃からユーザーを保護し始めることができます。TLS 1.3とハイブリッド鍵交換Zscalerのインライン検査エンジンは、従来の一時鍵を用いた楕円曲線ディフィー・ヘルマン鍵共有(ECDHE)とML-KEM (FIPS 203)を組み合わせたハイブリッドのPQC鍵確立をサポートしています。このハイブリッド方式は、純粋なPQCへの直接移行に比べて安全かつ慎重であると広く認識されており、多層防御を提供します。適切に実装されたハイブリッド方式を侵害するには、従来のアルゴリズムとPQCアルゴリズムの両方を破る必要があります。最新のWebブラウザー(Chrome、Edge、Firefox、Safari)との完全互換性を提供し、インターネットエンジニアリングタスクフォース(IETF)の現在の推奨事項に従っています。OMB M-26-15は、ハイブリッドアーキテクチャーを有効な移行モデルとして認めており、ネットワークレベルでPQCを導入するための基盤としてTLS 1.3を指定しています。すべての政府機関に対して、2030年1月2日までの導入期限としています。今後の予定：暗号化ポリシープロファイルPQCの要件はすべて同じではありません。IETFは、インターネット上で幅広い互換性を確保するために、ML-KEMと従来のECDHEを組み合わせたハイブリッド鍵交換方式を推奨しています。一方、NISTのCNSA 2.0スイートは、国家安全保障システムにおいて純粋なML-KEMを採用することを求めており、従来の要素を完全に排除しています。Zscalerは現在、暗号化ポリシープロファイルの開発を進めています。これにより、セキュリティ部門は、どの暗号標準をどこで施行するかをきめ細かく制御できるようになります。管理者は、一般的な組織のトラフィックにはハイブリッド鍵交換を義務付ける一方、CNSA 2.0の要件に該当する接続には純粋なML-KEMを義務付けるポリシーを定義できるようになります。ポリシーは、ユーザーグループ、アプリケーション、データ分類、またはコンプライアンス体制によって適用範囲を設定できます。大統領令で定められた2030年の期限とCNSA 2.0のガイドラインの両方に従う連邦政府機関の顧客にとって、この柔軟性は不可欠です。これにより、組織全体に画一的なアプローチを強制することなく、1つのプラットフォームで多様な暗号化要件を満たすことが可能になります。ゼロトラストアーキテクチャーが適切な基盤である理由ZscalerのPQC機能は、世界最大のセキュリティクラウドであるZscaler Zero Trust Exchangeにネイティブに組み込まれています。このアーキテクチャー上のメリットは、PQCへの移行において重要です。インラインで動作する設計：すべてのユーザー接続がZscalerを経由するため、エンドポイントエージェントやネットワークの再構築を必要とすることなくPQCインスペクションを一律に適用します。クラウドならではのスピードでの拡張性：Zero Trust Exchangeは1日あたり数千億件のトランザクションを処理しており、ユーザーエクスペリエンスを低下させることなくPQCアルゴリズムによる計算負荷の処理に必要な能力を提供します。ポリシー主導型：セキュリティ部門は、ユーザー、グループ、アプリケーション、データ分類ごとに適用範囲を決めて量子安全なTLS要件を選択的に施行でき、段階的かつ制御された移行を実現します。統一された可視性：従来のトラフィックと量子安全なトラフィックの両方が単一の画面で提供されるため、移行期間中に死角は発生しません。暗号の機動性：PQC研究は現在も活発なテーマであり、NISTは追加アルゴリズムの標準化に取り組んでいます。Zscalerクラウドは常に最新のセキュリティガイドラインを採用しており、PQCに関する推奨アプローチが変更された際にも予期しない混乱を顧客が心配する必要はありません。結論：2030年まで待たずに今すぐ行動2030年という期限はまだ先のように感じられるかもしれません。しかし、HNDLの脅威はまさに今、現実となっています。現在、従来の鍵交換方式で確立されたチャネルを介して送信されるデータは、量子コンピューターの実用化が組織の準備よりも先に進むと見込んでいる攻撃者によって収集されています。移行が1日遅れるごとに、さらなるデータがリスクにさらされることになります。Zscalerが政府機関や組織に伝えたいメッセージはシンプルです。保護を始めるのを待つ必要はありません。自社の暗号情報の露出状況を確認し、量子安全なトラフィックをインラインで検査し、ネットワークファブリックを保護するためのツールは、現在利用可能です。PQCへの準拠に向けた取り組みはゼロトラストを通じて実現され、Zscalerはその道のりを皆さまとともに歩む準備ができています。Zscalerのポスト量子暗号ソリューションの詳細は、PQC準備状況評価を依頼するか、Zscalerテナント内のPQC Visibility Reportをご覧ください。今後のブログでは、FedRAMPと戦争省の組織を対象としたPQC移行に関する推奨事項を取り上げる予定です。

Why Do F1 Teams Need Cybersecurity, and How Is AI Changing the Threat Landscape?

Matt McCabe (Senior Web Content Writer) — Thu, 09 Jul 2026 19:10:53 GMT

An F1 car doesn’t just burn fuel, it burns data. 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.

アラート疲れを超えて：Zscaler Workflow Automationによる次世代データセキュリティの構築

Michael Schneider (Principal Specialist Solution Architect) — Wed, 08 Jul 2026 15:22:34 GMT

情報漏洩防止(DLP)担当アナリストに日々の運用上の課題について尋ねると、通常はアラート疲れがまず挙がります。組織がクラウドアプリケーション、エンドポイント、組織メールに展開を拡大するなかで、データ保護インシデントの件数は急増しています。従来の「ブロックして記録する」アーキテクチャーは、手動によるトリアージに大きく依存しています。そのため、セキュリティ部門はエンドユーザーを追跡して「これは意図した共有であったのか、ビジネス上の正当な理由は何か」と尋ねることを強いられてしまいます。真のデータ保護は、IT部門やSOC部門だけの責任であってはなりません。セキュリティは誰もが活用できるものでなければなりません。Zscaler Workflow Automationを活用すれば、組織はデータセキュリティインシデントの処理方法を変革できます。Workflow AutomationはZscaler Internet Access (ZIA)やEndpoint DLPと直接統合され、トリアージの責任をデータ所有者に戻し、煩雑な例外管理を自動化するとともに、セキュリティ担当者が真の内部脅威やデータ持ち出しの試みに集中できるよう支援します。今回は、この変革を可能にする技術的な機能について詳しく解説します。トリアージの分散化：エンドユーザー正当化のワークフローWorkflow Automationは、IT担当者を介することなく、エンドユーザーとリアルタイムで直接やり取りできます。インラインDLPポリシーがトリガーされると、システムはインシデントをシームレスに取得し、きめ細かなロールベースアクセス制御(RBAC)を通じて機密性の高いトリガーデータや証跡を保護するとともに、自動化対応ワークフローを開始します。このプラットフォームは、SIEMで静的アラートを生成するのではなく、マルチチャネル対応の通知テンプレートを活用し、Slack、Microsoft Teams、メールなど、ユーザーが普段利用しているチャネルへ直接通知します。通知は、エンドユーザーに理由の入力を求めるアンケートを提供します。管理者はこれらのアンケートテンプレートを作成、複製、カスタマイズ、翻訳することで、世界中の従業員をサポートできます。図1:エンドユーザーに理由の入力を求めるアンケートにより、ユーザーがトランザクションを許可すべき理由を特定できます。ユーザーによる相方向の回答に応じて、自動化エンジンはインシデントを動的にルーティングします。誤検知やミスの自動修復：ユーザーが自身のミスに気付いて転送をキャンセルした場合、インシデントはタグ付けされて自動的にクローズされます。管理者へのエスカレーション：アイデンティティープロバイダーを通じてユーザーを直属の管理者に関連付けることで、ワークフローは特定の理由説明を伴う申請を管理者に回付し、二次承認を受けられるようにできます。アナリスト向けの情報拡充：操作が重大度の高いしきい値に達した場合は、ユーザーが入力した理由説明やコンテキスト情報がイベントに追加されます。ZscalerはServiceNowやJiraなどのITSMプラットフォームとネイティブに連携し、コンテキスト情報を付加したチケットを自動的に作成するため、アナリストはフォレンジック調査に必要な情報を即座に把握できます。ゼロタッチIT:例外管理の自動化これまで、エンドユーザーがDLPポリシーと相反する正当かつ緊急のビジネスニーズを抱えている場合、運用上の負担が非常に大きなものでした。ITチケットを提出し、セキュリティ管理者が手作業でポリシー例外(多くはIPアドレスやURL単位)を設定するのを待ち、さらにポリシーの肥大化を防ぐために後でその例外を取り消すカレンダーリマインダーまで設定する必要がありました。Zscaler Workflow Automationは、この手作業を大幅に削減します。ワークフローがユーザーにコンテキストを求める指示を出し、事前定義された許容基準または指定された承認者を通じてリクエストが承認されると、システムは例外を動的に管理します。図2:ワークフローモデリングでは、ユーザーへの通知、その回答の取得、その後の管理者への通知を実行します。この機能により、管理者は例外を作成し、最後には自動的に終了処理を実行できるため、DLP部門の担当者がプロセスに関与する必要はありません。トランザクションは業務上の理由とともにすべて記録されたうえで許可されるため、基礎となるDLPポリシーを手動で変更する必要はありません。これにより、基本的なセキュリティ態勢を健全な状態に保ち、ネットワークとエンドポイントのポリシーの複雑化も避けられます。シームレスなメールセキュリティ：隔離メールの解除を自動化メールは依然として偶発的なデータ漏洩の主要な経路となっていますが、メールの隔離メールの管理には膨大な時間が費やされています。従来、送信メールが機密データに関するルールに抵触した場合、そのメールは隔離され、ヘルプデスクへのチケットが発行されていました。その後、管理者がメールの内容を手作業で確認してから、隔離を解除しなければなりませんでした。Zscalerは高度なインシデント情報インターフェイスを通じて、この状況を根本的に変革します。送信元DLPタイプがEmailの場合、管理者は「メール隔離の解除」の操作を手動で行ってメッセージをすべての受信者に配信できます。または、プラットフォームから特定の受信者のみを選択して解除することも可能です。高度なインシデント情報インターフェイスは管理者にとって価値がありますが、真に変化をもたらすのは高度なアカウント設定にある「エンドユーザーによるメール隔離解除の有効化」機能です。この機能を有効にすると、IT部門の負担が軽減されます。メールが隔離される場合、ユーザーにはポリシー違反の説明が瞬時に通知されます。その後、ユーザーには正当性の説明を求めるワークフローが提示されます。ユーザーが許容されるビジネス上の理由を提供するか、統合された管理者の承認を得ると、自身で隔離されたメッセージを解除できます。その後、システムが自動的にメールをMTAに送信し、配信を実行します。ITチケットは0件となり、手動によるレビューは不要で、重要な業務コミュニケーションの遅延も発生しません。自己修復型セキュリティ態勢の設計データセキュリティは、ビジネスのボトルネックやSOCの疲弊と同義であってはなりません。Zscaler Workflow Automationを活用することで、セキュリティアーキテクトは高度に応答性が高く自己修復可能なDLPアーキテクチャーを構築できます。SlackやTeamsのようなプラットフォームにカスタムワークフローを直接統合し、例外管理を完全に自動化するとともに、エンドユーザー自身が管理された条件下でメールの隔離を管理できるようにすることで、これまでデータ保護に伴って発生していた手作業を削減できます。その結果、組織のレジリエンスを強化し、インシデントキューを削減しながら、セキュリティ部門は真の脅威ハンティングに集中できるようになります。Zscalerが次世代データセキュリティを支援する方法の詳細は、製品データシートを確認し、デモを依頼してください。よくある質問DLPアラート疲れとは何ですか？また、Zscaler Workflow Automationはどのように解決しますか？DLPアラート疲れとは、セキュリティ部門が大量の情報漏洩防止アラートにさらされることで、どのインシデントに即時対応が必要なのか特定が困難になる状態です。アラートが繰り返し発生するもののリスクが低い場合や明確なビジネスコンテキストが欠けている場合、アナリストは徐々にそうした状態に慣れてしまいます。その結果、調査が遅れ、重要なアラートを見落とす可能性が高まります。Zscaler Workflow Automationは、DLPインシデントを自動的に強化、優先順位付け、ルーティングすることで、この課題の解決を支援します。これにより、セキュリティ部門はノイズの中から選別する時間を減らし、意味のあるリスクに対応する時間を増やせます。さらに、自動化されたワークフローでは、インシデントの確認や対応を手作業で行う必要がなくなります。この自動化により、DLP部門はノイズを分離し、本当に重要なことに集中できます。その結果、効率が向上し、対応が迅速化され、担当部門がより一貫した意思決定を行うことができます。 Zscaler Workflow AutomationはどのようにDLPインシデントのトリアージを自動化しますか？Zscaler Workflow Automationは、アラートの調査やルーティングにかかる手作業を削減することで、DLPインシデントのトリアージを自動化します。関連するコンテキスト情報をインシデントに付加し、意思決定ロジックに基づいて承認を開始し、対応を割り当てたうえで、各インシデントを適切な部門やワークフローへ振り分けることができます。これにより、組織は日常的なインシデントを効率的に処理しつつ、リスクの高いイベントに対してより迅速に対応できるようになります。 Zscalerでは、エンドユーザー自身が隔離されたメールを解除できますか？はい、組織はZscaler Workflow Automationを通じてエンドユーザー自身が隔離されたメールを解除できるように設定できます。この機能は制御された形で設定できるため、特定のメッセージのみをユーザー自身による解除の対象とし、より機密性の高いケースについては追加の確認や承認を求めるように設定できます。このアプローチにより、管理者による監視を維持したまま、ユーザーエクスペリエンスを向上できます。自動化された例外管理と従来のDLPポリシー例外の違いは何ですか？従来のDLPポリシー例外は通常、ポリシー内で直接行われる静的な変更であり、積極的に見直さなければ、意図した以上に長期間そのまま残ってしまう可能性があります。自動化された例外管理は、より動的で制御されたアプローチです。これにより、組織は、定義された条件下で特定の操作を許可でき、期間限定で付与され、承認プロセスや監査証跡とともに管理されます。 Zscaler Workflow AutomationはどのようにSlack、Microsoft Teams、Jira、ServiceNowと連携してデータセキュリティインシデント管理を行っていますか？Zscaler Workflow Automationは、Slack、Microsoft Teams、Jira、ServiceNowと連携し、組織がすでに利用しているプラットフォームを通じてデータセキュリティインシデントを管理できるよう支援します。通知の送信、承認の要求、回答の収集、記録の更新、主要な関係者間でのインシデント対応の連携維持などが可能です。Zscalerにより、組織は対応時間を短縮し、より一貫性があり監査可能なインシデント管理プロセスを構築できます。免責事項：このブログは、Zscalerが情報提供のみを目的として作成したものであり、「現状のまま」提供されています。記載された内容の正確性、完全性、信頼性については一切保証されません。Zscalerは、ブログ内の情報の誤りや欠如、またはその情報に基づいて行われるいかなる行為に関して一切の責任を負いません。また、ブログ内でリンクされているサードパーティーのWebサイトおよびリソースは、利便性のみを目的として提供されており、その内容や運用についても一切の責任を負いません。すべての内容は予告なく変更される場合があります。このブログにアクセスすることで、これらの条件に同意し、情報の確認および使用は自己責任で行うことを理解したものとみなされます。

SSE Architecture Explained: How SSE Enables Zero Trust

Julia Benson (Senior Web Content Writer) — Mon, 06 Jul 2026 22:25:03 GMT

A 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. 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 SWG, CASB, and 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 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. Inline controlsStops threats and data exfiltration during user access.Threat protection stack Includes malware and phishing protection, content scanning, and integrations for EDR/XDR, SIEM, and SOAR. Traffic steering and connectivity 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 Prepares real-time logs and reporting for visibility, alerting, incident response, and compliance or audit requirements. How AI enhances SSE architecturesAI and machine learning shift 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 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) 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 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 and recommends policy changes based on real-world usage and risk. How does SSE enable zero trust? A step-by-step overviewSSE enforces zero trust principles through a combination of its integrations and its SWG, CASB, and ZTNA functionality. Here's what SSE does in real time when a user requests access to an app:Verify user identity. When a user requests access to an application, SSE uses its integration with an IdP to authenticate that user via MFA.Assess device posture. 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. SSE checks the user’s role, device type, and location to enforce the correct access policy.Replace traditional network access with ZTNA. Rather than placing the user on a broader network, SSE establishes a ZTNA connection directly to the application.Inspect all traffic inline. SSE implements TLS/SSL inspection on all traffic. The platform scans encrypted and unencrypted traffic for malware, phishing, and policy violations. Apply inline threat prevention. SSE blocks malicious content, unauthorized SaaS apps, and other threats before they reach the user or application.Control cloud and SaaS app activity. 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. Monitor user behavior. 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. When SSE detects anomalous behavior, it immediately takes action to isolate the threat.Complete audits and implement incident response. 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: Least-privileged access: 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: The same rules apply whether users are at the office or working remotely.Threat prevention applied at the edge: Inspects traffic, blocks malware, and proactively identifies risky behavior.Improved visibility and auditability: 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 SSE represents an accessible starting point for that evolution. As you mature your zero trust architecture and SSE program, you'll find that deploying secure access service edge (SASE) is a natural next step. Bringing together networking and security using a 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. Ready to learn more about Zscaler SSE?See why Zscaler achieved a “Highly Effective & Reliable” rating in the Q2 2026 NSS Labs SSE Threat Protection test.Request a demo to see how Zscaler protects against AI-driven threats.

SecOps for the AI Age: Detecting and Responding to AI‑Related Incidents

Matt McCabe (Senior Web Content Writer) — Thu, 02 Jul 2026 21:06:09 GMT

AI-related incidents don’t look like traditional security alerts, which means 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. AI incidents create a new detection gap: Threats such as prompt injection, sensitive data exposure, 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. — 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: 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: 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 security operations 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: 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: 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.

When To Choose SSE vs. SASE: A Decision Framework for Security Leaders

Julia Benson (Senior Web Content Writer) — Thu, 02 Jul 2026 17:09:36 GMT

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). SASE, which encompasses all the features of SSE plus SD-WAN capabilities, is often viewed as the desired end state. But launching a 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 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 CASB features to identify SaaS app usage, monitor risk, and enforce policies for app access and data handling.Remote users are vulnerable to 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 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, SASE helps address the following problems: 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. What are the key differences between SSE and SASE? 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&A activity and the security team needs a solution that can easily integrate new infrastructure and onboard new users. When to start with SSEYou’ll want to begin with an SSE implementation when:You’re frustrated with your VPN. 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. 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 ransomware. 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. Your SD-WAN or WAN is “good enough.” 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. Your organization is cloud and SaaS-heavy, and you need improved security today. 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. 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: You’re already doing a WAN refresh. 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. You need consistent policy delivery across branches, users, and cloud workloads. 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. SASE is especially useful for organizations with branch-heavy footprints, like in the retail, finance, or manufacturing sectors. You want a single platform and need a simplified rollout strategy. 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. 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 full SASE implementation. With a 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 SSE capabilities on a unified architecture. And that vendor must be able to help you scale into a 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 path to SASE. Want to learn more about Zscaler SSE and SASE?Request a demo to see Zscaler in action.

An AI Agent That Can’t See the Whole Path Is Just a Faster Way to Be Wrong

Rohit Goyal (Sr. Director, Product Marketing - ZDX) — Wed, 01 Jul 2026 18:16:39 GMT

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. 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: A 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. A 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 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: 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

Five Eyes Cyber Agencies Signal a New AI Security Consensus: “We Must Act Now”

Adam Dobell (Head of Government Affairs, APJ) — Tue, 30 Jun 2026 19:04:08 GMT

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 “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: “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.” 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 Zero Trust for AI Agents framework and in Zscaler’s own research. As noted in our preliminary security research published on Anthropic Mythos and OpenAI GPT 5.5, 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. The Five Eyes Five Actions Organizations Should Take Now1. 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.” 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.” 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. Address Legacy Systems“Unsupported systems are easy targets. They are not just technical debt, they are strategic liabilities.” 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. 4. Review and Strengthen Identity and Access Controls“Limit who can access critical systems. Enforce strong authentication and regularly review permissions.” 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 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. Prepare for Incidents Before They Happen“Test response plans, train and prepare teams, and assume breaches will occur. Focus on fast containment and recovery.” 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. As outlined in our recent blog, How Zscaler Secures the Agentic AI Era with Zero Trust, organizations should apply the same principles that have proven effective for users and workloads. 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. 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.

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

Jose Arvelo Negron (Manager, Sales Engineer) — Tue, 30 Jun 2026 13:03:32 GMT

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. 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 & 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: 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: 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: 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: 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: 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.

SSE Components Explained: SWG, ZTNA, CASB, and How They Work Together

Julia Benson (Senior Web Content Writer) — Mon, 29 Jun 2026 22:12:17 GMT

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. As remote work and SaaS adoption dissolve traditional network perimeters, legacy solutions like 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. 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? Secure web gateways give visibility into threats hidden in HTTPS connections. Most modern threats don't arrive in plaintext. According to Zscaler ThreatLabz research, 86% of threats, including malware, phishing, drive-by downloads, and ransomware, are delivered over encrypted HTTPS traffic. 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: 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 command-and-control (C2) traffic. What does ZTNA do? 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. 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. 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: Location-agnostic policy enforcement: 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: Grants the minimum access necessary for a user to complete a task. Full session inspection: Inspects sessions inline for 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 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. CASB core capabilitiesHere are seven core capabilities to look for in a CASB solution:Shadow IT discovery: Provides visibility into all cloud app usage across the organization and surfaces shadow IT risks. 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: 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. 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. And if the contractor’s risk profile changes mid-session, the policy engine can dynamically adjust controls without administrator input. 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. 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. Why a platform approach to SSE mattersSecurity service edge is a powerful tool against modern threats like 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 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. Ready to learn more about SSE?Request a demo to see Zscaler SSE in action. Download the ThreatLabz 2026 AI Security Report for the latest data on emerging threats and enterprise AI adoption trends.

AI in Cybersecurity: Benefits and Risks

Matt McCabe (Senior Web Content Writer) — Fri, 26 Jun 2026 19:36:49 GMT

What Is AI in Cybersecurity? 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. 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. 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. 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. 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. 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 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: 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

リリースからリーダーへ：Zscaler AI ProtectによるAIセキュリティ基準の引き上げ

Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives) — Thu, 25 Jun 2026 22:27:47 GMT

概要6か月前、私たちはAIを根本から保護することを目的として構築された業界初のプラットフォームであるZscaler AI Protectをリリースしました。当時、組織向けのAIは急速に発展していました。現在、その勢いはさらに増しています。重要なのは、この変化のスピードです。従来のセキュリティサイクルで何年もかかったことが、AIによって数か月で実現しています。だからこそ、私たちは先手を打ちました。初回リリースからわずか6か月後に開催されたZenith Live 2026で、AI Protectの大幅な強化を発表します。これにより、保護範囲を拡大し、制御を強化すると共に、現在セキュリティ部門にとって最も重要なギャップを解消します。こちらで新機能を紹介します。 AI資産管理：稼働中のAIをすべて可視化セキュリティ部門が見えないものを保護することはできません。AIは許可されたツールをはるかに超えて広がり、SaaSトラフィックに組み込まれ、クラウド環境で動作し、開発者コードベースにも組み込まれています。今回の機能強化により、全体像を把握できます。2,900以上のAIアプリに対応：シャドーAIはすでに社内に存在しています。業界で最も幅広いAIアプリカタログ全体を可視化することで、承認の有無にかかわらず、使用されているすべてのツールを把握できます。パブリッククラウドエージェントのスキャン：AIエージェントはAWS、Azure、GCPでどの部門も手作業では追跡できない速さで次々と展開されています。自動検出と評価により、クラウド環境内で見落としが発生することはありません。ソースコードのスキャン：AIは今この瞬間もアプリケーションに書き込まれています。リスクの高いAI使用や、エージェント型コードベースにおけるモデルロジックの露出は、本番環境に到達する前に検知されます。AIコード実行時のスキャン：脅威の中には、コードが実際に実行された際に初めて顕在化するものもあります。本番環境でエージェント型コードを監視することで、展開前のスキャンでは検出できない脅威を捉えます。AIの攻撃対象領域分析：把握していないものは防御できません。攻撃者に先んじてすべてのAI資産、接続、露出を継続的かつ包括的に把握します。これらの機能を組み合わせることで、すべてのCISOが抱える「自社環境では実際にどのAIが稼働しており、どこにリスクがあるのか」という問いに答えます。 AIへの安全なアクセス：AIの実際の動作に合わせて構築されたより高度な制御稼働状況を把握するだけでは十分ではありません。今回の機能強化により、セキュリティ部門とコンプライアンス部門は業務のスピードを損なうことなく、AIの実際の使用方法を正確に制御できます。マルチターンプロンプト検査：AIとの会話は一度のやり取りでは完結するものではありません。複数回にわたるプロンプト全体の文脈を評価することで、単一ターンのみの視点では完全に見落とされてしまうリスクを検出できます。プロンプトと応答の再現：調査や監査には、断片的な情報ではなく全体像が求められます。すべてのAIとのやり取りを記録し、行われたとおりに再現します。ランタイム保護の施行：事後にのみ適用されるポリシーは保護ではなく、記録です。やり取りの瞬間にポリシーを施行することで、リスクを未然に阻止します。自動修復ポリシー：すべての違反に人間が関与する必要はありません。検出された違反には自動で対処するため、担当部門は対応時間を短縮し、より重要な業務に集中できます。AnthropicとOpenAIのコンプライアンスAPI:社内のユーザーはすでにChatGPTやClaudeを業務で使用しています。両社のコンプライアンスAPIをネイティブサポートしているため、カスタム開発なしで、ポリシーをそれらのサービスにも適用できます。独自検出モデルの導入：機密性の高いコンテンツの定義は組織によって異なります。独自の検出モデルをネイティブに施行するため、汎用的なリスクプロファイルでなく、自社のリスクプロファイルに合わせてプラットフォームを運用できます。Zscaler Private Accessとの統合：AIリスクはパブリッククラウドの境界だけにとどまりません。プライベートアプリケーションや社内ワークロードにも制御を拡張することで、ゼロトラストポリシーを真にエンドツーエンドで実現します。制御を伴わない可視性は、単なる観察に過ぎません。これらの機能により、あらゆるAIとのやり取り、あらゆる環境、あらゆるユーザーに対して、インサイトをポリシー適用へとつなげます。 AIインフラとアプリの保護：導入から信頼性の確保まで可視化とアクセス制御は、AIの活用方法に対応するものです。この第3のレイヤーはAI自体が信頼できるかどうかという点に対応するものであり、AIインフラの強化を担当する部門にとって今回の最も重要な新機能がこの点に集約されています。オンボーディングエージェント：新たなAIツールはすべて潜在的なリスク要因となり、手作業による評価では変化のスピードに追いつけません。リスク評価プロセス全体を自動化することで、新しいツールを数週間ではなく数時間で承認できます。MCPレッドチーム演習：モデルコンテキストプロトコル(MCP)はエージェント型AIとのやり取りにおける新たな標準であり、すでに攻撃対象となっています。MCPサーバーに対して直接行う自動攻撃テストは、攻撃者より先に弱点を発見します。プロンプト強化サービス：プロンプトインジェクションは、AIの動作を操作する最も一般的で有害な手法の1つです。サービスレベルで体系的に強化することで、脆弱性が悪用される前にリスクを軽減します。コンプライアンスヒートマップ：ガバナンス上のギャップは、インシデントになる前に修正することが最も簡単です。AIガバナンスの状況を常に最新の状態で可視化することで、自社の強みと次に注力すべき点が明確にわかります。迅速に導入し、導入したAIを信頼する。そのために、今回の機能は構築されています。より大きな視点AI Protectは2026年1月に、明確な理念を掲げてリリースしました。それは、AIのを保護するには、既存ツールを流用するのではなく専用に構築されたプラットフォームが必要であるという考え方です。16もの新機能が追加された現在、この理念は単に正しさを証明しただけでなく、さらに説得力を増しています。組織はAIのスピードとAIセキュリティのどちらかを選ぶ必要はありません。組織には、そのような妥協自体をなくすプラットフォームが必要です。それこそZscalerが構築したプラットフォームであり、今すぐご利用いただけます。デモをご要望の場合は、こちらからご依頼のうえ、ご確認ください。

Hardening Federal Networks for the Mythos Era: What the AI Executive Order and BOD 26-04 Demand Now

Ryan Gillis (Zscaler) — Thu, 25 Jun 2026 22:21:30 GMT

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 joint statement calling AI-driven cyber risk a matter requiring immediate action. Their message was direct: "The timeline is not years, it is months." 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. 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. 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 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. 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 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.

The Salesforce-Klue Incident: How Zscaler Protects SaaS Data

Niharika Sharma (Staff Product Manager - CASB PM) — Thu, 25 Jun 2026 17:00:10 GMT

A recent Salesforce security 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. The rise in SaaS supply chain security attacksOver the past few years, incidents involving vendors such as Gainsight and 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 modern SaaS security. 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 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. 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. 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. 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. 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. 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 Zscaler SaaS Security, organizations can discover third-party applications, assess risk, understand exposure, and rapidly respond when incidents occur, all from a single platform. To learn more about how Zscaler can help your organization respond to incidents like Salesforce-Klue, request a demo. FAQWhat happened in the Salesforce-Klue security incident? 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? 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? 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? 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? 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.

The Agentic AI Threat Model: Prompt Injection, Context Poisoning, and Agent Behavior Drift

Matt McCabe (Senior Web Content Writer) — Thu, 25 Jun 2026 16:55:34 GMT

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. How to secure agentic AI at the build phase 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. 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. 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.

Transforming Mission Partner Data Exchange: Moving Past the Networks

Patrick Perry (Public Sector Field CTO) — Mon, 22 Jun 2026 18:13:09 GMT

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. Integrate an identity provider. Access decisions start with identity, so identity is not an afterthought. Instrument early with visibility and logging. If you move fast without visibility, you accumulate risk faster than you can manage it. 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

AI Security Guidelines for Employees: An Acceptable‑Use Policy You Can Enforce

Matt McCabe (Senior Web Content Writer) — Mon, 22 Jun 2026 17:26:09 GMT

Enforcing safe AI use across a workforce requires four things working together: 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 A published policy creates accountability. These four layers make it enforceable. 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: 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. 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.

Zero Trust, Zero Downtime: Ensure Security and Compliance Through Outages and Disruptions

Ganesh Vellala Umapathy (Sr. Product Marketing Manager) — Sat, 20 Jun 2026 06:56:20 GMT

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 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. 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 & 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 & 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. 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. 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 solution brief to learn more about Zscaler Business Continuity Cloud.For a tailored discussion: [Sign-up to Chat with an Expert] 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.

Why SAP User Experience Starts with End to End Visibility

Prateeksha Nagar (Sr. Product Marketing Manager) — Fri, 19 Jun 2026 22:07:06 GMT

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. 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 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. 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.

Zscalerがゼロトラストでエージェント型AIの時代を保護する仕組み

Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives) — Thu, 18 Jun 2026 16:57:24 GMT

Zscalerがゼロトラストでエージェント型AIの時代を保護する仕組みAIは今、セキュリティ部門を取り巻く環境が大きく転換する領域へと足を踏み入れました。この2年間、組織向けAIに関する話題は生産性向上が中心でした。調査をより速くし、文章作成をより賢くし、意思決定をより良くするということは序章に過ぎませんでした。現在の状況は、本質的にまったく異なります。答えを生成するだけではなく、実際に行動を起こすAIエージェントが登場したからです。AIエージェントはデータベースを照会し、APIを呼び出し、ワークフローをトリガーし、システム間でデータを移動させ、サブエージェントを生成するなどさまざまな処理を行います。しかも、そのすべてをマシンの速度で実行します。一方、そのアイデンティティーは一時的なものであり、権限はしばしばしばしば過剰に広く付与されており、その振る舞いは、ほとんどのセキュリティツールが可視化できるように設計されていないものです。Zenith Live 2026において、私たちは、この新たな現実を統制するために組織がまさに必要としているものを発表しました。それは、エージェント型AIのための業界初の包括的なゼロトラストプラットフォームです。これは概念実証ではありません。すでに1日あたり7,500億件のトランザクションを処理するZero Trust Exchange™を基盤とした、展開可能なアーキテクチャーです。従来のセキュリティモデルではエージェント型の脅威に対して不十分である理由従来のセキュリティは人間を中心に設計されており、既知のアイデンティティー、予測可能なアクセスパターン、静的なディレクトリーを想定していました。AIエージェントはそうした前提をすべて覆します。エージェントは有効な認証情報を保持し、正規ユーザーに代わって行動し、承認されたシステムとやり取りする場合があります。このとき、過剰な権限や緩い管理、セキュリティスタックから見えない状態といった要因が重なると、深刻なリスクに発展する可能性があります。課題はエージェントが何にアクセスできるかだけでなく、アクセスが許可された後に何を実行できるかという点にあります。Anthropicは最近、同社のZero Trust for AI agentsフレームワークでこの点を明確に指摘しました。つまり、境界ベースの防御はAIによって加速する脅威に追いつくことができないのです。同社の結論はZscalerと一致しています。ゼロトラストはエージェント時代において単に適切であるというレベルに留まらず、エージェント時代のために構築された唯一のモデルであるということです。Zscalerは長年にわたり、ユーザー、拠点、クラウドワークロードに対してゼロトラストが大規模に機能することを実証してきました。現在は、同じアーキテクチャーを、AIエージェント向けに特化した新たな機能を備えて拡張しています。Zenith Liveで発表した内容はこちらです。 Zscaler AI BrokerAIエージェントはMCP (モデルコンテキストプロトコル)やA2A (エージェント間)などの新たなプロトコルを通じて、エージェント同士、または企業データと通信します。ほとんどのセキュリティツールはこれらのチャネルを全く可視化できません。AI Brokerはこれらの通信の間にインラインで介在し、すべてのエージェント間のやり取りに対してきめ細かなアクセス制御を施行します。統合されたエージェントレジストリーにより、各エージェントがアクセス許可されている内容を明確かつ管理された視点で担当部門に提供し、リアルタイムでその制御を施行します。もはやブラックボックス化したエージェントの活動は存在しません。 Zscaler AI Access Graphこれはその他のすべてを実現する可視化レイヤーです。Symmetry Systemsの買収により、AI Access Graphはアイデンティティー、AIアプリケーション、データソースが組織全体でどのように接続されているかをリアルタイムでマッピングします。過剰な権限を持つアクセスを侵害が発生する前に明らかにし、すべてのチャネルにわたるデータリネージを追跡し、Zero Trust Exchangeと直接統合することで、同じプラットフォーム内でインサイトから施行へと移行できます。エージェントが自社のデータにアクセスした際には、誰がそれを許可したのか、何にアクセスしたのか、そしてそのデータがどこに行ったのかを正確に把握できます。 Zscaler Endpoint AI Securityエンドポイントは、IT部門が把握しているかどうかに関わらず、すでにAIを実行しています。AIを活用したIDE、ローカルモデル、ブラウザープラグイン、開発者向け拡張機能は、従来のエンドポイントツールでは検査が設計されていなかったレイヤーです。Endpoint AI Securityはまさにそのレイヤーにまで踏み込み、AI関連の脅威を検出し、ポリシーを施行します。これにより従来のEDRソリューションでは完全に見逃されるリスクを阻止できます。これはデバイスレベルでのゼロトラストの施行であり、AI時代に対応したものです。 Zscaler AI Protectの主な機能強化2026年1月にリリースされたAI Protectを基盤として、Zscalerは3つの柱のすべてにおいて重要な新機能の提供を開始します。AI資産管理：SaaSやインターネットトラフィックに埋め込まれたAIを検出できるようになりました。パブリッククラウド環境におけるAIエージェントやMCPサーバーを特定し、エージェント型コードベースをスキャンしてリスクを評価するほか、エンドポイント上のAI活動まで可視化を拡張しました。AIへの安全なアクセス：プロンプト抽出制御が、2,900以上の生成AIアプリに対応するようになりました。完全な会話ビュー、AnthropicとOpenAIのコンプライアンスAPIへのサポートに加え、マルチターンのエージェントとの対話において意図ベースのガードレールを適用します。AIインフラとアプリケーションの保護：MCPサーバー向けの新しいAIレッドチーム演習、スタンドアロンのプロンプト強化サービス、コンプライアンスヒートマップにより、環境全体にわたるAIガバナンスを強化します。結論組織はAI導入のペースを落とす必要はありません。必要なのは、そのペースに追いつけるセキュリティインフラです。AIエージェントは新しいタイプのデジタルアクターであり、自律的で高速、そして人間には到底及ばない範囲と規模で動作する能力を持っています。それらを統制するには、ユーザーやクラウドワークロードのセキュリティを変革したゼロトラストの規律と同じものが必要です。これは、より高い精度で広範かつ迅速に適用する必要があります。これこそZscalerが構築したものであり、今すぐご利用いただけます。デモをご要望の場合は、こちらからご依頼のうえ、ご確認ください。

What the ThreatLabz 2026 Phishing and Initial Access Report Means for the Public Sector

Adam Ford (Chief Technology Officer) — Wed, 17 Jun 2026 14:28:20 GMT

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. That reality sits at the center of the 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. 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 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. As highlighted in the report, adversary-in-the-middle (AiTM) and browser-in-the-middle (BiTM) phishing kits are also designed to capture credentials 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. 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. 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. 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. 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. 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.

デセプションテクノロジーによるAIを悪用したサイバー攻撃の阻止

Julia Benson (Senior Web Content Writer) — Tue, 16 Jun 2026 19:16:35 GMT

デセプションテクノロジーとは、偽のファイル、AIエージェント、LLM API、ネットワークセグメントなどのデコイを組織環境に組み込むセキュリティ手法です。これらのデコイは、AIを悪用したサイバー攻撃でネットワークに侵入しようとする攻撃者を罠にかけることができます。正規ユーザーがデコイに関与することはないため、デコイへの何らかの働きかけが発生した時点で、それは侵害が発生したことを示す即時かつ高精度のシグナルとなります。デセプションテクノロジーは組織のシステムを攻撃者に対する罠へと変えるのです。Cloud Security Alliance (CSA)は新たなAIセキュリティリスクの出現を受け、すべての組織が直ちにデセプション機能を導入することを推奨しています。AIを悪用する攻撃者はキルチェーン全体を数分で実行できますが、EDR、SIEM、XDRのような従来のツールでは、これらの攻撃を十分な速さで検出できません。デセプションテクノロジーは、AIで高度化したサイバー攻撃など、巧妙な脅威を瞬時に高精度で警告するアラートを生成することでこの問題を解決します。この記事では、デセプションテクノロジーの仕組み、従来のツールとの違い、そしてサイバー攻撃を防ぐ方法について解説します。デセプションテクノロジーの仕組みデセプションテクノロジーは、以下の手順でサイバー攻撃を防ぎます。セキュリティ部門が偽の資産を展開する。これにはデコイサーバー、AIチャットボット、AI学習データ、エンドポイントなどが含まれます。攻撃者から見ると、これらのデコイは正規のリソースと見分けがつきません。攻撃者が初期アクセスの権限を獲得する。その後、攻撃者はネットワーク内で価値のある標的を探します。攻撃者がデコイ資産を見つけて操作する。たとえば、ルアーのドキュメントをクリックしたり、ハニートークンを使ったり、偽の認証情報でログインしたりします。デセプションソリューションが確定的で高精度のアラートを生成する。セキュリティ部門が攻撃者の行動を監視する。デセプションソリューションは、攻撃者のTTP、標的となるデータやシステムの種類、攻撃者が単独の脅威か大規模なキャンペーンの一部かといった脅威インテリジェンスを収集します。攻撃者は足止めされ、別の方向へと誘導される。攻撃者はデセプションソリューションを通じて誤った情報を探索します。この情報には偽の認証情報、架空のネットワークマップ、行き止まりのファイルパスが含まれます。セキュリティ部門が引き続き脅威インテリジェンスを収集する。攻撃者の行動は記録および分析され、将来的に組織の防御の強化に使われます。SIEM、SOAR、エンドポイントセキュリティツールとの統合によって自動応答が発動する。たとえば、攻撃者のデバイスの隔離、アクセストークンの失効、疑わしいIPのブロックにより、実際の資産にアクセスされる前に対応します。インシデント後に分析する。この分析では、攻撃者の行動から得た情報を、脆弱性の修正、脅威モデルの更新、デセプションレイヤーのさらなる改善に活用します。デセプションは能動的防御の手法により、ネットワーク内で攻撃者と関与し、あざむき、操作します。能動的防御は、サイバー攻撃における力関係を逆転させます。防御の姿勢から攻撃的な姿勢へと移行することで、組織は脅威に対してより迅速かつ断固とした対応を取れるようになります。攻撃者の手法をリアルタイムで監視し、貴重な脅威インテリジェンスを収集できます。一方で、正規のリソースは危険にさらされる心配は一切ないという、確かな安心感を持つことができます従来の防御ではAIを悪用した攻撃から保護できない理由シグネチャーベースや行動ベースのツール(EDR、SIEM、XDRなど)のような従来の防御は、イベントを関連付け、確率的なアラートを生成します。こうした関連付けの結果が得られるまでには数時間から数日かかる場合がありますが、最新のAIを悪用した攻撃は数分以内にキルチェーン全体を進行します。AIが指揮する攻撃は、環境の大規模な探索も行います。たとえば、ThreatLabzの最近の調査では、わずか6か月で8,990万件の外部デコイとのやり取りが記録されています。従来の環境では、これらの探索の速度と量の両方に追いつくことができません。ESGによると、WebアプリケーションやAPIセキュリティソリューションのようなツールは誤検知率が45%に達しており、これらのツールはアイデンティティー攻撃の91%でアラートを生成しません。従来の防御とは異なり、デセプションテクノロジーは即時かつ確定的なアラートを生成します。シグネチャーや行動の基準に依存しておらず、手動でのトリアージを必要とするようなノイズの多いアラートも生成しません。そのため、デセプションはAIを悪用したサイバー攻撃のような重大かつ急速に進展する状況において、迅速かつ確実に対応できます。デセプションで最新のAIによる脅威から保護する仕組みデセプションは、攻撃者が境界を探索した瞬間から、ネットワークを水平移動してエンドポイントやActive Directory、クラウド環境とやり取りする段階に至るまで、キルチェーンの各ステージで悪意のある活動を可視化します。デセプションはこれらのレイヤーにデコイ、ルアー、ブレッドクラムを仕掛け、APT、ランサムウェア、内部脅威、ファイルレス攻撃、サプライチェーン攻撃などのAIを悪用した攻撃から保護します。デセプションがどのように攻撃を阻止するのか、例をいくつか見ていきましょう。AIが指揮する攻撃への対抗AIエージェントは、人間よりもはるかに速いスピードで、ネットワークの列挙を実行し、認証情報を収集し、環境内で水平移動することが可能です。EDR、SIEM、その他の従来のツールでは、イベントをリアルタイムで特定するほど速く関連付けができません。攻撃者は自身のAIエージェントにすべてのリソースを徹底的にレビューするようプログラムしています。そのため、こうしたエージェントは必然的にデコイを探索します。エージェント型攻撃向けデセプションを備えたデセプションテクノロジーは、そうした探索にアラートを発し、そのAIエージェントをリアルタイムで妨害します。ランサムウェア実行前のラテラルムーブメントの検知攻撃者がネットワークを侵害すると、権限昇格を行い、ファイルサーバー、バックアップシステム、ドメインコントローラーなどの価値の高い標的を特定しながら、水平移動します。その後、ランサムウェアを展開します。デセプションは、偽のActive Directoryオブジェクトやデコイのファイル共有、ルアーの認証情報などのリソースを戦略的に配置し、攻撃者が水平移動する際にそれらのデコイに遭遇させる仕組みです。これらのデコイとのやり取りは瞬時にアラートを生成し、ランサムウェアが実行される前に自動の封じ込め手順を発動させます。生成AIインフラの保護組織がLLM、RAGパイプライン、AI APIなどの生成AIインフラを展開すると、攻撃者はこのインフラの脆弱性を探ります。AIインフラを標的とした攻撃には、プロンプトインジェクションからモデルスクレイピング、学習データの汚染、ベクトルデータベースからの機密情報の窃取まで多岐にわたります。生成AIインフラ向けのデセプションは、デコイのLLMチャットボット、偽のAI API、ハニートークンなどのリソースをRAGパイプラインやベクトルストア内に展開します。生成AIシステムからデータを操作したり、そこからデータを抜き取ろうとする攻撃者はこれらの罠に誘導され、デセプションソリューションがアラートを生成します。デセプションでゼロトラストに対応する仕組みAIを悪用した攻撃が高速化するなか、デセプションはあらゆる組織のセキュリティ戦略において不可欠な要素となっています。たとえば、AIはフィッシング攻撃を劇的に加速させており、ThreatLabzは最近、3万7,000件以上のAI生成サイトインスタンスを悪意のあるものとして特定しました。AIを悪用すれば、高精度な偽サイトや偽アプリ、その他の誘導用インフラを素早く作成し、フィッシング攻撃に用いることができます。組織はこれらの脅威に対抗するために、デセプションテクノロジーとゼロトラストを組み合わせる必要があります。ゼロトラストは、アイデンティティー検証、最小特権アクセス、継続的な検証を通じて攻撃対象領域を最小化します。しかし、ゼロトラストでは、認証情報を侵害した攻撃者が環境に侵入しないという保証はできません。そこでデセプションが必要となります。デセプションは、隙間をすり抜けた攻撃者を特定した後に、攻撃者を操作して脅威インテリジェンスを収集します。セキュリティ部門は収集した情報を使って防御を強化できます。両者を組み合わせることで、ゼロトラストとデセプションは多層防御を形成します。すべての入口でアクセスが厳格に制御され、環境に侵入した攻撃者は罠にかかる構造になります。デセプションの詳細Zscaler Deceptionが実際のサイバー攻撃を10回防いだ方法をご確認ください。

Zero Trust for AI Agents: The Only Model Built for What’s Next

Max Messina (Sr. Campaign Manager) — Tue, 16 Jun 2026 17:04:05 GMT

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. 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. 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: 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. 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. Architecture that reduces exposureThe fewer reachable paths and exposed services, the less opportunity for machine-speed abuse. 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 a deployable reality. And that is exactly what Zero Trust was built to do. Ready to see the Zero Trust platform for Agentic AI in action? Learn more and schedule a demo.

Secure the High Value SAP Data Estate: Why Zero Trust Access is Now a Business Imperative

Prateeksha Nagar (Sr. Product Marketing Manager) — Fri, 12 Jun 2026 23:05:12 GMT

Your Crown Jewels Live in SAP. SAP is where the business keeps its most valuable data. For many organizations, SAP isn’t just 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. 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. 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.

Why AI Red Teaming Matters for Enterprise Security

Matt McCabe (Senior Web Content Writer) — Fri, 12 Jun 2026 18:25:48 GMT

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. 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. 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: 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. 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: 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. The key shift is moving from one-time assessment to ongoing AI red teaming programs that evolve alongside the technology. 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. 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. 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. 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. 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. What security leaders should do nextAI red teaming is still maturing, but the direction is clear. Based on Forrester’s research, security leaders should: 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. Learn moreDownload the full Forrester report on AI red teaming to explore testing approaches, engagement models, and best practices for securing AI-enabled applications.

The 'Easy Button' for Zero Trust B2B Connectivity: Introducing ZPA B2B Federation

Ganesh Vellala Umapathy (Sr. Product Marketing Manager) — Wed, 10 Jun 2026 12:29:10 GMT

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. 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. – 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 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 or shipping hardware 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 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 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. 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. Control the partner federation status: Active, Pause or Terminate. Step 2: Publish private application segments with your partner tenant. The host defines application segments with specific applications that guest users need access to. Step 3: Enforce Zero Trust access by configuring access policies for each B2B app group.The guest configures the access policy. Host can view the policies defined by partners. Use Cases for ZPA B2B FederationOur design partners intend to utilize ZPA B2B Federation for several critical scenarios such as: - 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. 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&A&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&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. Conclusion: Transform your Business Partner Connectivity and Eliminate Legacy Complexity and Cyber Risk 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 [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? [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

ZAgentフレームワークの紹介：自律型SASEの基盤

Elie Bitton (SVP, Strategic Development) — Tue, 09 Jun 2026 22:51:32 GMT

ゼロトラストSASEプラットフォーム全体で多数のAIエージェントを統合管理する新しいアーキテクチャー、ZAgentフレームワークをご紹介します。管理者は、これにより、平易な自然言語によって複雑なタスクを自動化できるようになります。大きく変わる管理者エクスペリエンス組織向けソフトウェアのUIにおける主流モデルは、数十年にわたり変わりませんでした。ログインして、操作、設定、監視する。この繰り返しでした。AIは、その状況を一変させます。AIエージェントがテレメトリーを読み取り、異常を特定し、根本原因を追跡したうえで、推奨される対応を数秒で提示できるようになれば、管理者の問いは「これをUIでどうやって見つけられるか？」ではなく、「エージェントはすでに対処済みか？」に変わります。人間とAIシステムのセキュリティインフラとの関わり方としては、すでに3つの明確なパターンが現れ始めています。1.対話型：人間が同僚と対話するのと同じようにセキュリティプラットフォームと対話します。これは、専用インターフェイス、Slackチャネル、メッセージングアプリなど、すでに使用しているツールで自然言語のプロンプトを通じて行います。2.生成型UI:対話だけでは対応できないほど複雑なタスクの場合、エージェントはその特定の調査に合わせて問題の可視化や解決のワークフローをオンデマンドで生成します。3.完全自律型：ヘッドレスエージェントが人間を介在させずにAPI、CLI、機械可読ツールに直接接続し、日常的な設定、トラブルシューティング、ポリシーの施行、監視をバックグラウンドで処理します。現在のほとんどの組織向けセキュリティプラットフォームは、これらのいずれのパターンにも十分対応できていません。コンソールを基準とした世界向けに構築されていたからです。Zscalerは、未来を見据えた構築を進めています。 ZAgentフレームワークの発表ZAgentフレームワークは、ゼロトラストSASEプラットフォーム全体において、エージェント型AIによる運用を実現するためのZscalerのアーキテクチャーの基盤となるものです。これは、管理者が従来のインターフェイスにログインすることなく、構成、監視、トラブルシューティング、最適化を行うことができるシステムである完全自律型SASEへの第一歩となります。提供開始時点で、管理者はZscaler Experience Centerの自然言語プロンプトを通じてZAgentとやり取りします。チャットでリクエストを入力すると、ZAgentオーケストレーターがその意図を解釈し、適切なエージェントまたは複数のエージェントの組み合わせに振り分けます。そして、途中で多数のシステムが動作した場合でも、最終的には1つのまとまった回答として結果を返します。ヘルプデスク担当者がパフォーマンスの問題のトラブルシューティングを行おうとしている場合でも、ネットワーク管理者がセグメンテーションポリシーを最適化しようとしている場合でも、ZAgentはリクエストをどこに振り分ければ求められる結果が得られるかをすべて理解しています。ZAgentフレームワークは、お客様に以下のような複数のメリットを提供します。課題の状況的なコンテキストを理解し、その解決のために専門分野に特化したエージェントを調整することで、ITとセキュリティの問題に対する解決時間を短縮します。対話型インターフェイスとタスク実行の自動化を通じて管理を効率化し、Zscaler環境の管理を簡素化します。1日あたり500兆件のシグナルと1兆件を超えるAIトランザクションにわたるコンテキストを関連付けることで意思決定の精度を向上させます。誤検知を減らし、従来であれば見過ごされていた脅威を検出します。Zero Trust Exchangeプラットフォーム内でガバナンスとガードレールを一元化することで、監査準備とリスク軽減を容易にします。日常的な調査、トリアージ、修復ワークフローを自動化することで担当部門の能力を拡大します。これにより、すべての管理者がプラットフォーム担当者と同等の知識とスピードで業務を遂行できます。専門特化型エージェントと共通のスキルセットZAgentフレームワークは、エージェントとスキルグループという2つの原則に基づいて構成されています。エージェントは一定のドメインに特化したAIエージェントであり、それぞれがZscalerプラットフォームの定義された特定の領域内で動作するようにトレーニングされています。提供開始時点では、フレームワークはZscalerの製品ポートフォリオ全体にわたる以下の8領域をカバーしています。インターネットアクセス(ZIA)デジタルエクスペリエンス(ZDX)プライベートアクセス(ZPA)Zero Trust CloudSecOpsAIセキュリティデータセキュリティ拠点向けのゼロトラスト各エージェントはそれぞれの領域のスペシャリストであり、行動に必要なデータとツールにアクセスできます(不要なものには一切アクセスできません)。スキルグループは汎用AIをZscaler製品のエキスパートへと変えるための機能群です。各エージェントは、以下のような(ただし、これらに限定されない)コアスキルグループの実装を活用します。知識：製品、ポリシー、構成に関する質問に回答します。データ：プラットフォームのテレメトリーと使用状況データから得られるインサイトを提示します。トラブルシューティング：根本原因を特定し、修復を推奨または実行します。構成：ポリシー設定、セグメンテーション、プラットフォーム構成を支援します。修復：問題を解決するための措置を講じます。ワークフロー：複数ステップからなる運用タスクを統括します。エージェントとそのスキルは、ZAgentによって自律的に起動および調整されます。管理者は、どのエージェントがリクエストを処理したか、あるいはいくつのエージェントが協力したかを知る必要はなく、出力が提示されます。さらに、この仕組みは時間とともに進化します。エージェントは可観測性を活用して管理者とのやり取りを監視および解釈し、継続的に学習することで、より良い回答を提供できるようになります。ガバナンスとコンプライアンスZAgentフレームワークは、Zero Trust Exchangeプラットフォームの一部です。このフレームワークには、地域ごとのガバナンスとコンプライアンス要件を満たすため、以下の制御が備わっています。データレジデンシー制御：ZAgentフレームワークのデータは、米国と欧州連合(EU)の2つの地域に保存され、各地域のデータ主権要件への準拠を確保します。すべてのお客様のエージェントに関するデータは、厳格な分離管理のもとで扱われ、テナント間でのデータ漏洩が発生しないようになっています。エージェントのリクエストと回答は、お客様の指定されたリージョン内で処理および保存されます。動的なロールベースのアクセス制御：人間の管理者が管理コンソールにログインすると、ZAgentは認証されたユーザーの既存の権限を継承します。これらの権限は実行時に評価され、その管理者の既存の権限に基づいてアクセスを細かく調整できます。これにより、エージェントは常にそれらを使う人間の管理者と同一の境界内でのみ動作し、いかなる時点においても、その役割が許可していないリソース、ポリシー、構成などにはアクセスできません。LLMへの脅威からの保護：エージェントは、OWASP Top 10 for LLMsに含まれるプロンプトインジェクション、トレーニングデータポイズニング、モデルの盗用など、LLMを標的とした脅威から保護されています。Zscalerは、AI Guardおよび自社のより広範なAIセキュリティポートフォリオをカスタマーゼロ(最初の顧客)として実践導入しており、すべてのAI操作のセキュリティを確保しています。AIエージェントによるやり取りは、組織内に定められたあらゆるガードレールとコンプライアンス要件を順守します。 ZAgentの実例：初期の2つの事例ZscalerのZAgentはすでに様々な分野や製品領域でスキルを発揮しており、今後数か月でさらに多くの機能を展開していく予定です。以下にZAgentのユースケースの一例を紹介します。ZDX Agent:数秒で苦情から根本原因へユーザーからパフォーマンスの問題が報告された場合、苦情から問題解決に至るまでにはこれまで複数のツール、複数のチーム、そして相当な時間が必要でした。ZDX Agentのトラブルシューティングスキルは、この状況を変えます。管理者が「北東部のユーザーがアプリケーションのパフォーマンス低下を経験している理由を調査してください」と入力すると、ZDX Agentは、複数段階の調査計画を作成して実行し、調査結果、裏付けとなる証拠、推奨を含む概要を数秒で返します。エンドポイントやWi-Fiの問題は除外され、ネットワーク通過経路にあるISPの問題であることが特定されます。同一のエージェントが個々のユーザーを調査することもできます。ユーザーのパフォーマンスが低下した場合、ZDX Agentは動画編集プロセスによるCPUリソース不足が原因で発生するネットワーク遅延を特定してから、管理者に連絡し、ハングアップしているプロセスを強制終了する修復ジョブの実行を承認させます。管理者が確認すると、アクションが実行され、正常な接続が回復します。ZPA Agent:セグメンテーションデータから得られる動的なインサイトZscaler Private Accessの強力な構成要素であるユーザーとアプリ間の自律型セグメンテーションは、機械学習を活用してアプリケーションを識別およびフィンガープリントし、アプリセグメントとポリシーの推奨を生成します。ZPA Agentはこの機能を拡張するものです。ZPA Agentを使用すると、管理者はExperience CenterのUIで事前構成されている範囲を超えて、セグメンテーションデータを動的にクエリーできます。すべてのユーザーが利用しているアプリケーションの種類を棒グラフで表示するよう指示すると、その場でグラフを生成されます。特定のアプリケーションのユーザー別使用状況を時系列で詳しく調べたり、その出力をアクセスを管理するポリシーに直接結び付けたりすることも可能です。将来的に、管理者はZAgentを使用してこれらのポリシーを自律的に設定および監視できるようになる予定です。なぜ今なのかセキュリティ部門は、同じ人員数でより複雑な業務に対応しなければならなくなっています。この問題に対応する管理者には、AIが処理できる手作業のワークフローに時間を費やす余裕がありません。ZAgentフレームワークはこの問題に直接対応します。これはエージェント型AIの時代に向けて構築された新しいアーキテクチャーレイヤーであり、現在はExperience Centerの下にありますが、将来的にはあらゆるインターフェイスに拡張可能です。ZAgentは、適切なユーザーに適切なアクセスを付与されるようにし、問題がインシデントに発展する前に発見して解決します。これにより、手動により注意を払い続けなくともセキュリティ態勢を改善できるようになります。次のステップZAgentはまず、Zscaler Experience Centerを通じて利用可能になります。ロードマップでは、この同様の機能をコンソール以外にも拡張していきます。ZAgentは、API、CLIワークフロー、MCPツールを通じてお客様がすでに利用しているAIシステムや運用プラットフォームと接続できるようになります。これにはChatGPT、Claude、ITSM、SIEM、コラボレーションツールなどが含まれます。これらのシステムから、Zscalerのコンソールを開くことなくZscalerのエージェントを起動することが可能になります。ポリシー管理、インサイト生成、インシデント対応、大規模な構成。そのすべてを、ユーザーに代わって動作するエージェントが実行します。ZAgentフレームワークの詳細はzscaler.jpで確認できます。また、Zenith Live Day 2の基調講演では、ZDX、ZPA、SecOpsエージェントが実際に動作する様子をご覧いただけます。

ZscalerはNSS LabsのSSE脅威対策テストにおいて「非常に効果的で信頼性が高い」との評価を獲得

Vinay Polurouthu (Principal Product Manager) — Tue, 09 Jun 2026 16:28:52 GMT

脅威アクターがAIを悪用して攻撃の速度、規模、高度化をますます進化させるなかで、サイバーセキュリティ対策を検証する手法も、それ以上のペースで進化していく必要があります。かつて標準であった特定時点における手動テストは、自動化され、検出を回避する脅威が絶え間なく攻撃してくる現在、プラットフォームの耐性を測定するには、もはや十分ではありません。これこそが、Zscalerが独立した検証に基づく製品改善に継続的に投資して、高度な標的型攻撃に先んじていることを実証している理由です。このたび、NSS Labsによる2026年第2四半期のセキュリティサービスエッジ(SSE)脅威対策テストにおいて、Zscaler Zero Trust ExchangeTMは、非常に効果的で信頼性の高いクラウド配信型セキュリティプラットフォームであると評価されました。厳格なサードパーティーテストにおけるZscalerのパフォーマンスは業界のベンチマークを確立しており、今回もまた業界で最も先進的なAI活用型のテスト手法の基準に照らしても、圧倒的に優れていることが証明されました。この新たなテストの波においてもリーダーシップを維持し、Zscaler Zero Trust Exchange™プラットフォームは総合的な有効性98.85%を達成しました。この非常に高いスコアは、最も重要な保護カテゴリーにおける優れた結果で構成されており、巧妙な回避技術に対する耐性率100%、マルウェアブロック率98.65%、エクスプロイトブロック率99.05%、誤検知精度99.63%を記録しました。これらの結果は、Zscalerがセキュリティを確保するために優れた保護を提供していることを明確に証明しています。テスト方法NSS LabsのSSE脅威対策テストの目的は、大幅に更新されたSSE脅威対策評価手法により、セキュリティサービスエッジ(SSE)プラットフォームの実際の機能とパフォーマンスを評価することでした。この手法は、セキュリティソリューションがユーザーの場所を問わず、脅威からユーザーをどれだけ効果的に保護できるかを測定するために設計されています。主な評価領域は以下の通りです。脅威対策：エクスプロイトやマルウェアがエンドユーザーに到達するのを、プラットフォームがどれだけ効果的にブロックできるかを評価します。回避技術に対する耐性：攻撃者がペイロードを偽装し、セキュリティ対策を回避するために使用する手法に対するプラットフォームの耐性を測定します。主な調査結果：結果の詳細な分析Zscalerが非常に効果的という評価を獲得したのは、すべての主要カテゴリーにおいて一貫したテスト結果を示したためです。主な調査結果をさらに詳しく見ていきましょう。マルウェアブロック率98.65%評価結果：4,873件の固有のマルウェアサンプルに対してテストを行った結果、Zscalerは98.65%のブロック率を達成しました。阻止したマルウェアには、一般的なランサムウェアの亜種から高度なポリモーフィック型脅威まであらゆるものが含まれていました。ビジネスへの影響：一度でもマルウェアに感染すれば、業務停止、データ窃取、多額の経済的損失、そしてブランドイメージの長期的な低下など壊滅的な結果を招く恐れがあります。効果的なセキュリティプラットフォームには、既知のマルウェアをブロックするだけでなく、新たなゼロデイ脅威が実行される前に特定し、阻止することが求められます。Zscalerが実現する仕組み：この非常に効果的な保護は、強力な多層防御戦略の結果です。これは完全なTLS/SSLインスペクションから始まり、AIを活用した一連のマルウェア検出エンジンによって強化されます。ZscalerのAdvanced Cloud Sandboxが未知の脅威をインラインで隔離および分析します。一方、1日あたり5,000億件を超えるトランザクションを処理し、数十億件の脅威をブロックすることから得られる「クラウドならではの効果」により、一度確認された脅威は瞬時に他のすべての顧客においてブロックされます。エクスプロイトブロック率99.05%評価結果：Zscalerは、テスト対象となった317件の固有のエクスプロイトのうち、99.05%をブロックしました。これらのエクスプロイトは、幅広いアプリケーション、プロトコル、オペレーティングシステムを標的としていました。ビジネスへの影響：エクスプロイトは、脅威アクターが最初の足がかりを築き、セキュリティ対策を回避し、ネットワーク内を水平移動するために使用する攻撃手段です。エクスプロイトを防止することが、攻撃チェーンを未然に阻止する最も効果的な方法です。これは、新たに発見された脆弱性を標的とするゼロデイ攻撃に対する防御において特に重要です。Zscalerが実現する仕組み：Zscalerのゼロトラストアーキテクチャーは本質的に攻撃対象領域を削減するため、エクスプロイトが標的を見つけることを困難にします。プラットフォームを通過するトラフィックに対しては、インラインの侵入防止システム(IPS)と高度な脅威対策の機能が連携することで、エクスプロイトの試みをリアルタイムで特定およびブロックし、ユーザーとシステムを侵害から保護します。回避技術に対する耐性100%評価結果：NSS Labsは583種類の異なる回避技術に対してZscalerをテストしました。その結果、Zero Trust Exchangeは潜んでいた脅威を特定してブロックすることに100%の成功率を示しました。ビジネスへの影響：高度な攻撃者は、既製のマルウェアをほとんど使用しません。難読化、圧縮、その他の回避技術を駆使し、セキュリティ防御をすり抜けてペイロードを忍び込ませます。これらの偽装を見破ることができないセキュリティ対策は、誤った安心感を与えるにすぎません。回避技術に対する耐性は、基本的なセキュリティと、真に高度な脅威対策プラットフォームとを分ける決定的な差別化要因です。Zscalerが実現する仕組み：Zscalerのプロキシベースのアーキテクチャーは、すべてのトラフィックを検査前に再構築するため、最も複雑で多層的な回避技術さえも、複数のセキュリティエンジンによって可視化および解読することが可能になります。回避技術が使用されていることを検出するだけでなく、その回避を無効化し、隠蔽しようとしていた悪意のあるペイロードもブロックします。99.63%の精度で誤検知を抑制評価結果：Zscalerは脅威を積極的にブロックしながらも、99.63%という驚異的な精度を維持し、正規のファイルとトラフィックを正しく識別しました。ビジネスへの影響：誤検知は単なる煩わしさにとどまらず、セキュリティプラットフォームへの信頼を損ない、運用上の大きな負担となります。セキュリティ部門が誤検知に追われると、貴重な時間を浪費し、重要なセキュリティ機能を無効化せざるを得なくなる可能性があり、意図せず実際の脅威に対し侵入口を開いてしまう恐れがあります。高い精度は、強固なセキュリティと効率的な運用の両方にとって欠かせません。Zscalerが実現する仕組み：Zscalerのクラウドを流れる大量のデータセットこそが私たちの最大の強みです。Zscalerは、1日あたり数十億件のトランザクションから得られる数兆のシグナルに基づいてトレーニングされた高度なAIと機械学習モデルを活用し、悪意のあるトラフィックと正常なトラフィックを正確に区別します。これにより、正当な事業活動を中断することなく、最高レベルの脅威対策を維持できます。 Zscalerが組織にもたらす圧倒的な価値AIによる脅威が蔓延する時代において成功を収めるには、同様に高度なテスト手法によって検証されたセキュリティへの投資が不可欠です。Zscalerは独立したテストにおいて最高レベルの結果を達成しており、今年の高度な評価基準に基づき非常に効果的という評価を獲得したことは、これまでで最も重要な成果です。これらの結果は単なる数字の羅列ではなく、安心感をもたらすものです。Zscalerを利用することで、組織は世界で最も高度な脅威と最も厳格な検証基準に対して徹底的に検証されたプラットフォームによって保護されていることが証明されます。デジタルトランスフォーメーションの複雑さに対応し、AIの導入を安全に進めるうえで、Zscalerの一貫した実績あるリーダーシップは、ユーザー、データ、アプリケーションを保護するための明確かつ信頼できる選択肢となります。レポートのダウンロードZscalerの詳細なパフォーマンスについてのより深い分析とセキュリティ戦略にもたらすその価値を理解いただくために、NSS Labs SSE脅威対策テストレポートの全文をダウンロードしてご確認ください。[レポート全文はこちらからダウンロードできます]

Wi-Fi Performance Crisis? How ZDX Revealed a Hidden Channel Conflict in 15 Minutes

Rohit Goyal (Sr. Director, Product Marketing - ZDX) — Mon, 08 Jun 2026 23:13:45 GMT

A Real-Time Troubleshooting Case Study for Network Operations TeamsNetwork Operations (NetOps) teams often face the challenge of troubleshooting intermittent or multi-stage network performance issues. Is the problem local Wi-Fi congestion, a misconfigured access point, or a downstream service routing bottleneck? Without proper visibility, diagnosis becomes guesswork—consuming hours and delaying resolution. Zscaler Digital Experience (ZDX) provides the granular, end-to-end data necessary to move past assumptions and deliver precise, actionable diagnostics with quantifiable results.We recently observed a prime example of ZDX's operational value when a ZDX administrator deployed the platform to quickly diagnose and confirm resolutions for a dynamic network scenario at a large corporate training event. This case study walks through the real-time diagnostic process, demonstrating how NetOps teams can isolate Wi-Fi configuration issues, validate fixes, and measure the operational impact—all within a single troubleshooting session. Section 1: Identifying Initial Symptoms & Establishing BaselinesWhen users report slow performance during peak utilization periods, the first step is to quantify the experience and establish whether the issue is widespread or localized. In this instance, the initial symptoms were:Elevated latency reported across the training network SSID (SampleSSID), with readings consistently above the 10 ms targetUser complaints concentrated on specific conference areas, suggesting either AP-level or RF environmental issuesScale: 18+ concurrent users on the 5 GHz band, indicating a high-density Wi-Fi scenarioZDX immediately provided end-to-end visibility into the network path, allowing the engineer to rule out obvious culprits (internet bandwidth, upstream ISP issues) and focus on the local wireless environment.ZDX Score trending over the 2-hour troubleshooting window. The score dips below 33, indicating degraded application performance during peak training event usage. Section 2: Diagnosing Local Wi-Fi Configuration IssuesThe real diagnostic power of ZDX lies in its ability to distinguish between different classes of wireless problems. A high latency could stem from poor RF coverage, channel saturation, misconfigured channel assignments, or device overload—each requiring different remediation. The ZDX engineer followed a structured diagnostic approach:Step 1: Signal Strength AssessmentThe engineer checked the wireless signal score across all connected access points. The RSSI (Received Signal Strength Indicator) readings ranged from –44 dBm to –64 dBm, which falls well within the acceptable range (–67 dBm is typically the lower threshold for 5 GHz networks). This indicated strong, consistent RF coverage—ruling out the "weak signal" hypothesis.Step 2: High Retransmit AnalysisGood signal strength (RSSI > –65 dBm)Low packet loss at the MAC layerHigh retransmit ratesThis pattern is a classic indicator of channel interference or channel overlap—not RF weakness.This dual-chart visualization reveals the diagnostic paradox: despite strong and stable Wi-Fi signal strength (~85%), retransmission rates remain elevated at 35–45%. This pattern is the hallmark of a channel configuration issue rather than RF weakness. High retransmits coupled with strong signal indicates that devices are competing for airtime on congested channels, not struggling with coverage. This insight—captured in real-time by ZDX—immediately pointed the diagnostic team toward channel overlap as the root cause, enabling them to move beyond RF troubleshooting and focus on access point channel assignment optimization.Step 3: Root Cause Confirmation—Channel ConflictSource-to-Gateway Latency & Jitter: Morning Volatility vs. Afternoon StabilityBefore channel redistribution (morning window), latency and jitter spike to 30–35 ms and 10–33 ms respectively—reflecting MAC-layer contention from the channel conflict. After the fix (11:15 AM onward), both metrics stabilize dramatically: latency settles to 5–10 ms and jitter drops to 5–15 ms range. This 6-hour trending view demonstrates sustained performance improvement, confirming the channel optimization was effective and durable throughout the event. Section 3: Implementing & Validating the FixRemediation: Channel RedistributionThe technical team reconfigured the three APs to use non-overlapping channels:AP 1: Channel 36 (5 GHz)AP 2: Channel 100 (5 GHz)AP 3: Channel 149 (5 GHz)Resolution Validation: Real-Time MonitoringBefore the Fix:Latency: 15–22 ms (Client to Egress)ZDX Score: ~72/100 (Okay)Retransmit Rate: ~7–9% (elevated)After Channel Redistribution:Latency: 8–12 ms (Client to Egress) — 44% improvementZDX Score: ~87/100 (Good) — 19-point increaseRetransmit Rate: <2% (normalized)Time-series graph showing latency and ZDX score improvements post-remediation. The chart spans the 2-hour monitoring window (10:15 AM–12:15 PM CDT on June 8, 2026) with a clear downward trend in latency after the channel change at approximately 11:00 AM, and a corresponding improvement in the ZDX score. Include threshold lines (10 ms baseline, 85 score target) for reference. Section 4: End-to-End Path Visibility - Supporting EvidenceWhile the local Wi-Fi optimization resolved the primary performance issue, ZDX's end-to-end path visibility provided additional context:Path Analysis ContextThe network path from source to the training application endpoint showed:Local Wi-Fi to Gateway: 8 ms (excellent post-remediation)Gateway to Egress Point (Las Vegas): Less than 1 ms (excellent)Egress to Remote Endpoints: 50–70 ms (baseline expectation for geographically distant services)The Microsoft service endpoints and other cloud applications, while geographically distant, were not the limiting factor in this scenario. The 50–70 ms egress-to-endpoint latency represents normal expectation for cloud services hosted remotely; this is not a bottleneck requiring remediation.Operational Insight: Clear Diagnostics Enable Confident Decision-MakingThis comprehensive path view enabled the NetOps team to:Confirm that local Wi-Fi was indeed the primary constraint (8 ms post-fix vs. 30–35 ms pre-fix)Rule out false leads (remote service latency was not causing the user experience issue)Validate that the application services remain usable despite geographic distance (egress latency is within acceptable bounds)Set realistic expectations for users (local Wi-Fi performance is now optimized; remote service latency is inherent to cloud architecture)This clarity prevents teams from chasing phantom problems or over-engineering unnecessary solutions. ConclusionThis scenario showcases ZDX in its operational prime as a diagnostic force multiplier for NetOps teams. By leveraging ZDX's deep, real-time data insights, the engineer was able to:For NetOps teams managing high-density Wi-Fi environments—whether permanent deployments or temporary events—ZDX transforms troubleshooting from a reactive, time-consuming process into a proactive, data-driven discipline. The combination of granular wireless diagnostics, real-time retransmit monitoring, and sustained performance trending empowers teams to identify and resolve local configuration issues with precision and confidence.Ready to see with this level of clarity?See ZDX in Action (Request a Live Demo)

Zenith Live 2026で発表される、Zero Trust Cloudによるワークロードセキュリティのさらなる進化

Sakthi Chandrasekaran (Sr. Director, Product Marketing) — Fri, 05 Jun 2026 23:04:26 GMT

Zenith Live 2026は、Zero Trust Cloudにとって重要な節目となります。今回の発表では、新機能だけでなく、モダンなアプリケーションを保護するお客様により優れた成果をもたらすことに焦点を当てています。Google Cloud Network Security Integrationを通じたZero Trust GatewayのGoogle Cloudへの拡張や、ホストベースのマイクロセグメンテーションのGKEへの導入など、これらのイノベーションは、ワークロード保護の簡素化、運用の複雑さの軽減、総TCOの削減とともに、セキュリティ部門がクラウド環境とKubernetes環境全体でより一貫してポリシーを適用できるように設計されています。Aflac、NOV、Northern Trust、Henkel、MRH、IIFLなどの組織の顧客セッションと併せて、Zero Trust Cloudがセキュリティ態勢の強化、コンプライアンスのサポート、マルチクラウドインフラ全体における保護の拡張にどのように活用されているのかをご確認いただけます。 Network Security Integrationを通じたGoogle Cloud向けZero Trust GatewayのサポートZero Trust Cloudは現在、顧客プレビュー版として提供されているGoogle Cloud Network Security Integration (NSI)を通じてGoogle CloudでZero Trust Gatewayをサポートしています。Zscalerは組織に対し、アプリケーション接続を再設計したり、ファイアウォール中心のアーキテクチャーに依存したりすることなく、クラウドトラフィックを保護するための、運用効率を向上させた拡張性の高い方法を提供します。Google Cloudのトラフィックフローにセキュリティをネイティブに組み込むことで、お客様はワークロードのより近くでポリシーを適用し、アプリケーション通信の可視性を向上させ、環境全体でセキュリティ制御を標準化できます。その結果、一貫したクラウドセキュリティ制御の導入が迅速化し、ネットワーク部門とセキュリティ部門の運用負荷を減らすとともに、管理されていない東西トラフィックと南北トラフィックによるリスクを軽減します。NSIは、アプリケーション設計の変更を強いることなく、Google Cloudのお客様がパートナーのセキュリティサービスへトラフィックを誘導できる、ネイティブな手段を提供します。実際には、これによりZscalerがGoogle Cloudのサービス挿入フレームワークを使用してクラウドトラフィックを検査し、ポリシーを制御できるようになります。アーキテクチャー上、NSIはプロデューサー/コンシューマーモデルを使用しています。ZscalerはGoogle Cloudでセキュリティサービスを運用する一方、お客様のワークロードは選択されたトラフィックを検査のために転送するGoogle Cloudの各種機能を介して接続されます。この統合における重要な技術的要素は、NSIがGENEVEカプセル化を活用している点です。これにより、トラフィックがセキュリティサービスに送信される際にパケットのコンテキストが保持されます。そのため、セキュリティポリシーは、トラフィックを汎用的な転送パケットとして扱うのではなく、本来のフローをより正確に把握したうえで運用できます。その結果、分散型のルーティング操作や従来のアプライアンス配置戦略に伴う複雑さを回避する、よりクラウドネイティブなモデルが実現します。セキュリティ部門に従来の制御のクラウド環境への後付けを強いる代わりに、Zero Trust Gatewayは、ネイティブな統合ポイントを利用してGoogle Cloudのトラフィック経路に組み込み、ワークロードの通信層のより近くで適用することができます。これは特に、Google Cloudを標準基盤とし、アーキテクチャーの複雑さを増すことなく、南北トラフィック、東西トラフィック、クラウド下りのユースケースにおいて検査やポリシーの定義をより簡単に拡張したいと考える組織にとって重要な意味を持ちます。さらに、Zscalerの完全なマネージドサービスとして提供されるため、お客様は総所有コスト(TCO)を大幅に削減できます。具体的には、データ転送量(DTO)のコスト削減、セキュリティアプライアンスの立ち上げに伴うコンピューティング負荷の排除、セキュリティインフラの管理と保守に必要な人員の削減が実現します。 Zscaler Microsegmentation:ホストベースのマイクロセグメンテーションをGKEに拡張2つ目の発表は、Zscaler MicrosegmentationがホストベースのマイクロセグメンテーションをGoogle Kubernetes Engine (GKE)にまで拡張したことです。コンテナー化されたアプリケーションを実行している組織は、これにより、ワークロードアイデンティティーが動的で東西通信が常時発生し、ラテラルムーブメントが依然として主要なリスクである環境をより正確に制御できまるようになります。従来のセグメンテーション手法は多くの場合、IPアドレスの範囲、静的なトポロジーの前提、またはKubernetesでは維持が難しい粗い境界に依存しています。ホストベースのマイクロセグメンテーションは、サイバーセキュリティをワークロードにより近い場所に移行することで、正当なアプリケーション通信の定義を容易にし、環境が拡大しても最小特権アクセスを継続的に維持できるようにします。Kubernetes環境では、セキュリティ部門が管理する必要のあるワークロードアイデンティティー、サービス間通信経路、短期間で消滅するコンピューティングインスタンスの数が増加します。Podはスケールアップ、終了、ノード間移動を行うため、静的なネットワークベースの制御を長期的に維持することが難しくなります。このような環境では、東西トラフィックが主なリスク領域となります。なぜなら攻撃者がノードやワークロードへのアクセス権を取得した場合にサービス間の経路を横切るラテラルムーブメントが即座に重大な懸念事項となるからです。ホストベースのマイクロセグメンテーションは、ワークロードが実行される場所により近い場所でセグメンテーションを適用することで、この問題の解決を支援します。セキュリティ部門は、クラスターレベルやネットワークレベルの制御だけに頼るのではなく、アプリケーションの動作や想定される通信経路に合わせた、よりきめ細かなポリシーを制御できます。これは、組織がネットワークの複雑さを増やすのではなく、マネージドKubernetesの運用モデルに適合するセキュリティ制御を必要としているGKE環境において重要です。モダンなアプリケーション配信のためにGKEを採用するお客様にとって、ホストベースのマイクロセグメンテーションは、コンテナー化されたワークロードの実際の動作形態(一時的で分散型、かつサービス指向)により適したセキュリティ制御プレーンを提供します。ビジネス上の成果として、コンテナー化されたアプリケーションの保護強化、ラテラルムーブメントのリスク軽減、Kubernetes環境が拡大しても運用しやすいセグメンテーションモデルの実現が挙げられます。 Zenith Live 2026における顧客セッション：Zero Trust Cloudの活用事例製品の発表と並行し、Zenith Liveでは、Zero Trust Cloudが大規模な実環境におけるクラウドセキュリティの課題を解決するためにどのように活用されているかを示す顧客セッションを実施します。お客様ZLive 2026におけるブレイクアウトセッションのテーマ*AflacZscaler Microsegmentationが、ワークロードのより厳密な分離、最小特権アクセス、ラテラルムーブメントの削減を通じてコンプライアンスと規制要件に対応できるよう支援する仕組み。NOVZero Trust Cloudが、マルチクラウドの下り保護とホストレベルのマイクロセグメンテーションを組み合わせることで、より包括的なワークロードセキュリティモデルを支援する仕組み。Northern Trustマルチクラウド環境全体にワークロード保護を一貫して展開しながら、ポリシー、セグメンテーション、段階的な展開を管理するためのベストプラクティスと教訓。Henkelポリシーの一貫性、セグメンテーション設計、段階的な展開に重点を置き、クラウド環境全体にわたるワークロード保護を実装するための実践的なガイダンス。MRH組織がZero Trust Gatewayを活用し、より迅速な実装と低い導入リスクを実現するように設計されたマネージドサービスモデルで、パブリッククラウドにワークロードセキュリティを導入する方法。IIFLZscaler Microsegmentationが、規制順守をサポートしながら、より効率的かつ低コストでセグメンテーションプロジェクトを実現する仕組み。これらのセッションは、Zero Trust Cloudの価値が決して理論だけのものではないことを証明し、今回の発表にさらなる深みをもたらします。導入組織はZero Trust Cloudの機能を利用することで、規制要件の順守、クラウドプラットフォーム全体におけるセキュリティ制御の統合、マルチクラウドセキュリティの運用負荷の軽減を実現し、ワークロード保護に向けたより一貫性のあるモデルへの移行を推進しています。これらのブレイクアウトセッションの詳細については、こちらのZenith Liveイベントページをご覧ください。今回の発表が重要である理由Zenith Live 2026で発信されるメッセージは明確です。ワークロードセキュリティは保護するアーキテクチャーとともに進化しなければなりません。組織がクラウドやKubernetes環境に拡大するなかで、よりネイティブできめ細かく、大規模な運用も容易なセキュリティ制御が求められています。NSIを通じたGoogle Cloud向けのZero Trust Gatewayのサポートや、GKE向けのホストベースのマイクロセグメンテーションを備え、それらのアプローチが実環境で機能していることを顧客事例で示すことができるZero Trust Cloudは、モダンなワークロードを、優れた一貫性と拡張性を持つ効果の高いモデルで保護できるようお客様の移行を支援しています。

デセプションの再評価

Brad Moldenhauer (VP, CISO in Residence) — Thu, 04 Jun 2026 18:21:48 GMT

クラウドセキュリティアライアンス(CSA)は最近、The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Programという文書を公開しました。これは、AIによる脆弱性の発見により、防御側のタイムライン、脆弱性管理の運用モデル、そして今すぐ必要な最低限のアクションがどう変化したのかを、セキュリティリーダー向けに解説したブリーフィングです。実効性のある計画を手に、明日の会議に臨まなければならないCISOのために作成されています。本書には、AIによる攻撃が新たな標準となる世界で運用するために必要な、即時のアクション、当面の優先事項、そして長期的な変化が要約されています。Mythos対応セキュリティプログラムのための11の優先アクションが定義されていますが、私はすぐに9番目の優先アクションに注目しました。デセプションテクノロジーは、長年にわたって控えめに評価されてきましたが、あくまで二次的な制御であり、有用でありながらもセキュリティプログラムの中心となることはほとんどありませんでした。Mythos級の能力の登場は、その計算式を具体的かつ重要な形で変化させます。その理由を正確に理解することには大いに意義があります。 Mythosの評価で何が示され、何が示されならなかったのでしょう。AI Security Institute (AISI)がMythos Previewを評価したところ、同モデルは32ステップにわたる企業ネットワーク攻撃シミュレーションをエンドツーエンドで完遂した最初のモデルであると判明しました。これは、人間の専門家であれば約20時間を要すると見積もられたタスクです。10回の試行のうち3回で全工程を完了し、すべての実行で平均32ステップ中22ステップを完了しました。しかし、ほとんどの報道が見落としている極めて重要な留意点があります。実験の環境にはアクティブな防御担当者や防御ツールが含まれておらず、セキュリティアラートを作動させる行為に対するペナルティーもありませんでした。AISIは、この結果によってMythosが十分に防御されたシステムを攻撃できることまでは確認できないと明言しました。包括的なログ記録、強力なアクセス制御、そしてアクティブなSOCを備えた成熟した環境では、命題が根本的に異なっています。この留意点こそが、デセプションの論理の核心です。このベンチマークは、仕掛けのない環境で活動する攻撃者を測定したものです。「防御のない実験環境で自律的に攻撃チェーンを実行できること」と「それを防御されたネットワークに対して行うこと」との間にある隔たりこそ、デセプションテクノロジーによる違いが際立つセキュリティギャップなのです。デセプションが再評価される時代が到来しました。分析全体において一貫して示されているのは、エージェント型システムは攻撃者の代わりになるのではなく、時間を圧縮するという点です。脆弱性の発見から悪用までの間隔を短縮し、標的のソフトウェア構成、パッチ適用レベル、権限構造に応じて攻撃経路を迅速に適応させます。侵入後の挙動に関する証言も一貫しています。Mythos級のモデルはネットワークに侵入すると、システムの自動マッピング、ラテラルムーブメント、データ抽出のための専用ツール構築を数時間以内に実行できます。従来の検知スタックのほとんどはこうしたモデルよりも劣っています。シグネチャーベースの検出は既知のパターンを前提とし、行動分析は人間の処理速度と学習可能なベースラインを前提とし、アラートのトリアージはアナリストに調査する時間があることを前提としています。数時間でマッピングし、水平移動しながら、その都度専用ツールを生成するエージェントは、これら3つの手法が依拠する時間的な前提を覆します。これは、サイバーセキュリティが根本的に非対称性の問題であることを示しています。デセプションの目的は、自動化された敵対的攻撃の手口を強制的に露出させ、ゼロデイをダミー環境で消費させることで、攻撃者の作業コストを広範かつ経済的に引き上げることにあります。その結果、防御側は緩和のための情報(エクスプロイトコード、C2、アトリビューションなど)を入手でき、それをクラウド配信や自動化された対応に展開できます。さらに重要なのは、それが攻撃者の攻撃資産を消耗させる代償を伴うことです。最新のデセプションは機械の処理速度で動作し、自動化された偽の攻撃経路、様々なアプリのセグメントに散りばめられたハニートークン、ハニートラップされたルート、ゴースト資産、合成認証情報などで構成されます。エージェント型攻撃シミュレーションモデルは、どれが高価値の標的でどれがシャドーインフラかを区別できない鏡の迷宮に遭遇します。デセプションのブレッドクラミング(偽の痕跡の配置)は仕掛け線です。攻撃者が何を武器化していたとしても、接触した瞬間に、極めて高精度のアラートが作動します。エージェント型攻撃シミュレーションモデルにゼロデイの時間的優位性を譲るとしても、デセプションは、この力関係の傾きを防御側へと戻します。デセプションの特徴は、攻撃手法についての高度な理解を必要とせずに検出制御を提供するという点です。攻撃されている局面で、デセプションは攻撃者の武器構成による影響を受けません。なぜならルアー、デコイ、ブレッドクラミング、攻撃検知用カナリアが、正当な接触やアクセスからは切り離されているからです。状態の変化はすなわち、高精度のシグナルです。これこそが、Zscaler Deceptionが当初から備えている不変の価値提案です。ここで経済性について考えてみましょう。Mythosの時代において、AIによって生成されたエクスプロイトは、計算と運用の両面で高額です。AIエージェントがデセプションのワークフロー上で1つのゼロデイを消費するたびに、脅威は未知から既知へと変わります。そのエクスプロイトはもはや使い潰された状態です。私たちはそこからTTPの情報を入手します。攻撃者は何も得られません。デセプションは単に検出するだけでなく、リアルタイムで攻撃者のROIを低下させるのです。私はこれまでデセプションの話題が出る場に参加したことがありますが、その際に「それには興味がありません。なぜなら、未知の脅威をシンクホールするために、わざわざMSFT 2025のメンバーサーバーを構築してDMZに展開するようチームに指示するつもりはないからです」といった憶測を耳にすることがあります。多くのセキュリティリーダーは、攻撃者が自社の人材よりもはるかに優れていると感じており、このような取り組みはかえって自社環境への攻撃を誘発するだろうと考えています。これは単に、最新のデセプションが防衛側に提供する自動化といった最新の技術力に対する知識不足に過ぎません。そもそもデセプションの有効性は、手動で実装される技術やプロセスを前提としたことはありませんでした。従来のハニーポットは静的で手動で展開されるものだったため、高度な攻撃者にとっては容易に識別して回避できるものでした。しかし最新のデセプションは機械の処理速度で動作します。LLMで生成されたカナリア、クラウド環境全体に埋め込まれたハニートークン、Active Directoryの合成アイデンティティーなどがそれに該当します。2026年に組織のネットワークを探索するAIエージェントは、本物の資産と区別できない、もっともらしく見える何千もの資産に遭遇するでしょう。それは単なるハニーポットではありません。環境全体に張り巡らされたデセプションファブリックです。長年、評価されながらも主力とはみなされてこなかった制御が、今、攻撃者の能力が向上するにつれて価値が高まる数少ない対策の1つとして注目されています。ほかのすべての検出レイヤーが成り立つ前提は、Mythos級の攻撃者により音もなく無効化されています。その前提とは、攻撃は既知のパターンに従い、人間の処理速度で動き、調査する時間的猶予があるというものです。デセプションは、これらの前提のどれにも基づいていません。デコイにはアクセスされる正当な理由がないため、侵入者がどれほど高度で高速であっても、デコイへの接触は高精度のシグナルとなります。そして、徹底的かつ体系的な列挙を強みとするエージェントこそ、まさに巧妙に配置された罠にかかる可能性が最も高いタイプの攻撃者です。この制御は、自律型エージェントの侵入を阻止するものではなく、予防策の代わりになるものでもありません。しかし、最も懸念すべき能力の実証実験が防御者が存在しない環境で実行されている状況においては、攻撃者自身の自動化を逆手に取るこの制御は、もはや余裕があれば取り入れる贅沢品ではなく、責任ある組織なら省略できないレイヤーとなっています。デセプションが進化したわけではありません。攻撃者が強くなったからこそ、有意義なものとなったのです。デセプションが再評価される所以はここにあります。

Top Features To Look For in an SSE Platform

Julia Benson (Senior Web Content Writer) — Wed, 03 Jun 2026 21:09:28 GMT

OverviewA complete security service edge (SSE) platform includes three core components: a cloud native secure web gateway (SWG) with full TLS/SSL inspection, zero trust network access (ZTNA) delivering app-level least-privileged access, and a multi-mode cloud access security broker (CASB). The best SSE platforms go further with integrated data loss prevention (DLP), AI security, firewall as a service (FWaaS), browser isolation, and advanced threat protection. Because not all SSE platforms are the same, you’ll need to carefully evaluate vendors’ advanced capabilities to make sure that they address your organization’s full-stack cloud native security needs. IntroductionSecurity service edge (SSE) is a subset of secure access service edge (SASE). Because a complete SASE implementation takes significant time and resources, many enterprises start with SSE as the first step toward security modernization with a clear path to SASE convergence.But not all SSE platforms offer the same capabilities, and there are many solutions that can’t provide the zero trust capabilities that are required to implement SSE correctly. This post walks through the top SSE features security and IT leaders must evaluate when selecting an SSE platform.But first, we should take a step back and define some terms. What is security service edge (SSE)?Security service edge is a cloud native security framework that combines multiple network security functions into a single, unified platform delivered from a globally distributed security cloud. Gartner defines SSE as a component of the broader secure access service edge (SASE) model, whereby SSE focuses exclusively on the security side of that architecture. With SSE, organizations can address the networking and security challenges that come with cloud application adoption and the shift to a remote or hybrid working model. SSE moves security enforcement to the cloud, rather than to the corporate data center, and applies a zero trust architecture to grant access based on verified identities and policies. Security service edge platforms enable a faster, more consistent, and more scalable security posture. SSE vs. SASE: What’s the relationship?SSE and SASE are related, but it’s important to distinguish them from each other. SSE is a subset of a complete SASE implementation. According to Gartner, SASE involves a cloud-based architecture that brings together security and networking connectivity in one approach. SSE is the security side of that equation, and the networking side of SASE involves software-defined wide area network (SD-WAN) solutions.Together, SSE and SD-WAN adoption represent a complete SASE implementation. Because of the resource-intensive nature of implementing a full SASE deployment, many organizations choose to adopt SSE first. What are the core components of an SSE platform? Security service edge consists of three core components: SWG, ZTNA, and CASB.SSE componentWhat it doesSecure web gateway (SWG)Protects users from web-based threats by monitoring, filtering and enforcing policies. SWG can protect against sophisticated threats, such as threats hidden in encrypted traffic through TLS/SSL inspection.Zero trust network access (ZTNA) Secures remote access to private services by establishing direct connectivity between users and the apps they use—and only those apps. This least-privileged access approach doesn’t require a VPN. Because VPNs put users directly on your network, VPNs introduce lateral movement risk and increase the likelihood of a data breach.Cloud access security broker (CASB)Secures sanctioned and unsanctioned SaaS apps and IaaS platforms with inline security and out-of-band scanning functionality. CASBs protect data, stop threats and ensure compliance.But top SSE platforms will extend their SSE features beyond SWG, ZTNA, and CASB. By choosing a top SSE vendor over one that only offers basic SWG, ZTNA, and CASB capabilities, organizations benefit from a fully integrated platform that consolidates tooling, closes security gaps, and enforces continuous adaptive trust across every user, device, and application. Let’s see how these advanced SSE features help enterprises simplify security operations and deliver consistent security outcomes. What advanced features should the best SSE platforms offer?Mature SSE vendors will include features such as DLP, digital experience monitoring (DEM), AI security, cloud sandboxing, browser isolation, FWaaS, and advanced threat protection.Advanced security service edge featureWhat it doesData loss prevention (DLP)Inspects data in motion across web traffic, applications, email, and endpoints. Applies classification policies automatically, and helps enterprises navigate compliance requirements for GDPR, HIPAA, PCI-DSS, and other frameworks without the need for a separate DLP point product.Digital experience monitoring (DEM)Delivers real-time insights into how users experience applications, networks, and the SSE platform itself. Helps organizations answer the question: Is a performance issue caused by the network, the application, or a security policy?AI securityDetects emerging threats, anomalous behavior, and zero-day exploits. Governs generative AI tools and usage within your organization, prevents sensitive data from being uploaded to LLMs, and enforces acceptable use policies across both sanctioned and unsanctioned AI applications.Cloud sandboxingAnalyzes suspicious files and URLs in an isolated cloud environment before those resources reach a user’s device.Cloud sandboxing is especially helpful for organizations in industries with high ransomware and supply chain attack risks, such as manufacturing, healthcare, and financial services.Remote browser isolation (RBI)Executes all web sessions in a cloud-hosted container and streams only a safe, pixel-rendered version of the page to the user's device. RBI is helpful for enterprises with many unmanaged devices or third parties that need access to sensitive systems. Firewall as a service (FWaaS)Replaces physical firewall infrastructure with a cloud-delivered, scalable policy engine that applies Layer 3 through Layer 7 controls across all users, locations, devices, and branches. Reduces hardware costs, simplifies policy management, and addresses the unique needs of distributed branch offices and remote workforces.Advanced threat protection (ATP)Delivers a layered defense that includes inline intrusion detection and prevention (IDS/IPS), DNS security, command-and-control (C2) traffic analysis, and continuous threat intelligence integrations. ATP is especially helpful for enterprises in regulated industries, critical infrastructure, or in sectors that face nation-state threats. With ATP, your SSE platform acts as an active threat defense layer that’s continuously updated with global threat intelligence.There’s no need to roll out all of these features at once. If your SWG solution is built on a cloud native architecture and you approach the transition with a platform-based mindset, as opposed to a point solution-based one, you can seamlessly extend to ZTNA, CASB, and advanced capabilities as your timeline and budget allow. SSE platform features to evaluate: Core vs. advanced capabilitiesAs you evaluate SSE platforms, it’s important to keep in mind that you’ll want to choose a vendor that offers both core and advanced capabilities so that you can roll out more advanced SSE capabilities over time. Here’s a breakdown of the top security service edge features you should look for as you evaluate vendors:SSE capabilityWhy it mattersIs it a must-have or advanced feature? SWGInspects web traffic and blocks threats Must-haveZTNADelivers app-level least-privileged accessMust-haveCASBSecures SaaS app usage and data Must-haveDLPPrevents loss of sensitive dataAdvanced but highly recommendedAI securityGoverns GenAI use, protects sensitive prompts and dataAdvanced but highly recommendedRBIIsolates risky browsingAdvancedFWaaSDelivers advanced firewall capabilities via the cloudAdvancedAdvanced threat protectionAdds layered inline threat defense Advanced Top SSE features to look for as you evaluate vendorsThe best SSE platforms have the following capabilities: Secure web gateway (SWG)SWGs sit between your organization’s users and the internet. SWGs monitor and filter traffic, enforce usage policies, and prevent data loss.Because over 95% of web traffic is encrypted, TLS/SSL inspection is a critical component of any complete SWG. Without TLS/SSL inspection, your SWG can’t identify or block the vast majority of malware, data exfiltration, or other threats hidden in encrypted traffic.Organizations should look for a SWG with a cloud native, inline proxy-based architecture. Unlike legacy passthrough firewalls, a true proxy terminates both the connection from the user and the connection to the destination. With this approach, the SWG can fully inspect content in real time before re-encrypting it and moving that content along, all without latency.Here are top SWG features to look for in your SSE solution:Inspects 100% of traffic to block encrypted threats. The solution decrypts and inspects every SSL/TLS session for every user, all without adding latency.Protects against advanced threats and malware by detecting and blocking ransomware, zero-days, and other emerging threats in real time.Monitors and controls web access with URL filtering and granular URL policy enforcement that scales to every device and site.Enforces policy for cloud apps and services by identifying, scoring, and governing all sanctioned and unsanctioned SaaS activity. Neutralizes web threats with secure, isolated browsing so that risky sites never reach the endpoint.Prevents bandwidth overuse by stopping non-critical apps from overusing bandwidth. The solution also automatically prioritizes business applications and reins in bandwidth hogs.Zero trust network access (ZTNA)Zero trust is the technical backbone of any complete SSE platform, but it can be challenging to evaluate this capability in vendors. Many vendors claim to offer zero trust architectures, but those architectures still grant broad network access to users after an initial authentication. Real ZTNA eliminates implicit trust by connecting users to only the specific applications they need, while never placing them on the network.Key ZTNA capabilities to look for include:App‑level, least‑privilege access with “inside‑out” connectivity. With this approach, apps and infrastructure stay dark to the internet. Users never join the network, which eliminates the risk of lateral movement.Unified ZTNA for users, workloads, and OT/IoT. The solution supports web and non‑web protocols in addition to client‑based and clientless options for third parties and BYOD.AI/ML-assisted user-to-app segmentation and app discovery to simplify microsegmentation without complex network rules.On-premises ZTNA and business continuity via Private Service Edge functionality, with automatic failover while retaining the same policies on and off network.A cloud native, globally distributed fabric for direct user-to-app paths, better performance, and centralized visibility and operations. Inline protection for private app sessions, including full content inspection, AppProtection (to protect against the OWASP Top 10), and integrated DLP/isolation to reduce the risk of compromise and data loss.Cloud access security broker (CASB)A cloud access security broker is a security control point that sits between users and cloud applications to enforce enterprise security policies. CASBs help organizations maintain visibility and control as data moves outside traditional network boundaries. The best SSE platforms include CASB capabilities that use two deployment modes simultaneously: inline CASB and API-based CASB. Inline CASB provides real-time enforcement for sanctioned and unsanctioned apps, and API-based (or out-of-band) CASB scans data at rest to detect malware and identify misconfigurations. This multimode approach helps organizations in regulated industries, like healthcare and finance, to demonstrate compliance with frameworks such as GDPR, HIPAA, and PCI-DSS.Key SSE features to look for in your vendor’s CASB solution include:Multimode enforcement, including inline proxy and API, to control data in motion and at rest across SaaS and IaaS with one policy model.Shadow IT discovery with application risk scoring and tenant/instance controls to distinguish sanctioned vs. unsanctioned usage.Granular data protection with integrated cloud data loss prevention (DLP) and collaboration management to detect and classify sensitive content and automatically remediate risky shares.SaaS security posture management (SSPM) to find and fix misconfigurations, excessive privileges, and risky integrations. Complete SSPM functionality includes guided or automated remediation capabilities.Threat prevention for SaaS via inline and out‑of‑band malware detection and cloud sandboxing, in addition to agentless browser isolation for unmanaged or BYOD access.Unified compliance visibility and reporting as part of a complete SSE platform, with CASB integrated alongside SWG, ZTNA, and DLP.Advanced SSE features beyond SWG, ZTNA, and CASBMature SSE platforms extend beyond basic functionality to include capabilities that close critical security gaps, consolidate point products, and continuously enforce least-privileged access.Features to look for in an advanced SSE platform include:Data loss prevention (DLP) that inspects data in motion inline and in real time across web, cloud, email, and private application traffic to prevent data from leaving the organization through an unauthorized channel. DLP integration with an SSE platform makes sure that data protection policies follow the user, not the network boundary.Digital experience monitoring (DEM) that provides real-time visibility into application performance, user experience, and network health across locations and devices. When integrated into an SSE platform, DEM helps IT and security teams identify the source of performance degradation.AI security applies machine learning and behavioral analytics to identify zero-day threats, malware, and anomalous activity that signature-based controls miss. AI security also enables teams with generative AI application governance and enforcement of acceptable use policies across sanctioned and shadow AI tools.Cloud sandboxing integrates into the SSE inspection pipeline and protects against ransomware, zero-day malware, and threats that evade inline signature detection.Remote browser isolation (RBI) prevents web code, scripts, or active content from executing locally, which protects against drive-by downloads, malicious JavaScript, and zero-day browser exploits. Enterprises with RBI that’s integrated into their SSE can apply selective browser isolation based on user, device, or risk profile without needing an endpoint agent or another point product.Firewall as a service (FWaaS) ties firewall enforcement to user identity and device posture instead of IP addresses, which helps enterprises align their network security with zero trust principles.Advanced threat protection involves a multilayered, inline defense stack that identifies and blocks sophisticated threats that can evade traditional controls, such as fileless malware and multi-stage attack chains. SSE vendor evaluation checklistAs you search for the best security service edge platform for your organization, make sure that the vendor you choose will: Provide SWG, ZTNA, and CASB capabilities in a single, cloud native platformPerform full TLS/SSL inspection at scaleDeliver app-level least-privileged accessOffer inline and API-based CASB capabilitiesIntegrate DLP, AI security, RBI, and advanced threat protection into its SSE solutionProvide centralized policy, reporting, and operations for security and IT teamsHave a credible roadmap to full SASE convergence How to evaluate SSE platforms: 9 practical stepsStep 1: Align internally on why you’re looking for an SSE platformWhat is your organization looking to accomplish with an SSE implementation? Your organization could be looking to reduce security risk, replace an existing VPN, protect SaaS data, or simplify operations.Once you’ve identified the business drivers of this decision, create clear success criteria for the implementation. Include security outcomes, user experience improvements, operational lift, and time-to-value in your criteria.This is also a great time to create a list of must-haves for your future SSE vendor, including organization-wide compliance, privacy, data residency, integrations, and inspection requirements.Step 2: Define your top SSE use casesWhat capabilities does your organization need today? List the most important applications (including both third-party and private applications), user groups, and data flows that must work well and integrate smoothly into your SSE implementation from day one. Step 3: Establish evaluation criteriaBuild a team of stakeholders across your security, network, SecOps, legal, compliance, IT, IAM, and endpoint teams. Then, create a scoring model for vendors with weighted categories based on the priority use cases you identified in the previous step.Step 4: Conduct exploratory vendor researchRequest vendor demos that are tailored to your priority use cases, and ask for customer references in your geography and industry. Make sure to compare vendors on the consistency of their policy model, the amount of visibility their solutions provide, the ease of administration, and the maturity of their integrations.Step 5: Calculate total cost of ownershipInclude licensing, professional services, legacy tool retirement savings, and SecOps efficiency gains in your total cost of ownership (TCO) model.Step 6: Evaluate the vendor's SASE roadmapIf full SASE convergence is a long-term goal, confirm the vendor has a credible, integrated roadmap that unifies SSE with SD-WAN under a single policy and management plane. Validate near-term milestones, interoperability today, and how the platform avoids reintroducing network-centric complexity.Step 7: Seek independent validationRely on vendor-neutral analyst research such as Gartner’s Magic Quadrant for SSE, the Forrester Wave for SSE, and peer reviews rather than vendor press releases. Use these sources to benchmark strategy, execution, and customer experience across contenders.Step 8: Conduct a proof of conceptOnce you’ve identified an SSE platform that aligns with your organizational priorities, test it with real users, applications, and realistic traffic. Then, measure outcomes relating to user experience, security control effectiveness, operational effort, and ease of troubleshooting. Step 9: Decide on a vendor and a rollout planUsing the information from your pilot and total cost analysis, choose a SSE platform and negotiate with a clear implementation plan in mind. Start your SSE implementation with a controlled pilot rollout, and then continue to implement the solution in waves across your organization. Continually evaluate the platform’s performance, and regularly report on the key success criteria you identified in the first step. Moving forward with a complete SSE platformChoosing the right SSE vendor is a strategic decision that involves many criteria and stakeholders. But with the right SSE features, you can reduce risk, simplify operational complexity, and reclaim capital for future innovation. And as your organization scales and adopts more sophisticated AI and cloud services, your security architecture will become a growth enabler rather than a blocker. Ready to evaluate SSE vendors?Request a demo to see Zscaler SSE in action. Download the ThreatLabz 2026 AI Security Report for the latest data on emerging threats and enterprise AI adoption trends.

How to Establish Least-Privilege Access for AI Agents and Assistants

Matt McCabe (Senior Web Content Writer) — Tue, 02 Jun 2026 20:02:14 GMT

OverviewArtificial intelligence (AI) assistants respond to prompts. AI agents go a step further by taking action, accessing data, triggering workflows, and interacting with connected systems through plugins and connectors.Because these systems can read, write, and move data across enterprise environments, organizations need zero trust controls built into every layer of the workflow. That includes least-privilege access, continuous verification, and inline policy enforcement at the prompt, plugin, and connector level.An AI assistant primarily generates information, summaries, or recommendations. An AI agent can also execute multi-step tasks using tools and external systems, which significantly expands the security risk and potential blast radius.Key termsAI assistant: A conversational AI tool that responds to prompts with information, drafts, or recommendations.AI agent: An AI system that executes tasks through tools, plugins, and connectors.Zero trust: A security framework based on continuous verification and least-privilege access. IntroductionWithout zero trust controls, AI agents often end up with broader access than most employees. They can read email, query databases, update customer relationship management (CRM) systems, and trigger workflows across connected environments. In many organizations, that access was granted through the path of least resistance: full-scope tokens, inherited permissions, and standing service accounts.Most authorization models assume a human user completing tasks one at a time. AI agents operate very differently, chaining together actions across multiple systems and applications in seconds.According to the Zscaler ThreatLabz 2026 AI Security Report, AI transaction volume grew 83.3% year over year. The agents driving those interactions are already embedded inside enterprise environments, and many organizations still lack effective governance over how those systems operate.Zero trust provides a more practical security model for AI-driven workflows.Applying least privilege, continuous verification, and inline enforcement at the prompt, plugin, and connector level gives security teams more control without slowing AI adoption. The shift from open-ended agent access to scoped, verified, and auditable workflows helps organizations scale AI more safely across the enterprise.Why do AI agents expand the attack surface?AI assistants answer questions. AI agents plan multi-step workflows and execute them through tools, plugins, and connectors. That distinction matters because the security implications are fundamentally different.Microsoft 365 Copilot can query organization-wide email and calendar data. Salesforce Einstein can read and update customer relationship management (CRM) records. GitHub Copilot can access large portions of source code repositories. Agents built on Model Context Protocol (MCP) servers can also connect directly to databases, application programming interfaces (APIs), and internal services through standardized interfaces.Most of these systems inherit permissions originally designed for a human sitting at a keyboard. The difference is scale. A person reads one email at a time, while an agent can query thousands in seconds. The permission model may appear identical, but the resulting exposure is not.New attack paths and prompt-based threatsOverprivileged connectors create one of the biggest risks in AI workflows.An agent with broad access to a file system, CRM platform, or internal application can expose significantly more data than a typical user session ever would. Retrieval-augmented generation (RAG) pipelines, long-term memory stores, and conversation logs expand that exposure even further, creating additional surfaces for data leakage.Prompt injection attacks introduce another layer of risk by manipulating agent behavior through crafted instructions.In indirect prompt injection attacks, malicious instructions are hidden inside content the agent later retrieves, such as a shared document, support ticket, email thread, or internal knowledge base article. The model processes those instructions as legitimate context without recognizing them as adversarial.The stakes increase significantly once agents can modify systems or trigger workflows directly. An agent with write access to a ticketing platform, deployment pipeline, or business application may act on injected instructions automatically. At that point, the issue is no longer limited to data exposure. The agent can begin affecting operational systems directly.Data poisoning compounds the problem further. Attackers can inject malicious content into retrieval corpora, including document repositories, email archives, or vector databases, influencing how the agent behaves during future workflows.Blast radius: The risk metric that defines agent impactBlast radius measures the potential scope of damage a compromised or manipulated agent could cause.Security architects should account for blast radius during connector design and permission scoping, before an agent ever reaches production. In most cases, three variables define the risk profile:The number of systems the agent can accessThe types of data domains it can reachWhether the permissions are read-only or write-enabledAn agent with full mailbox access, CRM write permissions, and connected source code repositories creates a fundamentally different level of exposure than an agent limited to read-only access within a single project folder.The underlying technology may be similar, but the operational risk is dramatically different.That is why blast radius should function as a practical scoping tool when designing connector permissions and workflow boundaries.In AI agent security, blast radius is the practical risk metric. The more systems, data domains, and write permissions an agent can access, the greater the impact of compromise, misuse, or prompt manipulation. How zero trust secures AI agent workflowsZero trust exchange: Mapping zero trust steps to AI workflowsTraditional zero trust models focused primarily on verifying a human user requesting access to an application. AI workflows require organizations to extend that model across several additional layers.In an AI-driven workflow, security teams need visibility into:The human initiating the requestThe agent acting on the user’s behalfThe connectors the agent is authorized to accessThe specific actions attempted within each connectorThe data the agent retrieves, generates, or modifiesEach layer requires its own verification and policy decision: verify identity, determine what the agent is attempting to access, assess risk, and enforce policy before execution occurs.That evolution matters because AI workflows introduce runtime behavior traditional access models were never designed to evaluate continuously.Identity for agents: Who and what is actingThree identity layers converge inside every AI workflow:The human userThe AI agentThe workload or infrastructure hosting the agentIn practice, organizations usually handle these identities in one of three ways, but only one consistently supports secure AI operations at scale.Inherited user tokenIn this model, the agent operates with the same permissions as the user who launched it.While convenient, inherited access often creates overprivilege risk because the agent gains visibility into systems and data unrelated to the specific task being performed. A marketing analyst’s Copilot session, for example, may unintentionally grant the agent access to every resource the employee can reach, regardless of what the workflow actually requires.Shared service accountSome organizations rely on shared credentials across multiple agents or workflows.The biggest issue is accountability. When several agents share the same token, incident responders lose the ability to attribute actions to a specific workflow, execution path, or user request.Scoped agent tokenThis is the preferred model for AI workflows. Each agent receives a dedicated, short-lived token scoped specifically to the task being performed. Permissions expire automatically when the workflow completes.MCP servers require separate governance under this approach because they expose callable tool endpoints that agents use during execution. Those endpoints need their own identity controls independent of the agent token itself.Strong authentication, multifactor authentication (MFA), scoped permissions, and time-bound credentials help reduce unnecessary standing access while improving visibility and auditability.Identity patternHow it worksRisk levelAppropriate for agents?Inherited user tokenAgent operates with the full permissions of the launching userHigh — Agent inherits all user access regardless of task scopeNoShared service accountMultiple agents share a single credentialHigh — Actions cannot be attributed to a specific agent or workflowNoScoped agent tokenAgent receives a dedicated, short-lived token scoped to the current taskLow — Permissions expire on task completion; MCP servers governed separatelyYesContinuous verification builds directly on this foundation. Scoped access limits what an agent can reach, while continuous verification ensures activity stays within policy boundaries throughout execution.Continuous verification for agent activityStatic authorization at login is not sufficient for AI workflows.AI agents may perform dozens or hundreds of actions during a single session, requiring authorization checks throughout execution rather than only at login.Step-up authentication becomes important for sensitive actions such as:Modifying production databasesExporting customer dataChanging access controlsTriggering external workflowsBehavioral signals provide additional context for risk evaluation.An agent that normally accesses five documents per session but suddenly queries hundreds may indicate compromise, abuse, or misconfiguration. Unusual access patterns, sudden volume spikes, and workflow sequences that fall outside expected behavior should all trigger additional verification and policy enforcement.Least privilege as the default for agentsLeast privilege should serve as the baseline for every AI workflow. That means limiting both the data an agent can access and the actions it can perform.Organizations should adopt just-in-time and just-enough access models wherever possible. Instead of granting standing permissions during deployment, agents request scoped access during execution and relinquish it once the task is complete.Time-bound approvals add another layer of protection. For example, a user may authorize an agent to send emails on their behalf for the next 30 minutes instead of granting indefinite access. Once the approval window closes, the permissions expire automatically.That approach reduces persistent privilege risk while maintaining operational flexibility. How to secure AI plugins, connectors, and MCP serversConnector inventory and classificationOrganizations cannot secure connectors they have not cataloged.A complete inventory should identify every plugin, connector, and MCP server operating across the environment, including the owner, deployment environment, purpose, associated permissions, and connected systems or data domains.From there, connectors should be classified across two dimensions:Privilege level, including read-only, write, or administrative accessData domain, including Human Resources (HR), Finance, Legal, Engineering, customer data, or source codeEmbedded AI agents inside software-as-a-service (SaaS) platforms require special attention.Tools like Microsoft 365 Copilot, Salesforce Einstein, and ServiceNow AI agents operate under delegated user identity and inherit existing SaaS permissions. That creates a different governance challenge than traditional API-scoped connectors because the permissions often originate from the underlying user account itself.MCP servers also deserve separate governance consideration.MCP servers expose callable tool endpoints that agents use during execution. A compromised or misconfigured MCP server can unintentionally expand an agent’s access far beyond the intended scope. Treating MCP governance as its own inventory category improves visibility and helps reduce hidden privilege escalation paths.Permission scoping patternsLeast privilege should extend directly into connector design. In practice, that means narrowing permissions as much as possible without breaking the workflow itself.Effective permission scoping patterns typically include:Read-only access by defaultFolder-level or project-level permissions instead of full drive or mailbox accessAllowlisting specific API endpoints and actionsSeparate tokens for separate tools and workflowsExplicit approval requirements for write or administrative privilegesRegular review and rotation of connector credentialsThese controls reduce standing access and help limit blast radius if an agent becomes compromised or manipulated. Even small reductions in scope can significantly reduce downstream risk.Guarding against indirect prompt injectionPrompt injection attacks introduce another layer of risk by manipulating agent behavior through crafted inputs.In indirect prompt injection attacks, malicious directives are hidden inside retrieved content that may come from:Retrieval-augmented generation (RAG) systemsShared documentsEmail threadsInternal knowledge basesSupport ticketsWeb contentWithout safeguards, the model may interpret retrieved instructions as trusted context.One of the strongest mitigations is architectural separation.Data context and instruction context should be processed independently so retrieved content cannot override system-level instructions. When an agent retrieves a document, for example, that content should enter a controlled data layer rather than being treated as executable instruction context.Security teams can also apply enforcement controls before retrieved content reaches the model.Those controls may include:Filtering and classifying retrieved contentRestricting which instructions can trigger actionsConstraining tool execution rulesRequiring user confirmation for sensitive workflowsValidating outputs before executionTogether, these controls reduce the likelihood that manipulated content can trigger unintended downstream actions.Connector governance controlsConnector governance needs to extend beyond formal approval workflows.Many organizations focus only on officially requested integrations while overlooking shadow connectors introduced through developer environments, unmanaged tools, or unsanctioned AI experimentation.A mature governance process should include:Approval workflows for all new connectorsVisibility into connectors appearing outside formal information technology (IT) processesVerified publisher or developer requirementsPrivacy and data handling reviewsOngoing connector usage assessmentsConnector governance should extend through the full lifecycle, including decommissioning. Removing a connector from an approved list is not enough. Effective programs also typically revoke associated tokens, review access logs covering the connector’s active period, and confirm the connector can no longer authenticate successfully after removal.Without those steps, residual access may persist long after the integration is considered retired. How to control data access in AI workflowsInspect and enforce at the prompt layerPrompts have become a major enterprise data exposure point.Employees routinely paste sensitive information into AI systems, including personally identifiable information (PII), Payment Card Industry (PCI) data, protected health information (PHI), credentials, source code, and confidential business content.That is why organizations need visibility and policy enforcement directly at the prompt layer.Effective controls typically include:Prompt capture and classificationAcceptable use enforcementContent moderationInline data loss prevention (DLP) for prompts and uploadsBlocking or restricting sensitive data typesRedaction and tokenization where appropriateInspection should not stop at prompts alone. Responses also need to be evaluated because models can unintentionally echo sensitive retrieved data, expose internal system context, or generate policy-violating content.Response inspection closes the loop on inline enforcement and helps prevent downstream exposure.Reduce data sharing risk with isolation controlsIsolation controls provide another layer of protection for high-risk AI workflows.Browser and session isolation become especially important on unmanaged devices and bring your own device (BYOD) endpoints where organizations may lack endpoint agents, local DLP, or visibility into user activity.Instead of relying entirely on device posture, isolation enforces security controls directly at the session layer.Organizations can restrict or monitor:Copy and paste actionsFile uploads and downloadsClipboard sharingPrintingData transfers to untrusted destinationsThese controls help reduce the likelihood of sensitive information leaving controlled environments during AI interactions.Protect outputs and downstream actionsSecuring AI workflows means controlling not only what enters the model, but also what the model is allowed to do afterward.Generated outputs can expose sensitive information, trigger unauthorized actions, or distribute content to unintended destinations if guardrails are not in place.A stronger approach could mean implementing controls that:Prevent sensitive data from appearing in responsesRestrict agent actions such as send, share, publish, or postValidate downstream workflows before executionRequire human approval checkpoints for high-risk actionsHuman-in-the-loop controls are particularly important for workflows involving financial transactions, external communications, access changes, or production systems.These controls help organizations maintain oversight over sensitive actions as AI workflows become more automated.Logging and audit trailsEvery AI interaction generates an audit record.Organizations need visibility into:Who initiated the requestWhich agent executed the actionWhich tool or connector was involvedWhat data was accessedWhat action occurredWhen the activity took placeThese logs serve both operational and governance purposes.Operationally, security teams rely on audit trails to investigate incidents, trace unexpected agent behavior, and reconstruct workflow activity during response efforts.From a governance perspective, frameworks such as the NIST AI Risk Management Framework, the European Union (EU) AI Act, and International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 42001 all require demonstrable visibility into AI system activity.Organizations that cannot produce an audit trail showing what an agent accessed, modified, or executed under a specific authorization context may struggle to meet compliance expectations.Comprehensive audit trails give organizations the visibility needed for both AI security operations and long-term governance. Reference architecture and rollout plan for AI agent securityAt a high level, the architecture should evaluate every request before an AI workflow can access sensitive data or execute downstream actions.The workflow typically follows this pattern:Users and devices → inline policy enforcement point → AI applications, agents, and connectorsSeveral supporting layers work together behind that enforcement point:Identity provider integrations authenticate users, agents, and workloadsRisk engines evaluate behavioral and contextual signalsData protection layers apply classification and DLP policiesAudit pipelines capture telemetry and workflow activityThe control plane manages policy creation, orchestration, reporting, and centralized governance while the data plane handles inline inspection, action enforcement, and session-level visibility during execution.Separating those layers improves scalability, enforcement consistency, and visibility across AI workflows.A phased rollout: Five steps from discovery to operationsOrganizations should approach AI security rollout in phases rather than attempting to deploy every control simultaneously.Each phase builds on the previous one.Discovery comes first because organizations cannot scope or secure assets they have not inventoried. Scoping comes next because enforcement policies applied to overprivileged environments create friction without meaningfully reducing risk. Enforcement should come before isolation because organizations need visibility and policy controls in place before restricting higher-risk workflows.Phase 1: DiscoveryInventory all AI applications, agents, connectors, and MCP servers across the environment. Identify shadow AI usage, map data flows, and document existing permission levels.Phase 2: ScopingApply least-privilege permissions and remove unnecessary full-access grants. Assign blast radius scores to workflows based on system reach, data access, and write permissions.Phase 3: EnforcementDeploy prompt inspection, content moderation, and inline DLP policies. Enable behavioral monitoring and continuous verification controls across agent workflows.Phase 4: IsolationAdd browser and session isolation controls for high-risk workflows, unmanaged devices, and sensitive data interactions. Constrain tool execution policies and downstream actions.Phase 5: OperationsOperationalize governance through recurring reviews, metrics dashboards, audit processes, policy tuning, and AI-specific tabletop exercises.Security teams should continuously evaluate agent behavior, connector usage, and policy effectiveness as workflows evolve.MilestoneTargetSuccess indicator30 daysAI asset inventory completePercentage of known AI apps and connectors inventoried; number of high-risk connectors identified and remediated60 daysLeast-privilege scoping activePercentage of connectors operating under scoped permissions; DLP policy coverage across prompt traffic90 daysInline enforcement operationalMean time to detect anomalous agent behavior; percentage of new connector requests processed through formal approval workflow Common AI agent security mistakes to avoidSecurity teams tend to encounter the same failure patterns repeatedly when securing AI workflows. Most stem from overly broad access, weak governance, or limited visibility into how agents interact with systems and data.One-time consent that never expiresOne of the most common issues is granting access once and never revisiting it.Permissions approved during initial deployment often persist indefinitely without expiration, validation, or periodic review. Over time, agents accumulate access that no longer aligns with their original use case, increasing unnecessary exposure across connected systems.Shared service accounts and long-lived tokensShared credentials and long-lived tokens create major accountability and governance gaps.In some environments, teams deploy broad-scope access because it simplifies integration and reduces deployment friction. In others, the permissions may have started appropriately scoped but were never reviewed, rotated, or revoked as workflows evolved over time.Without clear ownership and lifecycle management, organizations lose visibility into who authorized access, which agent used it, and whether the permissions still match the workflow.Overly broad connector permissionsMany AI workflows still operate with mailbox-wide, drive-wide, or administrative-level access when the task itself only requires a narrow subset of permissions.This often happens because broad access is easier to configure than granular scoping. The result is a significantly larger blast radius if an agent becomes compromised or acts on manipulated instructions.Limited auditability and workflow visibilityOrganizations frequently underestimate the importance of centralized logging and audit trails.Without visibility into prompts, connector activity, downstream actions, and data access, security teams struggle to investigate incidents or understand how agents interact with sensitive systems and information.Incomplete audit trails also create governance and compliance challenges as AI regulations continue to evolve.Automating sensitive actions without human approvalAutomation becomes risky when organizations remove human checkpoints from high-impact workflows.If an agent acts on manipulated instructions without approval controls, the downstream impact may include unauthorized communications, workflow disruptions, policy violations, or operational changes inside production environments.Human-in-the-loop validation remains critical for sensitive actions involving financial systems, external communications, or privileged access changes.Treating AI security as disconnected point solutionsMany organizations approach AI security as a collection of separate tooling problems.One platform handles prompt inspection. Another governs connectors. Another manages posture visibility. Another monitors runtime behavior.The result is fragmented enforcement, inconsistent visibility, and incomplete audit trails between control points.AI security works best when governance, access control, inspection, and runtime protection operate as part of a unified framework. How Zscaler protects AI assistants and agents with zero trustAI adoption is accelerating faster than most security programs can adapt. Agents are already operating across enterprise environments with access to sensitive systems and data. The question is whether the controls governing them are commensurate with the access they hold.Zscaler delivers AI security through three integrated pillars on the Zero Trust Exchange™ platform.AI Asset ManagementAI Security Posture Management (AI-SPM) helps organizations eliminate the visibility gaps that allow shadow AI usage to bypass governance controls.Security teams gain a continuously updated inventory of AI applications, agents, models, connectors, and MCP servers operating across the environment.AI-SPM identifies excessive permissions, risky configurations, and governance gaps before they become operational problems.AI Access SecurityAI Access Security applies least-privilege access controls and inline data protection at the prompt layer.Every AI interaction passes through policy enforcement that inspects prompts, responses, file uploads, and downstream actions. Granular controls determine which users can access which tools, under what conditions, and with what permissions.This allows organizations to scale sanctioned AI adoption without increasing the risk of sensitive data exposure.AI Red Teaming and AI GuardrailsAI Red Teaming and AI Guardrails connect adversarial testing directly to runtime protection.Automated testing identifies exploitable weaknesses, including prompt injection exposure, jailbreak susceptibility, and unsafe tool execution paths. Those findings feed directly into runtime guardrails that block policy violations and malicious behavior during production use.That closed-loop relationship between testing and enforcement helps organizations continuously improve protection as workflows evolve.The controls described throughout this article also align closely with governance requirements in the NIST AI RMF, the EU AI Act, and ISO/IEC 42001.Instead of relying on disconnected tools for discovery, connector governance, runtime inspection, and posture management, organizations can apply those controls through a unified platform with centralized visibility and policy enforcement.Zero trust is becoming the foundation for AI governanceAI adoption will continue accelerating. The question for security leaders is no longer whether agents will expand across the environment, but whether governance and enforcement controls will evolve alongside them.Zero trust provides the architectural foundation for that shift.Applying least privilege, continuous verification, and inline enforcement throughout the workflow helps organizations reduce blast radius, protect sensitive data, and maintain the visibility needed for both security operations and governance. Request a demo to see how Zscaler secures AI workflows. Download the Zscaler ThreatLabz 2026 AI Security Report for the latest research on AI-driven threats and enterprise adoption trends. Read How to Detect and Defend Against Shadow AI for a practical checklist on identifying and governing unsanctioned AI in your environment.

How Zero Trust Branch Addresses the TIC 3.0 Branch Office Requirement

Sean Connelly (Zscaler) — Tue, 02 Jun 2026 12:00:21 GMT

Zscaler Zero Trust Branch is now available in FedRAMP Moderate. For agencies pursuing CISA's TIC 3.0 Branch Office Use Case, this is a direct implementation path, not a roadmap item.I want to explain why that matters, and what problem Zscaler actually solves.When we built the TIC 3.0 Branch Office Use Case during my time at CISA as the Federal TIC Program Manager, we were responding to a real and persistent problem: federal agencies with dozens, sometimes hundreds, of distributed locations, all constrained by legacy architecture that demanded every packet travel back to a central access point before reaching the internet, a cloud service, or even a neighboring application.That was TIC 2. That was the "TIC Tax."Field offices in rural counties. Regional labs. Benefits processing centers. IRS Taxpayer Assistance Centers. VA clinics. USDA service centers. Embassies, where 20 or more federal agencies may share a single facility. All forced through the same small number of Trusted Internet Connection Access Points, most concentrated in the National Capital Region, regardless of where the user was or where the application lived.Agencies knew this was unsustainable. Missions needed speed. Users needed access. The applications were already moving to the cloud. What TIC 3.0 Branch Office Actually RequiresThe TIC 3.0 Branch Office Use Case is not simply "let the branch go direct." That was not the intent.What CISA defined was a set of architectural expectations for any branch that breaks out locally to internet, SaaS, or cloud services, or communicates with the agency campus or other branches:Policy Enforcement Points (PEPs) must exist between the branch and any external trust zoneSecurity capabilities like content filtering, malware inspection, access control, and encryption validation must be applied consistently at those enforcement pointsTelemetry must be collected and shared with both CISA and the agency's own SOCTrust zones must be defined, with clear boundaries between the branch, the campus, and external servicesConfiguration management must ensure that enforcement points are deployed and maintained to a known baselineNone of this is optional. It is the minimum expectation for agencies adopting TIC 3.0 at the branch. Why the Branch Was StuckThe branch access problem was not a technology gap. It was a policy constraint.Under TIC 2, OMB limited each agency to a small number of approved TIC Access Points. Direct internet access from branch offices was simply not permitted under that model. Every session had to traverse one of those designated chokepoints, no matter where the user sat or where the application was hosted.The result: branch offices across the country were forced to backhaul traffic to headquarters or a regional TIC access point before reaching the internet. Latency climbed. User experience suffered. Cloud and SaaS adoption stalled at the edge, even as agencies invested in those platforms at the core.TIC 3.0 removed that constraint. It allowed agencies to define new trust zones and place Policy Enforcement Points closer to the user. But removing the policy barrier was only the first step. Agencies still needed a way to implement consistent security at every branch without recreating a true TIC access point at every location.That was the real question. How Zero Trust Branch Meets the ArchitectureZscaler Zero Trust Branch, now available in FedRAMP Moderate, directly addresses the TIC 3.0 Branch Office Use Case. Not in concept. In operation.Here is how the architecture maps:Policy Enforcement at the Edge, Without Appliance SprawlZero Trust Branch routes all internet and SaaS traffic through Zscaler Internet Access (ZIA), which serves as the Policy Enforcement Point for outbound access. Traffic from each branch connects to the nearest Zscaler data center across a network of 150+ points of presence in the U.S. and globally. That means a field office in Boise or a service center in Atlanta is connecting to an enforcement point nearby, not routing traffic back to the DC metro area. Every session is inspected, filtered, and policy-enforced through the same cloud-delivered controls that protect agency headquarters. The enforcement point is consistent. The policy is uniform. The "TIC Tax" is eliminated.Least-Privilege Access to Private ApplicationsFor branch users who need access to agency campus applications or private resources, Zscaler Private Access (ZPA) brokers connections on a per-session, per-user, per-application basis. There is no site-to-site VPN. There is no network extension. There is no implicit trust granted by virtue of being "on the branch network." Access is earned through identity, context, and policy. That is what TIC 3.0 and Zero Trust demand.Device Segmentation to Contain Lateral MovementTIC 3.0 defines trust zones. Zero Trust Branch enforces them, including inside the branch itself. Device segmentation isolates every connected endpoint (printers, cameras, badge readers, HVAC controllers, IoT sensors) into its own micro-boundary. Lateral movement between devices is denied by default. This is increasingly critical in civilian facility environments where OT and IoT devices share physical space with user workstations.OT/IoT Discovery and IsolationFederal branches are not just offices. They are facilities with building management systems, physical access control, environmental monitoring, and operational technology. Zero Trust Branch discovers and classifies these devices automatically, without agents, without disruption, and applies policy enforcement that contains them.Telemetry and VisibilityTIC 3.0 requires agencies to share telemetry with CISA and maintain internal visibility. Zero Trust Branch provides full session-level logging: who accessed what, from where, when, and how, for every connection transiting the platform. That telemetry feeds agency SIEM and SOC workflows and supports CISA reporting obligations.Zero-Touch Provisioning and Configuration ManagementTIC 3.0 expects configuration management rigor at the branch. Zero Trust Branch delivers zero-touch provisioning: new sites come online with policy pre-applied, without sending engineers to each location, without local configuration drift, without manual baseline management. The branch inherits the agency's security posture from day one. Architecture Over AspirationI want to be clear about something. TIC 3.0 was never intended as a theoretical framework. We built it at CISA so agencies would have concrete, implementable architecture patterns for real-world scenarios. Branch offices were one of the first use cases published precisely because the pain was so acute and so widespread.Zero Trust Branch is that implementation. FedRAMP authorized, cloud-delivered, deployable today.For agency CISOs and enterprise architects evaluating their TIC 3.0 posture at distributed sites, the path is now clear:Consistent policy enforcement for all branch internet and SaaS access via ZIA, delivered from local points of presenceIdentity-based, least-privilege access to private applications via ZPA, without VPNDevice segmentation to enforce trust zone boundaries inside the branchOT/IoT discovery and containment, without additional infrastructureCentralized telemetry for CISA reporting and internal SOC operationsZero-touch provisioning aligned to TIC 3.0 configuration management expectationsTIC 3.0 defined what agencies need. Zero Trust Branch makes direct access actionable.I want to thank the Zscaler Public Sector engineering and compliance teams for the work required to bring this capability through FedRAMP authorization, and for continuing to help agencies translate architecture guidance into something they can actually deploy.Join us for a webinar on June 17 at 1pm ET to explore Zero Trust Branch further: Modernizing Federal Branch Security in GovCloud: A zero Trust Approach to Distributed Locations.

AIを悪用した攻撃をZscaler Zero Trust Firewallで阻止する方法

Karan Dagar (Senior Product Marketing Manager) — Mon, 01 Jun 2026 16:01:30 GMT

人工知能は、サイバーセキュリティにおける攻防の両面を変革しつつあります。防御側はAIを活用して検知と対応能力を向上させていますが、一方で攻撃側もAIを駆使してより迅速に動き、より積極的に試行し、従来型の制御を驚くほど効率的に回避しています。かつては熟練した攻撃者が数時間から数日かけて行っていた作業も、現在では自動化された適応型の攻撃ループによって数分で実行できるようになっています。この変化が重要なのは、多くの組織向け防御が異なる時代に合わせて構築されているためです。従来のIPベースの境界型ファイアウォールは、脅威が既知のシグネチャーや固定された指標、疑わしい宛先によって特定できることを前提としています。しかし、AIを悪用した攻撃はそのような仕組みではありません。AIは学習し、適応し、繰り返し攻撃を試みます。攻撃者は複数の侵入経路を試し、ドメインを次々と切り替え、ビーコンの通信タイミングを調整し、通常のトラフィックに紛れ込みます。さらに、Webプロトコルと非Webプロトコルの両方を悪用し、システム環境への最も侵入しやすい経路を探り当てます。そこで特に重要となるのが、Zscaler Zero Trust Firewallの事例です。 AIが攻撃者に与える最初のメリットは、規模の拡大です。組織がパブリックIPアドレスやインターネットから到達可能なサービスを公開すると、それらは継続的に発見、スキャン、検査の対象となる攻撃ターゲットを生み出すことになります。AIツールは、露出した資産を迅速に調査し、弱点を特定するとともに、人間の攻撃者よりもはるかに速くさまざまな攻撃パターンを試行できます。リスクは単純です。攻撃者が公開されたサービスを把握できれば、そのサービスを悪用する作業を開始できるということです。AIはそのプロセスの速度と持続性の両方を向上させます。そのため、設定ミスやパッチが適用されていない脆弱性、見落とされた公開箇所が発見され、悪用される可能性が高まります。従来のセキュリティの考え方では、攻撃チェーンを個別の段階が順に進行するプロセスとして扱われることが一般的でした。しかし、AIはキルチェーンを高速に学習するループへと変化させています。そのパターンは以下のようになります。1. 生成 – 攻撃者は新しいサブドメインのパターンやコマンド＆コントロールの識別子などの亜種を作成します。2. 実行 – 信頼されたツールを介したり、通常のユーザーやアプリケーションの動作に紛れ込んで攻撃を実行します。3. 学習 – 攻撃者は何がブロックされたか、何が許可されたか、そしてどこで抵抗が最も少ないかを観察します。4. 再試行 – ドメイン、タイミング、プロトコル、技術を調整し、攻撃を再び実行します。このループにより、攻撃者はほぼリアルタイムで進化することが可能になります。既知の悪い指標に頼るのではなく、環境寄生型の手法を用いて足がかりを築き、アクセスやデータの移動が成功するまで適応することができます。 1. エンドポイント上のAIエージェント攻撃者は侵害したエンドポイント上でエージェントによる試行錯誤のループを駆使します。これらの攻撃は正規のツールや信頼されたプロセスを悪用することで、静的な侵害の痕跡に引っかかることなく足掛かりを築くことが可能です。必ずしも既知の不正なシグネチャーに依存しているわけではないため、従来のエンドポイント中心の検出モデルを回避できる可能性があります。 2. 適応型コマンド＆コントロールコードが実行された後、攻撃者は信頼性の高いアウトバウンド通信を必要とします。AIは、ドメインのローテーション、DNS、HTTPS、DoH間の切り替え、ビーコンのタイミング調整によって検出を回避することで、そのチャネルの維持を支援します。これにより、コマンド＆コントロールのトラフィックは、従来の制御を通過できるほど正常に見えるパターンの中に紛れ込むことが可能となります。 3. ラテラルムーブメントとデータの持ち出しアクセス権を取得した後、攻撃者は環境内を調査してRDP、SMB、SSHなどのプロトコルを悪用し、盗み出した認証情報を用いながら攻撃の方向転換を図ります。その後、データは正規の活動に見せかける形で、小規模かつ暗号化された断続的な通信によって持ち出しされる可能性があります。これは、Webのみの検査や内部ネットワーク間の通信を暗黙的に信頼している環境において特に危険です。 Zscalerのアプローチは、単一の検査ポイントに頼るのではなく、攻撃チェーンのあらゆる段階で攻撃を阻止することにあります。 DNS制御は、DGAによるアクティビティー、新規登録ドメインまたは新たに観測されたドメイン、戦略的に長期間保存されたドメインなどの疑わしいドメインを検出できます。また、DNSトンネリングなどのデータ漏洩手法の防止にも役立ちます。 DoH対応プロキシは、TCPとUDPのトラフィックを検査し、エッジでDNS over HTTPSを復号することで、暗号化によって生じる死角を削減します。これは、攻撃者がコマンド＆コントロールの挙動を隠すために暗号化されたチャネルに移行する傾向が強まっているため重要です。シンクホール機能とリダイレクト機能は、危険なDNS解決をポリシーによって上書きし、悪意のあるリクエストをリダイレクトすることで、通信が確立される前に攻撃インフラを遮断します。インライン行動分析型IPSは、非Webプロトコルやカスタムプロトコルに対して適応型の検査を実施します。従来のWebトラフィックのみに焦点を当てるのではなく、攻撃者が移動、制御、窃取に悪用する広範なインフラプロトコル全体にわたって異常を検出できます。エンドポイントアプリ制御は、プロセスレベルで重要なコンテキストを追加します。ポリシーはPowerShell.exeやChrome.exeなどトラフィックを生成している実際のプロセスに関連付けることができます。そのため、セキュリティ部門は正規のアプリケーション挙動と、信頼されたツールの悪用による不審な利用とを識別できるようになります。ユーザーアイデンティティーベースのポリシーは、ユーザー、グループ、場所、リスクプロファイルなどに基づいて制御を適用します。これにより、ポリシーは静的なネットワーク中心のものではなく、動的なコンテキスト認識型のものになります。アイデンティティーベースのセグメンテーションは、ユーザーとアプリケーション間の暗黙的な信頼関係を排除することで、攻撃の影響範囲を制限します。攻撃者が1台のシステムに侵入しても、環境全体に広範囲に攻撃を仕掛けることは非常に困難になります。 AIを悪用した攻撃は、従来の多くの防御が想定していた範囲を超えて高速で適応性が高く、正規のトラフィックに紛れ込む能力にも優れています。単に境界型アプライアンスを追加するだけでは対策になりません。必要なのは、露出を軽減し、Web以外のトラフィックも検査し、ユーザー、デバイス、プロセスのコンテキストを理解するとともに、攻撃者のループが成功する前に中断するセキュリティアーキテクチャーです。これこそが、Zscaler Zero Trust FirewallがAIを悪用した攻撃への防御を支援する仕組みです。すなわち、資産を発見されにくくし、悪意ある通信を隠蔽しにくくし、ラテラルムーブメントを実行しにくくすることによって、防御を強化します。セキュリティリーダーにとっての要点は明確です。攻撃者が高速で攻撃を生成、テスト、学習、再試行できるようになった現在においては、防御側も境界だけでなく、攻撃チェーン全体にわたって攻撃を阻止できなければなりません。今後開催されるワークショップに参加し、Zero Trust Firewallを実際に体験してみませんか？今すぐ登録してください。

The Verizon DBIR Report, Project Glasswing Update Expose the Risk of Legacy Remediation Workflows

Chris McManus (Senior Product Marketing Manager) — Mon, 01 Jun 2026 15:37:05 GMT

Last week, Verizon released its 2026 Data Breach and Incident Report highlighting trends across 31,000 security incidents and 22,000 confirmed data breaches in 145 different countries. For the first time in the history of the report, “exploitation of vulnerabilities” was the most common initial access vector for breaches.The details of Verizon’s report highlighted two startling metrics:The median organization saw 50% more critical vulnerabilities to patch compared to last yearThe mean time for full resolution increased year-over-year from 32 days to 43 daysIn other words, the volume of findings to patch is increasing and the speed of remediation are heading in opposite directions – and these findings came in a pre-Mythos world. A few days after the annual Verizon report hit, Anthropic released an update on Project Glasswing, an exclusive project with 50 partners (including Zscaler) designed to identify and fix the critical software vulnerabilities using a preview of Mythos. In less than two months, Mythos Preview has found an estimated 6,202 high- or critical-severity vulnerabilities.As Anthropic discloses in its update, significant delays and challenges have plagued the process from discovery to disclosure to patch, particularly when it comes to open source maintainers – as of that update, only 75 high- or critical-severity vulnerabilities had been patched.Bear in mind that this early volume of findings resulting from Project Glasswing come from just a few dozen partners. When Claude Mythos and similar models become generally available, floodgates will open, with AI-powered vulnerability discovery hitting the entire software ecosystem.Bottom line: security teams are struggling to patch critical vulnerabilities in a timely manner today, and the challenge is about to multiply to a previously unimaginable scale. Two familiar challenges in vulnerability management: volume and speedSecurity teams are quite familiar with flooded vulnerability queues and shrinking exploit windows.Within a similar number of distinct organizations studied, Verizon cites almost eight times the aggregate number of CISA KEV findings in 2025 compared to a few years earlier in 2022. Despite more vulnerabilities getting closed in 2025 vs. any other year, the backlog of unaddressed KEVs has grown. The report draws a direct line from the exponentially increasing volume to the 8% increase in CISA KEV findings still open at Day 28.In other words, the pace of vulnerability resolution hasn’t slowed. Instead, current tooling and processes simply do not scale for today’s reality.Again, these data points come pre-Mythos, which demonstrated an ability to find and exploit previously unknown vulnerabilities at machine speed. In two short months, that code is already producing POC exploits that open source maintainers are struggling to patch.When it comes to vulnerability discovery and exploitation, the game has changed. Security teams need to change their game accordingly. Start with machine-speed analysis and prioritizationThe first place to audit your workflow is prioritization.Static scoring like the Common Vulnerability Scoring System (CVSS) and Exploit Prediction Scoring System (EPSS) lack environmental context about your assets, multiplying risk factors such as open ports or misconfigurations, and mitigating controls blocking attack paths. As a result, security teams waste precious time and resources chasing “false criticals,” reporting on generic findings and patches without a perspective on the reduction of actual business risk.Traditional prioritization methods slow down response times by junking up remediation pipelines with issues that don’t rise to the level of emergency response. In a previous post, we covered the need for CISOs to “adjust their definition of exploitability.” AI-powered vulnerability discovery will soon outpace the traditional scoring and threat intelligence models. While previous models can indicate “theoretical exploitability,” security teams instead need a finely-tuned model that understands exploitability in context of their environmental factors, mapped against their mitigating controls.In the post-Mythos world of machine-speed exploits, prioritization must also happen at machine-speed. The manual process of exporting scan results into spreadsheets and mapping to asset criticality and controls will never keep pace.Your Exposure Management solution must handle each of the following items without the need for human analysis:Incorporate all relevant context from assets, identities, and alerts connected to each exposure finding – whether it originates from a traditional scanner or an AI modelApply multiplying risk factors from all relevant sources to adjust severity scoringAutomatically reduce severity scoring based on the presence of mitigating controls (such as your ZIA/ZPA policies)Allow you to customize or adjust the weight of each contributing factorNo one can afford to build context manually – security teams must get the priority list for risk burndown much faster to keep pace. “Design for triage”In its executive briefing in response to Claude Mythos, the Cloud Security Agency calls for organizations to “Stand up VulnOps,” a risk reduction program staffed and automated like DevOps.In its description of VulnOps, CSA instructs security teams to “design around triage discipline from the start.”As the number of vulnerabilities and subsequent patches increase, it is imperative to group and route findings to rightful owners automatically. Ticket grouping and triage are low hanging fruit that can deliver dramatic improvements in response time.If triage in your organization is manual today, think about the ways your teams work and how you might automate it. We see Zscaler customers group and assign tickets according to many of the following attributes:Asset typeAsset ownerAsset tags (such as PII or PCI)Available fixesFinding type (vulnerability, misconfiguration, etc.)Finding severityBy managing one ticket for numerous findings and automatically assigning the ticket, you’re moving the starting line of the race to your advantage. Any triage dwell time is wasted time in the age of AI-powered exploits. Don’t wait for patch windows to reduce riskThe Verizon DBIR Report and the Project Glasswing update each provide evidence that faster patching and remediation can no longer outpace the AI-powered adversary, no matter how efficiently your teams operate.As frontier AI models discover vulnerabilities and code flaws, security teams will often be tasked to reduce risk outside of patching windows – or even before a patch is available.In addition to efficient patch management workflows, automated response playbooks can block attack paths and minimize the potential blast radius while you wait for an available patch. For example, a risky asset with an exploitable vulnerability could be isolated from the network. The associated user could be restricted from crown jewel applications. Sure, the finding is still present, but risk and reachability have greatly reduced.By evaluating risk holistically – with the context of asset relationships, identities, and alerts – your exposure management program is positioned to reduce risk in near real-time rather than waiting for the next available patch.AI-powered attackers will not wait for patch windows, and neither should you.Learn how Zscaler Exposure Management is helping customers keep pace with a new generation of AI-powered exploits.

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

Jose Arvelo Negron (Manager, Sales Engineer) — Fri, 29 May 2026 05:07:00 GMT

We know it can be challenging to stay current on new releases while managing mission priorities, operational demands, and compliance obligations. Here is a curated roundup of notable Zscaler GovCloud updates from May, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include Zero Trust Branch availability in FedRAMP Moderate, expanded policy controls for GenAI prompts and URL filtering, and Cloud Connector enhancements for more flexible upgrade management. Zero Trust Branch, FedRAMP Moderate Cloud AvailableZscaler Zero Trust Branch helps modernize branch security and connectivity by bringing zero trust principles to branch offices, remote sites and OT/IoT, reducing reliance on legacy appliances while maintaining consistent policy enforcement.This month, Zscaler released Zero Trust Branch to the FedRAMP Moderate cloud. This expands options for agencies and partners looking to standardize security and access controls across users, workloads, and branch locations while staying aligned with federal compliance requirements.Click here for the full announcement. Zscaler Internet Access (ZIA)Product intro: 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 improving policy precision and expanding control for generative AI usage, helping teams apply governance in a way that maps more cleanly to mission needs and organizational structure.HighlightsPolicy Level Gen AI Prompt Configuration: Customers can now capture end user prompts for generative AI applications from the Cloud Application Control policy. This enables more granular control of Gen AI prompt configuration and supports tighter governance as Gen AI adoption grows across teams and roles.Enhanced Flexibility in the URL Filtering Policy Rule Creation: Customers can now build URL Filtering Policy rules that match their org structure more precisely, supporting cleaner segmentation and easier administration at scale.For full release notes: https://help.zscaler.us/zia/release-upgrade-summary-2026 Zscaler App ConnectorZscaler App Connector is a key component of Zscaler Private Access (ZPA) that enables secure, policy-based connectivity between users and private applications without exposing apps to the internet. It helps organizations reduce attack surface while improving access experience, which is especially important for distributed users and mission partners.This month’s update delivers a new App Connector release to FedRAMP Moderate, focused on keeping environments current with fixes and operational improvements.HighlightsApp Connector Version 26.53.4: An update was released to FedRAMP Moderate for App Connector that includes bug fixes, optimizations, and version enhancements.For release notes: https://help.zscaler.us/zpa/app-connector-release-summary-2026 Zscaler Cloud ConnectorZscaler Cloud Connector helps extend Zscaler policy enforcement and traffic forwarding for workloads running in public cloud environments. It supports organizations that need consistent security controls for cloud-hosted services while enabling architectures aligned to modernization initiatives.This month’s Cloud Connector updates focus on more flexible, customer-controlled upgrade operations and expanded API support for managing upgrades at scale.HighlightsCloud Connector Scheduled Upgrade Enhancements: Cloud Connector now supports enhanced upgrade capabilities by allowing customers to select release channels. When upgrading Cloud Connectors, customers can choose between the stable, latest, or beta release channels, helping teams balance change control with speed of adoption.Endpoints for Scheduled Upgrade Enhancement: New endpoints extend programmatic access for managing Cloud and Branch Connector virtual machines (VMs). These APIs allow customers to update the release channel for VMs, update VM status in bulk, and retrieve release channel and scheduled upgrade metrics:PUT /ecgroup/releaseChannelPUT /ecgroup/vmStatusGET /ecgroup/vmUpgradeMetricsTo learn more about each endpoint, see the API Reference Guide.Release notes located here: https://help.zscaler.us/cloud-branch-connector/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.

Deep Dive: Inside the Zscaler and Vectra AI Integration

Abhishek Gupta (Principal for Cyber Solutions) — Thu, 28 May 2026 16:41:47 GMT

The complexity and sophistication of today’s cyber threats demand a unified defense that doesn’t just detect threats but enables detailed investigation, rapid mitigation, and proactive prevention before damage occurs. If you’re a SOC analyst or security engineer who’s tired of stitching together partial views of remote-user and Security Service Edge (SSE) traffic, this is for you.Zscaler, the AI Security Platform Built on Zero Trust, and Vectra AI empower SOC teams to achieve operational resilience. By combining Zero Trust access, AI-driven threat visibility, and automated response, organizations can eliminate blind spots, detect threats faster, and maintain secure, uninterrupted operations across hybrid and cloud environments.This post gives you a technical understanding of how the Zscaler + Vectra AI integration works under the hood.Let’s look at three common SOC use-cases we hear from our customers. Use Case 1: Neutralize “low-and-slow” Command and Control (C2C) trafficSOC teams frequently investigate outbound connections that look normal at first glance. Take for example, C2 traffic that disguises itself as HTTPS requests to a major Content Delivery Network (CDN), using Domain Fronting where the DNS request shows a legitimate domain, but the HTTP Host header triggers a hidden malicious destination. In this instance, the traffic would be periodic and will not trip obvious blocks. Of course, blocking CDNs is not an option, and chasing IP reputation is futile because the destinations keep changing. That’s often by design. In this attack pattern, the threat actor uses Fast Flux DNS and Domain Fronting to rotate infrastructure frequently – sometimes every 15 minutes – so destination-based controls (URL filtering, IP reputation, static deny lists) struggle to keep up. You end up with suspicion, but not a clean handle to scope the activity without breaking legitimate cloud usage. Zscaler Internet Access (ZIA) provides detection for this suspicious traffic but the lateral movements need to be stitched with east-west traffic detected anomalies that are not internet bound. The Zscaler and Vectra AI integration changes your threat hunting workflow by focusing on the TLS handshake fingerprint and pattern validation.With Zscaler Internet Access (ZIA) integrated into Vectra AI, you can hunt on stable signals even when destinations churn. ZIA can capture selected internet-bound sessions as PCAPNG (based on your capture policy with a rich set of criteria) and forward those captures to a customer-owned AWS S3 bucket. Vectra AI then ingests those PCAPNGs using a dedicated AWS vSensor, driven by an event pipeline that makes the sensor near real time ingestion for quick detection and hunting. Operationally, that’s what makes remote-user internet traffic analyzable even when it never traverses a corporate tap point reducing blind spots for SOC team that need data driven hunting with improved automated playbooks.In this scenario, the JA4 fingerprint stays constant even as destinations change, and that consistency helps you distinguish a customized Sliver C2 framework or new Cobaltstrike profile from standard browser miming traffic.Instead of blocking “AWS”, you can act precisely and promote the verified fingerprint/pattern into Indicators of Compromise (IOC) or risk trigger and take targeted enforcement in ZIA. This is the practical advantage of this integration: you improve response accuracy while minimizing false positives and avoiding collateral damage to legitimate cloud usage. Figure 1 : Vectra NDR finding slow and hidden C2C traffic from captured traffic Vectra AI ingests ZIA PCAPNGs using a dedicated AWS vSensor, driven by an event pipeline that enables near real-time analysis. By focusing on stable signals like the TLS handshake fingerprint (JA4) and behavioral patterns, the integration allows you to hunt for "low-and-slow" C2 traffic even as threat actors rotate infrastructure frequently to evade destination-based controls. Use Case 2: Driving Early Detection with Unified SSE VisibilityIn this scenario, you’re dealing with what modern SOC operations actually look like at scale: strong security controls are firing, attackers are probing, and you have to prioritize fast. Zscaler Advanced Threat Protection sandboxing surfaces suspicious artifacts as intended, giving you early indicators that something is not right. The challenge is not that the controls are failing—it’s that a motivated attacker can generate multiple adjacent signals (downloads, staging, retry attempts) and your team needs to answer the next question quickly: is this activity progressing into reconnaissance, lateral movement, or private app targeting?The Zscaler + Vectra AI integration drives attack stage clarity instead of simple alerting as early from recon stage before it starts compromising and moving laterally in the connected network . Vectra AI’s behavioral analytics surface a very indicator—a cautious, recurring horizontal port sweep and enumeration behavior—so you can focus on what the host is doing next, not just what it downloaded. In this scenario, the laptop attempts SMB/445 connections to roughly 50 internal IPs and shows enumeration patterns against private applications—especially SMB, RDP, and SSH paths targeting higher-value systems. Deception signals from Zscaler (like Kerberoasting-related indicators) further increase confidence that this isn’t benign user behavior.This is difficult precisely because each signal can be argued in isolation. A burst of suspicious artifacts can reflect attacker experimentation, limited scanning can be misconfiguration, and private app access attempts can resemble legitimate IT workflows. What you need is attack-stage context—behavior plus access context—connected fast enough that you can contain it, while the attacker is still in reconnaissance and enumeration.This is where running both integration lanes matters. ZIA gives you an internet-traffic view through PCAPNG ingestion for suspicious and SOC interesting traffic As described in the Zscaler and Vectra AI Deployment Guide, Vectra AI sensors and ZPA logs generated by LSS track behaviors undertaken by remote workers. These logs are preferably sourced from a dedicated App Connector Group used only for LSS, contain data related to the activities brokered through App Connectors used for ZPA traffic, and—when forwarded to the Cognito Brain—form the basis of this integration. The Vectra AI Brain serves as an enterprise log receiver in ZPA parlance.In practice, this combined view lets you connect the dots quickly: what the host is doing on the internet through ZIA, what it’s attempting against private apps through ZPA-brokered access, and what Vectra AI is prioritizing behaviorally. With high-confidence signals in hand, your SOC can shift from investigation to containment by applying targeted enforcement in ZIA—and, where appropriate, tightening access via ZIA and ZPA policies—so the device is constrained while you complete the response. After you stabilize the incident, you can strengthen posture using what you learned—updating criteria and policies in Zscaler based on impact and known advisories—so you reduce unnecessary noise while keeping the controls that matter. Figure 2: Vectra NDR finding suspicious Active Directory recon for Private Applications By ingesting ZPA logs alongside on-premises telemetry, Vectra AI applies sophisticated behavioral analytics to east-west traffic, surfacing lateral movement and internal reconnaissance as they occur. This unified visibility for remote-user behavior allows SOC teams to move beyond basic alerting and prioritize threats based on high-confidence actions against private applications. Use Case 3: Detecting Compromised Identities & "Living off the Land" within SaaS AppsModern attackers no longer “break in”; they “log in.” By using stolen session tokens or sophisticated phishing, they bypass Multi-Factor Authentication (MFA) and “live off the land” within SaaS platforms like Microsoft 365 or Google Workspace. They use legitimate administrative features—such as creating enterprise searches for keywords like “Merger,” “Password,” “Secret,” or “Contract,” configuring OAuth access to privileged services, or setting up Mail Forwarding Rules—to steal data without ever triggering a malware alert.Vectra AI flags the identity behaving strangely—for example, when a non-admin user suddenly starts creating automated flows with external connectors they have never used before. Zscaler provides the “What”: it shows that this same user is accessing crown-jewel applications and applications that are rare for that user. By correlating the source internal IP from App Connector with the ZPA LSS logs and Vectra AI telemetry, the SOC team can hunt for instances where a legitimate SSH session is being used for unauthorized “Lateral Movement,” and identify abnormal or rare access patterns based on frequency and the number of endpoints the compromised identity is attempting to access over time. The SOC uses Zscaler to “Terminate” the ZPA session and updates ZPA policy to require Step-up MFA for any SSH access to that SQL segment.This stops “fileless” attacks where no malware is present. By combining Vectra AI’s focus on who is behaving abnormally with Zscaler’s visibility into what they are touching, the SOC team can catch the attacker during the “Exploitation” phase—before they can complete a large-scale data breach. Figure 3: Vectra NDR finding suspicious SaaS access from a compromised identityBy leveraging this unified SASE visibility, your SOC can rapidly identify and isolate compromised accounts attempting to "live off the land" through unauthorized lateral shifts or stealthy data exfiltration.Figure 4: Zscaler and Vectra AI Quick view: What You Need to EnableIf you want to run use case 1, you need ZIA visibility in Vectra. Customers using ZIA with Vectra AI have two options: on-premises capture (the older method supported for years) and the newer PCAP ingestion method. If your priority is visibility for remote users and modern ZIA deployments, PCAP ingestion is the path you’ll typically implement.If you want to run use case 2, you need that same ZIA visibility plus ZPA context. That means enabling ZPA LSS and forwarding those logs—preferably from a dedicated App Connector Group used only for LSS—into the Vectra AI Brain as the enterprise log receiver.Most importantly, giving visibility to compete SASE platform for specific use cases is just a start for SOC journey, depending on tooling, automation and playbooks this can help SOC for many more use cases like DNS Behavioral Baselining, encrypted tunnels visibility, baselining access to critical applications, insider misuse for rare access attempts, spike or unusual or suspicious activity for data transfer and customer specific Traffic investigations for Living off the Land anomalies from legitimate tools. Note: this post intentionally avoids step-by-step UI instructions; the Zscaler and Vectra AI deployment guide covers those details. The point here is to help you map each use case to the lane(s) you must deploy and the kind of evidence you should expect to gain. These scenarios are different—one is about evasive outbound behavior and the other is about early containment across attack stages—but the operational payoff is the same. You’re building a repeatable evidence pipeline across SSE traffic so you can validate faster and act with confidence.If interested, you can do a quick “outcome check” that matches the investigation you care about. For the first use case, generate a small amount of representative outbound TLS traffic from a test user and confirm the end-to-end chain works in practice: your ZIA capture policy results in PCAPNG objects in the S3 location you configured, the ingestion path is active, and you can complete the pivot that matters—spotting the same stable JA4 fingerprint pattern across endpoints. For the second use case, confirm the same ZIA ingestion path and then validate that ZPA LSS logs are landing in the Vectra AI Brain and are usable as investigation context, because your ability to connect behavior to private-app access context is what makes earlier containment possible.When those pivots work end-to-end, you’re not just “integrated.” You’re operational—able to hunt with better evidence, contain earlier when warranted, and feed what you learn back into tighter policy and more automation over time.Interested to hear more? Please reach out to your Zscaler and Vectra AI account team members.

Automating Operational Notifications from Zscaler with OneAPI

Puja Wheeldon (Senior Product Manager) — Thu, 28 May 2026 11:00:05 GMT

How OneAPI eliminates manual monitoring by pushing critical operational alerts directly to the tools teams already use.The problem with manual monitoringIT and security teams today manage complex environments that span dozens of vendors and countless solutions for secure web access, private application access, data protection, digital experience monitoring, endpoint posture, traffic forwarding, and more. Each generates its own alerts, reports, and dashboards. Keeping on top of everything requires practitioners to constantly pivot between interfaces, manually refresh their views, and hope they catch the right signal before it becomes an incident.This approach is time-consuming and error-prone. Critical operational signals often go unnoticed until a user files a ticket. Hours that could be spent on higher-value work like threat hunting, policy tuning, and incident response are consumed by routine monitoring instead. And as environments grow, the burden compounds.What organizations need is not another dashboard to watch. They need a security platform that reaches out when something matters, automatically, through the channels where their teams already work.OneAPI and Zero Trust AutomationWhen it comes to Zscaler, practitioners can avoid the above challenges entirely. That’s because the Zero Trust Exchange platform includes OneAPI, a single, unified programming interface that provides programmatic access across ZIA, ZPA, ZDX, Client Connector, Zscaler’s authentication service, and more—and, it’s included for free as part of the platform, with no additional SKU or provisioning required.OneAPI helps organizations move away from manual administrative tasks and toward automated, repeatable workflows. Customers are already using it to automate policy configuration, retrieve analytics data, and build custom reports, reducing management overhead and freeing admins to focus on more strategic work. Now, Zscaler is expanding OneAPI’s capabilities to include automated operational notifications.Introducing automated notifications through OneAPIZscaler is rolling out the ability for customers to subscribe to platform event notifications, which are pushed directly to relevant parties without requiring them to manually log in or check various dashboards. Rather than asking administrators to go looking for problems, the platform proactively delivers the signal when and where it is needed.This capability is being introduced first for operational notifications: events that indicate whether infrastructure is healthy and traffic is forwarding correctly. That includes things like connector health, capacity thresholds, and service availability. These are the signals that, when missed, tend to surface as user-reported outages rather than proactive catches.Security incident notifications and end-user policy events will continue to be handled through their existing dedicated channels for now. Operational health is where automated push notifications are launching first, given their direct and immediate impact on day-to-day operations. We will provide updates in the coming months on security-oriented alerts through OneAPI.How it worksThe setup for automated notifications is straightforward. Zscaler already detects operational health conditions internally—that is what populates our dashboards today. Our new notification framework just pushes those signals out to customers automatically. At a high level, the process works like this:Authenticate once: register an API client in Zscaler’s authentication service (formerly ZIdentity) and use it to obtain an access token; one identity gets one token across the platform.Subscribe to events: browse the event catalog, select a source and source type, and choose specific events worth tracking, such as status changes, threshold breaches, and availability issues.Choose a delivery channel: notifications can be delivered via email, webhooks, and SNS, with more options like Slack and SMS on the way. Webhook URLs are validated, and duplicate events are automatically de-duplicated to prevent alert fatigue.Let alerts drive remediation: each notification includes enough context to trigger a remediation playbook without requiring anyone to log in to the portal.Close the loop: when remediation requires a configuration change, playbooks can call back into OneAPI to update the relevant settings, automatically closing the loop for deploying, monitoring, and responding. What this looks like in practiceTo make this concrete, here is an example of how automated operational notifications can streamline daily operations.Connector health: catching degradation before users noticeConsider a scenario in which connectors in a certain group begin going offline, and the remaining ones start running above CPU and memory thresholds. Historically, this kind of situation surfaces when users start filing tickets—at which point, an administrator has to log in to the portal to reconstruct what happened.When using OneAPI for notifications, administrators simply subscribe to the relevant status and metrics events. The moment a threshold is breached, a webhook delivers the component ID, event type, threshold value, and current value to whatever automation platform the team uses. A playbook can then immediately remove the affected component from rotation, provision additional capacity, and open a ticket for the on-call engineer before any user is impacted.The business caseAutomating operational notifications through OneAPI delivers meaningful improvements that enable a more secure, productive, and cost-effective business:Less manual effort: administrators no longer have to stay glued to their dashboards in order to catch problems. The platform surfaces what matters automatically.Faster response times: automated first-line response shrinks mean time to remediation (MTTR), reducing the scope and duration of incidents.Fewer human errors: codified playbooks replace ad hoc manual workflows, removing the potential for operational mistakes.Better use of skilled resources. When routine monitoring is automated, security and network teams can focus on investigation, tuning, response, and other strategic, value-added work that requires human judgment.Wrap-upAutomated operational notifications represent the next step in Zscaler's Zero Trust Automation journey, extending OneAPI's programmatic reach from configuration and analytics to ongoing operational monitoring. By pushing the right signal to the right place at the right time, organizations can reduce complexity, respond faster, and free their teams to focus on higher-value work.To see automated notifications in action, watch this webinar that includes a demo. To get started with SDKs, code samples, and template playbooks, visit the Zscaler Automation Hub. And to see examples of use cases you can automate with OneAPI, read our latest ebook.

Data Leakage Through AI Prompts: 12 Realistic Examples (and Controls That Stop Them)

Matt McCabe (Senior Web Content Writer) — Mon, 18 May 2026 22:10:14 GMT

IntroductionEvery time an employee pastes text into a generative AI (GenAI) tool, uploads a file, or copies an artificial intelligence (AI)-generated response into an email, data is moving. Most organizations have controls in place for file transfers, email attachments, and web traffic. Almost none of them were designed to see what happens inside an AI prompt.That gap has a name: prompt data leakage. It is the accidental or intentional exposure of sensitive information through AI prompts, file uploads, or model outputs, where the exposure vector is conversational rather than transactional. A user asks a question, pastes a document, or copies a response, and sensitive data moves with it.The scale of what's moving through those blind spots is significant. ChatGPT alone generated 410 million data loss prevention (DLP) policy violations in a single year, a 99.3% year-over-year increase. Most of that activity looked like ordinary work: a developer pasting a function to debug, a marketer drafting copy against a tight deadline, an HR manager cleaning up a performance review.410 million DLP violations tied to ChatGPT in a single year, a 99.3% year-over-year increase. —ThreatLabz 2026 AI Security Report Get the full reportTraditional DLP tools were built to inspect files in transit. They were not built to classify what a user typed into a chat interface, flag what they attached to a model session, or catch sensitive data echoed back inside a response. Prompts, uploads, and outputs are all data movement. They just do not look like it to legacy controls.The scenarios, controls, and rollout guidance that follow are built around that reality. Where data leaks in AI workflowsAI-related data exposure does not come from a single entry point. It happens across three distinct vectors, and most organizations have meaningful gaps in at least one of them.AI risk doesn’t just come from models. It comes from exposed access paths, prompt-level data movement, and lateral movement across connected systems. Prompt text (copy/paste)The most common vector. Employees paste content directly into AI interfaces without a clear mental model of where that text goes.Common examples include:Personally identifiable information (PII), payment card industry (PCI) data, and protected health information (PHI)Credentials and API keysInternal strategy documents, source code, and contractsAttachments and uploadsFile-based exposure often carries more data in a single event than a pasted prompt. Uploads tend to contain structured data and can include entire datasets.Common examples include:Spreadsheets, PDFs, and presentationsCall transcripts and meeting notesScreenshots (a DLP blind spot worth naming explicitly, since image-based content bypasses most text-based inspection)Outputs and downstream reuseThis is the vector traditional controls miss entirely. Sensitive data does not have to leave through the prompt. It can leave through the response.Common examples include:Sensitive data echoed back in model outputsAI-generated content reused in external communications, policy documents, or customer-facing materialsHallucinated facts treated as validated information and passed downstreamThe scenarios that follow are organized across these three vectors. Some are obvious in hindsight, and others happen so routinely they rarely get flagged at all. 12 leakage scenariosScenario 1: Contract summary pasted into a public chatbotA legal team member pastes a vendor contract into a public AI tool to generate a plain-language summary.Example prompt: "Here's our vendor agreement. Can you summarize the key terms, obligations, and termination clauses in plain language? [full contract text pasted below]"Leak vector: Prompt/Attachment (if uploaded as PDF)Data at risk: Confidential commercial terms, counterparty names, financial obligationsMost effective control pattern: Block/IsolateRecommended enforcement: Inline DLP, cloud app control, browser isolationScenario 2: HR performance review rewriteAn HR manager pastes a draft performance improvement plan into a GenAI tool to improve the writing.Example prompt: "Can you rewrite this performance review to sound more professional? [employee name], [salary], current rating: needs improvement, flagged for potential termination."Leak vector: PromptData at risk: PII, employment records, compensation dataMost effective control pattern: Block/RedactRecommended enforcement: Inline DLP (PII detectors), app-level policy controlsScenario 3: Candidate resume uploaded to generate interview questionsA recruiter uploads a candidate's resume to a public AI tool to generate tailored interview questions.Example prompt: "I'm interviewing this candidate next week. Based on their resume, generate 10 technical interview questions." [resume attached]Leak vector: AttachmentData at risk: PII (name, address, employment history, education)Most effective control pattern: Warn/IsolateRecommended enforcement: Upload controls, browser isolation, inline DLPScenario 4: Customer contact list pasted for cleanupA marketing operations employee pastes a raw CRM export into a public chatbot to remove duplicates and standardize formatting.Example prompt: "Clean up this contact list—remove duplicates, fix formatting, and sort alphabetically. [list of customer names, emails, and phone numbers pasted below]"Leak vector: PromptData at risk: PII (customer contact data)Most effective control pattern: Block/RedactRecommended enforcement: Inline DLP (PII/contact data detectors), app-level policy controlsScenario 5: Sales Outreach Draft Using Raw CRM NotesA sales rep pastes internal account notes into a GenAI tool to draft a follow-up email.Example prompt: "Write a follow-up email for this prospect. They have a $2M budget, are frustrated with [competitor], and their decision deadline is end of quarter. Contact is [name], VP of IT."Leak vector: PromptData at risk: Confidential account intelligence, prospect PII, competitive positioningMost effective control pattern: Warn/RedactRecommended enforcement: Inline DLP, content classification, loggingScenario 6: Employee benefits and claims dataA benefits administrator pastes employee claims data into an AI tool to generate a summary report.Example prompt: "Summarize these employee claims for my monthly report. [employee names, claim types, diagnosis codes, and amounts pasted below]"Leak vector: Prompt/AttachmentData at risk: PHI, PIIMost effective control pattern: Block/IsolateRecommended enforcement: Inline DLP (PHI detectors), browser isolation, upload controlsScenario 7: Proprietary source code pasted for debuggingA developer pastes a proprietary function into a public AI coding assistant to troubleshoot a bug.Example prompt: "This function keeps returning null on the third iteration. Can you find the bug? [proprietary source code pasted below]"Leak vector: PromptData at risk: Proprietary source code, internal logic, IPMost effective control pattern: Block/WarnRecommended enforcement: Inline DLP (source code detectors), app-level policy, sanctioned coding tool allowlistScenario 8: Internal budget spreadsheet uploaded for forecastingA finance analyst uploads a departmental budget file to a public AI tool to build a forecast model.Example prompt: "Here's our Q3 actuals. Can you build a forecast model through end-of-year and flag any categories running over budget?" [spreadsheet attached]Leak vector: AttachmentData at risk: Confidential financial data, internal cost structuresMost effective control pattern: Block/IsolateRecommended enforcement: Upload controls, browser isolation, and inline DLPScenario 9: Product roadmap pasted for stakeholder summaryA product manager pastes an unreleased roadmap into a GenAI tool to create a stakeholder-ready summary.Example prompt: "Can you turn this into a clean one-pager for our leadership presentation? [internal roadmap with unreleased feature names, timelines, and pricing attached]"Leak vector: Attachment/PromptData at risk: Unreleased product plans, competitive intelligence, pricingMost effective control pattern: Block/WarnRecommended enforcement: Inline DLP, upload controls, app-level policyScenario 10: Draft patent uploaded for editingAn engineer uploads a draft patent filing to a public AI tool to improve the language before submission.Example prompt: "Can you make this patent draft clearer and more readable? Keep all the technical details intact." [draft patent attached]Leak vector: AttachmentData at risk: Unreleased IP, proprietary technical methodsMost effective control pattern: Block/IsolateRecommended enforcement: Upload controls, browser isolation, cloud app controlScenario 11: Live API keys pasted during integration troubleshootingA developer pastes a live API key into a public AI tool while troubleshooting an integration failure.Example prompt: "My API call keeps returning a 403. Here's my request with the auth header: Authorization: Bearer [live API token]. What am I doing wrong?"Leak vector: PromptData at risk: Credentials, API keys, authentication tokensMost effective control pattern: BlockRecommended enforcement: Inline DLP (credential/token detectors), hard block policy, loggingScenario 12: AI output reused in customer-facing communicationsAn employee pastes an AI-generated response directly into a customer-facing email or external document without reviewing it for accuracy or sensitive content.This scenario has no user prompt to inspect. The data left the environment inside the model's response, and traditional input-focused controls do not catch it.The risk here is twofold: Sensitive data echoed back in model outputs, and hallucinated facts passed downstream as validated information (in a customer communication, a policy document, or external-facing content)Leak vector: Output (downstream exposure)Data at risk: Sensitive data echoed in model response, hallucinated facts treated as validated informationMost effective control pattern: Content moderation/LoggingRecommended enforcement: Output inspection, content moderation policies, AI audit trail Controls that stop each scenarioThe right control depends on the data at risk and the workflow it lives in. Applying a hard block across every scenario creates friction that pushes usage toward tools that are harder to monitor. The goal is appropriate enforcement, not maximum restriction.Control pattern libraryAllow: The right response when approved AI applications are interacting with non-sensitive data. No intervention needed. Log for audit and move on.Warn: A coaching message surfaces before the user submits a prompt or upload. They acknowledge it and either proceed or stop. Most effective for first-time violations and lower-severity data classes where education matters more than enforcement.Block: A hard stop for high-severity data: credentials, regulated information (PII/PCI/PHI), unreleased plans, source code. The transaction ends and the policy violation is logged.Redact: Sensitive elements are automatically replaced before the prompt reaches the model (identifiable information swapped for placeholders, financial figures rounded, credentials masked). The user keeps working; the risk doesn't travel with them.Isolate: Browser isolation lets users access AI applications while cutting off the paths data usually escapes through (copy/paste, upload, download, and print are all disabled). The right pattern for regulated use cases where data cannot leave a controlled environment under any circumstance.See how Zscaler enforces these controls in practice.Core enforcement capabilitiesEffective enforcement across all twelve scenarios depends on controls that work together across every layer of the AI workflow.Prompt visibility: See and classify prompt content at scale. This is the foundation. Without it, every other control is operating blind.Inline DLP inspection: Detect and act on sensitive data in prompts and uploads in real time before the data reaches an external model.Cloud app control: Granular allow/block/warn/isolate policies applied by application, user, group, or risk category.Browser isolation: Isolate AI application sessions. Control cut/paste, download, and print without blocking access entirely.Content moderation: Enforce acceptable use policies on outputs. Off-topic, restricted, or harmful content caught before downstream reuse.AI audit trail: Log users, prompts, responses, and applications for investigation and compliance reporting. This is what proves the controls are working.Recommended policy starter setThese are the minimum viable guardrails for organizations at the beginning of an AI data protection program:Block credentials and API key patterns in all AI channelsInline DLP for PII, PCI, and PHI in prompts and uploadsIsolation for unsanctioned GenAI application categoriesWarn and coach for first-time policy violationsAllowlist for sanctioned AI tools, including Microsoft Copilot and other embedded AIExtend runtime guardrails to private AI applications and internally developed modelsThe starter set above gives you a defensible baseline. From there, policies should evolve as your AI application footprint grows and usage patterns become clearer. Phased rollout approachMost organizations cannot stand up full enforcement on day one. The following phased approach is designed to build coverage progressively, with visibility established before policy is applied.Phase 1: Visibility first (Week 1)Controls cannot protect what you cannot see.Discover all GenAI applications in active use across the environmentEnable prompt-level visibility and content classificationDefine "red data,” or the data classes that trigger hard enforcement: credentials, regulated data, source codeDo not apply enforcement policy yet. Understand the baseline first.Phase 2: Protect data in motion (Weeks 2–3)Deploy inline DLP for prompts using high-confidence detectorsApply upload controls and block or isolate by application category and data classConfigure department- and role-based policiesThis is where Scenarios 1 through 11 get covered. Scenario 12 (output-based exposure) requires a separate track.Phase 3: Optimize and scale (Week 4+)Expand coverage to additional applications and GenAI categoriesAdd automated coaching workflows for policy violationsRefine allow/block/redact thresholds by department and use caseExtend protections to private AI applications and internally developed models aligned with runtime guardrails capabilityOptimization is ongoing. As AI application usage evolves, policies need to evolve with it. What to monitor and measureMetrics only work if coverage is complete. Before tracking reduction trends, confirm the AI audit trail covers all in-scope applications, user populations, and data classes. Gaps in logging mean gaps in your risk picture.Adoption and exposure metricsCount of GenAI applications in use—sanctioned vs. unsanctionedCount of users interacting with GenAI, by departmentPrompt volume and upload volume over timeData protection metricsDLP violation count in prompts and uploads, by data type (PII, PCI, PHI, source code, credentials)Block vs. warn vs. redact ratesTop triggering detectors and policiesRisk reduction and productivity metricsSensitive prompt rate over time: The primary signal that risk is actually decliningRepeat-offender rate: An indicator of whether coaching and policy enforcement are changing behaviorMean time to policy deployment for newly discovered AI applications: A measure of how quickly governance keeps pace with adoptionAI-channel incident metrics: Tracked where logging coverage allowsDownward trends in sensitive prompt rate and repeat-offender rate are the clearest indicators that the program is working.Quick "safe prompting" checklistNo credentials or API keys in any promptNo regulated data (PII, PCI data, or PHI)Use placeholders instead of real identifiers: [CLIENT_A], [EMPLOYEE_B]Use sanctioned AI tools accessed through corporate accountsIf uncertain about data sensitivity: use browser isolation or skip the upload Securing AI starts with seeing itPrompt data leakage is not a user behavior problem. It is a visibility and enforcement gap—and it is one that existing controls were not built to close. The scenarios above are not edge cases. They are what happens when AI becomes part of daily work before security architecture catches up.The ThreatLabz 2026 AI Security Report maps the full scope of enterprise AI data exposure—the applications, the violation types, and the patterns security teams need to understand before they can act on them.Read the ThreatLabz 2026 AI Security Report

While You Embrace AI, Fix This Fast

Misha Kuperman (Chief Reliability Officer & GM) — Thu, 14 May 2026 18:15:01 GMT

IntroductionAI is here and enabling tangible, real-world use cases.Boards are talking about it. Teams are experimenting with and deploying it. Roadmaps are being rewritten around it.But there’s a hard truth most organizations are not always paying attention to:If your foundation isn’t secure, AI will amplify your risk, not just your capability.Much of the discussion around AI security focuses on models, data, and governance. That’s critical, but something foundational is often missed or brought to light too lateBefore you fully embrace AI and become fully operational with it, you need to answer two questions:What resources can be reached from the internet?What can move laterally in your enterprise?If you don’t control those two things, you will always be exposed to breaches. 1. If You’re Reachable, You’re BreachableAI doesn’t just introduce new capabilities, it also introduces new and faster ways to discover and exploit your infrastructure which can happen accidentally or maliciously.Agents, automation, and modern tooling can continuously scan and profile IT environments at machine speed. What used to take time, skill, and persistence now happens by default and is accessible to not only broad and skilled adversarial audiences but also unskilled but motivated ones.If your applications or infrastructure are exposed, public IPs, open ports, reachable services, they are not just available. They are visible, profilable, and targetable.This means:You are continuously being mappedYour posture is being analyzedYour weaknesses are being identified and exploited faster than everThe reality is simple:If something can be reached, it can be profiled. If it can be profiled, it can be exploited and breached, and that includes your AI models.Reducing the attack surface—namely, making AI models and applications invisible unless explicitly accessed—is no longer a best practice.It’s table stakes. 2. Lateral Movement Makes Small Problems BigEven in well-defended environments, initial access is rarely the end goal.It’s the starting point.In traditional attacks, lateral movement is what turns a foothold into a breach. Once inside your environment, attackers move across systems, escalate privileges, and expand impact.With AI, that risk doesn’t just remain, it accelerates.AI agents are dynamic. They connect to systems, interact across environments, and increasingly act with autonomy. Whether they’re running on endpoints, inside your infrastructure, or interacting with third parties, they create new and often unintended paths.If an AI agent is compromised or simply behaves in an unexpected way the ability to move laterally can turn a contained issue into a systemic one.Think of a clinical AI agent with access to patient Electronic Health Records, connected to labs, imaging systems, and billing platforms.Now imagine it gains access to more than it should, or simply takes a path no one anticipated, and starts touching records across patients, departments, or even external systems.Patient data doesn’t have to be “stolen” to be compromised. It just has to be exposed.This is the risk most organizations underestimate.Eliminating lateral movement is not about improving detection. It’s about removing the opportunity entirely. Zero Trust Changes the EquationThis is where architecture matters.Zero Trust is not a control layered on top. It’s a different way of designing connectivity.Zscaler’s Zero Trust Exchange is built on this simple principle:Nothing is trusted. Everything is verified. Access is explicit.There is no implicit network access like with firewalls or with flat networks. No broad connectivity to exploit.Instead:Applications are not exposed to, and therefore not discoverable from, the internetUsers, workloads, and agents connect only to what they are explicitly allowed to, for example the apps onlyEvery connection is verified, scoped, and continuously monitored and evaluatedCrosstalk is visible, and even failed attempts to communicate are immediately brought to attentionThe result is a fundamentally different security posture.Even if something goes wrong and an AI agent “finds a way”, the blast radius is drastically reduced:To a specific userTo a specific workloadTo explicitly allowed connectionsThere is no network to traverse. No hidden paths to discover. If alarms are blaring, remediation is immediate! This Is the Foundation for AIOrganizations that are moving quickly and safely on AI are not starting with models.They’re starting with architecture.They are:Reducing the attack surface by making your AI models invisible to the internet, so there is less to discover and exploitEliminating lateral movement in case your AI is compromised and behaves in an unexpected way, so issues cannot spreadDesigning for containment by default just in case, things go southThis doesn’t slow innovation. It enables it.Because once the foundation is in place, teams can experiment, deploy, and scale AI with confidence without exposing the broader enterprise.Alibaba IncidentWe are not just recommending you to protect your AI deployments, we are recommending it strongly as such a case happened recently with Alibaba. Read our blog here to know more about this incident.The Bottom LineAI will explore, connect, and find paths you didn’t expect or don't know exist.The question is not whether that happens. The question is whether your architecture assumes it will. Before you embrace AI at scale, address the foundation. Reduce what can be reached. Eliminate how things can move. Everything else builds on that. Before You Embrace AI, Fix This FirstAI is accelerating fast and so are the risks.Most security conversations focus on models and data. The bigger issue is much more fundamental: what can be reached can be breached and what can move laterally inside your environment can turn minor issues into major ones —intentional or accidental.If your applications are exposed, they can be discovered, scanned, and breached. If lateral movement is possible, a small issue can quickly become a systemic one, especially with AI agents that operate across systems.This is why leading organizations are focusing first on two things:Reducing the attack surface so nothing is reachable unless explicitly allowedEliminating lateral movement through Zero Trust architectureGet this foundation right, and AI becomes an accelerator.Get it wrong, and it amplifies risk.Read more.

Why You Can’t Miss Zscaler Digital Experience (ZDX) at Zenith Live 2026

Cynthia Tu (Sr. Product Marketing Manager, DEM) — Tue, 12 May 2026 23:26:37 GMT

When a major service like Microsoft Outlook goes down or a global ISP experiences a massive spike in latency, most IT teams are stuck in "war rooms" playing the blame game. As we’ve seen in recent high-profile outages, Zscaler Digital Experience (ZDX) customers didn’t have to guess, they had the "ground truth" at their fingertips, identifying the root cause in seconds while others waited for a status page to update.Come learn how to bring this same level of visibility and value to your organization in just a couple of days. Zenith Live 2026 is going all-in on ZDX! This year in Las Vegas (June 8–11) and Vienna (June 15–18), you’ll move from "I think it’s the network" to "I know exactly which local ISP is failing." What to Expect at Zenith Live 2026Zenith Live is the premier learning conference where experts converge, focusing on modernizing security with the AI Security Platform built on zero trust.Here is what we have lined up for the ZDX:The Keynote: Get ready for some game-changing announcements. We’re unveiling the future of digital experience monitoring, focusing on how AI and deep telemetry redefine the standard for enterprise productivity.ZDX Breakout Sessions: Add 5 deep-dive ZDX sessions to your agenda to learn how to master Device, Network, and App experience monitoring within a Zero Trust environment. You’ll walk away with actionable strategies to operationalize AI-powered troubleshooting and resolution, giving you the "how-to" details on identifying and remediating complex performance issues across your entire environment.Live Demos at the Booth: See the power of ZDX in real-time. Stop by our booth for deep dives on how to:Detect and troubleshoot "silent" device issues, like CPU spikes or disk failure, and resolving them with remote remediation before the user even opens a ticket.Get hop-by-hop visibility into last mile and intermediate ISPs to prove whether a slowdown is in the local Wi-Fi, a regional ISP, or the app itself.Capture the "ground truth" of every interaction and use deep-dive waterfall analyses to pinpoint the specific API call, third-party script, or oversized image that is degrading the user experience.In-Person Training: Want to become a ZDX power user? Join our hands-on training to master all things ZDX.Exclusive Giveaways: Join our sessions and visit the ZDX booth to learn how you can participate in our special event-only giveaways. ZDX Breakout Sessions: Your Deep-Dive AgendaWe’ve curated five essential sessions to help you master digital experience monitoring. Whether you’re just starting your journey or looking to operationalize at scale, we’ve got you covered.Day 1: Foundation and ValueSession 1: Ensure Zero Trust SASE Success: End-to-End Visibility and Faster RemediationDiscover how Zscaler Digital Experience (ZDX) measures digital experiences continuously for every user, anywhere, to keep users productive during Zero Trust adoption. It uses AI to correlate devices, Wi-Fi, ISP, Zero Trust Exchange, and application signals to pinpoint likely root causes faster via a natural-language interface.Session 2: Unlock ZDX Value: Best Practices to Deploy, Adopt, and Operationalize Learn how to deploy and operationalize ZDX to accelerate your Zero Trust adoption, all with a single agent. Learn activation, rollout, and best-practice policies/segments, plus alert tuning to cut noise. Get performance insights across Internet and Private Apps while maintaining security—and speed triage with actionable device, network, and application dashboards.Day 2: Innovation and RemediationSession 3: Master Zero Trust SASE Performance: Identify App and Network Issues with RUM and ISP InsightsGo beyond "the internet is slow" with ZDX. Learn how network insights—ASN visibility, ISP benchmarks, and path analytics with loss/latency/jitter—pair with app monitoring from 24/7 global data-center synthetics and Real User Monitoring "ground truth." Using lightweight Chrome/Edge extensions, ZDX pinpoints end user productivity issues in minutes, not hours or days.Session 4: Identify and Remediate Device Issues to Improve User Experience Connected to Zero Trust Device health impacts app experience in Zero Trust environments. Learn how ZDX Device Health Scores and Events correlate CPU and memory pressure, app crashes, BSOD, disk health, and security posture such as BitLocker and antivirus to SaaS and private app performance. See Device Remediation run remote scripts at scale to clear caches, restart services, run nslookup and ping, and cut tickets and MTTR.Session 5: What’s New with Zscaler Digital Experience: Agentic IT Ops for Faster Issue Resolution ZDX brings an AI-powered expert to every IT team member to accelerate troubleshooting and resolve complex performance issues. Join us for an exclusive look at the latest ZDX innovation, Agentic IT Ops. We’ll showcase how Zscaler’s AI agents tap into massive telemetry to not just find problems, but to proactively guide teams toward instant, data-driven resolution. Ready to Transform Your IT Ops?Don't let your Zero Trust journey be slowed down by silent performance issues. Join us at Zenith Live 2026 to see how ZDX turns telemetry into action.Register for Zenith Live 2026 and add the ZDX sessions to your agenda!

Shadow AI & Shadow AI Agents: Regaining Visibility and Control Over Public GenAI + Embedded SaaS Copilots

Matt McCabe (Senior Web Content Writer) — Mon, 11 May 2026 19:03:48 GMT

IntroductionArtificial intelligence (AI) is already part of how work gets done.Employees are using public GenAI tools to move faster, while SaaS platforms are rolling out copilots by default. AI is no longer a separate tool. It is being embedded directly into applications that were already trusted, which changes their risk profile overnight. At the same time, developers are integrating AI directly into their workflows.What most organizations have not kept up with is visibility.Enterprise AI and machine learning activity increased 83.3% year over year, and during that same period, organizations transferred over 18,000 terabytes of data to AI tools, a 92.6% increase.Most of that activity is happening outside the scope of existing security controls, not because teams are ignoring risk, but because existing security architectures were never designed to govern AI interactions.This is what defines shadow AI today. It is not just unsanctioned tools. It is the growing gap between how AI is actually being used across the business and what security teams can confidently monitor or control.Shadow artificial intelligence (AI) is the practice of employing advanced AI tools or AI applications without formal approval from an organization’s technology leadership. This often occurs when department heads or individuals seek quick fixes, like ChatGPT, beyond standard policies, ultimately raising data privacy and compliance concerns. What shadow AI looks like in modern workflowsIn most organizations, shadow AI is not isolated to a single category. It shows up across multiple layers of the business, often overlapping in ways that make it difficult to track.In practice, that footprint includes:Public GenAI tools accessed through browsers, apps, and extensionsEmbedded AI copilots inside software-as-a-service (SaaS) platforms already in useAI agents executing tasks across systems and maintaining contextDeveloper tools sending source code and system data to external modelsInternally developed AI systems, including models and datasetsEmerging infrastructure such as cloud AI platforms and Model Context Protocol (MCP) serversMany of these interactions rely on persistent protocols such as WebSockets and MCP, which traditional security tools were never designed to inspect or control. Each introduces a different type of data exposure, and together they create a much larger and less visible attack surface.What makes this challenging is how these tools interact with each other and with your data.Why AI agents change the security modelAI agents introduce a different kind of risk. Their behavior doesn’t align with how traditional security models were designed to operate.Most enterprise systems are built around discrete interactions. A user submits a request, receives a response, and the transaction ends. Security controls were designed to inspect that exchange and enforce policy at a single point in time.Agents change that model.They carry context across interactions, build on previous inputs, and continue operating over longer sessions. Instead of responding to a single prompt, they can execute a series of actions across multiple systems, often using delegated credentials and preconfigured access.That shift creates a different set of challenges:Sensitive data can accumulate across conversations, not just single promptsSessions remain active, which limits the effectiveness of transaction-based inspectionAgents can act autonomously, increasing the impact of compromiseAccess often spans multiple systems, expanding the blast radiusThe real concern is not just access, but unintended actions at scale when agents operate without clear guardrails. When something goes wrong, it does not stay contained. It moves across systems in ways that most governance models were not built to handle. The business impact of uncontrolled AI usageThe risks associated with shadow AI are no longer theoretical. They are showing up in measurable ways across both security outcomes and business impact.Organizations with higher levels of unmanaged AI usage are seeing an average of $670,000 in additional breach costs, according to IBM. In the same research, 20% of organizations reported experiencing a breach tied to shadow AI, reinforcing how quickly unmonitored usage can translate into real exposure.The impact comes from how AI is being used without sufficient control or oversight.IBM found that 97% of organizations that experienced an AI-related breach lacked proper access controls on those systems. At the same time, nearly two-thirds of organizations either have no AI governance policies in place or are still developing them.That combination creates a pattern: AI adoption is accelerating faster than the controls needed to manage it.The downstream impact tends to fall into a few consistent areas:Intellectual property exposure through developer workflows and internal documentationSensitive data compromise, particularly customer personally identifiable information (PII) and regulated informationNew attack vectors such as prompt injection and agent manipulationCompliance gaps as AI usage outpaces governance frameworksReputational risk from inaccurate or unsafe AI-generated outputsIBM’s findings reinforce how these risks play out in practice. In shadow AI-related incidents, customer PII was the most commonly compromised data type, affecting 65% of cases, while intellectual property was exposed in 40% of incidents. Many of these breaches also led to broader business impact, including operational disruption and increased security costs.The issue comes down to visibility and control, not how employees are using AI.Most employees are not trying to bypass policy. They are trying to work faster. The issue is that AI usage is happening in environments where visibility is limited and guardrails are either incomplete or missing entirely.You cannot govern what you cannot see. Building a complete AI asset inventoryBefore organizations can enforce policy or reduce risk, they need a clear understanding of where AI exists across the environment.This is where many programs fall short.An effective AI asset inventory goes beyond listing tools. It requires understanding how AI is used, how data flows through those systems, and where risk is introduced.Two foundational components help structure this:AI Bill of Materials (AI-BOM): A unified inventory of AI models, workflows, agents, MCP servers, and guardrails that provides a consolidated view of AI assets and how they are connected across the environmentAI Security Posture Management (AI-SPM): Identifies misconfigurations, excessive permissions, and vulnerabilitiesTogether, they provide a working view of the AI landscape rather than a static inventory.In practice, this means building visibility across four key areas:Workforce usage: Understanding how employees interact with AI tools, including both approved and unapproved usage, and how data is shared across those interactions.SaaS copilots: Tracking embedded AI features inside trusted applications, including what data they can access and how they are configured.Developer environments: Monitoring AI-powered integrated development environments (IDEs), command-line tools, and repository integrations that connect directly to external models and process sensitive code.Internal AI systems: Mapping models, agents, datasets, and infrastructure, along with identity and access controls that govern how those systems operate.Each layer introduces a different type of risk. Without visibility across all of them, governance remains incomplete. Governing AI without slowing it downBlocking AI access often creates more risk than it removes. When approved tools are restricted, employees turn to alternatives that are harder to monitor.A more effective approach is to define clear boundaries and enforce them consistently.That starts with clarity around what is allowed. Organizations need to define approved tools, acceptable use cases, and what types of data can be shared. When expectations are clear, employees are more likely to operate within them.At the same time, it is important to define what is not allowed. Certain applications and use cases introduce higher risk and need to be restricted or closely monitored, particularly in developer workflows and agent-based systems.Governance should also align with established frameworks. Common starting points include:National Institute of Standards and Technology (NIST) AI Risk Management FrameworkEU AI ActOpen Web Application Security Project (OWASP) LLM Top 10MITRE ATLAS (developed by the MITRE Corporation)International Organization for Standardization (ISO) 42001The goal is not to slow AI adoption. It is to make it scalable and defensible. Control patterns that scale across the enterpriseMany organizations try to address AI risk by layering point solutions across visibility, access, and testing. In practice, that approach increases complexity without closing the gaps between those controls. Effective AI security requires a coordinated set of controls that operate across multiple layers.At a high level, that system includes five core layers:AI asset visibility and inventory: A complete view of AI usage, assets, and risk across the environment—the foundation for every control that follows.Access and policy enforcement: Controls determine who can use which AI tools and under what conditions, using identity and context to make real-time decisions.Prompt and interaction visibility: Sensitive data is often typed directly into AI systems. Visibility needs to extend into prompts, responses, and full conversations.Data protection: In 2025 alone, enterprise environments recorded more than 410 million data loss prevention (DLP) violations tied to AI usage. Protection must cover prompts, uploads, and generated outputs as a single surface.Runtime and infrastructure security: Internally developed AI systems require continuous testing, monitoring, and posture management to address vulnerabilities and misconfigurations.These layers are most effective when they work together, creating consistent visibility and enforcement across the AI lifecycle. How Zscaler secures the AI lifecycleMost organizations approach AI security in parts, focusing on visibility, access, or testing in isolation. The challenge is that risk spans the full lifecycle, and gaps between those areas are where exposure emerges.Zscaler connects these capabilities within a single platform built on a zero trust architecture.It starts with visibility across AI usage, including public GenAI tools, embedded SaaS features, developer environments, and internally developed systems. Proven inline inspection at scale enforces policy on prompts, responses, and data in real time, while identity and context-based access controls govern who can use which tools and under what conditions.For internally developed AI, continuous testing and runtime protection extend coverage across development and production, helping organizations identify vulnerabilities early and adapt controls as systems evolve.The result is a more unified approach that reduces fragmentation and allows AI adoption to scale without losing control. This includes extending zero trust to AI agents: Ensuring that agentic workflows operate within defined boundaries, even as they interact across systems at machine speed.Enable AI safely, not slowlyAI is already embedded in how modern organizations operate. The question is not whether it will be adopted, but how it will be governed.The organizations that move ahead will be the ones that build visibility early, define clear boundaries, and implement controls that reflect how AI actually works across users, applications, and systems.That foundation allows teams to move faster without increasing risk.When visibility, governance, and protection are aligned, AI becomes something the business can scale with confidence.Explore how Zscaler enables secure AI adoption with visibility, governance, and runtime protection.