Security Policy

1. Tenant separation

Every table that holds a school's data carries that school's identifier and is protected by row-level security in the database. Separation is therefore enforced by PostgreSQL on every query, not by a filter in application code that a single missing clause would defeat.

We verify this rather than assume it: signed-in sessions belonging to real schools are used to sweep every table in the database, both reading whatever comes back and explicitly asking for another school's rows, and to attempt cross-tenant inserts and updates. The expected result — and the current result — is that nothing crosses.

2. Encryption

• In transit: TLS on every connection, to the application, the database and object storage.
• At rest: the database and object storage are encrypted by the provider.
• Passwords are never stored in a readable form.

3. Access control

Each school defines roles and the permissions attached to them, and the platform checks a permission on every action, not only when drawing a menu.

The service-role database key exists only on the server and is never sent to a browser or exposed in a client bundle. The same is true of every third-party key, including the assistant's.

4. The assistant

The assistant's isolation is structural rather than instructed. Its lookups take no school identifier — there is no argument by which one could be supplied — and the school it reads is derived on the server from the signed-in session. A model instructed to fetch another school's figures is asking for something the tool surface cannot express.

Every lookup re-checks the caller's permission, and an unknown lookup and a forbidden one return the same response, so the catalogue cannot be probed. Requests are rate limited per user and per school.

5. Audit trail

Significant actions are recorded with who, what, when and — where the change is to a record — what changed. When a platform administrator is acting inside a school, the trail records the administrator as the actor and the identity they were using alongside it, so the school can tell its own staff's actions from ours.

6. Our own practices

• Administrative access is limited to the people who need it and is itself audited.
• Dependencies are kept current and reviewed for known vulnerabilities.
• Changes are reviewed before release.
• Secrets are held in environment configuration, never in source control.

7. Reporting a vulnerability

Write to us at the address on the Grievance Redressal page with enough detail to reproduce it. We will acknowledge within two working days and keep you informed.

We will not pursue anyone who reports a genuine flaw in good faith, tests only against their own account, does not access or alter another school's data, and gives us a reasonable opportunity to fix it before saying anything publicly.