Skip to content
ZHERO Docs

Privacy and Data

ZHERO is a browser extension. Zscaler is called only from your browser, with your own console session. ZHERO’s servers hold no Zscaler credentials and cannot read or change your tenant.

Your configuration and logs are analyzed in your browser and stay there. With Team Collaboration on, what you choose to share with your team (shared pending changes, comments, to-dos, score history) is stored in ZHERO’s cloud. This page says precisely what reaches ZHERO’s servers, what each item carries, and how you turn the optional parts on and off.

If you are filling in a security questionnaire about ZHERO, this is the page to read.

The short version

DataWhere it lives
Your Zscaler configurationYour browser
Analysis findings and the posture scoreYour browser
Your personal pending changesYour browser
Troubleshooting sessions, log investigations and HAR analysisYour browser
ZIA and ZPA logs read by ZHEROYour browser
OneAPI credentialsYour browser
The 30-day local audit store, including field-level diffsYour browser
Licence, tenant and administrator details, usage dataZHERO servers, always
Collaboration tags, comments and to-dosZHERO servers, after an explicit tenant opt-in
Changes you promote to the team queueZHERO servers, and they carry that change’s configuration
Audit entries for executed changesZHERO servers, as a reference only: which entity, never how
Posture score history and shared ignoresZHERO servers, only with Collaboration on
Domains looked up and their standard categoryA shared cache, anonymously, when the sync is enabled

What never leaves the browser

  • Your configuration at large. Entities, policies, profiles, criteria. ZHERO reads them through your session and analyses them locally.
  • Analysis results and the posture score. Computed in the extension, from local data.
  • Your personal pending-changes queue, until you deliberately share a change with your team.
  • Troubleshooting sessions, stored locally, and HAR analysis, parsed entirely in the browser and never uploaded.
  • The local 30-day audit store, which is where the field-level before-and-after diffs in the audit timeline come from.
  • Zscaler audit log entries shown in that timeline: read locally, or fetched live from Zscaler through your own session.

What always reaches ZHERO’s servers

These are needed to run the licence and the product, with or without Collaboration:

  • Tenant and licence data: customer name, tenant identifier and type, cloud, user count, licence dates
  • Administrator details: name, e-mail, username and role, as shown by your console session
  • Usage data: sessions, number of interactions, extension version
  • Your acceptance of the terms

None of these carries your configuration. And none of them gives ZHERO a way into your tenant. Zscaler is called only from your browser, with your own console session. ZHERO’s servers hold no Zscaler credentials and cannot read or change your tenant. Nothing is written to Zscaler until an administrator reviews a change in the pending changes queue and presses Execute, from their own browser, with their own rights.

Collaboration: the explicit opt-in

Collaboration is off until a tenant admin enables it, and enabling it requires accepting a disclaimer that lists the data involved. See Enabling Collaboration for the flow.

Stored on ZHERO servers when Collaboration is on:

  • Entity type and entity ID, the Zscaler internal identifier
  • Tags you create, with name and colour
  • Comments you write
  • Shared to-dos: title, description, due dates, lists
  • Assignee names you type for to-dos, including people who have no ZHERO account
  • Audit logs of tag, comment and to-do changes, recording entity type and ID only, never configuration
  • Changes you explicitly promote to the team queue, which carry that change’s entity configuration so your team can review and execute it
  • Posture score history and shared ignores, with the reason given for each ignore; per check only its severity, counts and state, never the entities. With Collaboration off, the score is still computed and shown, but nothing about it is stored

Not stored:

  • Your Zscaler configuration at large, other than the shared changes above
  • Before and after snapshots of executed changes
  • Credentials or API keys
  • Traffic logs or analytics data

Two things are worth stating plainly. First, a tag or comment on its own is a reference: an entity type and a numeric identifier, which means nothing without your tenant. Second, the shared change queue is the one place where an entity’s configuration leaves the browser, and only for changes you chose to share. The other thing that comes from your configuration is the list of domains in the shared URL cache.

Collaboration data is strictly tenant-isolated: only members of your tenant group can see it.

Reference-only cloud audit

Audit entries for executed changes, stored in the ZHERO cloud, record which entity changed and never how. No Zscaler configuration snapshots are kept server-side. The visual diff you see on such an entry is rendered from your local 30-day audit store, which never leaves the browser.

URL lookup and the shared cache

