Security at Seteo
Seteo handles sensitive things — your sermons, your team, your weekly plan — so we build security in by default and try to be plainly honest about where we are. Seteo is in early access; this page describes our current practices and the third parties we rely on. It will grow as we do. If anything here is unclear, or you find a vulnerability, please reach out at security@seteoapp.com.
01Authentication & access
Every request to the application is authenticated. Sign-in is handled by our dedicated authentication provider (email and password, or Google sign-in). Each API route independently verifies your session, so no endpoint depends on a single gate. Role-based access (Admin, Worship Leader, Team Lead, Member) shapes what each person can see. Data is isolated per church: every query is scoped to your organization server-side, so one church can never read or write another's records.
02Volunteer links
Volunteers access their schedule through personal links built on 192-bit random tokens. We store only a SHA-256 hash of each token for verification, plus an encrypted-at-rest copy under a server-side key for support operations; a database compromise alone does not yield usable links. Links expire on a sliding ~180-day window, are instantly revocable by the volunteer ("Not you? Reset") and by leaders, and every reset is recorded in the church's activity log. Public link pages enforce durable rate limits to resist token guessing.
03Data in transit & at rest
All traffic is served over HTTPS/TLS. The application runs on a major cloud platform, and application data is stored in managed Postgres with encryption at rest. We apply standard security response headers (HSTS, X-Frame-Options, nosniff, a restrictive Permissions-Policy) on every route, and a Content-Security-Policy is enforced on every route.
04Your content & AI
Seteo uses our AI provider's API to turn a sermon into a service plan and to power the chat co-pilot. Your sermon and plan text are sent to our AI processing provider only to generate your results, are processed transiently, and are not used to train public models (per our AI provider's API data policy). We do not log your sermon content. Prompts are hardened against injection — your sermon text is treated as content, never as instructions — and all AI routes enforce authentication, rate limits, and payload-size limits.
05Subprocessors
We share data with a small set of vetted providers, only as needed to run the service: our AI processing provider (sermon/plan text, transient processing only), our authentication provider (account data), our database and application-hosting platforms, our transactional-email provider (schedule notifications and security alerts), and Discord (our own bot, "Seteo Worship," runs in your server: it creates private per-service channels, manages member permissions on them, posts set summaries, and reads your server's member list to do so; the bot's single credential is held server-side in environment configuration — never in our database — and per church we store only your server's ID and name). We do not sell your data, and we do not use third-party advertising or analytics trackers. The site self-hosts its fonts, so loading a page does not leak your visit to a font CDN.
06Application security practices
Authentication is enforced in middleware and again at each API route as defense-in-depth. Requests carry rate limits and body-size limits. We avoid storing secrets in the browser and keep integration credentials server-side. As an early-access product we have not yet completed a SOC 2 audit or third-party penetration test; we will update this page as those milestones land.
07Responsible disclosure
If you believe you have found a security issue, please email security@seteoapp.com with the details and steps to reproduce. We will acknowledge your report, investigate promptly, and keep you updated. Please give us a reasonable chance to fix the issue before disclosing it publicly.