Skip to content
ZHERO Docs

Privacy and Data

ZHERO is a browser extension that reads your Zscaler tenant through your own authenticated session. The default is that your configuration stays on your machine. This page says precisely where the exceptions are, what each one carries, and how you turn them 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 and HAR analysisYour browser
The 30-day local audit store, including field-level diffsYour browser
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
URL lookup resultsA shared cache, anonymously, when URL lookup 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.

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

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 configuration genuinely leaves the browser, and only for changes you chose to share.

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 URL string and its standard Zscaler categorisation, which is identical for every customer
  • 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.

Error reports

When an error report is generated, personally identifiable information is detected and redacted before the report is sent.

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 by default, and not in bulk ever. The only 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.

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