Sarabellum
Trust
Security
What actually protects your data, described plainly — including the parts that aren’t finished. You’re trusting this app with your whole head; you should know how it’s built.
Last updated July 2026
The database enforces privacy, not the app
Every table uses Postgres Row Level Security: the rule that a row belongs to one account is enforced by the database itself, underneath the application. Even if the app had a bug that asked for someone else’s tasks, the database would refuse. App code that checks permissions is a promise; RLS is a wall.
We never see your password
Sign-in is Google OAuth. Sarabellum has no password field, stores no passwords, and couldn’t leak one if it tried. Your Google account’s own protections — including two-factor, if you have it on — are what protect your Sarabellum.
The AI key never touches your browser
Every call to Claude runs inside a serverless function on the server. The API key lives only in the hosting environment’s encrypted variables. Nothing secret is ever shipped to the page — a key in a frontend bundle is a key that’s already public.
The Discord bot verifies its callers
The interactions endpoint checks an ed25519 signature on every request, so it only answers to genuine Discord traffic. An unauthenticated bot endpoint is an open door into your system, so it isn’t one.
The contact table can’t be read back
The public contact and newsletter forms can insert a row and nothing else — there’s no read policy at all, so nobody can pull the list back out through the public API. Write-only by design.
Encrypted in transit, and no third parties
HTTPS everywhere, automatically. This website loads no external scripts, fonts, trackers or ad networks whatsoever — every byte comes from sarabellum.io. Fewer third parties, fewer ways to be let down by one.
The honest part
What we haven’t done.
Any security page can list its wins. Here are the gaps, because you can’t make a real decision about trusting something without them.
No compliance certifications
No SOC 2, no ISO 27001, no HIPAA, no third-party penetration test. Those cost more than this project has ever spent on anything. If your employer requires them, Sarabellum can’t meet that bar today and won’t pretend to.
The operator can read your data
RLS seals users off from each other, not from whoever runs the service — a database administrator can read any row, exactly as at every hosted app you use. The only real fix is end-to-end encryption, which is fundamentally incompatible with an AI that reads your system to help you. We chose Sara, and we’d rather say so than bury it.
Backups aren’t where they should be
The database is on a free tier whose automated backup and restore story is thin. Improving that is an active, named piece of work. Until it’s done: please don’t let Sarabellum hold the only copy of something irreplaceable.
One person reviews the code
There’s no security team. There is a written review log, a linter and typechecker on every push, and a habit of writing down what’s wrong instead of forgetting it — which is not the same thing as a team, and shouldn’t be sold as one.
Reporting a vulnerability
If you find something, please tell us — genuinely, thank you in advance. Email aolsendev@gmail.com with what you found and how to reproduce it. Please don’t post it publicly until it’s fixed, and please don’t access, modify or delete anyone else’s data while proving it — describing the hole is always enough.
You’ll get a reply from a human, usually within a few days. There’s no bug bounty programme and no money to pay one with; there is real gratitude, credit if you want it, and a fix as fast as one person can ship it.
If you think your account is compromised
Secure your Google account first — that’s the front door to Sarabellum. Then get in touch and it’ll be looked at directly.