Security & privacy

Access rules belong at the data boundary.

The platform is designed so page appearance is never the security control. PostgreSQL row-level policies and restricted database roles enforce access.

01
Isolation

Constrain every database request

Application queries run in an authenticated transaction with the caller identity bound for policy evaluation.

  • ✓Tenant and school row isolation
  • ✓Student-own-work policies
  • ✓Reviewer-own-feedback policies
02
Role safety

Keep sensitive guidance out of student queries

Student-facing assessment views omit answer columns; authorized staff retrieve guidance through restricted functions.

  • ✓Answer-key column protection
  • ✓Role-aware navigation
  • ✓Administrative scope enforced by policy
03
Operations

Deploy with least privilege

Runtime, login verification, and migration connections are separated. Production passwords and providers remain deployment blockers until configured.

  • ✓No superuser runtime connection
  • ✓Separate authentication-service role
  • ✓Auditable privileged activity
04
Account activity

Use limited activity records for support and oversight

The platform owner can review successful logins, active days, estimated active time, and page or curriculum codes opened. Estimates come from recent interaction while a page is visible and do not prove continuous reading.

  • ✓No passwords, form contents, student work, IP addresses, or full browser fingerprints
  • ✓Owner-only reporting
  • ✓180-day activity-record retention boundary
i

This describes the current application architecture, not a third-party security certification. A production privacy policy, hosting configuration, retention schedule, incident process, and legal review are still required before launch.

A practical next step

See whether Finlit.education fits your classrooms.

No generic sales theatre. We’ll focus on curriculum, teaching workflow, privacy, and your pilot goals.

Request a security review→