Trust & privacy
The honest answer to your privacy questionnaire is short.
This page is written for the person who has to say yes: privacy officers, technology directors, and the teacher who answers to both. Checklist first, vision never.
§ 01
updated 2026-08-30
The checklist
What’s true about student data here
We are pre-launch. The list below is the posture the product is being built to and what we will defend in a security review — every line is a committed default, not a screenshot. Where something isn’t built, published, or signed yet, section 3 says so by name. Some of these are longer than a marketing page would like; that’s the point.
- No student accounts; sessions are not linked to student identities by us. Students can participate without creating an educagents account. Where a school wants identity — rostered, external pseudonymous ID, or institutional SSO — each mode will ship with its own published policy profile, and none of them turn on by default.
- The teacher can see and end every session. Live visibility and a termination control on every student session, on every plan, free.
- Short retention by default — student transcripts auto-delete on a teacher-configurable window; deletion on request. The full retention schedule — ours and our model providers’ own windows, which are the part most vendors leave out — is published in full rather than summarized, before the first student session runs. It exists in draft now; ask and we’ll send it.
- No training on student data on our approved student-facing inference routes. A route becomes “approved” only after we verify against the provider’s own terms that the tier we use carries a no-training commitment, an acceptable retention window, and audience terms that permit our deployment — provider by provider, tier by tier, and feature by feature, because features like grounding, caching, and stored completions can each retain data differently from a provider’s headline policy. On managed routes that commitment is contractual: the provider is our disclosed sub-processor under a data-processing agreement, and no route carries a student session before that agreement is in place and that verification is complete. We scope this precisely instead of saying “never, ever” — unscoped promises are how vendors end up lying.
- Chat content is processed by a model provider. Anyone who tells you otherwise about an AI product is wrong. On our managed routes that provider is our disclosed sub-processor under a data-processing agreement. Our sub-processor register — naming each provider, what it processes, and where — is published and versioned with change notification before the first student session, at a fixed URL you can subscribe to. Evaluating us now? Ask, and we’ll send you the current candidate list and the terms review behind it.
- Safety event detection and flagging, described honestly: detection is probabilistic; flags notify the supervising teacher under our response policy. This is not an emergency service and has no emergency-service dependence.
- We don’t make decisions about students. Agents here draft, explain, and give formative feedback; they do not determine grades, admissions, placement, or level, and they do not proctor. Under our own policy those are regulated decision-making, blocked by default, and available — if ever — only under a reviewed institutional agreement with a named human decision-maker who can override every output. And every agent surface tells the person they’re talking to an AI before the first exchange, in language matched to their age.
- No ads. No sale of personal data. Not as a policy achievement — as a business model: schools and educators pay us; data brokers don’t.
§ 02
The compliance words, used correctly
Why we won’t say “FERPA compliant”
Compliance is a property of a school’s practices; no vendor can confer it — and vendors who stamp “FERPA compliant!” on a landing page are telling you they don’t understand the law they’re citing. What we say, and mean:
- Designed to support FERPA compliance — built to operate under the FERPA school-officials exception, with the direct-control, purpose-limitation, and no-redisclosure conditions treated as product requirements.
- Supports your COPPA school-authorization obligations — with the minimization, security, and deletion posture that authorization actually requires.
- GDPR-ready processor terms for institutions that need them.
We name third-party certifications only when we hold them and they’re current. Today we hold none — see the next section.
§ 03
What we don’t have yet
Plainly: what’s not true yet
We’re pre-launch, and this page doesn’t pretend otherwise.
- No third-party certifications yet. When we complete one, we’ll name it here with its date. Until then, the word “certified” doesn’t appear on this site.
- The compliance artifact pack — DPA template, data-flow map, retention schedule, security overview — is in preparation and will be reviewed by counsel. We don’t sign school or district contracts until counsel review is done. If you’re an administrator, we’ll happily walk you through the drafts.
- No signed provider agreements yet — and no student sessions until there are. Our approved-route policy is written and our provider-terms verification is documented and dated. The data-processing agreements behind those managed routes are not signed. No student session runs on any route before its agreement and verification are complete. That order isn’t negotiable, and it’s why we won’t quote you a date we don’t control.
- Classroom monitoring today means the committed mechanisms on this page — live session visibility, session termination, retention controls. We’re not claiming dashboards we haven’t shipped.
- Under-13 use has extra constraints by design. Self-serve student links for young learners run without accounts and without persistent memory; anything more requires verified institutional authorization. We’d rather under-build here than over-promise.
If a claim on this site ever outruns what we’ve built, that’s a bug — report it like one: tell us.
pre-launchno signed provider agreements yetupdated 2026-08-30
§ 04
For teachers reading this
What this means in your classroom
Trying educagents yourself doesn’t put student data anywhere: building and testing agents involves no student data at all. (Your district’s rules about which tools staff may use still apply — we’re describing what the product does, not what your policy says.) When you’re ready to run a student session, the posture above is already the default: no student accounts needed, your eyes on every session, short retention you control. Safe to try was a design goal, not a sales line.