Security & trust
Trusted with the things that matter most.
Children are on this system. The controls are not bolted on after the fact; they are how Brim is built. Here is exactly how, in plain terms, with no badges to hide behind.
Encryption
Sealed to one 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 role’s key, so IT and Brim staff cannot read them either. A master-key ceremony protects the keys themselves. No 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 reconstructs it
The master key is split into five shares held by separate officers. Any three reconstruct it. One person alone can do nothing, and that includes every Brim engineer.
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. Segregation of duties is enforced in the database, so the same hand cannot post and approve a transaction. The admin role is powerful. The platform’s guarantees bind it too.
- Capability-based RBAC rather than all-or-nothing roles
- Two-person approval on sensitive actions
- Maker-checker enforced by the database, where no screen can skip it
A. Nakato
posts the entry
B. Mukasa
approves it
A. Nakato cannot approve her own entry. That refusal comes from the database itself.
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 are swapped for neutral placeholders: names, student numbers, contacts. The model works on the shape of the task. Brim checks the result back before anyone sees it.
- Identifying fields tokenised before a model ever sees them
- Grounded in our own NCDC corpus rather than the open internet
- AI drafts; a person decides. Nothing acts on a child alone
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 sees the shape of the question and nothing of the child.
Auditability
An account you can always produce.
Every governed event writes to an append-only, hash-chained log: a broadcast, a released grade, an opened safeguarding case, a sensitive read. Each entry carries the hash of the one before it, so tampering shows. This is how a school proves it handled something correctly.
- Append-only and hash-chained, so alterations are detectable
- Sensitive reads are logged alongside every write
- 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 stops verifying. 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, enforced on every query, so one school can never read another’s rows. SMS and USSD ride Africa’s Talking, reaching any phone in Uganda.
- Edge Worker, with 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
The database enforces isolation on every single query. One tenant can never read another’s rows.
Device security
Hardware you can trust at the gate.
Station kiosks authenticate with a biometric whose template is sealed on the device and never shipped to a server. A PIN narrows to one student; the face or fingerprint authenticates. A reported-stolen tablet locks instantly, holds the lock across reboot, pings its location and captures evidence covertly.
- Biometric templates sealed on-device, never uploaded
- PIN narrows; biometric authenticates. A PIN alone grants nothing
- 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 has been rehearsed.
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 is trusted. There is a written disaster-recovery procedure and an annual drill. Nobody should learn on the day that the backups do not restore.
- 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. The disaster-recovery restore is rehearsed.
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 hold at once.
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.