--- title: "Capability: Approved and unauthorised AI" canonical_url: "https://tokenobserve.com/platform/approved-ai" published: 2026-09-06 last_updated: 2026-10-21 --- # Capability: Approved and unauthorised AI Approved, prohibited or unknown, so the subscriptions you already pay for stop arriving in the seat-spend report. ## What it is Token Observe holds an approval register for the AI services your business uses. Each entry names an exact vendor, tool, team and owner, and carries one of three states: approved, prohibited or unknown, with unknown as the default, so nothing passes by silence. An approved entry quietens the per-user seat-spend report, which is the one detector that names people; billing reconciliation, network egress, the service-account key audit and IDE telemetry do not read the register at all. Coverage is a separate axis: a source nobody has connected reads as unknown rather than as clean. Approval records the current decision, not that earlier use was permitted. ## Facts - States: Approved, prohibited, unknown; unknown by default - Attribution: Exact vendor, tool, team and owner - Coverage: Its own axis. Unconnected reads as unknown - Every change: Operator rank, team-scoped, audited ## The limit What a hostname cannot establish: That a particular person's subscription is authorised ## Why it exists: A shadow-AI list nobody actions twice. The standard report lists every AI destination anyone in the building reached, sorted by volume. Most of it is the marketing team's approved Claude subscription. Reporting a paid, approved subscription as unauthorised use costs you the credibility of every other line, and the second time somebody works through that list they stop working through it. The mirror-image failure is worse: a feed nobody connected produces an empty report, and empty renders identically to nothing found. So the register takes approved services out of the report that names people, and coverage keeps an unconnected source visibly apart from a clean one. What is left is short enough to act on. ## How it works - Register an exact combination: Approval attaches to one vendor, tool, team and owner rather than to a vendor in general: approving Claude for engineering approves nothing for finance. Vendor and tool are lower-cased on write, so capitalisation cannot create a second entry for the same service. - Default to unknown, never to allowed: A service nobody has classified is unknown until a person decides. It is a queue rather than a verdict, and it is the default so the register never implies an approval nobody granted. - Quieten the report that names people: The per-user seat-spend detector reads the register and skips a finding whose vendor, tool and team match an approved entry. It is the only detector that consults it: billing reconciliation, network egress, the key audit and IDE telemetry never do. - Keep coverage on its own axis: A disconnected source is unknown rather than zero usage or a clean verdict. Neither error is permitted: no false alarm, and no false all-clear. - Audit every change: Reads need viewer rank, writes need operator rank, both inside the user's team scope, and every mutation is audited. Moving a service from prohibited to approved is a governance decision with a name on it. ## What it does not do - It stops nobody using a tool. Marking a service prohibited records the decision and classifies later evidence; it enforces nothing at the vendor or on an endpoint. - It cancels no subscriptions, changes no payment plans and reclaims no seats. Nothing here reaches into a vendor account. - A hostname is not a verified employee identity, so observed traffic cannot establish that a particular person's use is authorised or unauthorised. - Identity mapping to real people, wider vendor coverage and the network collection rollout are remaining work rather than shipped behaviour. - Approval is the current decision only. It makes no statement that use before the decision was permitted. - Being outside the gateway is a coverage fact, never on its own evidence of a policy violation. - Suppression is one detector, not the radar. Only the per-user seat-spend detector reads the register (billing reconciliation, network egress, the service-account key audit and IDE telemetry do not), so approving a subscription does not quieten those. - No report here is a complete claim about the estate. A network observation cannot prove comprehensive coverage, and an absence of findings is not an assurance. ## Read next - https://tokenobserve.com/platform/estate-spend - https://tokenobserve.com/platform/shadow-ai-radar - https://tokenobserve.com/platform/conversation-evidence ## Questions and answers Q: Will it flag our team's paid Claude subscription as shadow AI? A: Not in the per-user seat-spend report, once it is registered as approved against that exact vendor, tool and team. The scope is one detector, not the whole radar. Billing reconciliation, network egress, the service-account key audit and IDE telemetry never read the register, and a browser AI destination is classified unknown whatever the register says. The rule behind the suppression is explicit: paid subscription use is never equated with unauthorised use. Q: If the report shows no unauthorised tools, are we clean? A: Only for the sources that are connected. Coverage is reported on its own axis, and a source nobody has connected reads as unknown rather than as a clean verdict, because an empty result from a dead feed looks identical to an empty result from a healthy one. The question is not only what was found, but what was capable of being seen. Q: Can we approve a tool for one team but not another? A: Yes, and that is the only way approval works. An entry names an exact vendor, tool, team and owner rather than a vendor in general, so approving a tool for engineering does not approve it for finance, and approving one product does not approve everything that vendor sells. Vendor and tool are lower-cased on write, so the same service registered with different capitalisation does not become two entries. 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/approved-ai.