Security Policy

Ritsu is a learning platform that holds something people care about deeply: their study notes, source materials, and the AI-generated aids they rely on. We take the security of that information seriously.

This page documents how Ritsu protects your account and your content. It is not a legal contract — our legal obligations are in the Terms of Service and Privacy Policy. This page describes the controls we actually have in place.

We are a small, independent operation. That means our security posture is shaped by two honest realities: (1) we implement industry-standard controls where the stakes warrant them, and (2) we are transparent about what we have not yet done. We believe honesty beats marketing for trust.

If you find a security issue, please email security@ritsu.ai.

2.1 At rest

• Database: All user data in our Supabase Postgres instance is encrypted at rest with AES-256. Supabase is built on AWS RDS and uses the underlying AWS-managed encryption keys.
• File storage: User-uploaded files (PDFs, DOCX, images, etc.) are stored in Cloudflare R2, which encrypts all objects at rest with AES-256.
• Backups: Database backups are encrypted with the same standard and stored alongside the primary database, rotated on a 90-day window.

2.2 In transit

• All traffic between your browser and Ritsu uses TLS 1.2 or higher, enforced by our Vercel edge network.
• We have HTTP Strict Transport Security (HSTS) enabled with preload submitted to the major browser HSTS preload lists. This means browsers will refuse to connect to Ritsu over unencrypted HTTP.
• Internal service-to-service communication (Ritsu app → Supabase → R2 → Gemini/OpenRouter) also uses TLS.

2.3 Secrets

• API keys, service-role tokens, and other secrets are stored in encrypted environment variables managed by Vercel.
• No secrets are committed to our git repository.
• Secrets are scoped to the minimum privilege required. Service-role keys for Supabase are never exposed to the client browser.
• Secrets are rotated at least annually, or immediately on suspected compromise.

3.1 User authentication

• User accounts are managed by Supabase Auth.
• Passwords are hashed with bcrypt (10 rounds by default). We never store or log plaintext passwords.
• Optional OAuth sign-in (Google, GitHub) is scoped to minimum profile data (email, name).
• Password reset uses time-limited tokens delivered by email.

3.2 Row-Level Security (RLS)

3.3 Session management

• Sessions are managed via Supabase Auth with secure, HTTP-only cookies.
• Sessions expire after a reasonable inactive period.
• Logout invalidates the session token server-side.

3.4 Rate limiting

• Authentication endpoints (login, signup, password reset) are rate-limited to prevent credential stuffing and brute-force attacks.
• API endpoints have per-user rate limits to prevent abuse.

Ritsu runs on a small set of well-known cloud services. We pick vendors based on their own security track records, not because we reinvent wheels.

• Application hosting: Vercel — Next.js app, edge delivery. Region: United States (global edge).
• Database & auth: Supabase — Postgres, auth, Row-Level Security. Region: US East (EU available on request for paid plans).
• File storage: Cloudflare R2 — user-uploaded sources. Region: global edge (primary: US).
• Payment processing: Lemon Squeezy Inc. — Merchant of Record; PCI-DSS compliant. Region: United States.
• AI inference (primary): Google Gemini API — LLM generation. Region: United States.
• AI inference (fallback): OpenRouter — LLM generation via multiple providers. Region: United States.
• Transactional email: Resend — receipts, security alerts. Region: United States.
• DNS: Cloudflare — domain resolution. Region: global.

Each of these vendors implements its own security controls (SOC 2, ISO 27001, etc.). We inherit the majority of our compliance posture from them. See their respective security pages for details.

We do not operate our own servers or data centers. We do not have physical infrastructure that can be stolen, broken into, or improperly disposed of.

5.1 Code and dependencies

• The Ritsu codebase is a TypeScript Next.js application versioned with Git.
• We use Dependabot (or equivalent) to flag known vulnerabilities in our dependencies and update them promptly (typically within 7 days for high-severity CVEs, faster for critical).
• Dependencies are locked to specific versions (pnpm-lock.yaml) and audited before upgrades.

