Approved and unauthorised AI
Approved, prohibited or unknown, so the subscriptions you already pay for stop arriving in the seat-spend report.
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
- 01
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. - 02
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. - 03
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. - 04
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. - 05
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.
One row per vendor, tool, team and owner. Approval attaches to that exact combination rather than to a vendor in general, so approving an assistant for marketing approves nothing for finance.
| vendor | tool | team | owner email | authorization |
|---|---|---|---|---|
| vendor-a | chat assistant | Marketing | priya.shah@example.com | approved |
| vendor-b | coding agent | Engineering | sam.ellis@example.com | unknown |
| vendor-c | meeting notetaker | Sales | dana.reid@example.com | prohibited |
A person decided this exact vendor, tool, team and owner is legitimate. A matching per-user seat-spend finding is suppressed; every other detector is unaffected.
A person decided this one is not permitted. Matching evidence carries that classification, which is a finding worth somebody’s time.
The default on creation, so nothing passes by silence. A queue of decisions waiting for an owner rather than an accusation.
authorization TEXT NOT NULL
CHECK (authorization IN ('approved','prohibited','unknown')),
UNIQUE(vendor, tool, team, owner_email)Field names, states and the constraint are the product’s own; the rows are illustrative. Vendor, tool and owner email are lower-cased on write, so capitalisation cannot open a second entry for the same service. The team is kept as it was typed.
Three states, and coverage on its own axis.
The register stores three authorization states and nothing else. Whether anybody has looked is a different question about a different thing (a source, not a service), and folding the two together is the error the design exists to avoid.
- Approved
- A person decided this vendor, tool, team and owner combination is legitimate. A matching per-user seat-spend finding is suppressed; every other detector is unaffected.
- 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, and not an accusation. Nobody has decided yet, so it is a queue of decisions waiting for an owner.
- Coverage, separately
- Five states over six evidence streams, reported beside every clean result. A source nobody connected reads as unknown, never as clean, because an empty result from a dead feed is not a result.
vendor anthropic state approved
tool claude owner priya.shah@example.com
team marketing default unknown
per-user seat spend, this vendor/tool/team suppressed
billing reconciliation unchanged
network egress unchanged
service-account key audit unchanged
IDE and CLI telemetry unchanged
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.
A hostname is not a person.
Network observation tells you a destination was reached. It does not tell you who reached it, and the gap matters here more than anywhere else in the product, because the natural next step after an unexpected AI destination is to go and speak to somebody.
A hostname without a verified owner cannot establish that a particular person's subscription is authorised, and cannot establish the reverse either. Mapping observed traffic to a real identity needs an identity feed somebody has connected and qualified, and that mapping is remaining work rather than shipped behaviour. The register is the record you build deliberately, with an owner on every entry. The radar tells you which conversations to have.
Each line closes off an assumption a reader would otherwise carry into a proof of concept.
What this does not doWhat this leans on
AI spend and subscriptions
What you were billed and what you were metered, recorded as two numbers and never added into one.
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.
AI conversation evidence
What the AI was asked and what it returned, redacted before it is stored and bounded before it is kept.
Where this comes up
Will it flag our team's paid Claude subscription as shadow AI?
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.
If the report shows no unauthorised tools, are we clean?
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.
Can we approve a tool for one team but not another?
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.
Prefer to ask a person? Write to James
Bring us the agent you are least comfortable with.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.