--- title: "Use case: Find the AI use happening outside your controls" canonical_url: "https://tokenobserve.com/use-cases/find-shadow-ai" published: 2026-09-02 last_updated: 2026-10-21 --- # Use case: Find the AI use happening outside your controls Five evidence sources (vendor bill reconciliation, network egress, a service-account key audit, IDE and CLI telemetry, and the gateway's own tables), with Token Observe reporting coverage beside every clean answer. An empty findings list is the same bytes whether nobody is bypassing the gateway or the export died in July. ## The stated limit What discovery does: It detects and reports. It blocks nothing at all ## A green banner over a dead feed is a claim nobody checked. A survey inventories the tools people were willing to write down; a procurement list finds what somebody bought on a purchase order and misses every personal card and every key minted during an outage two years ago. Then comes a discovery tool with a findings page, and the trouble is the sentence underneath the list when it is empty: a stopped export and a clean estate emit the same bytes. ## The steps, in this order 1. Mint an ingest credential. Minting is an admin action and revoking an operator one. The credential may only post evidence rows for its streams; it cannot read findings. 2. Send the vendor master bill first. It is ground truth for what was spent, and the only source that finds usage leaving no network, identity or endpoint trace. 3. Add egress, keys and IDE telemetry. Destinations matched against a fixed hostname list, keys past a rotation window, and coding agents whose base URL is not this gateway. 4. Read coverage before findings. The report attaches to the findings list, the scan response, the coverage route and the dashboard summary. ### An empty delivery is not the same as no delivery. A delivery proves the connector is alive; a delivery carrying at least one row proves the estate was observed. They are kept in different columns because they were once the same column, and the consequence was a source held at fresh indefinitely by an exporter delivering nothing. Connector runs, delivery outcomes and credential liveness are joined in too, because freshness alone is always late. - connected_fresh: Evidence arrived inside the bound. The only state a clean result can stand on, anywhere in the product. - connected_empty: Deliveries are still arriving and none recently carried a row. The connector is alive and the estate has not been observed. - feed_failing: The evidence is inside its bound and the thing that fetches or delivers it has stopped. - connected_stale, never_connected: Evidence arrived before and not recently enough, or never. Stale is the dangerous one, because everything still looks configured. ### Closing a finding by absence is the hardest operation here. A wrongly resolved finding is worse than a stale one: a condition that was true, is still true, and is now filed as handled. Four things must hold. The run reported completed. The source is one where absence is evidence, which is only the gateway's own tables; an export that omits last month's shadow key has not remediated it. The source ran in that pass. And the detection side saw its whole population. ## What this still does not solve - Discovery blocks nothing. It cannot stop a workstation talking to a vendor API, and it cannot say where a workload the gateway refused went next. - Egress matches a fixed list of vendor API hostnames plus regional Bedrock shapes, and IDE detection recognises six named coding agents. Anything else is a code change. - Neither shipped pull connector has been run against a live vendor tenant. Cisco Umbrella and GitHub Copilot are written to recorded-shape fixtures and published documentation. - A finding is a lead rather than proof, and some are structurally ambiguous. A silent endpoint seat cannot be told from a person on leave. ## Questions and answers Q: How do you tell a dead feed from a clean estate? A: By recording two facts per source and reporting them beside every clean result: when a delivery last arrived, which proves the connector is alive, and when a delivery carrying at least one row last arrived. Those produce five states, and only connected_fresh permits an unqualified all-clear. Q: Does Token Observe need access to our finance system or our firewall? A: No. Your own exporter pushes to a receiver on a credential Token Observe issued, scoped to the streams it may post, so there is no standing broad credential into your stack. Two optional pull connectors hold a narrow, read-scoped vendor credential you supply (Cisco Umbrella for egress and GitHub Copilot for seat spend), and both stay off until you set it. Q: Can a finding close itself once the problem is fixed? A: Only for the source that reads the gateway's own tables, and only when the run completed, the prior snapshot was not truncated, the source ran in that pass and detection saw its whole population. The four operator-fed sources never clear by absence.