Privacy Policy

Tolus, Inc. (“Tolus”, “we”) provides an oral defense layer for written assignments. This policy describes what we collect, why we collect it, who we share it with, and how we handle it. We follow this policy for every teacher and every student who uses Tolus.

Who the policy applies to

Tolus has two types of users: teachers, who sign in with their school’s learning management system (LMS) — Google Classroom, or Canvas or Schoology where their school has connected one — to set up defenses for their classes, and students, who complete a defense using a private PIN assigned for their class. Students do not create accounts. We also receive contact details from people who apply for a pilot.

Pilot applications

When someone applies for a pilot, we collect the name and email address they provide and, when provided, their role, school or organization, and pilot goal. We also store a request identifier and a one-way hash of the normalized application to prevent duplicate retry submissions. We store this application in our database and send email copies through Resend so our team can review the request, respond to the applicant, and plan a potential pilot. Submitting an application does not create a Tolus account or authorize student-data processing.

Pilot application records are automatically deleted after 12 months. An applicant may ask us to correct or delete their application sooner by emailing hao@tolus.dev.

What we collect from teachers

• Name and email address from your LMS sign-in, plus your Google profile photo when you sign in with Google.
• Your LMS course or section list, assignments, and student rosters for the courses you connect (Google Classroom, or Canvas or Schoology where your school has connected one).
• A long-lived LMS credential — a Google or Canvas OAuth refresh token, or a Schoology OAuth 1.0a access token. We store this credential so Tolus can continue to act on your behalf in your LMS — reading assignment materials and student submissions, and writing the defense assignment, per-student PIN delivery, and grades back (and, for Google, transcript documents) — without asking you to re-authorize before every defense. The credential is encrypted at rest, stored server-side, and used only for the purposes described in this policy.
• The defense configurations you create: assignment context, rubrics, and pass thresholds.

What we collect from students

• The student’s full name, email address, and LMS user ID (Google Classroom, Canvas, or Schoology), as supplied by the teacher’s roster.
• The student’s Google profile photo. We fetch this live for display to the teacher and do not store it.
• A per-student PIN used to start the defense. Because the teacher must be able to see and distribute the PIN, it is stored in readable (un-hashed) form by design.
• The audio of the oral defense, streamed from the student’s browser for real-time transcription (see below).
• The text transcript of the defense, the AI’s questions, the resulting score, and the AI feedback.
• If the teacher enables photo verification and the student explicitly consents, verification images captured during the defense. Tolus stores them in the teacher’s Google Drive for human review only; it does not run facial recognition, biometric identification, or AI analysis on them.
• Any free-text feedback the student chooses to submit after a defense.
• For security and abuse prevention, a truncated (masked) IP prefix and a device identifier in our authentication logs.

Student voice and audio

During a defense, the student’s spoken audio streams directly from the browser to our speech-to-text subprocessor (Deepgram) over an encrypted connection for real-time transcription. Tolus never stores the audio — we keep only the resulting text transcript.

We want to be transparent that we treat a person’s voice as biometric personal information and handle it accordingly. Even though Tolus does not retain audio, we handle the streamed voice with that sensitivity in mind: it is used solely to transcribe the defense, it is not used to identify, profile, or advertise to anyone, and it is never sold or used to train models.

How we use it

• To run the defense: the AI uses the student’s submission, the rubric, and the in-progress conversation to ask follow-up questions and produce a score and feedback.
• To deliver results: the score and transcript are returned to the teacher and the grade is posted back to the teacher’s LMS gradebook (Google Classroom, Canvas, or Schoology). For Google, a transcript document is also created in the teacher’s Google Drive and shared to the student’s email when configured. When consented photo verification is enabled, the verification images are stored in a teacher-controlled Drive folder for human review. Canvas and Schoology have no document-storage equivalent, so the transcript stays in Tolus.
• To operate, secure, and improve the service: we log requests for debugging and abuse prevention, and we relay student-submitted feedback to our team.

We do not sell or share student data, share it with advertisers, use it for targeted advertising or profiling, or use it to train any model. Student submissions and transcripts sent to our AI subprocessor are excluded from training under that provider’s API terms.

Subprocessors

We rely on a small set of vendors to operate Tolus. Each is contractually bound to handle data only to provide service to us.

