1. What Tookii is, and why that matters for your risk review

Tookii generates synthetic user personas and runs them against a product experience — a website, an A/B copy variant, a set of product screens, or a moderated focus-group discussion — to produce research-style findings before a real user ever sees the change.

Two facts shape the risk profile, and they pull in opposite directions. We state both plainly, because a review that discovers the second one on its own will rightly discount the first.

Tookii is not a system of record for your customers' personal data. We do not receive your user database, we do not embed a tracking script in your product, and we do not observe or record your end users' sessions. The personas that browse your site are software agents, not people, and the recordings we store are recordings of those agents.

Uploading real customer research is a supported, first-class capability. Personas are far more useful when grounded in real evidence, so Tookii is built to accept your actual interview transcripts, support conversations and research notes — material that contains real people's personal data by its nature. Rather than asking customers to sanitise files by hand before uploading, we built de-identification into the ingest path: personal data is removed at upload, before anything is stored. Section 4 describes exactly how, and is the section a security reviewer should read first.

The practical consequence for your review: where you upload research, Tookii is a processor of personal data. We will execute your data processing agreement on request, and §12 sets out which obligations sit with you and which sit with us.

2. Architecture and hosting

All customer traffic reaches the application over HTTPS. HTTP Strict Transport Security is sent with a one-year max-age.

The application enforces the following response headers on every request (src/server/security-headers.ts): Content-Security-Policy (enforcing; ran in Report-Only mode first), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, frame-ancestors 'none', form-action 'self', object-src 'none', and Referrer-Policy: strict-origin-when-cross-origin.

---

3. What data Tookii processes

3.1 Account data

Name, email address, and authentication metadata, held by Clerk. Tookii stores only the opaque Clerk user identifier alongside application records; there is no local user table and no local credential store.

3.2 Your public web content

When you submit a site for analysis, Tookii fetches its public pages (via Firecrawl) and captures screenshots. This is the same content any visitor or search engine can retrieve.

3.3 Product context you provide

Free-text descriptions, positioning, target-audience notes, and A/B copy variants that you type into the product. Stored in your account's records.

3.4 Uploaded customer research — a supported capability

Interview transcripts, support conversations, sales-call notes and research documents you upload to ground persona generation in real evidence.

This is a designed use of the product, not an edge case. You are not expected to de-identify these files before uploading them — that is the job of the ingest pipeline in §4, which removes personal data before anything is written to storage. Uploading raw research is the intended workflow.

3.5 Uploaded product stimuli (optional)

Screens, mockups, PDFs and images used as stimulus material for Focus Group and Journey tests. These are stored in private object-storage buckets, readable only through short-lived signed URLs generated server-side.

Please note: stimulus uploads are treated as product artifacts and are not run through the personal-data redaction pipeline. Do not upload screens containing real end-user records. The product states this on the relevant upload surfaces.

3.6 Agent run artifacts

Recordings and transcripts of synthetic agents browsing your public site, plus the personas' generated reactions and the resulting reports.

3.7 Operational telemetry

Product analytics via PostHog (page and feature events, keyed to the Clerk user id) and a model-call audit log (§6).

3.8 What Tookii does not process

• Your end users' personal data, session recordings, or behavioural analytics.
• Payment card data — billing is handled entirely by our merchant of record (§7); card numbers never reach Tookii systems.
• Special-category personal data, health data, or financial account data as a designed use.

---

4. De-identification of uploaded research

Because uploading real research is a supported workflow (§3.4), the ingest path is the most security-critical component we operate, and it is engineered accordingly (src/server/pii/scrub.server.ts). The design goal: you upload the raw file, and what lands in our database cannot be traced back to the people in it.

upload → text extraction → structured redaction → name pseudonymisation → persist

1. Text extraction happens in our process. PDFs and DOCX files are converted to text server-side. Raw file bytes are never forwarded to a model in their original form.
2. A deterministic pass runs first, removing email addresses, phone numbers, national identity numbers, payment card numbers (Luhn-validated), IBANs, IP addresses and street addresses. This pass runs before any model sees the text, so no contact or financial identifier is ever transmitted to an inference provider.
3. A second pass pseudonymises person names, replacing them with stable tokens ([person 1], [person 2]) that preserve coreference across the document so the research signal survives.
4. Signal is preserved deliberately. Job title, seniority, company, industry and the narrative of the problem being described are retained — de-identification, not destruction.
5. Raw bytes are never written to storage. Redaction happens in memory; only the redacted text is persisted.
6. The mapping from real name to pseudonym is not stored anywhere — not in the database, not in a side table, not in logs. It exists only for the duration of the request. There is no key that would allow re-identification, by us or by anyone who obtained our database.
7. The pipeline fails closed. If redaction cannot complete, the upload is rejected. A partially redacted document is never written.

