Security & data handling

NextPass is a voice-driven practice platform. A learner has a spoken role-play conversation with an AI character, then receives structured written feedback on their performance. Its first application is a management-coaching practicum.

A learner signs in, selects a practice scenario, and speaks with an AI character playing a counterpart — an employee, a peer, a manager. The conversation is a rehearsal. Afterwards the system produces a written debrief scoring the learner against a defined rubric.

Not collected, by design: payment or card data, Social Security or national identity numbers, health information, biometric identifiers, customer records, HR or personnel records, performance-review data.

  Learner's browser
     │  (HTTPS / WSS — TLS on every hop)
     │
     ├──────────────► Vercel — Next.js app; server-side authentication boundary
     │                   │
     │                   ├─► Supabase  — identity, transcripts, scores   [system of record]
     │                   └─► Anthropic — transcript text → written feedback
     │
     └──(live audio)──► ElevenLabs — speech in/out; audio never stored
                             │
                             └──(HMAC-signed webhook)──► our app ──► Supabase
                                    returns the text transcript only

  Errors and diagnostics ──────► Sentry

Microphone audio streams to ElevenLabs to power the conversation in real time and is discarded as it is consumed. What comes back to us is the text transcript, delivered over a signature-verified webhook. That transcript is the working record for everything downstream.

Compliance postures are each vendor’s own published attestations, verified 12 August 2026. Each vendor name above links to its trust centre, where current certifications and reports can be requested at the source. We recommend confirming there rather than relying on our transcription — attestations lapse and renew on the vendor’s schedule, not ours. We will supply each vendor’s DPA on request.

Our own DPA chain is not yet fully executed. Named in §10 with the rest of what is outstanding.

Sign-in

Magic-link (email one-time link, PKCE flow) is the primary and preferred method, and the only one used for enterprise cohorts. Passwords exist as a secondary path and are never stored by this application — Supabase Auth holds them hashed and performs verification. Compromised-password protection (HaveIBeenPwned) is enabled.

Single sign-on

Microsoft Entra ID SSO is built and available. It is not a switch we flip alone: it requires your IT to stand up an enterprise application and share federation metadata, plus a database-tier change on our side. Where an organisation adopts it, the password path is removed entirely and deprovisioning follows your directory.

Isolation

• No self-serve signup. Only email addresses we explicitly provision can authenticate. There is no public registration surface.
• Per-learner isolation is enforced in the database by PostgreSQL Row-Level Security, not by application code alone. A learner’s credentials cannot read another learner’s sessions, transcripts, or feedback even if the application layer were bypassed. Verbatim evidence quotes are readable only by the learner they belong to — deliberately not exposed to facilitators.
• Server-side identity is always re-verified against the authentication provider on every request. We never trust a client-cached token. An automated check fails the build if the unsafe pattern appears anywhere in the codebase.
• Privileged database access — the credential that bypasses row-level security — exists only in server-side webhook, scheduled-job, and administrative code paths, each of which authenticates its caller independently by HMAC signature or shared secret before doing anything. It is never present in the browser.
• Administrative access to production data is limited to the founder. There is no support tooling that surfaces learner conversation content to staff.

• TLS everywhere, with HSTS preload — two-year max-age, includeSubDomains.
• Hardened response headers in production: X-Frame-Options: DENY and CSP frame-ancestors 'none' (clickjacking); nosniff; Referrer-Policy: strict-origin-when-cross-origin; a Permissions-Policy restricting browser capabilities to the microphone alone, with camera, geolocation, and payment explicitly disabled.
• Content-Security-Policy with a tight source allowlist — self plus the named subprocessor domains. Currently deployed in report-only mode while we validate it against real traffic. Enforcement is planned; see §10.
• Inbound webhooks are HMAC signature-verified before the payload is parsed, are idempotent at the record level so replays cannot duplicate data, and are dead-lettered to an append-only table on failure rather than silently dropped or automatically retried.
• Microphone access requires an explicit user gesture every session. The application never opens the microphone on its own, and this is structurally enforced rather than merely intended — see 7.7 below.
• Secrets live in encrypted hosting environment variables and are never committed. The only credential stored in our source-control provider is a single read-only monitoring token.

7.1 · Which models do what

Model selections are pinned in code and asserted by an automated configuration check, so a silent substitution by us or by a vendor default is detected rather than discovered later.

7.2 · Training and data use

No vendor trains models on our data. Anthropic does not use API data for model training; inputs and outputs are retained up to roughly 30 days for safety monitoring and then deleted, and zero-retention arrangements are available. The voice vendor’s retention is covered in §8.

7.3 · Conversation audio

7.4 · Guardrails on what the AI will discuss

Three independent layers:

• Vendor-native guardrails, fully enabled — topic focus, manipulation resistance, and content filters covering sexual content, violence, harassment, self-harm, profanity, politics and religion, and medical or legal advice.
• Instruction-level constraints in each agent’s own prompt, defining what it will coach on and what it must decline and route to a human.
• A written, human-run proof suite that exercises hard-stop and soft-redirect cases against the live system, with recorded results and a sign-off. It is run against changes to the coaching agents rather than assumed.

