Shadow AI Discovery

Shadow AI is the usage an organization cannot see: an employee pasting a customer list into a public chatbot from a managed laptop. It does not appear in gateway logs, because it never went through the gateway. AgentWatch closes that gap.

What is the shadow AI problem?

Public AI assistants are reached directly over the browser, so they bypass any API gateway an organization has deployed. The result is that the most sensitive AI usage in the company is often the least visible: no record of what was shared, no policy applied, no attribution to a person, and no evidence for a regulator asking whether customer data left the environment.

How does AgentWatch discover it?

Through a lightweight endpoint agent deployed to managed devices, shipped as signed installers for macOS, Windows, and Linux and running as a managed system service. On the device it inspects traffic destined for known public AI services and reports it to the central gateway. Crucially, this works without requiring a corporate proxy — the usual blocker on shadow-AI visibility for remote and hybrid workforces, where traffic never traverses the corporate network.

For environments that do route traffic centrally, network-level steering is also supported, and AgentWatch integrates with existing corporate proxies and CASBs such as Zscaler, Forcepoint, and Netskope.

What does it show you?

• Which public AI tools are in use, across the managed fleet.
• Who is using them, mapped to an employee identity and a device.
• What is being shared — including risky document uploads — with the same DLP categories used on gateway traffic.
• Full conversation records where policy permits, subject to DLP redaction.
• Fleet health, so you know which devices are covered and which are not.

Can I see every host an endpoint talks to, not just the AI ones?

Yes, from 2.0.302, and it is off until you switch it on.

By default an endpoint only reports hosts that already look like AI — a known vendor, or a name suggestive enough to be worth sampling. Anything else is discarded on the machine and never sent. That keeps the data minimal, but it means a tool on a neutral domain is invisible: if the hostname gives nothing away, nobody learns the machine contacted it. Tools like LM Studio, Antigravity or an in-house endpoint on a plain corporate domain fall in exactly that gap.

Turn on host inventory. In Settings → Compliance, tick Shadow AI host inventory. Endpoints then report every host they resolve. View it under Observe → Fleet, in the Endpoint host inventory panel: hostname, how many lookups, how many distinct endpoints saw it, when it was last seen, and whether it is already being captured.

What is and is not collected

Collected	Hostnames and counts — api.example.com, seen 40 times, on 3 endpoints
Not collected	URLs, paths, query strings, headers, request or response content
Never collected	Banking, health, government and adult categories, plus any host you add — these are excluded on the endpoint and never transmitted

That last row is the important one. The exclusion happens before the hostname leaves the machine, so “we never saw it” describes what was collected, not what we chose to keep. You can extend the list with your own hosts (for example payroll.acme.internal) in the same panel; matching is on label boundaries, so acme.com covers hr.acme.com but not notacme.com.

Finding tools whose domain tells you nothing. Inventory shows you that a host was contacted, not what it is. Also identify tools by traffic shape goes further: unknown hosts are briefly sampled to see whether their traffic looks like an LLM API, and anything that does is promoted to full capture automatically.

⚠ This has a real cost, so it is a separate switch. Sampling briefly routes a host through the local proxy. An application that pins its TLS certificate will fail for that moment — once. The result is remembered on disk, so the host is never sampled again, including after a restart or reboot. Sensitive categories are never sampled at all. If you support users who cannot tolerate a single failed request in a pinned app, leave this off and promote hosts from the inventory by hand instead.

Then capture what matters. A host in the inventory is only observed. Once you decide a host is an AI tool, promoting it to full capture gives you the thing inventory deliberately does not: URLs, prompts, responses, DLP and guardrail enforcement — and it appears in Usage Insights like any other gateway traffic.

Why can’t it just capture everything?

Because interception is per-host by design, and the two ways of doing it both have hard limits.

Redirect-based capture rewrites name resolution for hosts AgentWatch knows about; there is no wildcard for “every host”, and there could not be one that behaves safely. Capturing all TLS on a machine would break every application that pins its certificate — banking apps, chat clients, many installers and updaters — and would decrypt personal traffic that has nothing to do with work.

So the model is deliberately two-stage: see everything (hostnames, no decryption, sensitive categories excluded), then capture deliberately (per host, with full content). Inventory plus shape detection is what closes the gap that “capture everything” was reaching for, without the collateral damage.

Can policy be enforced, not just observed?

Yes. Captured traffic runs through the same DLP, guardrail, and audit pipeline as API traffic, so sensitive uploads can be blocked or redacted rather than merely recorded. AgentWatch also supports an account identity policy: administrators define which AI accounts employees may use on managed devices — a corporate account rather than a personal one, for example — with dry-run testing of a policy before enforcement, an exemption list for legitimate cases, and a decision log of every enforcement outcome.

How is the endpoint fleet managed?

Devices enroll through a token exchange and then check in on a heartbeat carrying version and health. Administrators can list enrolled devices, view coverage and version distribution on a fleet health view, send actions (restart, update, disconnect), deauthorize a device, and apply bandwidth limits. Device-to-gateway communication is mutually authenticated with certificates.

Does it work for servers and containers too?

Yes. The same agent runs in a sidecar mode designed for Kubernetes pods and Linux virtual machines, exposing explicit proxy endpoints that workloads opt into — used for governing AI traffic from applications rather than from people. It reports Kubernetes node, pod, and namespace context, and fails open, so a workload never blocks on AgentWatch being reachable. See Agent fleet and insider risk.

How do I roll this out?

Do it in the order below; each step stands alone, and you can stop after any one of them and still have gained something.

1. Pilot on a handful of devices. Install the agent (see endpoint enrollment) on a few laptops, including one of your own.
2. Observe only, first. Leave DLP in warn for this traffic. Let a week of real usage accumulate before you enforce anything — the list of tools in use is usually the surprising part, and it is the argument for the rollout.
3. Turn on content inspection once the certificate trust is confirmed on the pilot devices.
4. Enforce, starting with the one category you care most about (usually secrets or customer PII) rather than everything at once.
5. Widen to the fleet by MDM.

How do I confirm it is actually capturing?

On a pilot device, open a public AI assistant in a browser and send a harmless message. Within seconds it should appear in Usage Insights attributed to that employee, with the tool identified.

If it does not, the fastest discriminator is whether you see nothing at all or traffic with no user:

What you see	Cause	Fix
Nothing at all	Interception is off, or the trust anchor is missing	agentwatch-connect status on the device; re-run the installer elevated
Traffic, no user	The device has no identity, or the address is unknown here	Set the enrollment identity, or enable Auto Create Users
Traffic attributed to the organization only	DNS steering with no agent	Install the agent for per-person attribution
A tool you expected, missing	Not in the known-services list, or it uses a transport that is not steered	Check discovery; some clients use WebSocket transports that are deliberately not redirected

What can I do about what I find?

The same policy engine as the API path: warn, redact or block, per category. A sensible first enforcement is to block secrets outbound to public assistants while leaving everything else advisory — it is the finding that most often justifies the programme, and the least likely to generate complaints.

Personal accounts are a genuine limit worth stating to stakeholders up front: activity from an address that does not exist in your directory cannot be mapped to an employee, though it is still visible, still policy-checked, and still attributed to the device.

Sources and references

• Policy engines applied to captured traffic: Data protection and guardrails.
• Fleet deployment options: Deployment.