How Twinbook Protects Student Learning Data

Twinbook Trust & Engineering series · ~10 min read

Twinbook asks for something significant: upload your lecture slides, your notes, your textbooks, your problem sets — and let an AI help you learn from them. For a medical student, that material is the core of years of work. For a university, it can include education records covered by law.

So "trust us" isn't good enough. This post explains, concretely, how we protect learner data — what we store, who can reach it, what our AI providers can and can't do with it, and where the boundaries are. Where something is on our roadmap rather than shipped, we say so.

Data ownership: it's yours

Learners and institutions own the content they upload and the learning data Twinbook generates from it. Uploading to Twinbook does not hand ownership to us. We process your content to run the service — extracting structure, generating study materials, answering questions, building your learning memory — and for nothing else. We don't sell user data. We don't share it with advertisers.

We don't train or fine-tune AI models on your content

This is a hard line, and it's worth being precise about.

We do not train or fine-tune models on user content — not on the pages you upload, your notes, your conversations, your learning memory, or institutional education records. None of it is fed into model training.

We may fine-tune models on our own data — Twinbook-owned, licensed, public, synthetic, or internally created datasets — to improve accuracy and product quality. Your content is never part of that. (So the honest promise is "we don't train on user content," not the vaguer "we don't train anything.")

And we choose AI providers whose terms keep your content out of their training. Document understanding, generation, and embeddings run through enterprise cloud AI providers under data-processing terms where submitted content isn't used to train the provider's foundation models. We publish the providers and what each one sees on our Subprocessors page.

If we ever build a feature that uses content to improve a model, it will be explicitly opt-in and off by default — never a silent change.

Private learning memory, scoped to you

The thing that makes Twinbook more than a PDF reader is learning memory: the concepts you've encountered, what you seem to have mastered, your study sessions. That's what lets the product resurface what you're about to forget.

Learning memory is scoped to you and to the specific space it belongs to. It's keyed by user and space on every read and write, so one learner's memory is never visible to another and never pooled to build a shared model. It exists for your benefit, and it's deleted when you delete your account or the space it lives in.

We'll be honest about the current limit: today you reset memory by deleting the space or your account, or by asking support. A self-serve in-app control to inspect and selectively reset memory is on our near-term roadmap. We'd rather name that gap than imply a button that doesn't exist yet.

Secure file handling

When you upload a PDF, slide deck, image, or note:

  • The API enforces size limits and content-type validation, and rejects oversized or malformed requests before doing any work.
  • Files are stored in private cloud storage — not a public bucket, not a server's disk. They aren't publicly listable or directly addressable.
  • When the app displays your document, it uses a short-lived, signed access token rather than a permanent public link. Each token is cryptographically signed, bound to that specific document, and expires. So if a link ends up in a log or a screen recording, it has a bounded lifetime and can't be swapped to point at someone else's file.
  • The heavy processing (OCR, layout detection, chapter structuring) runs in internal services that don't accept anonymous requests — they only take work from authenticated internal callers.

Encryption and access controls

In transit: everything is HTTPS/TLS, with HSTS and conservative security headers.

At rest: Twinbook runs on enterprise cloud infrastructure. Your data in our managed database, file storage, and document database is encrypted at rest with AES-256 by default. Internal credentials live in a managed secrets manager and are injected at deploy — not stored in code.

Access control runs on every request, in layers:

  1. Authentication — you must present a valid identity (a verified identity token from our managed authentication provider or a signed Twinbook session). Notably, Twinbook never stores your password — credentials are handled by that provider.
  2. Ownership / membership — for anything inside a space, you must own or be a member of that space. This is checked before any content is read or written.
  3. Entitlement gates — quota and feature checks run after access is established.

We've tested these against the obvious attack — one user trying to read or edit another user's spaces, content, or members — and confirmed those attempts are blocked at the right layer instead of quietly succeeding. Internally, our team's production access follows least-privilege service accounts with separated build, deploy, and runtime identities.

What our AI providers see

We're transparent about the fact that AI work involves external services, and about what we send: only the content needed for the task — the page for document understanding, the relevant passage and your question for an answer, a concept string for an embedding. We don't attach advertising identifiers, and we select providers under terms where your content isn't used to train their models. Calls between our own services require an internal credential, and queue events are verified by cryptographic identity before they're processed — so the pipeline can't be driven by an anonymous party on the internet. Our primary processing region is in the US.

Defending against prompt injection

Because we feed user-supplied documents into language models, we take the OWASP "Top 10 for LLM Applications" risks — especially prompt injection — seriously. Document content is treated as data to reason over, not as instructions to obey; the Space Assistant answers from a retrieval layer over your materials and cites its sources; and any generated/exported HTML is sanitized against a strict allowlist. There's a dedicated post on this — Our Approach to AI Safety in Education.

Deletion

Delete a document or a space, and Twinbook removes it from the database, the document store, and the underlying files in cloud storage — with relationships configured to cascade so nothing is orphaned. Delete your account, and that cascades to the data tied to it. We retain financial records (purchases, subscriptions) as required for accounting and tax, even after content is removed. The full schedule is on the Data retention & deletion page.

An honest word on compliance

We serve medical students, so we're careful here. Twinbook is an educational study tool, not a clinical system — please don't upload identifiable patient information unless your institution has the required agreements in place (see HIPAA & PHI). For institutions, we're prepared to operate under FERPA-aligned terms and sign a data-processing agreement. SOC 2 and a HECVAT are on our roadmap; we'll complete a HECVAT for active evaluations, and we will not call ourselves "SOC 2 compliant" until we are.

That last point matters more than any single control: the fastest way to lose a security reviewer's trust is to overstate your posture. So we've tried to draw the lines exactly where they really are — what's shipped, what's on the roadmap, and where you should still be careful.

Want the full detail? See our Trust & Security page, our Subprocessors list, and our University readiness roadmap. Found a security issue? Our responsible disclosure page explains how to reach us.