Security
Batonly is used to document internal workflows, systems, and operational processes. Because that content can be sensitive, security isn't an afterthought here — it's part of how the product is built.
Overview
Batonly uses modern cloud infrastructure and strong access controls throughout. Your data is isolated, encrypted, and only accessible to you.
Accounts are protected by Supabase Auth, with session-based login and full password reset flows.
Row Level Security ensures database queries only return data belonging to the authenticated user.
Screenshots are stored in private buckets. Files are never publicly accessible — only via signed URLs.
All traffic is encrypted using HTTPS and TLS. Data at rest is encrypted by the underlying cloud providers.
Batonly runs on Supabase, Vercel, and Cloudflare — providers with proven security track records.
Access policies, restricted APIs, and secure auth flows are applied as standard practice throughout.
Authentication
Batonly uses Supabase Auth to handle all user authentication. This is a purpose-built authentication system with a strong security model — Batonly never stores raw passwords or manages authentication directly.
Row Level Security is a Postgres feature that attaches access policies directly to database tables. Every query — no matter how it originates — is automatically filtered by these policies.
In Batonly, all tables enforce a policy that restricts reads and writes to rows owned by the currently authenticated user. Even at the database level, your data is invisible to other users.
Data isolation
Every project, guide, and task in Batonly is linked to the user who created it. Database policies prevent any user from reading or modifying another user's data — even if they know the ID.
This isolation is enforced at the database level, not just in application code. It cannot be bypassed by a bug in the application layer.
File security
Batonly is designed for documenting real workflows, which often means your screenshots contain internal systems, dashboards, or operational tools. Those files are treated accordingly.
All uploaded screenshots are stored in private storage buckets — they are not publicly accessible via any URL, and are never exposed without authentication.
Infrastructure and encryption
Batonly is built on infrastructure from providers with strong security records. Encryption is applied at every layer as a baseline, not an option.
Batonly runs on three core providers:
AI processing
Batonly uses Anthropic's Claude API to generate guides from the screenshots and context notes you provide. This means content you upload is processed by Anthropic's systems as part of that generation step.
Only the data required to generate your guide — the relevant screenshots and your context notes — is sent to the AI. Anthropic's API usage policies do not permit user data to be used for model training. You can review Anthropic's privacy practices at anthropic.com/privacy.
Recommendation: Avoid uploading screenshots that contain credentials, personal data, or confidential financial information. AI processing involves third-party systems outside Batonly's direct control.
Development practices
Security isn't something added at the end. The following practices are applied throughout Batonly as standard.
Row Level Security is enforced on all tables. No unauthenticated or cross-user queries are possible.
File storage is configured with private access by default. Uploads are only accessible via authenticated, time-limited requests.
External API calls — including to the AI provider — are made server-side, with keys stored securely as environment variables.
Authentication, password resets, and session management are handled by Supabase Auth with industry-standard token handling.
If you discover a potential security vulnerability in Batonly, please let us know. We take all reports seriously and will investigate promptly.
security@batonly.comGeneral questions? Reach us at hello@batonly.com