Skip to main content
Shadow AI is the AI a workforce reaches without approval: the personal ChatGPT tab, the AI writing assistant someone expensed, the inference host a team wired into a side project, the automation platform quietly relaying customer records through an LLM step. The DLP agent already sits on the network path of every managed laptop. Shadow AI discovery uses that position to answer a question that comes before enforcement: which AI services is this company actually using? Detection is passive. Agents read the destination hostname of each outbound TLS connection (the SNI) and report a per-host rollup. They do not decrypt, and they never see the prompt.
Discovery is usually the opening wedge of a DLP rollout. Run the agents in observe mode for a week, look at the inventory, and you have an evidence-backed list of what to sanction, what to block, and what to onboard, before you enforce anything.

​
Discovery vs inspection

The agent handles two classes of AI host differently. Both are driven by the same host rules, which carry an action. A host that is already inspected is not shadow AI, so it never enters the inventory. The inventory is the list of AI destinations you are not looking inside yet. The two other actions never produce a discovery record: tunnel (explicitly not AI, or opted out of inspection) and block (refused at connect time).

​
How detection works

1

The agent observes the destination

On the interception path the agent already parses the TLS SNI (and the CONNECT target on the explicit-proxy path). Non-inspected hosts stop there, no decryption happens.
2

It classifies the host locally

The agent carries a copy of the AI catalog and the heuristic, so it only records hosts that look like AI. Everything else is ignored and never leaves the device.
3

It rolls up per host

Observations are aggregated in memory: host, provider, connection count, first seen, last seen. A background thread drains the rollup on an interval.
4

It batches to the cloud

The rollup is POSTed to /api/runtime-security/agent/discovery, authenticated with the device token. Up to 1000 observations are accepted per report.
5

The cloud re-classifies authoritatively

The agent’s classification is advisory. The cloud re-runs the classifier on ingest against the current catalog and rules, so coverage can be extended centrally without shipping a new agent build.
6

The inventory is updated

One row per workspace and host. Device IDs are unioned, connection counts accumulate, and a per-day rollup records when the traffic happened.

​
Classifications

Every observed host lands in one of three classifications. Only the last two are shadow AI.

​
The built-in catalog

Blindsight ships a curated catalog of roughly 180 AI hosts, maintained centrally and extended without an agent release. It spans:
  • Chat assistants and answer engines, poe.com, perplexity.ai, grok.com, chat.deepseek.com, meta.ai, …
  • Frontier labs and model makers, mistral.ai, cohere.com, stability.ai, …
  • Inference hosting and LLM API platforms, together.ai, fireworks.ai, replicate.com, openai.azure.com, …
  • Local and self-host model runners, huggingface.co, ollama.com, lmstudio.ai, …
  • Code assistants, cursor.com, codeium.com, tabnine.com, continue.dev, devin.ai, …
  • Writing and marketing AI, jasper.ai, quillbot.com, grammarly.com, …
  • Image, video, and audio generation, midjourney.com, runwayml.com, elevenlabs.io, synthesia.io, …
  • Research and search AI, exa.ai, elicit.com, consensus.app, …
  • Agents, automation, and voice agents, lindy.ai, dust.tt, vapi.ai, …
  • Companion and roleplay AI, high data-exfiltration risk and usually the first thing security teams want to see.
  • Smart-workflow platforms with AI steps, Power Automate, Copilot Studio, Make, n8n, Workato. These carry extra risk weight because they can move data between systems.
The full list is in the console: Runtime Security → Shadow AI → See what is detectable. It is also served by GET /api/runtime-security/discovery/catalog, together with the list of providers the agents actively inspect.

​
The unknown-host heuristic

A host in no rule and no catalog entry is still flagged as a candidate when it looks like an LLM service. This is what catches brand-new tools, internal AI gateways, and anything the catalog does not know yet. The rule is deliberately strict, matched against the dot- and hyphen-separated labels of the hostname:
  • A label token matches a high-precision AI keyword: llm, gpt, chatgpt, copilot, genai, chatbot, or a brand or model token such as openai, claude, anthropic, gemini, mistral, deepseek, llama, groq, huggingface, elevenlabs.
  • Or the host is on the .ai TLD and its stem carries an assistant token: chat, bot, assistant, llm, gpt, copilot, agent, ai.
Substring matching alone never qualifies. email.example.com and domain.example.com do not become candidates, while my-llm-proxy.example.com does.
The heuristic is a net, not a verdict. A candidate means “worth a look”, which is exactly why unknown hosts rank as high risk in the worklist until somebody decides.

​
What a discovery record contains

And what it never contains: prompt text, response text, request bodies, URLs beyond the hostname, file contents, headers, or credentials. Discovery cannot see them, because nothing is decrypted.

​
The lifecycle of a discovered service

1

Observed

A device reaches an AI host that is not inspected. The service appears with status new, shown as Needs review.
2

Ranked

Risk is derived from recognition, capability, and exposure, so the worklist orders itself. See Triage and governance.
3

Decided

You sanction it (approved tool), block it (agents refuse the connection), or onboard it as a managed App so its traffic can be inspected like any other App.
4

Evidenced

Every decision writes an audit record, and the Shadow AI report exports the inventory, the risk analysis, and the exposure breakdown as a PDF.

​
What it covers, and what it doesn’t

Discovery sees AI traffic from enrolled devices only, so it covers the same surface as the rest of DLP: browser tabs, IDE plugins, native desktop apps, and CLI tools on managed laptops. It does not cover:
  • Unmanaged devices. Personal phones and contractor laptops without the agent are invisible to discovery. Use SSO and conditional access there.
  • Server-side AI calls. Traffic from your own backends does not pass through a laptop. Instrument those with Runtime Security.
  • What was sent. Discovery is destination-only by design. To see content you must onboard the service as a managed App and inspect it.

​
Prerequisites

  • The DLP agent enrolled on at least one device. See Fleet rollout.
  • Runtime Security with the endpoint component enabled on your workspace.
  • runtime_security.view to read the inventory, runtime_security.policy.manage to sanction, block, or onboard.
  • Optional but recommended: identity binding and directory groups, so discovery can attribute services to real users and departments instead of OS user names.

​
Where to next

Set up discovery

Turn it on, verify the first observations, and tune what the agents observe, inspect, or ignore.

Triage & governance

The worklist, the risk model, the sanction / block / onboard decisions, insights, and the PDF report.

Policies & agent API

Host rules, actions, and the endpoints the agent calls.

Devices & enrollment

The fleet that feeds discovery. No enrolled agents, no inventory.