Zscaler’s AI offer focuses on protecting the way organizations use and build AI. AI Protect brings together discovery of AI assets, controls over employee interactions and protection for applications and infrastructure. Its value depends on coverage: the organization needs to know which traffic and resources the system can inspect, where policies are enforced and which channels remain outside that view. A broad dashboard is useful only when those boundaries are clear.
- 01The offer AI security connected to Zscaler’s zero-trust and data-security portfolio.
- 02The fit Organizations governing employee AI use and enterprise AI resources across an established environment.
- 03The scope Public-source research and a proposed rollout; vendor protection claims are not independent test results.
01 / ProductTreat discovery, access and application protection as separate jobs
The current AI Security page organizes the offer around AI asset management, secure access, application and infrastructure security, and an AI Gateway. That structure is useful because the risks differ. Discovering a model deployment is not the same action as blocking a sensitive prompt or testing an application before release.
AI Asset Management describes inventory and risk analysis for models, agents, services and connected data. It includes cloud AI environments and unmanaged model services. The reader’s question should be whether the relevant resource can actually be discovered and associated with its owner, permissions and data dependencies in the proposed deployment.
Secure Access to AI covers user-based access policies, prompt and response visibility, content moderation and inline data loss prevention. It presents warning, blocking and browser isolation as different responses. Those choices matter: allowing an approved task with constraints can have a different operational effect from blocking an application altogether.
02 / AudienceA fit for security teams enabling a real AI program
Zscaler is relevant when employees are already using AI across browsers, SaaS applications and developer tools, and the security team needs more than a list of approved brands. An application can be acceptable for public information while unsuitable for a particular internal dataset. A usable policy therefore considers the user, activity and data, not only the destination’s name.
The same organization may also build an internal AI assistant. That introduces another set of resources: retrieval stores, service credentials, model endpoints and tool connections. Discovery can help relate those resources, while runtime controls address interactions. The deployment plan should distinguish employee access from application-to-model traffic so one successful control is not mistaken for complete coverage.
The Palo Alto Networks blueprint provides another perspective on securing enterprise AI systems. The Cisco blueprint is relevant where network and security operations already form the purchasing context. Compare coverage of the actual AI channels and the work required to operate the policy, rather than broad claims that one portfolio secures everything.
03 / WorkflowA proposed rollout for an engineering team using AI tools
Start with one engineering group and a concrete policy: approved AI tools may assist with public documentation and permitted code, while restricted repositories and customer data require a different route. This proposed rollout tests whether users can complete legitimate work while sensitive material is handled as intended. It is not a claim that Sequenced tested Zscaler’s enforcement.
Inventory the group’s actual tools before enforcing a broad rule. Include browser applications, embedded assistants and development environments. Record whether each is company-managed or personally registered, who owns its approval and what data it receives. A discovered application with no owner is a decision to resolve, not simply an item to remove from a dashboard.
Define a small set of representative interactions. Use synthetic data that resembles the organization’s sensitive formats, approved sample code and public text. Include both permitted and prohibited examples. This lets the security team examine false blocking as well as missed detection, without exposing production secrets merely to demonstrate that a control exists.
Map each interaction to its enforcement point. A browser prompt, an uploaded file and an API request may travel through different paths. Ask the implementation team to show which policy sees each path and what evidence is recorded. If a channel bypasses inspection, document the gap and choose an appropriate compensating process before describing the rollout as complete.
Use warning or coaching for cases where the policy allows the user to correct the action, and blocking for defined prohibited transfers. Give employees a useful explanation and an approved next step. A policy that only reports failure encourages workarounds and leaves the security team unable to distinguish an accidental attempt from a legitimate task lacking a supported route.
Zscaler’s June 2026 AI Protect update describes multi-turn inspection, interaction replay, runtime enforcement and compliance API integrations. Evaluate the features available in the proposed tenant against the complete conversation, not only isolated prompts. Several individually ordinary messages may jointly reveal a sensitive context that a single-message test would miss.
For an internal coding assistant, separately inventory its service identity and connected repositories. Verify that a request from one user cannot retrieve material that user cannot access. Prompt filtering is useful, but the underlying retrieval and tool permissions still need to be correct. The assistant should not depend on a text classifier to compensate for an overprivileged backend account.
Review the results with both security and engineering staff. Measure which permitted tasks were interrupted, which sensitive transfers were stopped and whether investigators can reconstruct a policy decision. Preserve the policy version and test route. That record makes later changes to the tool, traffic path or detector easier to assess without repeating the entire rollout blindly.
04 / PricingConfirm the security modules and the billable scope
| Requirement | Published packaging context | Confirm in proposal |
|---|---|---|
| Platform access | Platform bundles and standalone offerings | Required base services and user scope |
| Data enforcement | Alert-only and inline capabilities are distinguished | Blocking entitlement for each AI channel |
| AI asset management | Demo-led product route | Supported environments and connectors |
| AI application controls | AI security portfolio | Runtime, gateway and testing components included |
Commercial scope from Zscaler pricing and plans and AI Security, consulted 23 September 2026. No public monetary AI Protect rate established.
Zscaler’s pricing and plans page describes platform bundles, advanced modules and standalone offerings. It does not establish a public currency-denominated AI Protect tariff in the consulted material. Request a quote for the required AI channels and controls, including the relationship to any existing platform or data-security subscription.
The important distinction is between observing an event and preventing it. The pricing page labels some standard data-security capabilities as alert-only while describing broader inline capabilities elsewhere. A proposal must identify the exact enforcement entitlement. A demo showing a sensitive prompt in a dashboard is not proof that the purchased configuration blocks it.
Budget for deployment and policy operation as well as licensing. The engineering rollout requires ownership of allowed tools, management of exceptions and investigation access. These may be performed internally or with a service partner. Make those responsibilities visible when comparing the total cost of maintaining useful AI access for the group.
05 / DistinctionsThe connection between inventory and enforcement is the useful distinction
Zscaler’s portfolio lets a buyer examine AI use alongside the access and data pathways already central to enterprise security. That can be useful when the organization needs to move from an application inventory to a decision about who may use it and what information may leave. The strength of that connection depends on the implemented traffic and identity architecture.
The AI asset-management material also links resources with data exposure and permissions. For an internal assistant, that context can matter more than a model name alone. A modest model connected to an overexposed repository may create a more immediate business problem than a more capable model restricted to public data. Prioritization should follow the actual access path.
The current AI Security page describes a gateway for governing AI transactions. Treat it as a distinct architectural decision: where requests pass, which identities are represented and what happens if that path is unavailable. Routing, inspection and application behavior need to work together. Security policy should be observable without turning every failure into an unexplained timeout for users.
06 / QuestionsAsk about coverage, inspection and evidence retention
Which precise interactions can be inspected in the intended environment? Confirm browser, application, API and agent-tool paths separately, including any encryption or integration prerequisites. The public pages describe broad capabilities but do not establish every tenant configuration. A coverage matrix with tested routes is more useful than assuming that detecting a destination means understanding all of its activity.
Who can see recorded prompts and responses, and how long are they retained? Interaction replay can help investigations while creating another sensitive dataset. Define investigator permissions, redaction and retention for the rollout. Security visibility should not give a larger audience routine access to information that the original AI policy was intended to protect.
How are newly announced controls enabled and licensed? The June update describes shipping enhancements, but the exact rollout and supported integrations should be confirmed for the purchased service. Ask for a demonstration using the organization’s intended tools. Avoid treating a product announcement or a framework mapping as proof of complete protection or regulatory compliance.
07 / DecisionBegin with a permitted task and prove the control path
Zscaler AI Protect is worth evaluating when a security team needs to enable AI use while understanding the associated data and access risks. Start with a defined group, a small set of legitimate tasks and explicit prohibited transfers. Then verify discovery, enforcement and investigation across the actual channels that group uses.
A successful first rollout would let engineers complete approved work and make exceptions understandable. It would also identify what remains outside coverage. Those results provide a practical basis for extending policy to more teams or internal agents, with each new path evaluated on its own evidence rather than inherited confidence.
Govern employee AI use
Pilot approved tasks and synthetic sensitive-data cases across actual tool paths.
Operate internal AI applications
Map models, service identities, retrieval data and tool access before adding runtime controls.
Only need an AI assistant
Select the user application separately; AI Protect addresses its security environment.
A business worth understanding.
Suggest your business or one you find interesting. Tell us what you want to understand about its product, positioning, design or workflows.
Suggestions are free. Selection and publication stay with the desk.
- Zscaler AI SecurityConsulted
- Zscaler AI Asset ManagementConsulted
- Zscaler Secure Access to AIConsulted
- AI Protect June 2026 updateConsulted
- Zscaler pricing and plansConsulted

