Guides / Zscaler

Shadow AI detection from Zscaler web logs

Zscaler proxies the web session itself, so its logs carry full URLs and authenticated usernames. For shadow AI, that is the richest evidence any log source produces. Here is how to spend it.

Layer: proxy / SWG
Identity: authenticated user per transaction
Format: CSV web log export
Per-user table: yes, strongest of any source
Run a free audit on a Zscaler export
Proxy vs DNS

What URL-level evidence adds over hostnames

DNS logs prove a tool was reached. Proxy logs add who, how often, and how much moved. Both feed the same audit; Zscaler simply feeds it more.

A DNS log line knows

  • The hostname resolved, once per cache lifetime.
  • The identity, when a connector maps it.
  • Nothing about volume: one query can hide a four-hour session.

A Zscaler transaction knows

  • The full URL, which the parser reduces to a hostname before matching.
  • The authenticated username on every single transaction.
  • Real request counts, so hits approximate actual usage intensity.
  • Bytes up and down, if you keep those columns for your own follow-up.

Privacy note: the audit only uses the hostname and the identity. Paths, query strings and payload sizes never influence a verdict and never appear in the report, and the uploaded file is discarded after the run.

Worked scenario

An engineering org meets its code assistants

A 600-person software company, Zscaler in front of everything. Sample data, familiar outcome: the tools were not the ones IT had approved.

export

Platform team pulls 30 days of web logs filtered to allowed traffic: 380,000 transactions, 5.1 MB compressed to CSV essentials. Full-report territory, uploaded in one go.

match

44 AI tools surface. The approved list has 6. Code & Development alone shows 9 distinct assistants across engineering.

finding-1

Three unsanctioned code assistants carry heavy per-user traffic in the platform group, one of them with an opt-out training default nobody had flipped. Proprietary code has plausibly been pasted into consumer tiers for months.

finding-2

An agent-builder platform appears with API-shaped traffic from a build server's service account. Someone wired an LLM into CI without a review. The per-user table caught it because Zscaler logged the service identity.

decision

One assistant gets sanctioned on an enterprise no-training tier for everyone. The other two get blocked, and the CI integration gets a design review instead of a burial. The audit PDF is the artifact in all three tickets.

re-run

Same window, next month: blocked assistants show attempts only, sanctioned share up from 14% to 61%. That delta is the slide leadership sees.

The export

Which Zscaler log, and which fields

You want the web transaction log as CSV over your window. Conceptually it is the web log view in analytics; exact naming varies by console generation, and any CSV with a header row parses.

Keep these columns

  • Time: keeps the window verifiable and re-runs comparable.
  • User: the authenticated identity, the whole per-user table hangs on it.
  • URL or Host: either works; full URLs are reduced to hostnames automatically.
  • Action: allowed vs blocked, worth keeping for policy evidence.

Safe to drop

  • Bytes, latency, threat columns: fine to keep, ignored by matching.
  • Anything you consider sensitive beyond hostname and user. Slimmer files upload faster and fit tiers easier.
time,user,url,action "09:41:02","[email protected]","https://chatgpt.com/c/68f...","Allowed" "09:41:15","[email protected]","https://cursor.com/api/auth","Allowed" "09:42:07","[email protected]","https://api.langflow.org/v1/run","Allowed" "09:43:51","[email protected]","https://codeium.com/profile","Allowed" "09:44:12","[email protected]","https://github.com/org/repo.git","Allowed" "09:45:33","[email protected]","https://replit.com/@user/agent","Allowed"

Highlighted hosts match the register. Note the service account on line three: proxy identity catches non-human AI usage too.

Inspection nuances

SSL inspection changes counts, not conclusions

Zscaler deployments differ in how much they decrypt. All three configurations still feed a valid audit.

Full inspection

Every transaction logged with full URLs. Hit counts track real usage closely, and API subdomains show up distinctly.

Selective inspection

Uninspected sessions still log the hostname from SNI. You lose URL depth, which the audit does not need anyway.

Bypassed categories

Traffic in bypass lists may skip web logging entirely. Cross-check with a DNS export once a year; the methodology page covers multi-source audits.

Output

What the report returns for a Zscaler export

Proxy evidence lights up every section of the report, including the ones DNS sources leave thin.

Report sectionWith a Zscaler CSV
Summary tilesFull totals with risk, training and abusive-purpose counts.
Tool tableEvery matched tool; hit counts reflect real transactions, not cached DNS.
Per-user breakdownAuthenticated usernames per tool, including service accounts. The strongest accountability any source offers.
Sanctioned splitApproved list vs observed, per tool and per user.
Policy verdictsBlock / control / allow suggestions per tool under your chosen profile.
CSV + PDFBoth ship with the full report, ready for the risk register and the board pack.

The export is read once, matched in memory and discarded. Reports are stored 90 days in your account and deletable earlier.

Engineering-org reading

Three patterns to look for in a developer-heavy report

Engineering networks produce distinctive shadow AI signatures. These are the ones worth a second look.

The assistant sprawl

  • Multiple code assistants with overlapping users means individuals are comparison-shopping with your codebase.
  • Consolidating onto one sanctioned enterprise assistant is usually the cheapest fix in the whole report.

