Provenance
Security, privacy and accessibility. Last verified September 23, 2026.
What this page is
aimodes.ai holds student education records for the courses that use it: the AI conversations students submit, how those conversations were scored, and who is enrolled where. This page says what we do to protect those records and to keep the site usable by everyone, which standards we measure ourselves against, and when each claim was last checked. It is a self-assessment, not a third-party audit or a certification.
Student records and FERPA
The Family Educational Rights and Privacy Act (20 U.S.C. § 1232g; 34 CFR Part 99) governs education records held by schools and the services they use. When an institution uses aimodes.ai for a course, we act under its direction as a service provider with a legitimate educational interest, and we hold its students’ records on its behalf.
- Least privilege. A student can read their own records. Instructors and administrators see what their teaching tools need. Nobody else can read student records through the site, and no signed-in user can change another person’s.
- No sale, no advertising. We do not sell records, share them with advertisers, or use them to profile students for anyone else.
- End-of-course handling. An instructor can remove a course’s records, or de-identify them by severing names, email addresses and sign-in details from the coursework. Both operations are audited, run as a dry run first, and refuse to touch an account a student registered for themselves.
- Research use of any record is governed by the consent collected in the study itself, as the privacy policy describes.
Security controls
- Database access rules. Every table reachable through the data API has row-level security. Each rule is the narrowest one the site’s own code needs, derived from a scan of every place the code reads or writes that table.
- Privileged key stays on the server. The database key that bypasses those rules is used only in server code, never sent to a browser.
- Transport and browser protections. HTTPS only, with HSTS preload; a Content-Security-Policy; framing denied; MIME sniffing disabled; a strict referrer policy; camera, microphone and location disabled by default.
- Encryption. Data is encrypted in transit (TLS) and at rest by our database host, Supabase.
- Dependencies are audited for known vulnerabilities, and fixed before release.
Accessibility
We aim for the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. That includes WCAG 2.1 AA, which the U.S. Department of Justice’s 2024 ADA Title II rule requires of public institutions’ web content, and WCAG 2.0 AA, which Section 508 incorporates.
Automated scanning finds only part of what WCAG covers. Keyboard use, screen reader behaviour and plain-language checks need people, and the gaps below say where that work has not been done yet.
Standards we measure against
- FERPA, 20 U.S.C. § 1232g and 34 CFR Part 99, for student education records.
- WCAG 2.2 level AA, for accessibility.
- The OWASP Top 10 (2021), as a checklist. The checks below cover broken access control (A01), security misconfiguration (A05) and vulnerable components (A06).
Verification log
Every check behind a claim on this page, with its date and result.
| Date | Check | Scope | Result |
|---|---|---|---|
| 2026-09-23 | Row-level security review of every table reachable through the data API | All policies in schemas exposed to signed-in or anonymous users | 33 tables let any signed-in account read or change rows it did not own. All 33 were narrowed to owner, staff or admin access, or closed to users entirely. The one broad read that remains, course_instructors, holds no student data. |
| 2026-09-23 | Access tested as real account types, in a transaction rolled back afterwards | Public sign-up, enrolled student, instructor and admin accounts | Before: a public sign-up account could read 256 personality and demographic profiles, 155 survey responses and every enrollment code, and could delete all 112 enrollments. After: it reads none of them. A student reads only their own enrollment, section and profile; instructors and admins keep the access their tools need. |
| 2026-09-23 | Analytics events access | The shared events table used by this site and two sibling sites | Was readable, editable and deletable by any signed-in account. Now readable by admins only; nobody can edit or delete rows through a session. |
| 2026-09-23 | API route review | Every API route that uses the server's privileged database key | Each route that returns or changes personal data checks the caller (session owner, course access, participant token, or scheduled-job secret). Live activity boards show participants by badge, not name. |
| 2026-09-23 | Dependency vulnerability audit (npm audit, production dependencies) | All production dependencies | 17 known vulnerabilities, including a critical remote-code-execution advisory in Next.js, reduced to 0 by upgrading Next.js to 16.3.4 and replacing the spreadsheet library with its patched release. |
| 2026-09-23 | Secret scan of the repository | Every tracked file | No credentials committed. |
| 2026-09-23 | Automated accessibility scan (axe-core, WCAG 2.0/2.1/2.2 A and AA rules) | 12 public pages at desktop width; the home and sign-in pages at phone width | Before: colour-contrast failures on every page and links distinguished by colour alone on three. After: no violations on any scanned page. |
| 2026-09-23 | File storage review | All storage buckets | Both buckets are private; neither holds files. |
What we have not done yet
- Course-scoped instructor access. An instructor can currently see students in every course, not only their own. Limiting it to their own courses is the next access-control change.
- Accessibility of signed-in pages. The scan covered public pages. The instructor and student dashboards still use a light grey for some text that falls below WCAG’s contrast minimum, and have not been tested with a keyboard or a screen reader.
- Leaked-password protection (refusing passwords known from data breaches) is not yet switched on for sign-in.
- Independent review. Everything here is self-assessed. No external penetration test or accessibility audit has been done.
Reporting a problem
If you find a security issue or an accessibility barrier, email mark_keith@byu.edu. Please do not test against other people’s accounts or data.