Security

Draft, pending legal review. Last updated 2026-09-24. Bracketed items are still to be filled in.

What protects your vaults, what doesn't, and how to report a problem.

The database enforces access

Every permission is a Postgres row-level security policy or trigger, not a check in the app that a bug could skip. Among them:

A member of one vault sees no trace of another.
Canon files change only through a proposal that a quorum of people approves.
An agent acts as its person, minus a ceiling: it can't approve, set rules, manage members, reveal a variable's value, erase a file, or export or delete a vault. Those need the person, signed in.
The activity log and the variables access log are append-only: nobody, us included, edits or deletes a row, except by deleting a whole vault.

Tested on every push

Each of those rules has a hostile test that tries to break it, for example a session for one vault reading another, an agent approving a proposal, anyone editing a log row, an agent revealing a variable. The whole suite runs on every push and pull request.

Variables

Values are encrypted by the web app with AES-256-GCM, under a key kept outside the database. The database only ever holds ciphertext.
Ciphertext leaves the database only through one function that checks the person's grant and writes the access log in the same transaction.
No MCP tool returns a value. Values reach a machine only through reliquary run (into one process) or reliquary env pull (into a gitignored .env).
Every read, reveal, change and refused attempt is in the access log.

Sign-in and the web app

Sign-in by emailed code or link; sessions in HttpOnly, Secure cookies.
No client-side script at all: the content security policy forbids scripts, and every form carries a token and must come from Reliquary's own pages.
AI tools connect with OAuth or with scoped, expiring tokens you can revoke.
Content written by agents is shown and served as quoted data, never as instructions.

Hosting

The database is in the EU (Frankfurt), and the app runs in Frankfurt. See the sub-processors. Backups: Supabase keeps daily backups for 7 days; the operator also keeps up to 14 off-site copies, in which variable values exist only as ciphertext.

What we can't promise

Agents can read what reaches them. An agent that can run commands in a process holding a variable can read that variable. reliquary run limits exposure to one process; it doesn't stop that process. Prefer scoped, short-lived credentials where your provider offers them.
The operator can decrypt. Someone with both the database and the web app's key, which means us as the operator, could technically decrypt variable values. We don't, and our access is limited to running the service. Client-side encryption, where only your members hold keys, is a later feature.
No certification yet. Reliquary has no SOC 2 report or ISO certificate, and no SSO. It is built and run by one person. We list the controls we have rather than claim a standard.

Reporting a vulnerability

Email andres@redmage.cc with what you found and how to reproduce it. We'll acknowledge it within [to be filled: response time], keep you updated, and credit you if you'd like. Please test only against your own account and vaults, don't access other people's data, and give us reasonable time to fix before you publish. We won't take action against good-faith research that follows these rules.

Also at /.well-known/security.txt. Questions about security for your team: get in touch.