Security & trust
Trusted with the things that matter most.
Children are on this system. So the controls aren’t bolted on after the fact — they’re how Brim is built. Here is exactly how, in plain terms, with no badges to hide behind.
Encryption
Sealed to the right person — and no one else.
Parent–child messages are end-to-end encrypted; the server only ever holds ciphertext. Medical and safeguarding records are encrypted to a specific role’s key, so even IT and Brim staff cannot read them. The keys themselves are protected by a master-key ceremony, not a password in a config file.
- Family messages: end-to-end, server sees ciphertext only
- Medical & safeguarding: role-encrypted at rest
- Master key split into Shamir shares — a quorum to reconstruct
The master key is split into five shares held by separate officers. Any three reconstruct it — no single person, and no Brim engineer, can act alone.
Access control
The right people, the exact access.
Roles map to granular, auditable capabilities rather than blunt “admin/everyone-else” tiers. Sensitive actions require two-person sign-off, and segregation of duties is enforced in the database — the same hand cannot both post and approve a transaction. The admin role is powerful, but the platform’s guarantees bind it too.
- Capability-based RBAC, not all-or-nothing roles
- Two-person approval on sensitive actions
- Maker-checker enforced by the database, not the screen
A. Nakato
posts the entry
B. Mukasa
approves it
A. Nakato cannot approve her own entry — the rule is enforced in the database, not the screen.
Artificial intelligence
AI that helps — without ever seeing the child.
Brim uses AI to draft parent-friendly lesson summaries, suggest Socratic hints grounded in the NCDC syllabus, and read handwriting and documents. Before any of that reaches a model, the identifying parts — names, student numbers, contacts — are swapped for neutral placeholders, so the model works on the shape of the task, not a real child. The result is checked back on Brim before anyone sees it.
- Identifying fields tokenised before a model ever sees them
- Grounded in our own NCDC corpus — not the open internet
- AI drafts; a person decides — nothing acts on a child on its own
On Brim
Nakato Sarah
S5 East · #S24-5892
Sent to the model
⟨student⟩
S5 East · ⟨id⟩
Names, numbers and contacts are swapped for neutral placeholders before anything reaches an AI model. It works on the shape of the question — never on the child.
Auditability
An account you can always produce.
Every governed event — a broadcast, a released grade, an opened safeguarding case, a sensitive read — writes to an append-only, hash-chained log. Because each entry carries the hash of the one before it, tampering shows. The audit trail isn’t a compliance checkbox; it’s how a school proves it handled something correctly.
- Append-only, hash-chained — alterations are detectable
- Sensitive reads are logged, not just writes
- Entries are role-signed: who acted, when, under what authority
Each entry carries the hash of the one before it. Remove or alter a link and the chain no longer verifies — tampering shows.
Data residency & messaging
A small surface, isolated by default.
Brim runs on the Cloudflare edge — there is no traditional app server sitting on the open internet to be breached. Tenant data lives in Postgres with row-level security, so one school can never read another’s rows, enforced on every query. SMS and USSD ride Africa’s Talking, reaching any phone in Uganda.
- Edge Worker — no long-lived app server to compromise
- Row-level security isolates every tenant, every query
- SMS + USSD via Africa’s Talking for low-connectivity homes
One tenant can never read another’s rows — isolation is enforced by the database, on every single query.
Device security
Hardware you can trust at the gate.
Station kiosks authenticate with a biometric whose template is sealed on the device, never shipped to a server — a PIN narrows to one student, the face or fingerprint authenticates. A reported-stolen tablet locks instantly, persists the lock across reboot, pings its location and captures evidence covertly.
- Biometric templates sealed on-device, never uploaded
- PIN narrows; biometric authenticates — PIN alone never grants access
- Theft response: instant lock, locate, covert capture
Lock
Instant, persists across reboot
Locate
GPS ping reported home
Recover
Covert capture for evidence
Continuity
Recovery that’s rehearsed, not hoped for.
Role keys are snapshotted weekly, encrypted under the master key and stored off-site with an HMAC tag, so a backup can be verified before it’s trusted. There’s a written disaster-recovery procedure and an annual drill — because the time to discover your backups don’t restore is never.
- Weekly encrypted key snapshots, stored off-site
- HMAC-tagged so a backup verifies before it’s trusted
- A written procedure and an annual restore drill
Role keys are snapshotted weekly, encrypted under the master key and stored off-site with an HMAC tag — a rehearsed disaster-recovery drill, not a hope.
What we don’t do
No theatre. No fine print.
We don’t claim certifications we don’t hold, and we don’t read a family’s private messages “for safety”. The school keeps governance on its own channels; the family keeps its words to itself. Both are true at once — that’s the point.
Sealed disclosure
encrypted at rest
DSL’s key
the only key that opens it
Not even IT or platform staff hold the key. Every open is written to a read trail.
Bring your hardest question.
If you assess vendors for a living, we’d rather you ask now than wonder later. Talk to us, or start a pilot and probe it on your own school’s data.
For the deeper localisation story, see why Brim.