> ## Documentation Index > Fetch the complete documentation index at: https://docs.blindsight.io/llms.txt > Use this file to discover all available pages before exploring further. # Shadow AI overview > Passive discovery of every AI service your workforce reaches from a managed device. Destination-only detection, no decryption, and a decision for every service you find. 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 endpoint 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. > [!NOTE] > > Discovery is usually the opening wedge of an Endpoint 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](https://docs.blindsight.io/endpoint/policies.md), which carry an `action`. A third action, `protect`, sits between them and is covered under [Protect unapproved AI](#protect-unapproved-ai). | Dimension | Inspected (`inspect`) | Observed (`observe`) | | - | - | - | | **What the agent does** | Local TLS MITM with the org root CA, then `/agent/scan`. | Records the destination hostname only. Bytes pass through opaque. | | **What you see** | Prompts, verdicts, PII spans, redactions, blocks. | Host, provider, device count, connection count, first / last seen. | | **Where it lands** | Events and dashboards, attributed to an App. | The Shadow AI inventory. | | **Typical hosts** | The providers you have onboarded (`chatgpt.com`, `claude.ai`, `api.openai.com`, ...). | Everything else that looks like AI. | 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). A `protect` host stays in the inventory: it is being inspected, but nobody has decided about it yet. ## 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. | Classification | Shown as | What it means | | - | - | - | | `managed_inspected` | **Managed** | Matches an `inspect` host rule. Fully scanned, attributed to an App. Not in the inventory. | | `catalog_observed` | **Known AI** | Matches the built-in AI catalog: a recognised provider, but nobody has approved it. | | `candidate` | **Unknown host** | Not in any rule or the catalog, but the heuristic says it looks like an LLM endpoint. | ### 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. > [!NOTE] > > 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 | Field | Example | Notes | | - | - | - | | `host` | `perplexity.ai` | The destination hostname, from SNI. | | `provider` | `perplexity` | Catalog provider slug. `null` for unknown hosts. | | `classification` | `catalog_observed` | `catalog_observed` or `candidate`. | | `status` | `new` | The governance decision. See below. | | `hit_count` | `1284` | Cumulative observed connections. | | `device_count` | `7` | Distinct devices that reached it. | | `first_seen` / `last_seen` | `2026-07-14T09:12:00Z` | UTC. | | `app_id` | `null` | Set when the service is onboarded as a managed App. | | `is_shadow` | `true` | `true` while `status` is `new`. This is the shadow-AI count. | | `protected` | `false` | Whether a rule currently has the agents inspecting this host. `null` when the caller did not resolve the rules. | 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](https://docs.blindsight.io/endpoint/shadow-ai/triage.md). **3. Protected, optionally** At any point you can **protect** it: agents start inspecting the traffic and pseudonymizing personal data in it, and nobody is ever blocked for using it. This is not a decision, so the row stays in the review queue. **4. 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. **5. 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. | Status | Shown as | Meaning | | - | - | - | | `new` | **Needs review** | Discovered, no decision recorded. This is the shadow AI number. | | `new` + `protected` | **Protected** | Still undecided, but agents are inspecting and pseudonymizing it. | | `sanctioned` | **Sanctioned** | Approved for use. No longer shadow AI; excluded from the report. | | `blocked` | **Blocked** | A `block` host rule is pushed to every agent. | | `promoted` | **Managed** | Onboarded as an App, with an `inspect` rule, so it is fully inspected. | > [!NOTE] > > Decision and protection are two independent axes, deliberately kept > apart. `status` records what the company decided about the service; > `protected` records what the agents are currently doing to it. A > service can be unreviewed and inspected at the same time, which is > the entire point of the protect posture below. ## Protect unapproved AI Discovery leaves you with two blunt options on a service nobody has vetted: watch it go past unseen, or ban it. **Protect** is the third posture between them. | Posture | The agent | The person using it | | - | - | - | | `observe` | Records the hostname only. Nothing is decrypted. | Notices nothing. | | `protect` | Decrypts and scans, pseudonymizes personal data before the prompt leaves the device, scores and logs injection. | Is **never blocked**. | | `inspect` | Decrypts and scans, and enforces the verdict. | Can be blocked or redacted. | | `block` | Refuses the connection. | Cannot reach the service. | Under `protect`, a `block` verdict is downgraded rather than enforced: a prompt that would have been blocked is `redact`ed instead, and a file that would have been blocked is allowed. The event records the downgrade, so you can see what *would* have been stopped. ### Turning it on for the whole workspace `dlp_protect_unsanctioned` on `PUT /api/runtime-security/config` is a **floor** over the entire discovery catalog: every AI service nobody has approved becomes `protect` instead of `observe`. It is off by default, because it decrypts traffic to services nobody vetted, so turning it on is a deliberate decision rather than an upgrade side effect. Switching it on first pins an explicit rule for every service that already has a decision, so a tool the company approved does not start being inspected by a setting whose label says *unapproved*. Requires `runtime_security.firewall.configure`. See [Configuration](https://docs.blindsight.io/runtime-security/configuration.md#workspace-config). > [!NOTE] > > You can also protect a single service without turning the posture on > for everything, from the row itself. See > [Triage](https://docs.blindsight.io/endpoint/shadow-ai/triage.md#protect-inspect-without-deciding). ## 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 Endpoint: 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](https://docs.blindsight.io/runtime-security/overview.md). * **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 endpoint agent enrolled on at least one device. See [Fleet rollout](https://docs.blindsight.io/endpoint/fleet-rollout.md). * Runtime Security with the endpoint component enabled on your workspace. * `endpoint.discovery.view` to read the inventory, `endpoint.ai_services.manage` to protect, sanction, block, or onboard. See [Endpoint permissions](https://docs.blindsight.io/endpoint/permissions.md). * Optional but recommended: [identity binding](https://docs.blindsight.io/endpoint/identity.md) and directory groups, so discovery can attribute services to real users and departments instead of OS user names. ## Where to next > **[Set up discovery](https://docs.blindsight.io/endpoint/shadow-ai/setup.md)** > > Turn it on, verify the first observations, and tune what the > agents observe, inspect, or ignore. > **[Triage & governance](https://docs.blindsight.io/endpoint/shadow-ai/triage.md)** > > The worklist, the risk model, the sanction / block / onboard > decisions, insights, and the PDF report. > **[Policies & agent API](https://docs.blindsight.io/endpoint/policies.md)** > > Host rules, actions, and the endpoints the agent calls. > **[Devices & enrollment](https://docs.blindsight.io/endpoint/devices.md)** > > The fleet that feeds discovery. No enrolled agents, no inventory. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.