Redaction results are recorded as counts only (how many emails, how many names) so the process is auditable without the audit trail itself containing identifiers. Every customer can see this report for their own uploads.

4.1 What reaches a model, stated precisely

Reviewers ask this, and a vague answer is worse than an honest one.

The name-detection call runs on Google Cloud Vertex AI under the Google Cloud DPA: the content is not used to train Google's models, and it is not retained by us. We explicitly do not log the text of these calls into our own model-call audit log — that log records counts only for this pipeline, precisely because the text at that moment is the only un-pseudonymised copy in the system (§6).

So the accurate claim is: no direct identifier ever leaves our process, and names transit once, to a contracted processor under enterprise terms, solely to be removed.

4.2 De-identification, not reversible pseudonymisation

We describe the output as irreversibly de-identified. The distinction matters legally: because the name→token mapping is never written down, there is no key by which the output could be re-linked to individuals — not by us, not by a subprocessor, and not by anyone who obtained a copy of our database.

We stop short of claiming the output is anonymous data outside the scope of data-protection law. Retained context — seniority, company, industry, a specific complaint — can in principle single out an individual within a small enough population. We therefore continue to treat de-identified research as personal data for contractual purposes, and apply the same access controls, deletion rights and subprocessor commitments to it..

---

5. AI model providers and your data

Tookii performs inference through Google Cloud Vertex AI using a dedicated Google Cloud project under our control.

