Find the AI use happening outside your controls
Bring five evidence sources together. See which feeds are connected, stale or missing. The head of IT whose discovery console has been green for three weeks The export died in July. Nothing on the screen distinguishes that from an estate with nothing to find, so a green banner has been asserting a clean result over a dead feed.
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.
4 steps, in this order.
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.
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.
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.
Read coverage before findings
The report attaches to the findings list, the scan response, the coverage route and the dashboard summary.
Check what each evidence source can establish before investigating a finding.
See the five sources and their boundsBuilt for
- A business that can export what it has: a vendor master bill, flow logs, a key inventory, workstation telemetry.
- Anyone who wants coverage stated beside every clean answer rather than a findings page with nothing on it.
- Anyone who will treat a finding as a lead and go and have the conversation it points at.
Wrong for
- Anyone who wants discovery to block something. It is a detective control and cannot stop a workstation talking to a vendor API.
- Anyone expecting endpoints outside the shipped lists to be recognised. IDE detection recognises six named coding agents.
- Anyone who needs the two pull connectors qualified. Neither has been run against a live vendor tenant.
One thing on the record
The reporting-integrity failure this page argues against is one Token Observe shipped and records. Arrival was once stored as a batch arriving, so an exporter delivering an empty page hourly held its source at fresh indefinitely.
Coverage now keeps two clocks per feed, and connected_empty is its own state. Stop a feed on your own install and watch where it lands.
Where this is publishedAn 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.
Sample data in the real Token Observe interface, recorded from a local evaluation with a temporary database, a mock provider and one request. No live provider key was used.
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.
4 things 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.
Check the product limits alongside the job you want to do.
What we do not claimThe parts that do the work.
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.
Only as current as the export it was computed from
Endpoint seats
Policy enforced inside each vendor’s own administrator hook, decided offline against a signed bundle, because a hook that phones home fails open.
Preview. Not an inline gateway on an unmanaged device.
Agent registry
One record per agent, and it is the record the gateway enforces against.
An overdue review never suspends the agent itself
Questions
How do you tell a dead feed from a clean estate?
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.
Does Token Observe need access to our finance system or our firewall?
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.
Can a finding close itself once the problem is fixed?
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.
Describe the version of this you have.
Say what your estate contains and which part of it worries you, and the reply will say where to start.