Amar Jeer

Why ZTNA Can't Govern Shadow AI (and On-Device Can)

July 16, 2026

MIN READ

Why ZTNA Can't Govern Shadow AI (and On-Device Can)

Short answer: ZTNA was built to connect users to private apps behind your network. Shadow AI is the opposite problem: employees reaching public AI services in the open internet, often with personal accounts, from any app on their machine. Those sessions never touch the ZTNA broker, so ZTNA has nothing to govern them with. On-device Fly Direct sits at the endpoint, where every AI request begins, which is the only place to see and control shadow AI.

ZTNA and shadow AI are aimed in opposite directions

ZTNA points inward. Its whole job is to give a remote user secure access to a private application that lives behind your network or in your cloud. The connector sits next to that app. The broker mediates the connection. Everything about the architecture assumes the destination is yours.

Shadow AI points outward. An employee opens ChatGPT, Claude, or Gemini in the open internet, frequently on a personal account, and pastes in whatever they're working on. That traffic isn't going to a private app behind a connector. It's going straight to a public service. There's nothing for the ZTNA broker to mediate, because the destination was never in ZTNA's scope.

This is a directional mismatch, not a tuning problem. You can configure ZTNA perfectly and it still won't see a personal ChatGPT session, because that session was never headed for one of your protected apps. The tool is pointed at your network. The risk walked out to the internet.

The scope gap, stated plainly

This isn't a knock on ZTNA doing its job badly. It's a category mismatch. A tool designed to broker access to your internal apps is not the tool that governs your users' use of external SaaS and AI. Asking ZTNA to control shadow AI is like asking the building's access badge system to manage what employees post on their home computers. Different problem, different place.

The numbers make the gap concrete. The average company uses 10x more AI tools than IT approved, and 77% of employees have already leaked sensitive data through tools like ChatGPT. Almost none of those tools are private apps behind a connector. They're public services, reached directly, from personal and corporate accounts alike. Our complete AI governance guide maps the full scope.

The three jobs shadow AI governance actually needs

Governing shadow AI takes three capabilities, and a private-access broker provides none of them for public AI:

Discovery. You have to see which AI tools are in use and tell personal accounts apart from enterprise-licensed ones. A broker only logs sessions to apps it fronts, so public AI use is invisible to it.

Account control. You have to allow the sanctioned enterprise tenant while blocking personal logins at the same service. That requires seeing which account is being used inside a session to a public domain, which a broker aimed at private apps never inspects.

Data protection. You have to inspect the prompt and the upload and stop sensitive content before it reaches the model. That requires content inspection at the point of use, not access mediation to a private app.

Each of these needs an enforcement point that sees the user's outbound traffic to the open internet. ZTNA's enforcement point sees inbound access to your apps. Wrong vantage, by design.

Why the endpoint is the right place

Every AI request, whether it's a browser tab, a desktop app, an IDE assistant, or a script, starts on the user's device. That makes the device the one enforcement point that sees all of it, regardless of destination. Fly Direct runs there. It discovers which AI tools are in use and separates personal accounts from enterprise-licensed ones, restricts tools to approved enterprise tenants with Cloud Application Control, and inspects prompts and uploads with on-device Dopamine DLP.

That's three layers of AI governance a broker can't provide because the traffic never reaches it. The full picture is in how to see and control generative AI and the Manage AI overview. And because the enforcement runs at the operating system layer, it covers the AI that lives outside the browser too: desktop clients, IDE assistants, and scripts hitting an API, all of which a browser-bound or network-bound control tends to miss.

Browser extensions and enterprise browsers fall short too

If ZTNA is the wrong tool for shadow AI, the next two candidates teams reach for have their own ceilings, so it's worth being clear about them. A browser extension can see AI use inside the browser it's installed in, which is genuinely useful, but its visibility ends at the browser boundary. It can't see ChatGPT Desktop, Claude Desktop, an IDE assistant, or a script hitting an API, and a user can switch to a second, unmanaged browser and step around it entirely.

An enterprise browser governs only the activity that happens inside that browser, which means it only works if you can force all AI use through it. You can't. Both approaches share ZTNA's core limitation from a different direction: they don't sit at the layer where all AI traffic converges. The endpoint's operating-system networking layer does. That's why on-device enforcement covers browser tabs and native clients alike, and why it's the vantage point that doesn't develop a fresh blind spot every time AI shows up in a new kind of app.

The pattern will repeat

Shadow AI is the current example, but the underlying shift is bigger: risk has moved from private apps behind your walls to public services on the open internet. SaaS did this first. AI accelerated it. The next wave, agentic tools and AI features embedded inside apps you already use, will push more sensitive activity to destinations that were never yours to gate.

Any architecture whose enforcement point only sees traffic bound for your own apps will keep missing the destinations that matter most, and it will keep missing them by more each year. On-device enforcement doesn't have that blind spot, because it sees the request at the source no matter where it's headed. The vantage point that's right for shadow AI today is the one that stays right as the destinations keep multiplying.

The honest scope

If you have private apps to protect, keep ZTNA for that job; it's the right tool for brokering that access. The point is that ZTNA and AI governance are different problems with different enforcement points, and no amount of ZTNA configuration turns a private-access broker into a shadow AI control.

For AI, put enforcement on the device, where every request begins and every account and prompt is visible. Compare the options in our best shadow AI governance tools guide, and see the on-device approach applied to specific vendors in the Zscaler AI governance comparison.

Frequently asked questions

Can ZTNA block personal ChatGPT? Not meaningfully. Personal ChatGPT is a public service reached over the open internet, not a private app behind a ZTNA connector, so the broker isn't in that path. On-device Cloud Application Control can allow the enterprise tenant and block personal accounts.

Is shadow AI an access problem or a data problem? Both. You need to control which AI tools and accounts are allowed and inspect what's sent to them. On-device enforcement does both in one place; ZTNA does neither for public AI.

Do I have to replace ZTNA to govern AI? No. Keep ZTNA for private app access if you use it. Add on-device enforcement for the web, SaaS, and AI plane where shadow AI actually lives.

Why can't a broker see shadow AI use? Because a broker only mediates access to the private apps it fronts. Traffic to public AI services goes straight to the internet and never reaches the broker.

Does on-device cover AI outside the browser? Yes. Because it enforces at the OS networking layer, it sees desktop AI clients, IDE assistants, and scripts, not just browser tabs, when the traffic is decryptable and the app is supported.

Will this problem get worse over time? Likely, as agentic tools and embedded AI features push more sensitive activity to public destinations. An endpoint vantage point stays valid as the destinations multiply; a private-app vantage point does not.