• OpenAI — generates the AI’s defense questions and scoring. Receives the student’s submission text, the live transcript, and the rubric. This data is excluded from training under OpenAI’s API terms.
• Deepgram — speech-to-text and text-to-speech. Receives the student’s defense audio directly from the browser for transcription, and receives the text of the AI’s questions to synthesize the spoken voice the student hears.
• Supabase — hosts our Postgres database in the United States. Stores all of the personal data described above.
• Google — authenticates teachers and provides read and write access to Google Classroom and per-file access to Google Drive on the teacher’s behalf. Tolus uses the Google Docs API with documents.readonly to read native Google Docs that a teacher attaches as assignment materials or that a student submits. It uses drive.file to create, update, organize, and share only Tolus-created transcript documents and consented verification images. Tolus does not read non-Google-Docs submission files such as PDFs or other uploads.
• Instructure (Canvas LMS) — only where your school has connected Canvas. Authenticates teachers and provides read and write access to the school’s Canvas on the teacher’s behalf, governed by an administrator-issued developer key. Tolus reads the teacher’s Canvas courses, rosters, and assignments (including teacher-attached PDF, Word, and text materials, which it reads to ground the AI’s questions), and writes back the defense assignment, each student’s grade, and a private per-student Canvas message (Conversation) delivering their PIN. The school’s Canvas instance is the school’s own system of record.
• PowerSchool (Schoology LMS) — only where your school has connected Schoology. Authenticates teachers and provides read and write access to the school’s Schoology on the teacher’s behalf, governed by an administrator-issued OAuth key. Tolus reads the teacher’s Schoology sections, rosters, and assignments (including teacher-attached PDF, Word, and text materials), and writes back the defense assignment, each student’s grade, and a private per-student Schoology message delivering their PIN. The school’s Schoology instance is the school’s own system of record.
• Vercel — hosts the Tolus web application. Vercel Analytics measures anonymous, aggregate page usage on the public site and teacher and administrator product pages, but is disabled on student-facing defense pages (/defense) and student report routes (/report). Before an event is sent, Tolus removes query strings and replaces course, session, school, and district identifiers in known dynamic page paths with route templates. It uses no third-party cookies or persistent cross-site identifiers. Tolus does not send transcript content or student answers as analytics properties.
• PostHog — receives a limited set of explicit events from the public site and teacher and administrator product pages, such as a pilot application, opening a class, or opening the billing portal. Tolus disables automatic click and pageview collection, session replay, heatmaps, performance capture, and automatic exception capture. Browser event properties are restricted to enumerated coarse values such as LMS provider, account type, CTA placement, or a count. Server events for defense publication and subscription changes use an organization-scoped identifier where available. Tolus does not send PostHog names, email addresses, course identifiers, page URLs, query strings, transcripts, student answers, or exception payloads. PostHog does not receive events from student-facing defense pages. Tolus disables PostHog person processing and does not store its anonymous browser identifier in cookies or browser storage.
• Resend — delivers our transactional email. This includes student-feedback emails sent to our team (which contain the student’s name and the verbatim feedback they submitted), beta-application emails, and LMS connection-request emails (Canvas and Schoology “Connect” requests, which contain the requester’s name, email, and school).
• Stripe — only for schools on a paid plan. Processes our subscription billing in the United States. Receives the billing contact’s name and email, the school or organization name, and payment details entered directly with Stripe (Tolus never sees or stores card or bank numbers). Stripe does not receive any student data, transcripts, or coursework.

Google Limited Use disclosure

Tolus’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In plain English, here is how we handle Google Workspace data:

• What we access. With the teacher’s authorization, we read the teacher’s Classroom courses (classroom.courses.readonly), rosters (classroom.rosters.readonly), and student submissions (classroom.student-submissions.students.readonly); the teacher’s assignment materials; and the Google Docs a student attached to the relevant Classroom assignment. We read each rostered student’s email address (classroom.profile.emails) and profile photo (classroom.profile.photos) so the teacher can identify students in the roster and so each transcript is shared to the correct student’s email; the profile photo is fetched live for display and is not stored. We read the text of those native Google Docs through the Google Docs API with documents.readonly so the AI can ask defense questions grounded in the student’s actual work. We do not request a broad Drive read scope and do not read non-Google-Docs submission files such as PDFs or other uploads.
• What we create and write. Using the classroom.coursework.students scope, Tolus creates the defense assignment (coursework) inside the teacher’s chosen Google Classroom course — this is how students receive the defense link — and posts each student’s grade back to that assignment when the defense is complete. Using the classroom.topics and classroom.courseworkmaterials scopes, Tolus also creates a topic and per-student course materials in that course to privately distribute each student’s defense PIN. Using per-file drive.file, Tolus creates and writes transcript documents and, only when the feature is enabled and the student consents, uploads verification images to a teacher-controlled Drive folder.
• How we use it. Only to operate the defense for that teacher: creating the defense assignment, generating grounded questions, returning scores and transcripts, and posting grades and transcript documents back to Classroom and Drive.
• How we store it. Defense configurations, transcripts, and scores are stored in our US database. The text of the assignments and teacher-attached materials you select is stored in the defense configuration so the AI can ground its questions, and it persists with the defense until the defense is deleted. For a student’s own attached submission files, we read the content to generate the defense; portions of the submission may be quoted in the transcript record, which is retained under the retention periods described below (up to 18 months by default) and then deleted.
• How we share it. Only with the subprocessors listed above, and only as needed to run the service. Google user data is never sold, never used for advertising, and never used to train AI or machine-learning models. No human reads Google user data except where strictly necessary to operate the service, address a security issue, or comply with applicable law.

Canvas and Schoology integrations

Where your school has connected Canvas (Instructure) or Schoology (PowerSchool), Tolus connects to that LMS in place of Google Classroom. The data handling mirrors the Google flow above, with these differences:

