How askonor handles trust.

askonor is an AI-powered research platform. Researchers use it to run structured and exploratory studies; respondents answer questions in their own words, in text or voice. The data this generates (transcripts, scores, contact info) is real research data, and we treat it that way.

A Data Processing Addendum (DPA) is available for all customers. This statement reflects the system as it stands today. If you are evaluating askonor for an enterprise rollout and need something more formal (sub-processor change notification SLA, SOC 2 evidence package), email [email protected] and we will tell you honestly where we are.

Who touches your data.

These are the third-party services askonor uses to deliver the product. Each one was verified against the running codebase and live infrastructure on 2026-05-20. If we add or change a subprocessor, we update this page.

Configured but not active

The codebase has an integration with ElevenLabs, Inc. for full-duplex conversational voice. That surface is currently disabled and no respondent data is sent to ElevenLabs in the current deployment. If we activate it, this page will be updated before the flag flips and ElevenLabs will move into the active list above.

What we collect, keep, and delete.

What gets stored

When a respondent completes a study, we store:

• The full conversation transcript (every assistant turn and every respondent reply).
• Structured answers (Likert scores, multiple-choice picks, integer values).
• AI-generated insights (themes, evidence quotes, summary).
• Timing metadata (started_at, ended_at, message timestamps, cost in cents).
• Optional respondent identity — only if the researcher chose to issue a tracked invitation (name, email). Anonymous distribution links do not capture respondent identity.

Where it lives

Everything above lives in the Supabase project that backs askonor (PostgreSQL with row-level security enabled on every public table). It does not get copied to a separate analytics database. We do not sell or share research data with anyone outside the subprocessor list above.

Retention

Research data (transcripts, structured answers, generated insights) is retained for as long as the associated account is active. We do not auto-expire completed sessions on a fixed clock — researchers expect to be able to revisit historic studies, and the data lives with the account.

When a researcher deletes their account, their data is deleted with it. Projects deleted from inside an active account are soft-deleted for 30 days (so a mis-click is recoverable), then hard-purged by a scheduled sweeper. Accounts that go inactive for an extended period may be flagged for cleanup; if that ever applies to your account we will email you first.

If your procurement requires a specific maximum retention window (e.g. transcripts purged 90 days after study close), we can configure that per account or per project — tell us what you need.

Deletion requests

Respondents and researchers can both request deletion of their data by emailing [email protected]. For a respondent, we need either the invitation link they used or enough context to identify the session (study name + approximate date). We honor deletion within 14 days and confirm by email.

Privacy policy.

This policy covers two audiences: respondents who answer questions through an askonor interview, and researchers who run studies on the platform. The rules are similar but not identical, so they are split out.

For respondents

If you got here from an askonor interview link, here is the short version:

• What you say in the interview is recorded as text. If the researcher enabled voice mode, audio is transcribed in your browser and then processed as text; we don't keep the raw audio after transcription.
• The researcher who invited you can read your transcript. They may also see AI-generated themes and quotes from it.
• Anthropic processes the transcript on our behalf to power the interviewer and generate insights. OpenAI processes the next single sentence the interviewer is about to speak (voice mode only) — they do not receive your replies.
• If you arrived from a tracked invitation, the researcher already had your name or email. If you arrived from an anonymous link, we don't know who you are.
• To request deletion of your transcript, email [email protected] with the invitation link or enough context to find the session.

For researchers

• We collect your email, name, and the contents of the studies you build (topic, goal, questions, advanced configuration).
• We log usage metrics (sessions started, LLM spend in cents) for billing and capacity management.
• You control the respondent identity surface: tracked invitations capture name/email; anonymous links do not.
• You are the controller of the respondent data your studies generate — we are the processor. Deletion requests from your respondents can be forwarded to us; we will execute them and confirm.

What we don't do

• We don't sell respondent or researcher data.
• We don't use interview transcripts to train any model. The Anthropic and OpenAI APIs we call are not opted in to provider training on customer data.
• We don't include respondent contact info or researcher account email in any LLM prompt context (see the security section for the audit).

How askonor is secured.

Authentication

Researcher accounts authenticate via Supabase Auth (magic link or OAuth). The application enforces a dual-mode resolver server-side: requests carry a Supabase JWT in the Authorization header, which we validate on every researcher route. A legacy token path is also accepted for accounts on the prior auth system.

Respondents do not authenticate. Their session is gated by a per-session bearer token issued at /api/session/start and invalidated when the session completes — duplicate-end calls return 401. For tracked invitations there is an additional invitation-redemption step that mints the bearer.

Row-level security

Row-level security is enabled on every public Supabase table. Researchers can only read their own rows; respondents can only act on their own session via the session bearer. There is no shared-tenancy data leak path through the database client — service-role access is server-only and never exposed to the browser.

Transport & headers

All traffic is HTTPS. The server sets Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a strict Referrer-Policy, and a Content-Security-Policy that constrains connect-src to self, Anthropic, and Supabase. CSP will tighten via nonces in a near-term update.

Third-party prompt boundary

We audited what actually leaves the system when an interview runs. As of 2026-05-20, the only data sent to Anthropic for an interview turn is: the system prompt (interviewer rules, the researcher-authored guide topic/goal/questions, the verbatim opening line) plus the running conversation messages (assistant turns and respondent turns). Researcher account email, respondent contact info, invitation metadata, and session UUIDs are not injected into the prompt context.

For post-interview insight extraction the full transcript ships to Anthropic with the research goals, again without identity metadata. For the browser-voice path, only the next sentence to be spoken ships to OpenAI; no transcript or respondent context.

Whatever the respondent self-discloses in their answers is, by nature, in the transcript and therefore in the LLM call. We don't strip that; the interviewer needs the full conversation to probe coherently. If your study domain requires PII redaction before LLM processing, tell us — it is a configurable behavior we have not yet built.

Secrets & keys

Provider API keys (Anthropic, OpenAI, Supabase service role) live in Cloud Run environment variables, not in source. The browser only ever sees the Supabase anon key (which is gated by RLS) and the public product URL.

Compliance posture

askonor's controls map to the policies and practices tested by SOC 2 and ISO 27001 — access control, encryption in transit, least-privilege service accounts, audit logging, secrets management, and the prompt boundary documented above. We have not yet completed a formal SOC 2 or ISO 27001 audit; we will say so plainly until we have. If your procurement requires either certification, talk to us about the timeline — it is on the roadmap, not aspirational.