URL lookup uses Zscaler’s OneAPI to categorise the URLs in your configuration. It is off by default, and turning it on requires reading and accepting its conditions.

Why a shared cache exists. Zscaler’s API allows roughly 400 calls a day at 100 URLs per call, and tenants commonly hold tens of thousands of URLs. Worse, each administrator’s local cache is separate, so a team of three can spend the quota three times on the same URLs. Enabling URL lookup therefore also enables anonymous synchronisation of lookup results with ZHERO’s servers, so one lookup serves everyone.

What crosses that boundary:

  • The domain, without protocol, wildcards or path, and its standard Zscaler categorisation, which is identical for every customer. The domains come from your own categories and policies, which is why this page describes the cache precisely
  • Nothing else: no tenant identity, no credentials, no configuration, no metadata that ties a URL back to you

What is filtered out by design: your tenant’s custom URL categories. Zscaler gives admin-defined categories identifiers of the form CUSTOM_nn, which mean different things in different tenants. They are stripped from anything entering or leaving the shared cache, in both directions. Locally, lookups from your own OneAPI call keep their custom categories in full, for the interface and the analysis.

Lookup results are cached for 30 days.

You can turn the sync off. In the URL lookup settings, the anonymous synchronisation checkbox can be cleared, in which case you use your own API quota exclusively, which exhausts faster.

Feature flags

Feature flags come from LaunchDarkly. To decide which features are on for you, it receives the administrator profile (e-mail, name, username and company) and tenant-level context (customer name, tenant identifier and type, licence status), plus the extension version. It never receives configuration data.

Error reports

When an error report is generated, IP addresses, e-mail addresses, URLs, phone and card numbers and credential fields are detected and replaced before the report is sent. Reports identify the ZHERO account that sent them. The same applies to feedback sent from the extension: its message and the diagnostic logs you choose to include are redacted in your browser before sending. The name and e-mail in the feedback form are sent as typed, so we can reply, and files you attach yourself are sent as they are. Redaction works by pattern, so names you gave to Zscaler objects, such as policy names, can still appear.

Your Zscaler session

ZHERO works through your existing authenticated console session and your admin role. It never asks for your Zscaler password. Two consequences follow:

  • What you can see, ZHERO can see. A restricted admin role limits ZHERO to the same objects.
  • When your session expires, the extension icon shows an orange ”!” badge, and features that need the tenant wait until you log in again.

OneAPI credentials, where you configure them, are stored for the extension’s use and validated up front for the roles the features need.

Handling sensitive files

Two things you bring to ZHERO deserve care on your side:

  • HAR files capture a browser session, including cookies and headers. ZHERO parses them locally and uploads nothing, but the file itself is sensitive: treat it as you would a credential.
  • Excel exports contain your configuration, and some carry credential-adjacent columns such as policy and machine tokens. They leave ZHERO’s control the moment they land in your downloads folder.

FAQ

Does ZHERO send my Zscaler configuration to its servers? Not in bulk, ever. Your configuration and logs are analyzed in your browser and stay there. The only entity configuration that reaches ZHERO’s servers is the content of the individual changes you deliberately promote to the team queue, and only when Collaboration is enabled for the tenant; the shared URL cache holds domains with their standard category, without your tenant’s identity.

Can ZHERO’s servers reach my tenant? No. Zscaler is called only from your browser, with your own console session. ZHERO’s servers hold no Zscaler credentials and cannot read or change your tenant.

Can ZHERO staff read my tenant data? The data stored server-side is what the collaboration disclaimer lists: references, annotations, and the shared changes you promoted. It is tenant-isolated. Everything else remains in your browser.

Is the shared URL cache traceable back to us? No. It is keyed by domain and carries only Zscaler’s standard categorisation, which is the same for every customer. No tenant identity is attached, and your custom categories never enter it.

Can we use ZHERO with the shared cache disabled? Yes. Clear the anonymous synchronisation checkbox in the URL lookup settings, or leave URL lookup off entirely. The rest of ZHERO is unaffected.

Where are the local stores, and what happens if I clear my browser data? They live in the extension’s local storage in your browser. Clearing browser data removes your personal pending-changes queue, your troubleshooting sessions and the local audit store. Shared collaboration data is unaffected, because it is not local.

What is in the legal documents? The terms are published at help.zhero.ai/legal, and the console asks you to accept them before it initialises.