--- title: "Solution: Data protection (by role)" canonical_url: "https://tokenobserve.com/solutions/data-protection" published: 2026-09-02 last_updated: 2026-10-21 --- # Solution: Data protection (by role) The retention default is keep forever, and that is a decision you have to make rather than inherit. ## The argument Cloud hosting holds workspace evidence and supplied credentials. For customer hosting, Token Observe runs on your own infrastructure with your own provider keys, and supplying the software does not itself send customer data to the vendor: there is no telemetry, phone-home or hosted component. That changes the data-custody review for that mode, and it is deliberately not an absolute: no claim is made that the vendor is legally never a processor. Retention and subject erasure are implemented, and the default is to keep everything: the retention variable is unset by default, which over-satisfies the six-month minimum in EU AI Act Article 26(6) and satisfies nothing in GDPR Article 5(1)(e). Detection before egress is regex plus checksum: a compensating control, not your DLP. ## Facts - Trace retention default: Cloud activity: 30 days. Customer hosting: unset means keep forever - Subject erasure: Yes, on the live primary database; the preview is audited too - Detection method: Regex plus checksum, with per-kind confidence exposed to policy - Vendor data copy: None in the runtime; counsel still decides the contractual roles ## The limit What a retention period does not cover: Approvals, radar findings, webhook deliveries, seats and the audit log all sit outside the trace window and outside subject erasure ## What this reader is under pressure about - Prompts are where unplanned personal data accumulates: The trace events table is the highest-sensitivity store in the system, and not by design: prompts and tool arguments are written by people solving a problem, and a customer's name, address or condition arrives inside a sentence nobody classified. - 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, and no default resolves that, which is why this one keeps everything and makes you choose. - Erasure requests will arrive for data nobody intended to collect: An erasure request against a prompt corpus is a different exercise from one against a CRM, because the identifier tying a person to the rows is a session or a delegated principal. Reading the corpus to find them is itself a processing act, so the dry run is audited too. ## What this reader asks, and the answer Q: Is your redaction sufficient? A: No, and Token Observe does not claim it is: it is 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. Cards are Luhn-validated, IBANs mod-97 and NHS numbers mod-11, scoring 0.9 to 0.98; national insurance numbers score 0.85; free-text personal data is not detected at all. Confidence is exposed so your policy sets its own threshold, and secret kinds are always masked irreversibly. Q: What is your retention policy? A: The cloud pilot configures activity retention to 30 days. Customer hosting has 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 window. The default is deliberate in both directions: retention should be decided rather than assumed, and an upgrade that silently began deleting evidence would be the worse failure. Q: Is the vendor a processor? Do we need a DPA? A: Cloud hosting holds workspace evidence and supplied credentials. For customer hosting, in the ordinary supply of the software the vendor holds no copy of anything (no telemetry, phone-home, licence callback or hosted component), and the licence states that as an undertaking rather than leaving it to an architecture diagram, which removes the sub-processor and transfer-assessment path from most procurement. It is deliberately not an absolute: no claim is made that the vendor is legally never a processor, because evaluation, support and incident handling create arrangements counsel has to assess. ### One setting decides whether any message text is stored at all. One configured database holds the entire persistent state, so back that up and you have backed up everything the product durably holds. Its highest-sensitivity table is trace events, and what that table holds depends on one setting. At the metadata default it holds no message text at all. Switch conversation capture to redacted and the same event carries the prompt as sent, the assistant reply, tool arguments and tool results, every string mask-redacted before truncation, bounded to 32,000 characters across at most 100 messages. - Model response text: At the metadata default the response event records stop reason, token counts and content-block types and no generated text. Set to redacted, the assistant reply is written as evidence, mask-redacted and bounded. - Approval records: The tool name, or the model name on the request path, plus the policy's own reason, mask-redacted, capped at 240 characters, and carrying none of the model's proposed arguments. - Encryption at rest: This is where reviewers find surprises: the database file is not encrypted by the product, so it is whatever your volume provides. ### A retention period does not reach these tables. A retention statement that promises deletion after N days without naming the exceptions is inaccurate, and a DPO will find them. The window and subject erasure act on traces, trace events, the search index and trace scores. Nothing else. The audit log is untouched by design, so the record of a deletion outlives the deleted data. - Approvals: Not purged and not erasable by subject. Each row carries the approver's identity, time and rationale, which is free text a person typed. - Radar findings: Not purged, not erasable by subject, and they may carry workstation hostnames, staff usernames and, where an operator supplies per-user spend, named employee email addresses. - Webhook deliveries: Not purged. Whatever a webhook carried, that table keeps the exact bytes posted to the receiver. - Seats, group snapshots and backups: Outside every control here. The seat census holds identified staff; group snapshots age out on their own twenty-four-hour window; a retained backup preserves whatever existed when it was taken. ## The capabilities that matter most to this reader, in order - https://tokenobserve.com/platform/policy-engine - https://tokenobserve.com/platform/flight-recorder - https://tokenobserve.com/platform/model-routing - https://tokenobserve.com/platform/audit-chain ## Questions and answers Q: Which data subject rights can this service? A: Access and portability directly: a trace read, a digest-sealed export and a period-bounded compliance bundle, in JSON. Erasure and a retention limit act on the live primary once a window is set, so the precise claim is erased from the primary rather than gone from every copy. Minimisation is partial: capture is metadata-only by default, but regex and checksum cannot find free-text personal data. One right has no mechanism: no endpoint deletes an agent and its history. Q: Does personal data leave our network? A: Only to endpoints somebody in your organisation configured, and only after policy evaluation and redaction: your model providers, tool servers, webhook receivers, identity provider and anchor sink, plus a public price catalogue an administrator triggers by hand, and the two vendor pull connectors if you enable them. There is no default egress. Q: Who inside our organisation can read prompt content? A: Whoever you grant it to, scoped twice and recorded. Every 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 reads append attributable audit events, so a read of the prompt corpus is itself part of the record.