Trust

Security overview

Draft — not yet in effect

The app sandbox is the main control

The hard part of hosting apps teachers make with AI is that you can't read every line of every app. KiteQuad doesn't rely on reading them. Instead, each app runs inside a locked-down frame on a separate web domain that holds no sign-in and no cookies:

• Network access from an app is blocked by a Content Security Policy. An app can't fetch from, post to, or open a connection to another website.
• The one way out is kitequad.store, which saves a student's work inside KiteQuad. Other ways an app might try to send data out — navigating away, embedding another site, opening a pop-up — are detected and reported to the teacher.
• Scripts run only from the app's own files. When you publish, KiteQuad moves the code the AI wrote inside your pages into files and runs the page under a stricter rule, which closes a way an app could otherwise slip past these protections.
• Every app is checked before it goes live for secret keys, trackers, personal-data inputs and links off the platform, and it's checked the same way whether you upload it or publish it from GitHub.

Because the protection comes from the sandbox and not from reading each app, one data agreement can cover every app a teacher makes — with no human review loop.

Where data lives, and how it's encrypted

KiteQuad runs on Cloudflare. The database and file storage are created in Cloudflare's United States jurisdiction, requests are handled at the Cloudflare location nearest the user, and nothing personal is kept in any globally replicated store. Traffic uses HTTPS (TLS), and stored data is encrypted at rest.

Who can get to student data

• Teachers see only their own classes and their own students' results; one teacher's request for another's data is refused.
• Schools that authorize real-data mode are kept apart from one another; a sign-in for one school's space is rejected on another's.
• The operator (KiteQuad's own staff) must pass 2-step verification, and every view that carries a school's data writes an audit record of who looked and at what.

Accounts and sign-in

Teachers sign in with an emailed link, a password, or Google. Accounts are created only for a verified email address; a password sign-up isn't active until the person confirms it from their inbox, so nobody can claim an address that isn't theirs. Passwords are stored only as salted one-way hashes. Students never use an adult account: they sign in to a class with a code and a PIN or picture password, or a QR badge, all rate-limited against guessing.

What we log — and what we never do

KiteQuad keeps the records it needs to run and to prove what happened, and deliberately keeps student data out of them. We never write a student's name or nickname, a saved value, a submission, a PIN, a token or a secret to logs, emails or any error tracker. There is no third-party error-tracking or analytics service on the pages students use. Audit records hold internal ids and action names only, so they can survive certified deletion of a school's data.

Our security program

KiteQuad maintains a written information security program and reviews its risks at least once a year. Our incident-response and breach-notification commitments are on the trust center, alongside downloadable vendor-risk answers.

Reporting a security problem

If you find a security issue, please tell us at support@kitequad.com with enough detail to reproduce it. We'll acknowledge your report and keep you posted while we fix it. Please don't test against real student data.