Security

Last updated 28 July 2026. Knora handles data belonging to school students, some of them minors. This page describes what we actually do, in enough detail to be checked — including what we do not have yet.

1. Where the data lives

Knora runs on Vercel (application hosting, EU and US edge network) and Supabase (PostgreSQL database, authentication and file storage). Data is encrypted in transit with TLS and at rest by those providers. We do not operate our own servers, and no student data is stored on staff laptops.

2. How schools are isolated from each other

Multi-tenancy is enforced in the database, not in application code. Every record carries the school it belongs to, and PostgreSQL row-level security policies decide what each authenticated user may read or write. A bug in a React component cannot leak another school’s students, because the query itself is rejected at the database.

A user’s school is derived server-side from their verified email domain. It is never taken from data the browser sends. This closed a real vulnerability we found in our own June 2026 audit, where sign-up metadata could have been used to join an arbitrary school. Similarly, a user cannot promote their own role: role changes are rejected by a database trigger unless they come from a privileged server-side path.

Accounts are not open to the public. Sign-up is restricted to the email domains of partner schools, and teacher accounts additionally require an invitation issued by that school.

3. What happens to a student’s voice

When a student speaks, the audio streams from their browser directly to our speech-to-text provider over an encrypted WebSocket, using a temporary credential that expires after 30 secondsand is scoped to that single session. The audio does not pass through Knora’s servers and is discarded once transcribed. What we keep is the text of the conversation, which is what makes the tutoring useful to the teacher.

Voice mode can be gated on verified parental consent: when a school enables it, a student can only use voice if their parent or guardian has authorised it, and that authorisation can be revoked at any time from the family portal.

4. AI and student data

Knora does not train AI models on student data, and does not sell or share it. The tutoring conversation is sent to commercial model APIs under terms that do not use API data for model training.

The model does not get to decide if a student is right

Where a verdict matters — a maths answer, a quiz response — the language model does not grade. A deterministic checker using exact rational arithmetic decides right or wrong, and a server-side guard prevents the model from asserting a verdict it never computed. This is a correctness property, but it is also a safety one: a tutor that congratulates a child for a wrong answer damages their learning.

Content generated by the model is sanitised

Diagrams and formatted explanations produced by the model are sanitised before rendering: scripts, event handlers and javascript:URLs are stripped. This matters because teaching material is uploaded by users — a malicious PDF must not be able to turn the tutor into a delivery mechanism for code in a student’s browser.

The teacher can see and shape the instructions

The instructions the tutor follows for a class are written and inspectable by the teacher in Knora Studio. A school that cannot see what the AI is told cannot be accountable for what it says to a child.

5. Subprocessors

These are the third parties that process data on our behalf.

Schools can request a Data Processing Agreement at privacy@knora.es.

6. Retention, export and deletion

Retention by data category is set out in the privacy notice (Spanish version is authoritative for schools in Spain and Latin America; the English version mirrors it).

A school or a parent can request the export or deletion of a minor’s data at any time. Deletion is not a manual sweep: it runs through an audited process that removes the student’s records across the database and any files they uploaded, then verifies the result and writes the request and its outcome to an audit log.

7. Abuse and availability

Endpoints that cost money to serve — voice, the tutoring model, file ingestion — are rate limited per user and per IP, enforced centrally in the database so the limit holds across every server instance rather than per process. Public demo endpoints have their own stricter per-IP limits, by the minute and by the day.

8. What we do not have yet

We are a small team and we would rather tell a school this before they ask than have them discover it during procurement. What we do have is the security work described above, an internal audit whose findings are fixed and traceable in our migration history, and the practice of writing down what is not done yet.

If your school requires a completed security questionnaire, a DPIA or a signed DPA before a pilot, write to us and we will work through it with you.

9. Reporting a vulnerability

If you find a security issue, please tell us before telling anyone else: security@knora.es. Machine-readable contact details are at /.well-known/security.txt.

We will not pursue legal action against researchers acting in good faith who stay in scope and give us reasonable time to fix the issue. Please do not run automated scanning that could degrade the service for students who are in class, and do not access data belonging to a real student — if you need an account to demonstrate an issue, ask us and we will provide a test one.

10. Contact

Security: security@knora.es
Privacy and data protection: privacy@knora.es
Schools and pilots: schools@knora.es