Privacy notice

This notice is about tokenobserve.com, the marketing website you are reading. Tenhaw LTD is the controller for the small amount of personal data that website processes, and clauses 2 to 12 describe all of it.

It is not a notice about your Token Observe deployment. Token Observe is self-hosted software: it runs inside your network, on infrastructure you control, against your own model-provider accounts using keys you supply. Whatever personal data passes through it is processed by you, under your own controllership, and supplying the software does not make Tenhaw a processor of it — not because a contract says so, but because no copy of it reaches us and there is no vendor-operated component anywhere in the request path. Clauses 13 to 15 set out that position, the narrow arrangements that would change it, and what a deployment actually holds, so that your own data protection officer knows where to look.

If you are completing a supplier assessment, those two halves usually map to different questions on the same form. Answering both from one paragraph is where most vendor notices go wrong, and it is the reason this one is shaped the way it is.

Tenhaw LTD, a company registered in England and Wales under company number 12735685, incorporated on 10 July 2020 and based in London, publishes Token Observe and operates this website. The registration is public and linked below, so it is a checkable fact rather than a claim.

Privacy questions and data subject requests about this website go to hello@tenhaw.com. Vulnerability reports go to security@tenhaw.com. Both are read by a person rather than a queue, and both are the addresses published in the product’s own repository rather than mailboxes invented for a website. There is no separate privacy@ or dpo@ address: creating one for this document would make its first specific statement untrue.

Tenhaw has not appointed a data protection officer and, on the processing described in clauses 3 to 12, is not required to. Whether that changes once the product is sold under a signed agreement is one of the questions counsel is being asked.

Page-level analytics through Plausible, which sets no cookies and stores nothing on your device. It records the page, the referring source, the country derived from your IP address, and the class of device and browser. Your IP address is used in transit to derive a rotating daily hash so that returning visits are not double-counted, and is not stored; nothing is set that could follow you to another site.

A small number of named events, so that the site can tell which arguments are actually read: a page opened, a page scrolled far enough to have been read, a named section reached, a call to action clicked, a command copied, a link to the repository followed, and a question asked of the on-page assistant. Each carries the page and a short label. None carries anything you typed, and none is attached to a person.

That is the whole of the automated collection. There is no second analytics tool, no advertising or cross-site tracking, no visitor-identification or IP-to-company resolution service, no session recording or replay, and no product analytics of any kind. One third party is contacted by your browser when you load a page, and it is the one named above.

Whatever our hosting provider records in order to serve the page, which is an ordinary request log: IP address, timestamp, path and user agent.

That is the complete list. There is no advertising or cross-site tracking, no visitor-identification or IP-to-company resolution tool, no session recording or replay, no embedded chat, no booking calendar and no form of any kind. The typefaces are served from this site, having been fetched at build time, so loading a page makes no request to Google Fonts.

This website sets no cookies. Not “no non-essential cookies” and not “none until you accept”: none at all. It writes nothing to your device, reads nothing from it, and stores nothing in localStorage, sessionStorage or IndexedDB.

That is why you were not shown a consent banner, and the reason is worth stating rather than leaving you to wonder whether one failed to load. The rule that produces cookie banners is about storing information on, or gaining access to information already on, your equipment. This site does neither, so there is nothing to ask you about — and a banner asking permission for something that was going to happen regardless would be a worse thing to have built than no banner at all.

The consequence is that there is nothing for you to switch off, and nothing to withdraw. If that ever changes — if a tool is added that writes to your device — a banner comes back with it and this clause is rewritten in the same commit, because the assertion above is a total and one addition falsifies it.

Plausible runs for every visitor, and it is not behind a gate. It stores nothing on your device and reads nothing from it, so the rule that requires consent before storing or accessing information on your equipment has nothing to bite on. Our lawful basis is legitimate interests — knowing which pages are read and which answer the question somebody arrived with — and the balancing test is short because the processing is aggregate, cookieless and carries no identifier that could follow you anywhere.

Running one ungated tool rather than a gated one beside it is a deliberate choice with a cost, and the cost falls on us rather than on you. What is given up is demographic breakdown, cross-device identity and user-level funnels, none of which is available without storing something on your device. What is gained is that the measurement is complete: a gated tool is declined most often by exactly the privacy-conscious readers this site is written for, so its numbers would have been systematically missing the people who matter most here.

Your IP address is used in transit to derive a rotating daily hash so returning visits are not double-counted, and is not stored. Plausible Insights OÜ processes on our behalf, in the European Union.

Vercel, Google and Anthropic are established in the United States. Where personal data reaches them, it is transferred under the UK International Data Transfer Addendum or the EU standard contractual clauses incorporated in their respective terms, with the supplementary measures those terms describe. Plausible processes within the European Union. The transfer basis for the email provider follows once that provider is named.

A Token Observe deployment makes no transfer to Tenhaw, in any jurisdiction, because it sends us nothing. There is no international transfer to assess between you and us in respect of the software, which is a shorter answer than a transfer impact assessment and a more durable one.

