Approved and unauthorised AI
Approved, prohibited, unknown — and unobserved kept separate from clean, because those two are not the same finding.
This one sits outside the eleven-step request path: it governs what happens around a governed call rather than inside one.
the whole pathOn this page
A shadow-AI list nobody can action
The standard shadow-AI report is a list of every AI destination anyone in the building reached, sorted by volume. It is usually long, it is usually mostly legitimate, and the second time somebody works through it they stop working through it. The problem is not detection. The problem is that the report has no idea which of those services the business already approved and pays for, so the approved ones sit in the list alongside the genuinely unexpected ones, and the signal is buried under the company's own subscriptions.
Treating paid subscription use as unauthorised use is the specific failure, and it is worth naming plainly because it is common. An employee using the Claude subscription their team bought, on the plan their manager approved, is not a security finding. Reporting them as one costs you the credibility of every other line on the report, and it costs the person who has to read it their afternoon.
The mirror-image failure is a green screen. If a source has not been connected — a network feed nobody enabled, an endpoint with no collector, a provider with no adapter — then a report over that source will show nothing, and nothing renders identically to no problems found. An estate with no usage and an estate nobody looked at produce the same chart, and only one of them is good news.
So the register exists to take the approved services out of the findings, and the coverage model exists to keep unobserved visibly distinct from clean. What is left after both is a list of things somebody genuinely has not accounted for, which is short, and which is the only version of this report anyone actions twice.
How it actually works
- 01
Register the approval against an exact combination
Approval attaches to a specific vendor, tool, team and owner rather than to a vendor in general. Approving Claude for the engineering team does not approve it for everyone, and does not approve every Anthropic product for engineering. Vendor and tool are normalised to lowercase so the same service does not appear twice through capitalisation. - 02
Default to unknown, not to allowed
A service nobody has classified is unknown, which is the state it stays in until a person decides. Unknown is a prompt for a decision rather than a verdict, and it is deliberately the default so that the register never implies an approval that nobody granted. - 03
Suppress the findings the register already explains
The radar suppresses findings that match an approved subscription entry, which is what turns the raw observation list into an actionable one. Evidence matching a prohibited entry, or matching nothing in the register, carries its corresponding classification instead of being dropped. - 04
Keep unobserved out of the clean column
Coverage is reported as its own fact. A source that is disconnected is unknown rather than zero usage or a clean verdict, and being outside the gateway is recorded as a coverage gap rather than as evidence of a policy violation. Both directions of that error are refused: no false alarm, and no false all-clear. - 05
Record the decision, not a history
The authorisation state is the current decision. It is not an attestation that use before the decision was permitted, and the page and the API both describe it that way, because a register that implied retrospective approval would be the one thing on this screen a regulator would object to. - 06
Audit every change, at operator rank
Reads require viewer rank and writes require operator rank, both within the user's team scope, and every mutation is audited. Changing a service from prohibited to approved is a governance decision with a name attached to it.
Four distinctions, three of them stored
The register stores three states. The fourth distinction is about coverage rather than about a decision, and conflating it with the other three is the error the design is built to avoid, so it is worth being exact about where each one lives.
- Approved
- A person decided this vendor, tool, team and owner combination is legitimate. Matching findings are suppressed. This is normal business usage and the report should be quiet about it.
- Prohibited
- A person decided this one is not permitted. Matching evidence carries that classification, which is a finding worth someone's time.
- Unknown
- The default. Nobody has decided yet. Not an accusation and not an approval — a queue of decisions waiting for an owner.
- Unobserved
- Not a register state but a coverage fact about a source. Nobody connected it, so nothing was seen through it. Reported as unknown, never as clean, because an empty result from a disconnected feed is not a result.
Why a hostname is not a person
Network observation tells you that a destination was reached. It does not tell you who reached it, and the gap between those two matters more here than almost anywhere else in the product, because the natural next step after seeing an unexpected AI destination is to go and speak to somebody about it.
A hostname without a verified owner cannot establish that a particular user's subscription is authorised. Nor can it establish the reverse. Mapping observed traffic to a real identity needs an identity feed somebody has connected and qualified, and the product repository lists that mapping — along with wider vendor coverage and network collection rollout — as remaining work rather than as something that ships today.
The practical consequence is that findings from observation are leads to investigate, not conclusions to act on. Treat the register as the record you build deliberately, with a real owner on every entry, and treat the radar as the thing that tells you which conversations to have.
What registering an approval does not change
Approval is a record of a decision inside Token Observe. It is not an action at the vendor, and it is not an enforcement control, and the distinction is worth being blunt about because the word invites the opposite assumption.
Registering a subscription does not cancel it. It does not change its payment plan, downgrade a seat, or reclaim a licence from somebody who left. It does not enforce anything on an endpoint: marking a tool prohibited records that decision and classifies subsequent evidence accordingly, and it does not by itself stop anyone from opening that tool in a browser.
Enforcement of what a governed agent may do is a different part of the product — permissions, policy and the gateway — and it applies to traffic that comes through Token Observe. The register is how you decide and record what should be true; it is not the mechanism that makes it true at the vendor.
What this does not do
Stated here rather than discovered during an evaluation. Every line below closes off a reasonable assumption a reader would otherwise carry into a proof of concept.
- It does not stop anybody using a tool. Marking a service prohibited records the decision and classifies later evidence; it does not enforce a control at the vendor or on an endpoint.
- It does not cancel subscriptions, change payment plans or reclaim 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 and feed 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.
- 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.
If one of those limits is the thing that decides it for you, say so and you will get a straight answer about whether it is on the roadmap or out of scope.
Talk it throughWhat 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.
Will it flag our team's paid Claude subscription as shadow AI?
Not once it is in the register as approved. Approved entries suppress matching findings, which is the main reason the register exists: a shadow-AI report that lists the company's own approved subscriptions alongside genuinely unaccounted ones is a report nobody works through twice. The product rule behind this is explicit — an approved subscription is legitimate usage, and 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 actually connected. A source nobody has connected is unobserved, and unobserved is reported as unknown rather than as a clean verdict, precisely because an empty result from a disconnected feed looks identical to an empty result from a healthy one. Read the coverage alongside the findings: the question that matters is not only what was found, but what was capable of being seen at all.
What is the difference between unknown and prohibited?
Unknown is the absence of a decision and is the default state for anything nobody has classified. It is not an accusation — it is a queue of things somebody needs to decide about. Prohibited is a decision that a person actually made, and evidence matching it carries that classification. Keeping them apart means the report can distinguish between what your business has ruled out and what it simply has not looked at yet.
Can we approve a tool for one team but not another?
Yes, and that is the only way approval works here. An entry is attributed to an exact vendor, tool, team and owner combination rather than to 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 names are normalised to lowercase so the same service registered with different capitalisation does not become two entries.
Prefer to ask a person? Write to us →
Bring us the agent you are least comfortable with.
Write to hello@tenhaw.com with what your agents do, which providers they call and what would have to be true for you to put something in front of them. James Rooney replies. You will get a straight answer about whether Token Observe fits, including when it does not.
no form · no qualification step · no sales desk · the other three ways in