The service-account tell

  • AI hostnames reached by svc- or build accounts mean a pipeline integration exists.
  • Those need architecture review, not blocking: breaking CI unannounced turns the audit into the villain.

The model-hub long tail

  • Model hosting and framework domains suggest local experimentation beyond SaaS chatbots.
  • Usually low headcount, high sophistication: a conversation with those two engineers beats any policy memo.

Flip through a real report before you upload anything

The sample evidence pack shows every section a Zscaler export fills: tiles, verdicts, the per-user table with a service account in it.

Open the sample PDF
After the audit

Turning verdicts into Zscaler policy

The report's three verdict groups map onto three pieces of configuration work, then one verification run.

Block and control

  • Block-verdict domains go into a custom URL category attached to a deny rule.
  • Control-verdict tools stay allowed while procurement moves users to enterprise tiers; some teams add a warn-page interstitial meanwhile.

Verify next month

  • Re-export the same window length and re-run. Blocked tools should show zero allowed transactions.
  • Persisting allowed hits mean a bypass list or split tunnel is leaking, which is a finding your next report documents for free.

Monthly re-runs are what plan allowances are for; packs work for one-off engagements. Both are on the pricing page, and the free tier detail is on the free audit page.

Numbers literacy

Reading proxy hit counts without fooling yourself

Zscaler's transaction counts are the most honest of any source, but three effects still distort them.

Chatty apps inflate

A chat tool polling every few seconds racks up transactions while idle. Compare tools by user count first, hits second.

CDNs deflate

Tools serving their app from a generic CDN log fewer transactions on their own domain. The auth and API hostnames still give them away.

One power user skews

A single heavy user can put a niche tool near the top by hits. The per-user column keeps the ranking honest.

Rule of thumb for proxy reports: rank by users for policy decisions, rank by hits for capacity and procurement conversations.

Sizing

Will your export fit? Planning by org size

Proxy logs are bulkier than DNS. Column discipline matters more here than anywhere else.

Org sizeA month of web log, trimmed to 4 columnsRecommended path
Under 100 usersTens of thousands of lines, a few MBFull report directly; a filtered week fits the free preview.
100 to 1,000Hundreds of thousands of linesFull report, filter to allowed traffic, drop byte columns.
1,000 to 5,000Millions of transactionsTwo-week window, or sample one representative week per month.
5,000+Beyond single-file capsAsk us: larger exports are handled on request as a custom run.

Trimming that never hurts

  • Keep time, user, host, action. Everything else is optional weight.
  • Filter to allowed if you must choose: exposure lives in allowed traffic.

Trimming that does hurt

  • Do not filter to an "AI" category before uploading. You would only find what Zscaler already knows, which defeats the audit.
  • Do not drop service accounts. They carry the most interesting findings in engineering shops.
Roles

Who does what in a Zscaler shop

The audit crosses three desks. Knowing the handoffs beforehand keeps it a one-week exercise.

Zscaler admin

Owns the export: window, columns, filter to allowed. Fifteen minutes of console work, and later owns the URL-category changes the verdicts call for.

Security lead

Runs the upload, reads the report, drafts the sanction/control/block split. Presents the tiles to leadership with the annotated tour as a reading guide.

Engineering management

Owns the conversations the per-user table starts, especially assistant consolidation and the CI integrations that deserve review rather than blocking.

FAQ

Zscaler export questions

Which Zscaler log does the audit want?

The web transaction log as CSV with time, user and URL or host columns. Any header-row CSV parses automatically.

Do full URLs expose sensitive paths?

Paths are stripped to hostnames at parse time, never matched, never shown in the report, and the upload is discarded after the run. Exporting a host-only column is equally fine.

We tunnel some traffic outside Zscaler. Blind spot?

Bypassed traffic misses web logs, yes. Run a DNS-source audit occasionally as a cross-check; the Umbrella guide covers that shape.

How big will a month of logs be?

Developer-heavy orgs generate a lot of transactions. Filter to allowed traffic and drop unneeded columns; the full report takes 2,000,000 lines or 25 MB, larger on request.

Will API and service-account AI use appear?

Yes. Proxied API calls carry hostnames and the authenticated service identity, which is how CI-embedded AI gets caught.

Does the audit replace Zscaler's own AI app controls?

No, it feeds them. The report tells you which tools to put into which rule, with dated training verdicts your change ticket can cite.

Scope note

Internet traffic is the audit's lane

Zscaler deployments often carry both internet security and private access. Only one of them matters here.

Internet web logs: yes

  • SaaS AI tools live on the public internet, so the internet transaction log is the audit's raw material.
  • This is also where consumer tiers, personal accounts and free trials show up.

Private access logs: no

  • Traffic to internal apps has no AI SaaS hostnames to match, so exporting it adds size without signal.
  • Exception: if you self-host models internally, inventory those separately; a hostname audit measures external exposure.

Multi-source truth: proxy logs for depth, DNS logs for breadth, one audit each, compared side by side. Teams running both catch bypass gaps the same week they appear. Start with whichever export is one click away today.

Your proxy already logged the answer

Export a window, upload it, read the totals free. The per-user table is where engineering orgs find their surprises.

Run the free audit