• What we access. With the teacher’s authorization, we read the teacher’s courses or sections, rosters (student name, email where the LMS exposes it, and the LMS user ID), and assignments. Unlike the Google flow — which reads only native Google Docs — on Canvas and Schoology we also read the text of teacher-attached PDF, Word, and plain-text materials so the AI can ground its defense questions in the assignment.
• What we create and write. We create the defense assignment in the course, post each student’s grade back to it, and deliver each student’s PIN privately — a private Canvas Conversation on Canvas, a private Schoology message on Schoology. If your district disables private messaging, Tolus reports this and the teacher distributes PINs from the in-app PIN sheet instead.
• No transcript document. Neither Canvas nor Schoology has a Google-Drive-style document store, so Tolus does not create a transcript document for these LMSs; the transcript is retained only in Tolus’s US database under the retention periods below.
• Authorization model. Access is governed by a developer/OAuth key issued by your school’s LMS administrator, not by individual teacher consent screens. We use it only to operate the defense for that teacher and never to sell data, advertise, or train models.

Children and COPPA

Tolus is a service for schools and is not directed to children for independent sign-up. Where students are under 13, Tolus relies on the school or teacher to provide consent on behalf of parents under the school-consent pathway recognized in FTC guidance under COPPA: the school authorizes the collection of student information solely for the educational purpose the school has approved.

• Student data is used only for the school-authorized educational purpose — running and scoring the defense.
• We do not serve targeted advertising to students and do not build advertising or behavioral profiles of students.
• A school may review the student information we hold and request its deletion at any time.
• We do not retain student personal information indefinitely; it is deleted on request, when the associated defense or account is removed, and automatically at the end of the retention periods described below (see Data retention and deletion).

Data retention and deletion

Transcripts, scores, feedback, and configurations are retained so they remain available to the teacher alongside the gradebook, but not indefinitely. As a current default, defense records are automatically deleted 18 months after they are created unless your school requests a different period, and authentication logs are deleted after 90 days. Teachers may also delete any defense at any time, and closing an account deletes all associated data. When you delete a defense or close your account, the removal is synchronous, not on a delayed schedule.

• Deleting a defense. When a teacher deletes a specific defense, we synchronously remove that defense’s configuration and all of its associated defense sessions, student feedback, and session tokens. PINs and authentication-log entries scoped to that defense’s course are removed when no other active defense relies on them. A student record is removed when the student is no longer enrolled in any other course you run on Tolus.
• Closing your account. When a teacher closes their account (deletes all of their data), we synchronously remove every defense the teacher owns and all of the associated student records under their control.
• Audio. We never store audio, so there is nothing to delete.
• Transcript Google Docs. Transcript documents are created in the teacher’s own Google Drive and are governed by the teacher’s Google account. When you delete a defense, Tolus removes its database copy and reference; it does not delete the file in your Drive — you control that file directly in Google.
• Verification images. When enabled with student consent, verification images are stored in the teacher’s own Google Drive and governed by that account. Deleting a defense removes Tolus’s database records and references; the teacher controls deletion of the Drive files.

To request deletion, a teacher can delete the defense or close their account, or you can email hao@tolus.dev.

Student and family rights

Tolus acts as a school official under FERPA only under a signed district data privacy agreement (DPA), processing student records solely at the direction of and under the control of the school, and does not re-disclose them except to the subprocessors listed above under contract (see our FERPA page). Students and parents may request access to, correction of, or deletion of a student’s defense records by contacting their teacher or school, or by emailing us at hao@tolus.dev.

California privacy (CCPA/CPRA and SOPIPA)

For California residents: Tolus does not sell or share personal information, does not use student personal information for targeted advertising or to build student profiles, and maintains reasonable security procedures appropriate to the data we handle, as required by the California Consumer Privacy Act (as amended by the CPRA) and the Student Online Personal Information Protection Act (SOPIPA).

Subject to applicable exceptions, you have the right to know what personal information we hold, to request its deletion or correction, to opt out of any sale or sharing (we do neither), and not to receive discriminatory treatment for exercising these rights. To exercise any of these rights, email hao@tolus.dev. For student records held on behalf of a school, we will direct or coordinate the request with the school as the controlling party.

Security

Data is encrypted in transit (TLS). Stored Google OAuth refresh tokens are encrypted at rest using AES-256-GCM application-layer encryption. Row-level security is enabled (default-deny) on every database table containing personal data as defense-in-depth; the application connects through a dedicated service role. We also use timing-safe PIN comparison, signed (HMAC) score and feedback tokens, request rate limiting, an origin check on state-changing requests, and short-lived session tokens. We are candid that student PINs are stored in readable (un-hashed) form by design, so that teachers can see and distribute them. We do not export student data outside the subprocessors listed above. Tolus maintains a Written Information Security Program (WISP), available to schools on request at hao@tolus.dev. Our controls are designed to align with the SOC 2 Trust Services Criteria (security, availability, and confidentiality); Tolus is not yet SOC 2 audited, and a formal SOC 2 audit is on our roadmap.

Changes

We’ll update this page if our practices change. Material changes will be communicated to active teacher accounts by email.

Contact

Questions about this policy? Email hao@tolus.dev.