Plausible holds aggregate statistics rather than a record about a visitor, so there is nothing attached to you to age out and no retention period to state. That is a consequence of the tool choice rather than a policy we operate: there is no per-visitor record here whose age we could decide.

Correspondence is proposed to be kept for 24 months from the last message, unless you become a customer, in which case for the term of the agreement and six years afterwards to meet the record-keeping obligations that follow a contract. Assistant conversations are not kept at all beyond the life of the request that produced them.

Every figure in this clause is a proposal in a draft. Retention is the first thing a data protection officer checks and the thing a draft is least entitled to state as settled, so it is flagged here rather than presented as operating practice, and it appears again at clause 18.

Token Observe is self-hosted, bring-your-own-key software. It runs on infrastructure you control, authenticates to model providers with keys you supply, and keeps its whole persistent state in one configured database on your disk. There is no vendor-operated component anywhere in the request path, and no hosted or managed offering exists.

It sends us nothing: no telemetry, no usage counter, no crash reporting, no licence callback and no phone-home of any kind. That is a property of the code rather than a setting you could forget to turn off — no such call exists to disable. The security page publishes the procedure for confirming it yourself in about five minutes, and section 9 of the licence exists so that you may run it, including fuzzing and penetration-testing your own deployment and commissioning somebody else to do it, with no gag clause and no pre-approval of what you publish.

The consequence for data protection is the important one. We hold no copy of your traces, your prompts, your policy decisions or your audit chain. We cannot reach your deployment and we hold no credential into your estate; every integration points inwards. And we cannot act on your instructions in respect of that data, because none of it arrives here. On the ordinary meaning of the words, supplying this software does not make Tenhaw a processor of anything that flows through it.

The same fact cuts the other way and is stated on the security page in the same terms: if the database file is lost and there is no backup, the traces and the audit chain are gone, because there is no vendor-side copy to restore from. Back it up like evidence, to storage the operators of the database cannot rewrite.

The architecture settles a technical question and does not by itself settle the legal one, so the position in clause 13 is stated for the running software and not for every arrangement around it. Four things can put personal data into our hands by choice rather than by design, and each needs an answer of its own.

A support ticket. The default is that we receive nothing, so a diagnostic bundle, a trace excerpt or an export attached to a ticket is a decision you make rather than something the product does. What happens to it is governed by the support agreement rather than by the architecture. Redact before sending.

An evaluation. The thirty-day evaluation grant in the licence excludes live production traffic and regulated personal data in its own words. An evaluation run inside those limits leaves the position in clause 13 intact; one run outside them does not.

Incident handling, and any design-partner or professional-services arrangement under which someone from Tenhaw is given access to your environment. Both create a relationship the architecture says nothing about.

Any hosted or managed offering. None exists today. If one ever does it is a different product with a different data position, and it needs its own notice rather than a paragraph added to this one.

Whether any of those requires a data processing agreement is a question for counsel rather than for a marketing page, and it is on the list at clause 18. The product’s own readiness documentation reaches the same conclusion and is careful about it: runtime phone-home is zero, while evaluation terms, support handling and anything you choose to put in a diagnostic bundle are contracts rather than architecture.

This is your processing rather than ours, and it is set out here because a controller cannot assess software whose storage they have to reverse-engineer. Every statement below is documented in full on the security page, and the limits travel with the claims.

The prompt corpus is bounded and post-redaction. A trace event holds an excerpt of up to four thousand characters, read off the outbound payload after redaction has run rather than off the original, so the search index cannot contain what the redactor removed; tool arguments and results are capped at sixteen thousand; redaction records are kinds and counts rather than values. Model response text is not stored. Full prompts are not stored. No API key exists in the database in any form.

Three tables deserve a data protection officer’s specific attention, and they are exactly the ones a summary would leave out. An approval record can contain up to 160 characters of unredacted model-generated text, because the action summary is built before egress redaction runs. Identity-provider group snapshots are attributes of a named person and should be treated like HR-adjacent data rather than like configuration. Radar findings can carry staff usernames, workstation hostnames and, where per-user seat spend is supplied, the email addresses of named employees.

Retention is unset by default, and unset means keep forever. That default over-satisfies the six-month minimum in Article 26(6) of the EU AI Act and satisfies nothing in Article 5(1)(e) of the UK GDPR, so a deployment processing personal data has to set the window rather than inherit it. Subject erasure reaches traces, trace events, the search index and trace scores, and nothing else: the audit log is deliberately never touched, which is what lets the record of a deletion outlive the deleted data, and approvals, radar findings and webhook delivery records are neither purged nor erasable by subject. Erasure acts on the live primary database, so restoring a pre-erasure backup can resurrect what was erased.

None of that is a Tenhaw processing activity. It is a map of where personal data in your own deployment actually sits, published so that your assessment can be done from documentation rather than from a support call.