5.2 Protections against common web vulnerabilities

• SQL injection: prevented by using Supabase’s parameterized query layer. We do not concatenate user input into SQL.
• Cross-Site Scripting (XSS): mitigated by React’s default content escaping + Content Security Policy headers. User-generated content shown in the UI is treated as untrusted.
• Cross-Site Request Forgery (CSRF): Next.js session cookies use the SameSite attribute; state-changing endpoints verify request origin.
• Clickjacking: X-Frame-Options and CSP frame-ancestors directives prevent embedding of Ritsu in third-party iframes.
• Open redirects: internal redirects validate destination URLs against an allow-list.

5.3 Input validation

• All user inputs (form fields, API payloads, uploaded files) are validated for type, length, and allowed content.
• File uploads are restricted to the allowed formats (PDF, DOCX, Markdown, TXT, PowerPoint, images, Jupyter notebooks) and a 20 MB per-file size cap.
• Malformed or suspicious inputs are rejected with a descriptive error, not silently accepted.

5.4 Webhook integrity

• Webhooks from our payment processor are verified using HMAC-SHA256 signatures against a shared secret before any action is taken on the payload.
• Unsigned or incorrectly signed webhooks are rejected and logged.

Ritsu’s core feature is AI generation. That creates security concerns that generic web apps do not have. We follow the OWASP Top 10 for LLM Applications guidance and apply the following controls.

6.1 Prompt injection (LLM01)

User-supplied content can contain instructions that attempt to manipulate the AI into unsafe behavior (“ignore previous instructions and …”). Our mitigations:

• User input is passed to the AI as data, not as instructions, using clear role separation in the prompt (system prompt vs. user prompt).
• We do not execute AI outputs as code automatically.
• We do not give AI outputs access to tools that modify other users’ data or send emails.
• Prompt boundaries are reinforced at each invocation, so one user’s session cannot poison another’s.

6.2 Sensitive information disclosure (LLM06)

• Prompts sent to Gemini / OpenRouter contain only the user’s own content and the context necessary for their request. We do not include other users’ content, credentials, or internal system data.
• System prompts do not contain secrets, keys, or other data that would be dangerous if leaked.

6.3 Training data poisoning (LLM03)

6.4 Overreliance (LLM09)

AI outputs in Ritsu are presented as study aids, not authoritative answers. The Terms of Service requires users to verify important information, and the UI reinforces this at appropriate moments.

6.5 Model denial of service (LLM04)

• Credits enforce per-user usage limits, preventing a single user from exhausting the Gemini / OpenRouter quota.
• Rate limits on AI endpoints are stricter than on general API endpoints.

6.6 Insecure output handling (LLM02)

AI outputs are rendered in the UI with the same XSS protections as user content. An output that attempts to inject JavaScript or HTML is escaped, not executed.

7.1 Personnel

Ritsu is operated by a very small team (currently the founder and co-founder). This keeps our attack surface small: the number of people with production access is extremely limited.

7.2 Access controls

• Production access is granted only to the operator(s) running Ritsu.
• Multi-factor authentication (MFA) is required on all administrative accounts: Vercel, Supabase, Cloudflare, domain registrar, payment processor, GitHub, email.
• MFA uses time-based one-time password (TOTP) authenticator apps. SMS-based MFA is avoided where alternatives exist.

7.3 Device security

• Development and administrative work is done on personal devices with full-disk encryption, screen lock, and reasonable operating-system hygiene.
• Secrets are not stored in plaintext files on dev machines.

7.4 Supply chain

• Dependencies are reviewed at upgrade time for maintainer reputation and known issues.
• New dependencies are added sparingly; we prefer fewer, well-maintained packages over many small ones.

8.1 Monitoring

• Vercel and Supabase provide baseline monitoring of availability, error rates, and unusual traffic patterns.
• Application logs are retained for 30 days (see Privacy Policy §10) for operational debugging and incident response.
• We will expand monitoring as the product and user base grow.

