Security at Ezra

Last updated July 29, 2026

A church database holds things people said in confidence. Here is, concretely, how Ezra protects it. No vague reassurances; these are the controls that exist in the product today.

Tenant isolation

Every church lives behind row-level security enforced by the database itself, not just the application. Every query runs as the signed-in user, and cross-church references are rejected by composite foreign keys at the schema level. Uploaded files live in a private bucket whose access rules are derived from the same tenant boundary; nothing is ever served publicly, and downloads use short-lived signed URLs minted after a permission check.

Least privilege inside your church

Roles map to specific permissions checked in the database on every read and write. Pastoral notes require a dedicated permission even to read. Volunteers can see and manage only their own serving information through constrained, audited operations. Sensitive state changes (ownership transfer, member removal, role changes, scheduling compliance) are enforced inside database transactions so they cannot be bypassed by calling the API directly.

Encryption and secrets

  • All traffic is encrypted in transit (TLS, with HSTS).
  • Data is encrypted at rest by our database provider.
  • Integration credentials your church connects (for example Planning Center) are additionally encrypted with AES-256-GCM before they are stored, so a database backup alone cannot expose them.
  • Card details are handled entirely by Stripe and never touch Ezra's servers.

Accountability

Every meaningful change in a workspace is written to an append-only audit log that browsers cannot forge or edit. Workspace deletion is recorded in a ledger that survives the workspace. Error monitoring scrubs personal information before events leave the server, and session recording is deliberately not used.

Testing and process

The tenant-isolation and permission rules are covered by an automated security test suite that runs on every change, including cross-tenant probes for every role and direct-API bypass attempts. We run internal security reviews against the full codebase and remediate what they find; an independent external security review has not yet been performed and is planned before wider rollout — we will say so here when it has happened, not before.

Reporting a vulnerability

If you believe you have found a security issue, email support@ezraos.co with enough detail to reproduce it. We will acknowledge within two business days, keep you informed, and never take legal action against good-faith research.