--- title: "Use case: Know which AI tools people are paying for, and whether anyone approved them" canonical_url: "https://tokenobserve.com/use-cases/know-who-approved-the-ai-tools" published: 2026-09-07 last_updated: 2026-10-21 --- # Use case: Know which AI tools people are paying for, and whether anyone approved them Keep the decision somewhere other than an email thread: a register in Token Observe where every entry names an exact vendor, tool, team and owner email and carries one of three authorization states (approved, prohibited or unknown, with unknown as the default), so nothing is agreed by silence. ## The stated limit What a hostname cannot establish: That a particular person's subscription is authorised ## The approval happened. The record of it is a thread. Somebody asked, somebody senior said yes, and the record is a message in one of their mailboxes, which cannot be queried and cannot be handed to a successor. The alternative is a discovery tool whose findings list has no idea which destinations the business already approved and pays for, so the signal is buried under the company's own spending. ## The steps, in this order 1. Write down the approvals you have. One entry per exact vendor, tool, team and owner email. Approving a tool for one team does not approve it for everyone. 2. Leave the rest as unknown. Unknown is the default and is not an accusation. A permissive empty state launders whatever is already happening. 3. Check it against money. Charge lines carry the same attribution, so a line nobody registered stands out. This finds the renewal whose buyer has left. 4. Read coverage before findings. The radar draws on five evidence sources. Only one of five coverage states permits an unqualified all-clear. ### Three states, and coverage is not a fourth one. The register stores three authorization states and only three. What people reach for as a fourth is a fact about a SOURCE rather than about a decision: whether a feed is connected, delivered recently and carried any rows are coverage questions, answered on their own axis with five values of which exactly one permits an all-clear. - Approved: A person decided this exact vendor, tool, team and owner combination is legitimate. A report that keeps alarming about it gets muted. - Prohibited: A person decided this one is not permitted. Matching evidence carries that classification, which is a finding worth somebody's time. - Unknown: The default. A named person has yet to make an approval decision. - Unobserved: Not a register state at all. A coverage fact about a source nobody connected, reported as unknown rather than as clean. ### Approval records a decision. It enforces nothing. Registering a subscription does not cancel it or reclaim a licence, and marking a tool prohibited does not stop anyone opening it in a browser. What approval changes is the noise: where per-user seat spend is reported from an invoice you supplied, a matching approved entry suppresses the finding. That suppression lives in that one detector; billing reconciliation, network egress, the key audit and IDE telemetry do not read the register. ## What this still does not solve - It does not stop anybody using a tool. Marking a service prohibited classifies later evidence; it enforces no control at the vendor and none on an endpoint. - A hostname is not a verified employee identity, so observed traffic cannot establish whose use is authorised. Mapping feeds to real people is remaining work. - No report here is a complete claim about the estate. A source nobody connected is unknown rather than zero, and an absence of findings is not an assurance. - Approval is the current decision only. It makes no statement that use before the decision was permitted. ## Questions and answers Q: Will it report our team's paid subscription as shadow AI? A: Not once it is registered as approved: where per-user seat spend is reported from an invoice you supplied, a matching approved entry suppresses it. The scope is narrow: that suppression lives in the per-user seat-spend detector, not across the whole radar, so billing reconciliation, network egress, the service-account key audit and IDE telemetry findings do not read the register. Q: Is there a fourth state for tools we have not observed? A: No. The register stores three authorization states (approved, prohibited and unknown), and coverage is a separate axis with five values across six evidence streams. Unobserved is a fact about a source rather than a decision about a tool, and it reads as unknown rather than as clean. Q: Can we see what people are typing into ChatGPT or Claude in a browser? A: No, and it is better to hear that now than in week three. A network feed reports that a destination was reached; there is no browser agent, no endpoint capture and no proxy that reads a session. A hostname is not a verified employee identity either.