Trust & Security

Twinbook is built to protect learners' data, uploaded course materials, the learning memory we generate, and every AI interaction in between.

Learners, educators, creators, and authors trust Twinbook with sensitive material — lecture slides, notes, textbooks, problem sets, research papers, and the record of how someone learns. That trust is the product. This page explains, in concrete terms, how we protect it: what we store, where it lives, who can reach it, what our AI providers can and cannot do with it, and the commitments we are willing to put in writing for the institutions, creators, and authors we work with.

We have tried to avoid security theater. Where something is a current control, we say so plainly. Where something is on our roadmap, we label it as a roadmap item rather than implying it already exists.

Last updated: 2026-06. For the machine-readable subprocessor list, retention schedule, and disclosure policy, see the linked pages at the bottom.

At a glance

Questions reviewers ask	Twinbook's answer
Who owns the data?	You do. Learners and institutions own their uploaded content and learning data.
Is learner data used to train AI models?	No. We do not train or fine-tune models on your content. We may fine-tune models on Twinbook-owned, licensed, public, or synthetic data to improve quality — never on user-uploaded content, learning data, or education records.
Can learners delete their data?	Yes. Deleting your account or a space removes the associated content from our databases and file storage. See Data retention & deletion.
Can learners export their work?	Yes. You can export all of your notes — including the drawings and images inside them — at any time. Your work is portable; there's no lock-in. See Export & portability.
Is data isolated per user / workspace?	Yes. Every content and learning-data query is scoped to the authenticated user and to spaces they are a member of, enforced in code on every request.
Is data encrypted?	Yes — in transit (HTTPS/TLS, HSTS) and at rest (AES-256, managed by our cloud provider).
What happens if someone uploads PHI?	Twinbook is an educational study tool, not a clinical system. We discourage uploading identifiable patient information unless a proper institutional agreement is in place. See HIPAA & PHI.
Can we review your subprocessors?	Yes. See our Subprocessors list.
Do you have audit logs?	Yes — request, authentication, AI-usage, and administrative actions are logged.
Can you complete a HECVAT?	A HECVAT is on our roadmap and we will complete one on request for active university evaluations. See University readiness.
Are you SOC 2 certified?	Not yet. SOC 2 is on our roadmap. We do not claim certifications we don't hold.

1. Data ownership

Learners and institutions own the content they upload and the learning data Twinbook generates from it. Uploading material to Twinbook does not transfer ownership to us. We process your content to provide the service — extracting structure, generating study materials, answering questions, and building your learning memory — and for nothing else.

We do not sell user data. We do not share it with advertisers. We do not use it to build products for third parties.

Your work is portable. You can export all of your notes — including the drawings and images inside them — at any time, so your study materials are yours to keep and take with you. There's no lock-in. See Data retention & deletion.

2. We do not train or fine-tune AI models on your content

This is a hard commitment:

We do not train or fine-tune models on user content. That includes user-uploaded content, learner data, institutional education records, learning memory, private notes, conversations, and uploaded course materials. None of it is fed into model training.
We may fine-tune models on our own data — never yours. Twinbook may develop, evaluate, or fine-tune models using Twinbook-owned, licensed, public, synthetic, or internally created datasets to improve accuracy and product quality. User content is excluded from all of it.
We select AI providers whose terms keep your content out of their training. When Twinbook uses AI providers for document understanding, generation, embeddings, or question answering, we send only the content needed to perform the requested task, through enterprise cloud AI providers under data-processing terms where submitted content is processed to serve the request and is not used to train their foundation models. The current list of providers and their roles is on the Subprocessors page.

If we ever introduce an optional feature that uses a customer's or learner's content to improve a model, it will be explicit, opt-in, off by default, and governed by clear terms — never a silent default.

3. Private learning memory, scoped to you

Twinbook builds a learning memory — the concepts you've encountered, what you appear to have mastered, your study sessions, and reflections — so the product can personalize review and surface what you're likely to forget.

Learning memory is scoped to the individual learner and the specific space (workspace) it belongs to. It is keyed by user and space on every read and write; one user's memory is not visible to another.
It is generated from your study activity, for your benefit. It is not pooled across users to build a shared model, and it is not used to train or fine-tune models (see §2).
It is deleted when you delete your account or the space it belongs to (see §8 and the Data retention & deletion page).

