--- title: "Capability: Shadow AI radar" canonical_url: "https://tokenobserve.com/platform/shadow-ai-radar" published: 2026-09-02 last_updated: 2026-10-21 --- # Capability: Shadow AI radar Five evidence sources for AI activity that never touched the gateway, and a coverage model that refuses to call a dead feed a clean estate. ## What it is Private-network feeds and endpoint hooks need separately configured connectivity or installation; they are not prerequisites for the cloud billing report. Token Observe finds AI activity happening outside the gateway from five evidence sources: vendor bills, network egress, service-account keys, IDE and CLI telemetry, and the gateway’s own tables. Four run on exports your systems push inwards; the fifth needs none. Every clean result carries a coverage report beside it, because an empty findings list reads the same whether nobody is bypassing the gateway or the export died in July. One of five coverage states entitles an all-clear. ## Facts - Evidence sources: Five: bills, egress, keys, IDE, own tables - Coverage states: Five, and one entitles an all-clear - Silence bounds: 6h egress, 48h IDE, 10d keys, 45d bills - Delivery ceiling: 10,000 rows or 8 MB, refused whole ## The limit What a finding is worth: Only as current as the export it was computed from ## Why it exists: Nothing found and nothing looked at are the same empty list. Any tool produces a list of findings. What matters is the sentence underneath it when the list is empty. A console that renders no findings as a green banner has made a claim about your estate, and usually has no idea whether it is entitled to. An export that stopped in July looks exactly like a clean estate. Freshness alone is always late. A master bill is monthly, so a credential revoked this morning leaves its source reading fresh until September, while the connector’s own verdict is available today. The later of two true answers is the same lie, slower. ## How it works - Your systems deliver; nothing here reaches into them: Your exporter posts evidence rows on a credential Token Observe issued and you can revoke, scoped to those streams and nothing else. Two scheduled pull connectors are the exception (GitHub Copilot, Cisco Umbrella), each on a narrow read-scoped credential you supply. - Two clocks per stream, never one: One clock for when a delivery last arrived, empty or not; one for when a delivery carrying a row last arrived. The first is liveness, the second freshness. An exporter delivering an empty page hourly once held its source at fresh indefinitely. - Clearing a finding is harder than raising one: A finding closes by absence only when the run completed, the source is one where absence is evidence, the snapshot was whole and the whole population was seen. A wrongly resolved finding is worse than a stale one: still true, now filed as handled. ## What it does not do - No standing broad credential into your stack: your exporters push inwards on a credential this deployment issued and can revoke, and a customer-hosted runtime has no vendor phone-home. Cloud hosting holds workspace data and supplied credentials. Two scheduled pull connectors are the exception (GitHub Copilot seat spend, Cisco Umbrella activity), each on a narrow read-scoped credential you supply and can withhold. - Four of the five sources are pure functions of rows you export. A finding is only as current as that export. - The radar detects and reports; it blocks nothing. It cannot stop a workstation talking to a vendor API, and cannot tell you where a workload the gateway refused went next. - Egress detection matches a fixed list of vendor API hostnames plus regional Bedrock endpoints; IDE detection recognises six named coding agents. Anything outside those lists is not detected, and adding one is a code change. - Per-provider billing attribution exists only where you have declared which invoice accounts belong to which provider. Nothing is name-matched or attributed by elimination. - A silent endpoint seat cannot be told from a person on leave, and the finding says so. - Neither shipped pull connector has been run against a live vendor tenant. Query parameters, pagination, paths and field names come from recorded fixtures and published vendor documentation; a renamed field lands as a typed schema error rather than as silence. ## Read next - https://tokenobserve.com/platform/spend-controls - https://tokenobserve.com/platform/agent-registry - https://tokenobserve.com/platform/endpoint-seats ## Questions and answers Q: How do you tell a dead feed from a clean estate? A: By recording two facts per source and reporting both beside every clean result: when a delivery last arrived, which proves the connector is alive, and when a delivery carrying a row last arrived, which is what freshness is computed from. Those give five states, and only connected_fresh permits an all-clear. Q: Does Token Observe need access to our finance system or our firewall? A: No. Your own exporter pushes on a credential Token Observe issued and scoped to those evidence streams: it cannot read findings, run a scan or change a policy. Two optional pull connectors are the exception and do hold a vendor credential you supply (Cisco Umbrella, GitHub Copilot), both off until you configure them. Q: Can a finding be closed automatically when the problem is fixed? A: Only for the source that reads the gateway’s own tables, and only when the run completed, the snapshot was not truncated and the whole population was seen. The four operator-fed sources never clear by absence: an export omitting last month’s shadow key has not remediated it. The long-form detail on this capability (the anchored sections, the worked policies and the error envelopes) is on the page itself at https://tokenobserve.com/platform/shadow-ai-radar.