Our commitment, and its limits. We protect personal and educational information with layered technical and organisational measures, described here so schools, parents and students can judge them. This page describes our practices; it is not a guarantee. No online service is perfectly secure, so please also follow the advice in “Your part”. This page is part of our Privacy Policy and the Data Processing Addendum annex of measures.
Encryption and storage
- In transit. Traffic between your device and the Service uses HTTPS (TLS). Plain-HTTP requests are redirected, browsers are told to use HTTPS only (HSTS), and session and CSRF cookies are marked secure in production.
- At rest. Our database, file storage and backup providers encrypt stored data at rest on their infrastructure. Some especially sensitive values we hold (for example a school’s single sign-on client secret and typed contact details held for an AI request) are additionally encrypted by the application.
- Passwords are never stored in plain text. They are stored only as salted, one-way hashes, and are checked against length, common-password and similarity rules when set.
- Private files. Uploads such as enrolment documents, books, recordings and exports are kept in private storage, never at a public address. They are downloaded only through short-lived signed links (minutes) after the Service checks that the person is allowed to see the file, and anything else is answered “not found”.
- Uploads are checked by content type and size before they are stored.
Signing in and sessions
- Two-step sign-in. Any account can turn on two-step sign-in. After the password, a single-use six-digit code is sent by email, or by text or WhatsApp if you chose that and have a verified number. Codes expire after a few minutes and lock out after repeated wrong attempts. Turning two-step sign-in off requires your password and a fresh code. We strongly recommend it for every teacher and administrator account. A school can also require its staff to sign in through its own single sign-on.
- Sign in with Google, Microsoft or Apple uses the standard OpenID Connect flow with proof-key protection; we accept only a verified email that matches the account, and two-step rules still apply.
- Sessions end automatically. A session expires after a period of inactivity and after a fixed maximum lifetime, whichever comes first. Signing out ends the session’s access.
- Brute-force protection. Sign-in and verification attempts are rate-limited per network address, and the limits are sized so a classroom can sign in together.
- Account holds. We can switch off an account that appears to be compromised or abused.
Access control and separation
- Role-based, least-privilege access. Students see their own records; teachers see the students in their classes; parents see their own linked children, after the link is accepted; administrators see their own school and, where a school limits them, only the programmes they are assigned to. Platform staff access is limited, logged and used only for support, security and legal needs.
- One school cannot see another. Every request is checked against the person’s school and role on the server; hidden buttons are not relied upon. A request for something you may not see is answered as if it did not exist.
- Student sessions on staff devices use a separate, time-limited credential that can reach only a short approved list of student pages, never account, chat, AI, privacy or sign-in settings, and are recorded and visible to the family and school.
- Audit trail. Significant changes in a school’s workspace (who changed what, and when) are recorded in an activity log that cannot be edited, and privacy requests keep a content-free audit record.
- Messages are visible only to the people in them; the review of a reported message is limited to named reviewers, and edited or deleted messages keep earlier versions only for that review.
AI safeguards
- Before text goes to an AI service, names, contact details and identifiers are replaced with placeholders where our systems support it, a safety check refuses a request that still contains a replaced name, and the real names are restored only in what you see (see the AI Use Notice).
- Text typed by people is handled as data and never as instructions, to defend against prompt-injection attacks.
- The Shams Agent acts with your own permissions, from a fixed list of approved actions, and waits for your approval before changing anything or contacting anyone; its steps are logged.
- Error reports sent to our monitoring service exclude request bodies, cookies, local variables and personal profile data so student information does not travel with them.
Infrastructure and application security
- Hosting. The Service runs on reputable cloud infrastructure with managed databases that are not publicly browsable and are reached only by our application with credentials we hold. Secrets are kept in the hosting platform’s secret store, not in code.
- Web protections. Cross-site request forgery protection on authenticated requests; a content security policy (strict on sign-in and registration pages); cross-site and framing protections; secure, HTTP-only, same-site cookies; input validation and parameterised database queries to prevent injection; throttling on every route.
- Changes are made through code review and automated tests, including tests that check permissions across every role and that fail the build if a new data path skips our privacy rules.
- Dependencies. We track security advisories for the software we depend on and apply updates.
- Plan limits and abuse controls. Per-person and per-school limits on AI use, exports and messages limit the damage from a stolen account or a runaway process.
Backups and recovery
We keep encrypted backups, stored separately from production, so that we can recover from data loss or corruption. Backups are kept for a limited period (about two months for older copies) and then destroyed; data you delete may remain in backups until then, and is not restored to the live Service afterwards except to recover from a failure. We maintain documented recovery procedures.
Monitoring and incident response
We monitor the Service’s health, errors and unusual activity. If we confirm a security incident affecting personal information, we will: investigate and contain it; assess what was affected; notify affected schools without undue delay so they can meet their own duties, and notify individuals and regulators where the law requires and within the legal deadlines (for example 72 hours to a European regulator where it applies); tell you what happened, what information was involved and what you can do; and fix the cause and review our controls.
Student data and the law
Our controls are designed to help schools meet their obligations under laws such as the Family Educational Rights and Privacy Act (FERPA), the Children’s Online Privacy Protection Act (COPPA), and the GDPR and UK GDPR. A school remains responsible for its own compliance, for the consents it must obtain and for who it gives access to. We act on a school’s instructions for its students’ records, as the Data Processing Addendum sets out, we do not sell student information, and we do not use it for advertising.
Reporting a vulnerability
We welcome responsible reports. To report one, email support@shamsai.app with enough detail to reproduce it. Please:
- give us a reasonable time to fix the issue before telling anyone else;
- avoid reading, changing or deleting other people’s data, avoid actions that degrade the Service (such as denial-of-service or spam), and do not use social engineering against our staff or users;
- stop testing and tell us at once if you reach personal information.
If you act in good faith and follow these rules, we will not take legal action against you for your research, we will acknowledge your report, keep you informed and, with your permission, credit you. We do not currently offer monetary rewards. This invitation does not authorise testing of any third party’s systems.
Your part
- Use a strong, unique password, and turn on two-step sign-in, especially for teacher and administrator accounts.
- Never share your password or sign-in codes, including with teachers, administrators or anyone who says they work for us. We will never ask for them.
- Sign out on shared or public devices, and keep your devices and browsers up to date.
- Be careful of phishing. Check the address in the link; we send email only from our own platform addresses.
- Review who has access to your school’s workspace, remove staff who have left, and give each administrator only the permissions they need.
- Report anything suspicious at once to support@shamsai.app.
Third-party providers
We use a limited set of providers for hosting, storage, payments, messaging and AI. They are listed in the Privacy Policy. We select them with security in mind, limit what we send, and bind them by contract to protect it. We do not share user data with providers for advertising.
Updates
We keep improving our security practices. We may update this page as the Service and threats change, and will tell you of material changes as the Privacy Policy describes.
Contact