Data protection
The retention default is keep forever, and that is a decision you have to make rather than one you can inherit.
On this page
What is already on you
- 01
Prompts are where unplanned personal data accumulates
The trace events table is the highest-sensitivity store in the system, and not because anyone designed it to hold personal data — because prompts and tool arguments are written by people and models solving a problem, and a customer’s name, address or condition arrives inside a sentence nobody classified. - 02
Storage limitation and an evidence obligation pull in opposite directions
One regime asks you to keep logs for at least six months; another asks you not to keep personal data longer than necessary. Both apply to the same rows. That tension cannot be resolved by a default, which is precisely why the default here is to keep and to make you choose rather than to delete quietly on an upgrade. - 03
Erasure requests will arrive for data nobody intended to collect
A subject-access or erasure request against a prompt corpus is a different exercise from one against a CRM, because the identifier that ties a person to the rows is a session or a delegated principal rather than a customer id. Reading that corpus to find them is itself a processing act — which is why the dry run is audited as well as the deletion. - 04
Directory group membership is HR-adjacent data, not configuration
A row saying which groups a named employee belongs to is personal data about that employee, and it should be treated the way you treat HR-adjacent data rather than as a settings table. It is capped, replaced wholesale at each sign-in, and aged out on its own window — twenty-four hours by default — separate from the trace window. - 05
Your model providers stay your processors
Nothing about installing a governance layer changes the agreements you hold with model and tool providers. What changes is that a per-agent data policy constrains which of them may receive a given payload, enforced on the fallback chain as well as the primary route, and refusing rather than silently downgrading when no route qualifies.
The objections, in the words they are raised in
Not a marketing FAQ. These are the sentences this reader says out loud in a first call, quoted rather than softened, and several of the answers below concede that the limitation is real and name the person who has to accept it.
- 01· asked
Is your redaction sufficient?
answeredNo, and Token Observe does not claim it is: it is described as a compensating control, not your only DLP. Detection is regex plus checksum, so what it catches it catches well and what it misses it misses entirely. Card numbers are Luhn-validated, IBANs mod-97 and NHS numbers mod-11, and those score between 0.9 and 0.98. National insurance and social security numbers score 0.85, telephone numbers 0.7, and free-text personal data — a name and a condition inside an ordinary sentence — is not detected at all. Confidence is exposed so your policy sets its own threshold rather than inheriting one. Secret kinds are always masked irreversibly whatever the policy mode says, because a reversible placeholder for a credential is a credential. The residual — false positives and false negatives, and nothing at all on free text — is named in the threat model as a risk requiring a dated acceptance from the Data Protection Officer specifically, not from an engineer and not from nobody.
- 02· asked
What is your retention policy?
answeredThere is no default period, and unset means keep forever — a decision you have to make rather than inherit. That over-satisfies the six-month minimum in EU AI Act Article 26(6) and satisfies nothing in GDPR Article 5(1)(e), so a GDPR-regulated deployment must set the trace retention window. The default is deliberate in both directions: retention should be decided rather than assumed, and an upgrade that silently began deleting a customer’s evidence would be the worse failure. Ageing runs hourly in small batches, each its own short transaction so a purge interleaves with traffic rather than stalling a fail-closed request path, and a status endpoint reports the window, the exact cutoff instant, the eligible count and the last pass — so configured and actually running stay separately checkable.
- 03· asked
Can you honour an erasure request?
answeredOn the live primary database, yes. Erasure takes a subject identifier and a match mode — the delegated principal, the session id, or either — with a dry run that returns the count before anything is deleted. Both the preview and the deletion are audited, the preview because reading the prompt corpus for a named person is itself an act worth recording, and the audit entry carries a SHA-256 digest of the identifier rather than the identifier, so the erasure record does not become a fresh copy of what was just erased. Two boundaries belong in the same breath: a retained full-snapshot backup preserves whatever existed when it was taken, so the precise claim is erased from the live primary rather than gone from every copy; and there is no endpoint that deletes an agent and its history.
- 04· asked
Is the vendor a processor? Do we need a DPA?
answeredIn the ordinary supply of the software the vendor holds no copy of anything — no telemetry, no phone-home, no licence callback, no hosted component — and the licence states that as an undertaking rather than leaving it to an architecture diagram, which is what removes the sub-processor and transfer-assessment path from most procurement. The undertaking is drafted rather than executed: the published licence carries a banner saying it needs counsel’s approval before it is relied upon, so the sentence your data protection team relies on has to be the one in your signed agreement. It is deliberately not stated as an absolute: no claim is made that the vendor is legally never a processor, because evaluation terms, support access and incident handling create arrangements counsel has to assess. The one exception is voluntary disclosure — a diagnostic bundle you choose to send. Redact it first, and if it would contain personal data, execute an agreement before you send it.
If the objection that would actually decide this for you is not one of the ones above, that is the more useful question, and it is the one worth sending.
Talk it throughWhat is stored, at what sensitivity, and the one place raw model output survives
One configured database holds the entire persistent state. There is no second datastore, cache tier, object store or external message broker, which makes the data-protection analysis unusually short: back up the configured database and you have backed up everything the product durably holds.
The highest-sensitivity table is trace events, and it is bounded rather than complete. It holds a post-redaction prompt excerpt capped at four thousand characters, tool arguments and results capped at sixteen thousand, policy decisions, and redaction records that carry kinds and counts but never values. The excerpt is read back off the outbound payload rather than the original, so it cannot contain the personal data the pipeline just removed. The traces table beside it is metadata only: agent, session, delegated principal, team, tags, status, token counts, cost, detected personal-data kinds and tool names, with no payload text.
One caveat is recorded rather than glossed, and it should shape how you classify the approvals table. When a policy requires approval for a tool call the model proposed, the approval summary is built as the tool name plus up to 160 characters of that proposal’s arguments, and it is built before egress redaction runs on the response — so an approval record, and the webhook event built from it, can carry up to 160 characters of unredacted model-generated text. It cannot carry unredacted prompt text, because the request was redacted before it reached the provider. Approvals raised on the tool gateway and on the request path carry no arguments at all.
- Model response text
- Not persisted. The response event records stop reason, upstream request id, token counts and content-block types rather than the generated text. Tool results are stored, capped, because a tool result is evidence of an action.
- Credentials
- No API key in any form. Provider keys, tool auth headers and webhook signing secrets are referenced by environment-variable name. Agent tokens are stored as a SHA-256 and a display prefix, and identity tokens from your provider are verified and read but never stored — no offline scope is requested, so there is no refresh token to replay.
- Rejected credentials
- Neither the presented secret nor a digest of it. Storing a digest would create an offline oracle against a secret that may well be live elsewhere in your estate, such as a mistyped production key from another system.
- Logs
- Structured JSON to standard output carrying method, matched route pattern, status, duration and identifiers. No query string, no request body, no headers and no prompt content — including at debug level.
- Encryption at rest
- Stated plainly because it is where reviewers find surprises: the database file is not encrypted by the product, so encryption at rest is whatever your volume or host provides. Effect recovery contexts are separately AES-256-GCM encrypted under a key derived from an environment secret, so database access alone does not decrypt them.
The tables a retention period does not reach
A retention statement that promises deletion after N days without naming the exceptions is inaccurate, and a DPO will find them. The trace window and subject erasure act on traces, trace events, the search index and trace scores. Nothing else — and the exclusions are decisions with reasons rather than gaps.
The audit log is never touched by retention, by design, because that is what lets the record of a deletion outlive the deleted data; chain verification still passes after a purge. Directory-group snapshots run on their own short window. Gateway caller sightings run on a separate ninety-day window, so quoting the trace window for them is wrong in both directions. Approvals, radar findings and webhook deliveries are not purged and cannot be erased by subject — and each of those carries something a DPO should classify deliberately.
- Approvals
- Not purged, not erasable by subject, and the one place payload-adjacent text survives a purge: up to 160 characters of unredacted model-proposed tool arguments.
- Radar findings
- Not purged, not erasable by subject, and they may carry workstation hostnames, staff usernames, service-account and key identifiers, and — where an operator supplies per-user spend — the email addresses of named employees.
- Webhook deliveries
- Keep the exact bytes posted to each receiver, and are not purged. Whatever a webhook carried, that table has a copy.
- Seats
- Outside both windows, and the only store whose primary subject is an identified member of staff rather than an operator. The endpoint seat surface is preview and should not be treated as production endpoint control today.
- Backups
- Outside every control here. Live retention, credential revocation and erasure act on the primary; a retained snapshot preserves what existed when it was taken. Backup scheduling, off-box placement, legal holds and proven deletion are operator-owned.
How redaction runs, in both directions, and where it gives up
Redaction runs inline and in-process before the request leaves — not asynchronously and not after the fact — which is what makes it a control rather than a report. Detection covers the checksum-validated identifier kinds, email and telephone, and secret kinds including JSON web tokens, cloud access keys, prefixed vendor API keys and private-key headers. Non-secret kinds are masked or tokenised according to the policy’s mode, and a tokenised value keeps a stable placeholder across one conversation so the model can still reason about the same customer without ever seeing them.
It runs in both directions. Responses are scanned too, so a data-class rule fires on an identifier the model produced even where nobody sent one. Streaming is covered by a hold-back buffer with a separate buffer for each tool-call argument channel, and the response-side decision is taken before the first byte, because a stream has no later enforcement point. The trace excerpt is taken from the outbound text after redaction, so the search index cannot contain what the redactor removed.
Where it gives up is stated in the same register as the claim. Matching is regex plus checksum, so free-text personal data and identifier formats outside the supported set are not detected at all. The residual is named in the threat model as a risk requiring acceptance by the Data Protection Officer specifically — not by an engineer, and not by nobody. Provider data-policy flags are a second, adjacent honesty: setting a zero-retention flag records your assertion about your contract with that provider, and the product cannot verify it. The assertion is itself audited, with the actor who set it.
The parts of the platform this leans on
In the order they matter to this reader rather than the order the platform argues them, and each one carries its own stated limit on the page it links to.
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
Flight recorder
Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL.
Model routing
Six upstreams behind one set of policies, and a fallback chain that will not launder a refusal.
Audit chain
Every administrative act hash-chained; seal it under a key held off the box, and anchor it with a signature your auditor can check alone.
Which data subject rights can this actually service?
Access and portability are supported directly: a trace read, a digest-sealed export and a period-bounded compliance bundle, in JSON. Erasure and a retention limit are supported on the live primary database once a window is set. Minimisation is partial — bounded excerpts and inline redaction reduce what is captured, but regex and checksum cannot find free-text personal data. One right has no mechanism at all and it is stated as such: there is no endpoint that deletes an agent and its history, so removing an agent’s whole record is not something the product does today.
Does personal data leave our network?
Only to endpoints somebody in your organisation configured, and only after policy evaluation and redaction. The complete list is your model providers, your registered tool servers, your webhook receivers, your identity provider during a human sign-in and your anchor sink — plus one public model-price catalogue that an administrator triggers by hand and that sends no prompt, trace or identifier. There is no default egress, and the last two do not exist at all until the corresponding feature is switched on. If your network policy allows outbound connections only to your providers, tool servers and webhook receivers, the product functions completely.
What does the per-agent data policy actually enforce?
Three independent requirements rather than one flag, because providers genuinely differ on each: require zero data retention, require no training on payloads, and require a serving region. Routing honours all three separately, on the fallback chain as well as the primary route, and a request that can find no route satisfying them is refused with a typed error rather than downgraded quietly to a provider that does not qualify. The honest limit: those provider flags are operator assertions about your contracts, unverified by the product, and the Head of Product is the named acceptor of that residual risk.
Who inside our organisation can read prompt content?
Whoever you grant it to, scoped twice and recorded. Every human account carries explicit team scopes alongside its rank, applied inside the queries and repeated on detail, search and export paths, and a caller cannot widen it with a query parameter. Sensitive trace list, search and detail reads append attributable audit events, so a read of the prompt corpus is itself part of the record. Demoting someone without setting an explicit scope drops any inherited organisation-wide access to nothing, so a role reduction cannot silently preserve full-corpus reach.
Is a DPIA required, and does the vendor help with it?
Whether one is required is your assessment to make; the product carries the reference rather than the conclusion. The agent record holds a DPIA or FRIA reference in its metadata, and that reference travels into the recertification snapshot and the compliance export. The support boundary is explicit on the rest: the vendor does not sign off your DPIA, FRIA, record of processing or risk register, and mapping a policy set to your control framework is a professional services engagement rather than support. The software is a compensating control and it does not discharge an obligation you owe.
Bring the objection that is not on this page.
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