The breaches of 2024 and 2026 happened after the API call returned. So that's where we built.

Sensitive fields on every record are encrypted at the application layer using AES-256-GCM via OpenSSL — per-field, each with its own initialization vector and authentication tag. Even if the entire database file were exfiltrated, an attacker would obtain ciphertext for every PII field with no realistic path to decryption without the application key.

Encrypted fields include: student names, email addresses, state/SIS identifiers, phone numbers and addresses, counselor session notes, parent/guardian contact information, sensitive demographic flags (IEP, 504, English-learner, meal program), and private messages.

Keys live outside the database, in server-process environment configuration — never in backups, logs, or version control. Key rotation runs as a batched re-encryption job without taking the application offline. Even an authenticated database administrator with full SQL read access cannot read encrypted fields without going through the application layer, and that access is itself audited.

Identifiers are tokenized wherever the identifier itself could leak — logs, telemetry, support tickets. We log internal numeric IDs, never SIS identifiers or names.

A single audit-trail funnel records every sensitive operation with actor, target object, action, structured detail, originating IP, user agent, and timestamp. Audit entries are append-only at the application layer — there's no interface to edit or delete them, and the model layer implements no update or delete methods for them.

Audited events include: every authentication event (logins, logouts, failed attempts, passkey enrollments, session expirations); every counselor-note read; every write or status change on student-support entries, action items, or behavior incidents; every permission change, role grant, or revocation; every export (CSV, transcript, report); every AI API call (metadata only — never the prompt body); and every SIS sync. Default retention is seven years, aligning with FERPA record-keeping guidance.

Passkey (WebAuthn) authentication is a first-class option — inherently multi-factor and phishing-resistant, with no password for an attacker to steal. Sessions are JWT-based with a 24-hour expiration ceiling, stored in HttpOnly cookies, invalidated on password change or passkey re-enrollment, with an idle lock screen requiring re-authentication.

Every data access passes through a single permission function that is the source of truth for organizational scope. A counselor at one school cannot reach another school's students even by manipulating URLs or API paths — the check happens at the model layer, not just the route layer. Role hierarchy (super-admin > admin > counselor > teacher > student/parent) is strictly enforced, and role elevation is itself an audited event.

AI features maintain a hard separation between identifying student data and the AI service. Where content doesn't need to be read, it's referenced by an opaque internal identifier so the AI works on routing and structure without ever seeing names or note bodies.

Where body content genuinely must flow to the AI for assistance, the user sees an explicit acknowledgment gate first. Every prompt that does flow out passes through a scrubber that replaces names, emails, phone numbers, addresses, and SIS identifiers with placeholder tokens before transmission — re-substituted locally on receipt. A second, independent verifier pass re-scans the scrubbed payload to catch anything the scrubber missed. The result: the AI provider's logs do not contain readable student or parent identities.

A compliance dashboard surfaces every AI exchange — model, timestamp, token counts, content category, originating user — without prompt bodies, which aren't retained. An organization can wipe its AI metadata at any time, and the wipe is itself audited.

The login endpoint applies rate limiting with progressive backoff and account lockout on sustained failures, with administrator notification. Passkey-bound accounts are immune to credential stuffing — there is no password to guess.

Against a stolen database file, the attacker holds AES-256-GCM ciphertext — not brute-forceable on any projected hardware roadmap, including state-level quantum investments per current NIST analysis. Where attackers have historically beaten encrypted-at-rest databases, the path was credential compromise — stealing the key, not breaking the cipher. Our keys live in environment configuration, never in the database, version control, or backups; host access requires SSH key authentication with password SSH disabled.

Per-session IP capture means a stolen session is detectable on first reuse from a different network.

No architecture is bulletproof; the question is detection, containment, and recovery. Containment tools include per-organization session suspension (a super-admin can suspend all sessions in their org in one action), per-user revocation and lockout, encryption-key rotation without downtime, and AI-metadata wipe.

In a confirmed incident affecting a customer's data, we commit to direct disclosure within the timeframes required by applicable state law — in Utah, within thirty days of discovery — with a full post-incident report naming root cause, data scope, contained-by timestamp, and remediation. We will not minimize or obfuscate.