• Content sent to Vertex AI remains within Google Cloud under the Google Cloud Data Processing Addendum.
• Your data is not used to train Google's models. This is a contractual property of Google Cloud's terms (Cloud Data Processing Addendum; see also Google's "Generative AI and data governance" documentation for Vertex AI), not a setting we toggle..
• Access is governed by Google Cloud IAM and audit logging; authentication uses a service-account credential held only in the deployment environment's secret store.
• Tookii does not train, fine-tune, or otherwise improve any model using customer data. We are willing to make this a contractual commitment.

Certain features additionally use Browserbase (hosted browser sessions for agent replay) and Firecrawl (public web retrieval). Both receive only the public URL under test and the agent's own interactions with it.

---

6. Access control and tenancy

• Authentication is delegated to Clerk. Tookii holds no passwords.
• Tenant isolation is enforced in the application layer: every data-access path is scoped to the authenticated Clerk user identifier. Database Row Level Security is enabled on all application tables in a deny-all posture, so no table is reachable through the database's public API surface; the application connects with a privileged service credential from the server only, and that credential is never exposed to the browser. Because this architecture concentrates isolation in application code, we audited every server-side query path against user-scoped tables (August 2026): no cross-tenant access path was found, and the audit's checklist is now a standing requirement for new code.
• Administrative access to the internal observability console is gated on an explicit tookii-admin role assigned in Clerk. It is not granted by email domain and not self-service.
• Programmatic access: the Model Context Protocol endpoint authenticates via OAuth bearer tokens issued by Clerk, with scope and audience verification on every request. The Partner API uses per-partner bearer keys held in the deployment secret store, so a compromised key for one partner grants no access as another.
• Rate limiting is applied per client IP on public paths and per authenticated user on agent-driven paths.
• Inbound webhooks (identity, billing) are signature-verified before processing.
• Human access to production data is limited to two named individuals, each with their own accounts on the production consoles (Railway, Supabase, Clerk, Google Cloud, GitHub) — no shared credentials.

Model-call audit log

Every model and tool call is logged with its stage, model, latency, token counts and status, so that we can debug failures and attribute cost. Access is restricted to the admin role above.

Two properties matter for review:

• The name-detection calls in §4 are logged as counts only — never the text, never the detected names. This is enforced in code, because that text is the one point in the system where un-pseudonymised names exist.
• Other pipeline calls do retain their prompt text as a debugging receipt. Any research-derived content in those prompts has already passed through §4, so what is stored is de-identified text. Product context and public site content are stored as supplied.

Prompt text is retained for 90 days, then removed by an automated daily sweep; the call's operational metadata (timings, token counts, status) is retained with usage logs (up to 12 months, per our privacy policy). The sweep runs continuously in the application (src/server/jobs/retention.ts).

---

7. Subprocessors

The current list is maintained in subprocessors.md and is incorporated into this document by reference. We will give notice of new subprocessors with 30 days' notice.

---

8. Secure development and change management

• All application code lives in a private GitHub organisation with branch-based promotion: feature → dev → staging → production. Production deploys only from the production branch.
• Pull requests run automated type-checking and an end-to-end test suite before merge.
• Deployment is automated through GitHub Actions to Railway; no engineer deploys from a laptop.
• Dependencies are pinned via a committed lockfile and installed with --frozen-lockfile.
• Secrets are held in the platform secret store (Railway service variables, GitHub Actions secrets). No credential is committed to source control; service-account key files are explicitly excluded at the repository level.
• Database schema changes are versioned as numbered migration files in source control, reviewed in the same pull request as the code that requires them. Application to each environment is performed by an authorised engineer, dev → staging → production in order; the migration file is the record of what changed and the pull request records why and by whom. (We are candid that this step is manual today; automating it is on the roadmap and our internal change-management document describes the current process.)

---

9. Availability

• The application runs as a managed container service with platform-level health checking and restart.
• Object storage is replicated by the storage platform.

---

10. Data retention and deletion

• Records are scoped to your account and to individual test sessions. Deleting a session cascades to its associated discovery data, personas, run artifacts and reports.
• Uploaded research sources can be deleted individually from the product.
• Account deletion is self-service: Account → Security → Delete account. Deletion is immediate and hard: all sessions, personas, uploaded research, run artifacts, reports, credits and connected-account tokens are removed, along with the associated storage objects. Deletion initiated by our identity provider (or by us on written request) flows through the same code path. Retained after deletion: billing entitlement records (proof of purchase, unlinked from the deleted account) and a counts-only deletion receipt — the receipt contains a hashed identifier and per-table counts, no personal data, and is what lets us evidence that a deletion was honoured.
• Retention: run artifacts and reports are retained for the life of the account and deleted on account closure. AI-call prompt text is retained for 90 days (§6); usage logs for up to 12 months.

---

11. Privacy and legal

• Data Processing Agreement: we will execute your standard DPA on request — most organisations prefer their own paper, and ours is deliberately not a precondition for evaluation.
• Roles: for customer content processed through the platform, you are the controller and Tookii is the processor.
• Purpose limitation: uploaded research is used solely to generate personas for your account. It is not used to serve any other customer, is not pooled across accounts, and is not used to train or improve any model (§5).
• International transfers: our subprocessors are US companies; data at rest lives in the AWS Tokyo region (Japan — EU adequacy decision) and application hosting is in the US. Standard Contractual Clauses are relied upon where required.
• Sub-processing: we do not sell, rent or share customer content with any third party beyond the subprocessors listed in §7.

---

12. Shared responsibility for uploaded research

De-identification at ingest is a strong control, but it operates on data you have already decided to send us. A few obligations necessarily remain with you as controller, and we would rather state them than let them go unexamined.

Ours

• Remove personal data at ingest, before storage, as described in §4, and fail the upload rather than store a partially de-identified file.
• Never retain the raw file, and never retain any mapping that would permit re-identification.
• Restrict access, honour deletion requests, and hold subprocessors to the commitments in §7.
• Notify you of a confirmed breach on the timeline in §13.

Yours

• Have a lawful basis for sharing the research with a processor, and ensure your own privacy notice and participant consents permit it.
• Do not upload special-category data (health, biometric, racial or ethnic origin, political or religious belief, sexual orientation), children's data, or payment and credential data. The pipeline is not designed for these and we do not accept them.
• Upload research material through the research-upload path specifically. Stimulus uploads for Focus Group and Journey tests are not de-identified (§3.5) — they are treated as product artifacts. Screens showing real user records belong in neither path.
• Tell us if a research participant exercises a deletion right, so we can remove the source.

The special-category exclusion above is stated in-product on the upload surface and in our privacy policy.

---

13. Incident response

• Security issues can be reported to security@tookii.ai; reports are acknowledged within two business days.
• We will notify affected customers of a confirmed personal-data breach without undue delay and in any case within 72 hours of confirmation, with a description of the incident, the data involved, and our remediation. Where a customer's DPA specifies a shorter timeline, that timeline applies.
• We maintain an internal incident-response runbook covering declaration, containment, assessment, notification and post-incident review.

---

14. Compliance roadmap

Tookii is an early-stage company. We are transparent about where we are:

We are willing to make specific security commitments contractually, including a target date for SOC 2 attestation, breach-notification timelines, and the no-training-on-customer-data commitment in §5.

---

15. Contact

Security and vendor-review enquiries: security@tookii.ai We will complete standard vendor questionnaires (SIG Lite, CAIQ, or your own) on request.