Guardrail events are logged for review.

7.5 · Scoring validity, bias, and how scores may be used

An AI evaluates human performance here, so we want to be direct about the limits.

How scoring works. The transcript is evaluated against a defined rubric by several independent model passes — dimensional scoring, pattern identification, debrief composition, and a consistency check that re-examines the result for internal contradiction. Output is a structured record, not free prose, so scores are inspectable and comparable rather than impressionistic.

Rubric maturity — stated plainly. The rubric content is at version 1 and is theoretically derived. It will be revised against real session data. The data schema is stable; the scoring content is explicitly expected to change. We have not yet conducted formal inter-rater-reliability or adverse-impact studies, and we will not claim validation we have not performed. This is a genuine limitation, and it is why the formative-use constraint above is a condition rather than a preference.

Human oversight. A learner can always see their own transcript, scores, and feedback. There is no automated decision with a legal or similarly significant effect on any individual.

7.6 · Adversarial input

Learners speak freely to a language model. The guardrail layers in 7.4 constrain the model’s behaviour, and role-play agents hold no privileged data and have no tool access — there is no system for a learner to reach through them. A learner who works hard at it may be able to induce off-script responses; that is a quality issue in a rehearsal, not a path to anyone else’s data.

7.7 · Autonomy and spend containment

Every paid AI call is gated by a layered set of controls: it requires an explicit user gesture, it must first write a row to an append-only attribution ledger server-side, it is checked against per-user rolling spend caps, it is subject to a per-agent daily ceiling at the vendor, and a server-side kill switch can disable all paid voice instantly.

This is engineered so that a software fault, a retry loop, or an abandoned browser tab cannot quietly generate cost or call volume. We describe it under security rather than operations because the same property that contains cost also contains runaway automated behaviour — the system cannot act at scale without a person having initiated it.

At our voice vendor

In our own database

Transcripts, scores, and feedback are retained so learners can revisit past sessions. A matching 90-day expiry for transcript text in our own database is adopted policy and is not yet implemented — the deletion job is in build. Scores and feedback are intended to persist beyond that window so a learner’s history survives; transcript text is what expires. Until that job ships, transcript text in our database is retained. This is stated as an open item rather than presented as complete, and it is listed in §10.

Deletion and residency

Deletion on request is supported today as an operated process: a learner and all associated data can be removed on request, within 30 days. It is a manual database operation rather than a self-serve feature.

Data residency: United States. Supabase on AWS in a US region; Vercel US region; Anthropic and Sentry US.

• Every change is gated by continuous integration — TypeScript strict-mode type checking, a full automated test suite of over 4,000 tests, linting, dead-code and dependency analysis, and architectural import rules that prevent, for example, a row-level-security-bypassing database client from reaching browser-side code.
• The main branch is protected. Changes land through pull request with green CI.
• Database schema changes are reviewed and applied deliberately, never automatically, and each migration carries its own documented rollback.
• Configuration-drift detection. A scheduled job re-reads our live external configuration — voice-agent privacy settings, model pins, spend ceilings, webhook routing, hosting environment variables — and compares it against what the code says it should be. Drift is reported rather than discovered. Section 12 explains why this control exists.
• Error monitoring through Sentry, with events routed through our own domain so that ad-blocking does not create blind spots in production error capture.

An honest inventory, so nothing here arrives as a surprise later in your review.

Company profile. NextPass is operated by a small team and is in pilot. We think that is compatible with taking security seriously, and this document is our attempt to show the difference between controls we have automated and intentions we have not.

Reviewers evaluating a delivery or content partnership, rather than an IT deployment, usually want a different set of answers.

• Data ownership. Learner-generated content — transcripts, scores, feedback — belongs to the sponsoring organisation and the learner. We process it to operate the service.
• Content and IP. Practice scenarios, rubrics, character definitions, and scoring prompts are our intellectual property or are licensed from the programme owner, and are not derived from partner-supplied materials unless we agree so explicitly and in writing.
• Aggregate insight. We intend to offer sponsoring organisations aggregate, anonymised views of themes across a cohort or organisation. Where this is built, it will operate on derived labels rather than conversation text, will be stored unlinked from any individual account, and will be reported only above a minimum population threshold so that no individual is identifiable. This capability is in design, not in production, and this document will state plainly when that changes.
• Exit. On termination we will export learner records in a machine-readable format and delete our copies on request, within 30 days.

We publish the verification method alongside each claim, because the difference matters.

Why we built continuous verification

In July 2026 a routine reprovisioning of our voice agents silently re-enabled audio recording on several of them, by inheriting a default we had not overridden. We found it, removed the affected recordings, and — the part that matters — built an automated check that now asserts the setting on every agent and fails if it is absent, malformed, or changed. No customer data was involved; the sessions were our own internal testing.

We mention it because it is the reason this document distinguishes between a control that is asserted continuously and a setting that was once correct. Configuration drifts. A security document that cannot tell the difference between those two things is describing intentions.