Roadmap (we won't overstate this): richer self-serve memory controls — an in-app view to inspect and selectively reset your learning memory without deleting the whole space — are on our near-term roadmap. Today, memory is reset through account/space deletion and on request to support. We'd rather tell you exactly where the line is than imply a control we haven't shipped.

4. Secure file handling

Uploaded PDFs, slides, images, notes, and problem sets are handled in controlled pipelines:

Bounded uploads. The API enforces request-size and per-route file-size limits, and validates content type. Oversized or malformed requests are rejected before processing.
Private storage. Files are stored in private cloud storage, not on a public bucket or a web server's disk. Stored objects are not publicly listable or directly addressable.
Signed, expiring access. When the app needs to display your PDF or an extracted image, it does so through short-lived, signed access tokens rather than permanent public URLs. Each token is cryptographically signed, bound to the specific document, and expires — so a link that leaks (in a log, a referrer header, a screen recording) has a bounded lifetime and cannot be reused against a different document.
Isolated processing. Document understanding (OCR, layout detection, chapter structuring) runs in internal services that are not directly reachable by end users; they accept work only from authenticated internal callers (see §6).

5. Encryption and access control

In transit: All client-to-server traffic is over HTTPS/TLS. We send HTTP Strict Transport Security (HSTS) headers, set conservative security headers (frame protection, content-type-sniffing protection, etc.), and strip server-fingerprinting headers.

At rest: Twinbook runs on enterprise cloud infrastructure. Data stored in our managed database, file storage, and document database is encrypted at rest with AES-256 by default, using provider-managed encryption keys. Internal service credentials and API keys are held in a managed secrets manager and injected at deploy time — they are not stored in source code or in plaintext environment configuration.

Access control: Access to user data is gated on every request through a layered authorization chain:

Authentication — the caller must present a valid session token (a verified identity token from our managed authentication provider or a signed Twinbook session token). Credentials themselves are managed by that provider; Twinbook does not store user passwords.
Resource ownership / membership — for anything inside a space, the request must belong to a user who owns or is a member of that space. This is checked in code before any content is read or written.
Entitlement / tier gates — feature- and quota-level checks (e.g., whether an AI action is permitted for the account) run after access is established.

We have tested these layers against cross-account access attempts (one user trying to read or modify another user's spaces, content, or members) and confirmed they are blocked at the appropriate layer rather than silently allowed.

Internal access by our team is restricted. Production access follows least-privilege service accounts, separated build / deploy / runtime identities, and secrets held in a managed secrets manager rather than shared with engineers directly.

6. AI provider boundaries

Twinbook uses external AI services for specific jobs — understanding documents, generating study materials, embedding concepts for retrieval, answering questions, and fetching transcripts for video content. We are transparent about this:

What is sent: Only the content needed for the task — e.g., the page image or extracted text for document understanding, the relevant passage and your question for an answer, a concept string for embedding. We do not attach advertising identifiers or sell context to providers.
What providers may do with it: We select providers operating under terms where submitted data is processed to serve the request and is not used to train their models (see §2). Each provider, its role, and the category of data it sees is listed on the Subprocessors page so any partner can review them.
Service-to-service trust: Our internal AI and processing services do not accept anonymous requests. Calls between internal services are authenticated, and queued events are verified by cryptographic identity before they are processed — so the AI pipeline cannot be invoked by an anonymous party on the internet.
Data residency: Our primary processing region is U.S.-based.

7. Defenses against prompt injection and unsafe content

Because Twinbook reads user-supplied documents and feeds them into language models, we take the risks described in the OWASP Top 10 for LLM Applications seriously — particularly prompt injection and unsafe output handling. Our approach:

Context boundaries. Retrieved document content is treated as data to reason over, not as instructions to obey. System behavior and tool use are not controlled by the contents of an uploaded file.
Grounded answers with citations. The Space Assistant answers from a retrieval layer over your own materials and cites sources, rather than free-associating — which both improves accuracy and limits the blast radius of injected instructions.
Safe rendering. Generated and exported HTML is sanitized against an allowlist (no scripts, no iframes), and our PDF/notebook export runs a hardened headless browser with JavaScript disabled and network requests restricted.
Educational-use framing. Outputs are study aids, not authoritative or clinical advice (see §9).

For more depth, see the blog post AI Safety in Education in our Research / Blog section.

8. Deletion and retention

Account deletion removes your user record and cascades to the data tied to it — your spaces, uploaded content blocks, study/activity records, and learning-memory-related rows.
Content / space deletion removes the item from our managed database, the corresponding documents in our document store, and the underlying files in cloud storage.
Financial records (e.g., purchase and subscription history) are retained as required for accounting, tax, and dispute-resolution purposes even after related content is removed.

The full schedule — what is deleted, what is retained and why, and how to request deletion — is on the Data retention & deletion page.

9. Educational-use boundaries

Twinbook supports learning, study, and review. It is not a clinical decision-support system, not a diagnostic tool, and not a source of authoritative medical, legal, or professional advice. AI- generated summaries, questions, and explanations are study aids that can contain errors and should be verified against primary sources and instruction. This is especially important for our medical- student users — see HIPAA & PHI for our position on patient data.

10. Audit logging

Twinbook logs the events needed to operate the service securely and to investigate incidents: authentication events, API request activity, AI-usage and cost accounting per account, and administrative actions. Logs are used for security monitoring, abuse prevention, billing integrity, and debugging — not for advertising or profiling. We are expanding structured audit trails as part of our SOC 2 readiness work (see University readiness).

11. Subprocessors

We use a small set of infrastructure and AI subprocessors (e.g., an enterprise cloud platform for compute, storage, database, and AI; a payments processor; a transactional-email provider). The current list — each named, with its purpose and the data category it processes — is maintained on the Subprocessors page so partners can review it as part of due diligence.

12. Compliance posture and university readiness

We are honest about where we are:

FERPA. Education records and student PII can be implicated when an institution uses an edtech service. We are prepared to operate under FERPA-aligned terms (including acting as a "school official" with a legitimate educational interest under an institutional agreement) and to sign a data-processing addendum. See FERPA.
HIPAA / PHI. Twinbook is designed for educational use. We discourage uploading identifiable patient information unless Twinbook has entered into the required agreements and controls with the institution. See HIPAA & PHI.
SOC 2. On our roadmap. We are aligning our controls to the SOC 2 Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy). We are not currently SOC 2 certified and do not claim to be.
HECVAT. We will complete a HECVAT (the higher-education vendor assessment) for active university evaluations, and intend to publish one as we mature.
Accessibility / VPAT. Accessibility is on our roadmap; a VPAT is a planned artifact.

The full roadmap, with what exists today versus what is planned, is on the University readiness page.

13. Reporting a vulnerability

We welcome reports from security researchers, institutions, and partner IT teams. If you believe you've found a vulnerability, please see our Responsible disclosure page for how to report it and what we commit to in return. Please do not test against other users' data.

More detail

Questions from a security, procurement, or partnerships team — at a university, a publisher, or a creator organization? Contact us and we'll work through your assessment, NDA, and any required agreements.