Security

Data Encryption

In Transit

All data transmitted between your browser and our servers is encrypted using TLS 1.2 or higher (HTTPS). This applies to web pages, API calls, and file uploads. We enforce HTTPS everywhere and use HSTS (HTTP Strict Transport Security) to prevent downgrade attacks.

At Rest

Sensitive data stored in our database — including passwords and personal identifiers — is encrypted at rest using AES-256. Passwords are stored as salted bcrypt hashes; we never store plaintext passwords and cannot retrieve them.

Database Encryption

Our database provider encrypts all data at the storage layer. Backups are also encrypted with the same level of protection.

Payment Security

• Stripe tokenizes your card and returns a token that we use for billing; your card number never touches our servers.
• PayPal transactions are processed entirely within PayPal's secure environment.
• Paddle, as Merchant of Record for the transactions it processes, handles cardholder data entirely within its own PCI DSS Level 1 certified environment.
• We store only the last four digits of your card and expiry month/year for display purposes.
• 3D Secure (Verified by Visa / Mastercard SecureCode) may be applied for additional transaction verification.
• All payment endpoints are rate-limited and monitored for anomalous activity.

Account Security

Password Requirements

Passwords must be at least 8 characters long. We strongly encourage the use of a unique, strong password and a password manager.

Brute-Force Protection

After 5 consecutive failed login attempts, your account will be temporarily locked for 30 minutes. Repeated lockouts may trigger additional verification steps.

Session Management

• Sessions are managed using secure, HTTP-only cookies with CSRF protection.
• Sessions expire after a period of inactivity.
• You can view and revoke active sessions from your Account Settings.
• Logging out invalidates your session token immediately on the server side.

Two-Factor Authentication (2FA)

We are developing optional 2FA (TOTP / email-based) for additional account protection. This feature will be available in a future release.

Fraud Prevention at Sign-Up

We use IP quality scoring and device fingerprinting to detect and prevent multi-account abuse during account registration. Fraudulent accounts are terminated and associated devices may be blocked.

Infrastructure & Hosting

Hosting Provider

The Service runs on infrastructure we operate and manage directly, behind an nginx reverse proxy with automatic HTTPS and network-level access controls, rather than a third-party platform-as-a-service.

Database

We run PostgreSQL with automated encrypted backups and network isolation. Database access is restricted to application servers on our private network — it is never exposed directly to the public internet.

DDoS Protection

API endpoints are protected by rate limiting (maximum 100 requests per 15-minute window per IP), with additional network-level mitigations in front of our servers.

File Storage

Uploaded documents and generated audio are stored in Cloudflare R2, in isolated, access-controlled buckets. Files are linked to your account and are not publicly accessible. Storage is encrypted at rest.

AI & Document Processing

When you use The Scholar Agent, document content is sent to the Google Gemini API for AI processing. We take the following steps to protect your data during this process:

• Only the text you explicitly request to be processed is transmitted — not your entire document library.
• Transmission to the AI API is encrypted via HTTPS.
• We operate under an enterprise API agreement that prohibits Google from using your data for model training.
• AI processing is ephemeral — data is not permanently stored by the AI provider.
• We do not log or permanently store AI conversation transcripts after your session ends.

Breach Notification

In the event of a data breach that affects your personal information, we will:

• Conduct an immediate investigation to contain and assess the breach.
• Notify affected users by email within 72 hours of confirming the breach.
• Report to relevant regulatory authorities as required by applicable law (e.g., GDPR requires notification to the supervisory authority within 72 hours).
• Provide a clear description of what data was affected, what we are doing to address it, and what you can do to protect yourself.

Internal Access Controls

• Access to production systems and databases is restricted to authorized engineering personnel on a need-to-know basis.
• All internal access is logged and audited.
• Engineers use multi-factor authentication to access production environments.
• We follow the principle of least privilege — each team member has access only to what is required for their role.
• Third-party vendor access is governed by data processing agreements (DPAs) and scoped to the minimum required.

Reporting a Vulnerability

We take security vulnerabilities seriously and appreciate responsible disclosure. If you discover a security issue in our Service, please do not publicly disclose it before giving us the opportunity to fix it.

We ask that researchers:

• Do not access or modify user data beyond what is necessary to demonstrate the vulnerability.
• Do not perform destructive actions or denial-of-service attacks.
• Do not disclose the vulnerability publicly until we have had a reasonable opportunity to remediate it.

While we do not currently operate a formal bug bounty programme, we will acknowledge responsible disclosures and may offer recognition or compensation at our discretion.