Know which AI tools people are paying for, and whether anyone approved them
Three states with unknown as the default, an owner on every entry, coverage on its own axis.The head of IT asked which AI tools the business has approvedThe approval that happened is in a thread somebody can nearly find. Meanwhile a tool nobody signed off renews on a card and a leaver's seat is still billing.
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.
4 steps, in this order.
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.
Leave the rest as unknown
Unknown is the default and is not an accusation. A permissive empty state launders whatever is already happening.
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.
Read coverage before findings
The radar draws on five evidence sources. Only one of five coverage states permits an unqualified all-clear.
Those steps build the register and put an owner on every line. What it does to the findings list is the capability page.
See the three states and the coverage axisBuilt for this. Wrong for that.
Built for
- A business where one team owns the estate, and the approval lives in somebody's inbox.
- Anyone who has to name the person who decided, not just the decision.
- Anyone who would rather have five unaccounted things than every destination the building reached.
Wrong for
- Anyone who wants to read what staff typed into a browser AI tool. A network feed gives a destination, not a transcript.
- Anyone who wants marking a tool prohibited to stop people using it. It records the decision and enforces nothing.
- Anyone who needs the register to prove a tool was authorised at the time it was used.
One thing you can check yourself
One command registers an approved subscription and a prohibited one, imports invoice lines against them, and asserts a caller scoped to Engineering cannot see the Finance evidence.
`npm run evaluate` starts a throwaway copy on a laptop. Team scoping is the check worth watching: it is the one an evaluation discovers late.
Where this is publishedThree 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. Nobody has decided yet — not an accusation and not an approval, which makes the register honest on its first day.
- Unobserved
- Not a register state at all. A coverage fact about a source nobody connected, reported as unknown rather than as clean.
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.
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.
4 things 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.
Every page here ends on what the job still does not solve. The complete position is on one page.
What we do not claimThe parts that do the work.
Approved and unauthorised AI
Approved, prohibited or unknown — so the subscriptions you already pay for stop arriving in the seat-spend report.
That a particular person's subscription is authorised
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
AI spend and subscriptions
What you were billed and what you were metered, recorded as two numbers and never added into one.
A subscription that is on no invoice you give it
Agent registry
One record per agent, and it is the record the gateway enforces against.
An overdue review never suspends the agent itself
Will it report our team's paid subscription as shadow AI?
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. Be precise about the scope — that suppression lives in the per-user seat-spend detector rather than across the whole radar, so billing reconciliation, network egress, the service-account key audit and IDE telemetry findings do not read the register.
Is there a fourth state for tools we have not observed?
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.
Can we see what people are typing into ChatGPT or Claude in a browser?
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.
Describe the version of this you actually have.
Say what your estate contains and which part of it worries you, and you will get a straight answer about where to start.
no form · no qualification step · no sales desk