8.2 Change management

• All code changes go through git version control with commit history and Pull Request review (when the team is more than one person).
• Changes are deployed through Vercel’s preview-and-production pipeline.
• Database migrations are applied via Supabase’s migration system with manual review.

8.3 Backups and recovery

• Supabase automated backups run daily, retained for 90 days, and encrypted at rest.
• In case of data loss, we can restore from the most recent valid backup. Recovery time objective (RTO) targets are measured in hours, not days; recovery point objective (RPO) is 24 hours or better.

If a security incident affects Ritsu users, we commit to the following.

9.1 Detection

• Monitoring alerts and user-reported issues are reviewed promptly.
• Suspected incidents are escalated internally to the operator for immediate assessment.

9.2 Response steps

1. Contain: isolate the affected system, rotate exposed credentials, disable access where appropriate.
2. Investigate: determine what happened, when, whose data was affected, and how.
3. Notify affected users: within 72 hours of discovering a breach of personal data, in line with GDPR Article 33 and similar US state-law requirements, where the breach is likely to result in a risk to user rights or freedoms.
4. Remediate: patch the vulnerability, restore affected services, rebuild what is needed.
5. Post-mortem: document what happened, what went wrong, and what we are changing so it does not happen again.

9.3 Communication

• Breach notifications include: what was affected, when, what data was exposed, what we have done, what the user should do.
• We publish a public summary of significant incidents on our blog (future) or changelog when the incident is resolved and legal counsel advises it is safe to do so.

If you discover a security vulnerability in Ritsu, please email security@ritsu.ai with:

• A description of the issue.
• Steps to reproduce (if possible).
• Any proof-of-concept code or payloads.
• Your name (or handle) if you want acknowledgment.

We commit to:

• Acknowledge receipt within 72 hours (usually much faster).
• Keep you informed as we investigate and fix.
• Not take legal action against researchers who act in good faith, follow responsible-disclosure norms, and give us reasonable time to fix before public disclosure.
• Publicly credit researchers in our security hall of fame (if you want credit) after the issue is resolved.

10.1 Out of scope

These are generally out of scope for security reports:

• Reports about vulnerabilities in third-party services we use (report to them directly).
• Denial-of-service attacks that you demonstrate by actually causing service degradation.
• Social engineering attempts against Ritsu staff or users.
• Physical attacks.
• Reports of missing security headers that do not lead to a concrete vulnerability.

10.2 No paid bug bounty yet

We do not currently operate a paid bug bounty program. We acknowledge that we should eventually, and it is on our roadmap. For now, we rely on the goodwill of the security community and offer public acknowledgment as the only reward.

Honest accounting:

11.1 What we do claim

• GDPR compliance for EU/UK users (see Privacy Policy).
• CCPA compliance for California residents (see Privacy Policy §11).
• Inheritance of SOC 2 Type II, ISO 27001, and similar certifications from our sub-processors (Vercel, Supabase, Cloudflare, Google, Lemon Squeezy). This does not mean Ritsu itself holds those certifications.
• 72-hour breach notification per GDPR Article 33.

11.2 What we do NOT claim

11.3 Why transparency matters

Claiming certifications you don’t have is the single fastest way to destroy trust when the claim is discovered. We would rather be honest about where we are than inflate our posture and get caught. Expect our compliance claims to grow with our engineering maturity, not before.

We update this page to reflect real changes in our security posture, not marketing updates. When material changes occur (new sub-processors, new controls, certification achievements, incident-driven changes), we:

• Update the “Last Updated” date at the top.
• Add a summary to the Legal Hub changelog.
• Notify paid subscribers if the change affects how their data is protected.

• Security / vulnerability reports: security@ritsu.ai
• General security questions: security@ritsu.ai
• Privacy / data rights: privacy@ritsu.ai
• Legal / compliance inquiries: legal@ritsu.ai

Security is not a destination. It is a practice, and we get better at it by paying attention. Thanks for caring enough to read this page.