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: 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 Web content you submit

When you submit a site for analysis, Tookii fetches it (via Firecrawl, with Bright Data as a fallback for sites Firecrawl cannot retrieve, on accounts where that fallback is switched on) and captures screenshots. Tookii fetches whatever URL you submit — a staging or pre-release URL is fetched like any other.

Private networks are refused. Addresses on private, loopback, link-local or cloud-metadata networks are refused at two points:

• Before a test starts: the host is resolved before anything is spent. A host that can't be resolved or verified is refused.
• During a browser test: every page the automated browser reaches is resolved again, and the visit ends if it points at a private network.

These checks run at every point Tookii can observe. Our retrieval and browser providers fetch from their own networks, so a redirect or DNS change that happens inside them is outside this control.

Captures are private. Screenshots of the submitted site are stored in a private bucket and served only to readers of that test, through an authenticated Tookii route.

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 the site you submit, plus the personas' generated reactions and the resulting reports.

• Goal tests can sign up and log in. A goal test may create an account on the site under test for each persona, using a persona-specific email inbox hosted by AgentMail and a generated password stored encrypted (AES-256-GCM). Recordings then include the logged-in pages the agent visits. Tookii never uses your own or your users' credentials.
• Step screenshots are stored in a private storage bucket and shown only through short-lived (one-hour) signed URLs, issued after checking that the reader owns the test.
• Video replays are recorded and held by Browserbase, which retains session recordings for 30 days under its published policy (at the time of writing).
• Persona intro audio is stored privately and served the same way. Persona portraits are AI-generated synthetic images with no customer content, and are served publicly.

3.7 Operational telemetry

Product analytics via PostHog: page and feature events keyed to the Clerk user id, plus your name and email address, the URLs of sites you test, short error messages, and the browser library's automatic interaction capture. 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. 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: well-formed contact and financial identifiers are removed before any model call; names — and any identifier the pattern pass cannot recognise, such as a handle or a phone number written out in words — transit once, to a contracted processor under enterprise terms, solely to be detected and removed.

Scope of de-identification. It applies to research uploads (this section) and to standing context set through our MCP connector (set_context). Other inputs — questions put to personas, product descriptions, A/B copy, design frames, and Focus Group stimuli (including PDFs, which are sent to the model as files) — are processed as supplied. De-identification also does not make proprietary business content confidential; that is protected by the access, storage, logging and subprocessor controls in §6–§7.

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 goal tests, routed through Browserbase's residential proxy network), Firecrawl and Bright Data (web retrieval), and AgentMail (persona email inboxes for goal tests). Browserbase receives the URL under test, every page the agent visits, the agent's interactions — including a persona's generated sign-up details in goal tests — and the session recording. Firecrawl and Bright Data receive the URL under test and return its content. On accounts where bot handling is switched on, goal-test sessions run in a Bright Data hosted browser instead of Browserbase: Bright Data then receives every page the agent visits and its interactions, and keeps no session recording. Bright Data is used only for accounts switched on by a server-side feature flag. AgentMail receives the emails the site under test sends to a persona.

---

6. Access control and tenancy

• Authentication is delegated to Clerk. Tookii holds no passwords.
• Tenant isolation is enforced in the application layer: data-access paths are scoped to the authenticated Clerk user identifier. Tenancy is per individual user; there is no organization-level tenant model today. Database Row Level Security is enabled on all application tables in a deny-all posture (verified against production, October 2026), 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, server-side query paths are reviewed against an isolation checklist (first audit August 2026, repeated October 2026), and the checklist is 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 (MCP connector): see the connector appendix for the full data-flow, controls and audit description. OAuth 2.1 with PKCE required. Access tokens are opaque and verified with the identity provider on every request, so a revoked token stops working immediately. Opaque tokens carry no audience. Tokens are bound to Tookii in two ways: a JWT naming a different resource is refused, and for enterprise accounts only explicitly approved connector apps (OAuth client ids) are accepted. This allowlist fails closed: if it is not configured, no app is accepted. The endpoint acts only as the user the token belongs to; there are no unauthenticated tools and no alternative credentials, and one switch takes the connector offline for everyone.
• Enterprise connector controls, applied per account under an enterprise policy and checked on every tool call:
  • Scopes: tookii:read, tookii:write, tookii:run, and tookii:browser (required in addition to run for tests that drive a real browser). A tool without a scope rule is refused.
  • An administrator tool allowlist; anything not listed is refused.
  • An allowlist of approved connector apps.
  • A per-user kill switch.
  • Six-month approvals. Each connection must be approved by the user in Account → Connections. Approvals expire after six calendar months, are recorded with who approved, when and for which scopes, and can be revoked there. A revocation takes effect on the connector's next request. Token refreshes and reconnects never extend an approval.
• Partner API: per-partner bearer keys held in the deployment secret store.
• 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, including the name-detection pass on standing context set through the connector, 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 sweep that runs every six hours in the application. Call records (timings, token counts, status, a short summary of the inputs) are deleted after 12 months by the same sweep. Error messages are reduced before they are logged: email addresses masked, URLs cut to their origin, long quoted text removed. Free-text previews of user questions are never logged.

Enterprise accounts are under a stricter policy:

• Prompt text is not stored at all.
• Input summaries keep only identifiers, counts and enumerations, and URLs only as a host name.
• The policy follows the account, so background work started by its users obeys it too.
• Existing logs are cleaned to the same standard when the policy is applied.

Security audit log

Security-relevant activity is written to an append-only audit log that holds metadata only, never content:

• MCP authentication failures, and every MCP tool call: who, which connected app, which tool, the outcome, the reason for any refusal, and the ids of the objects it created;
• authorization refusals;
• administrator access to another user's data;
• connector approvals and revocations, and account-policy changes;
• account and test deletions.

The database itself refuses updates, deletions and truncation of this log for every role, including the application's own. Entries leave only through a retention function that will not remove anything younger than 12 months. The log can be exported per user for a customer's audit request.

---

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

• Deleting a test (from the dashboard, or with the MCP connector's delete_run) removes it permanently: its report, its personas' visits and answers, its screenshots and its model-call log. A goal test is deleted as a whole.
• Uploaded research sources can be deleted individually from the product.
• Account deletion is self-service: Account → Security → Delete account. Deletion initiated by our identity provider, or by us on written request, follows the same path.
• What it removes: a hard delete of your tests, personas, uploaded research, run artifacts, reports, model-call logs, connector approvals, credits and connected-account tokens, together with their stored files: screenshots, uploads, intro audio and design frames.
• It is built to complete. Every target is recorded before anything is deleted. If any step fails, the deletion is retried from that record until it finishes, and repeated failures alert us.
• Copies held by providers:
  • AgentMail: persona inboxes are deleted.
  • PostHog: we request deletion of analytics data.
  • Browserbase: it offers no deletion interface. Session recordings expire under its 30-day retention, and we request earlier deletion on your behalf.
• Retained after deletion:
  • billing entitlement records (proof of purchase; the account link is removed, the purchaser email remains);
  • the security audit log (12 months);
  • a counts-only deletion receipt. It 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 until you delete the test or the account. AI-call prompt text is retained for 90 days, or not at all for enterprise accounts. Model-call records are kept for 12 months and the security audit log for 12 months (§6).

---

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.