Veiligheid

This page is maintained by the Reynard AI team to answer common security and privacy questions about Reynard AI. It is editable project content and is not an independent certification or audit attestation. Security is a shared responsibility between Reynard AI (the application), our platform providers, and you as the account holder.

Access & Authentication

• Email + password sign-in and Google sign-in are supported.
• Sessions are managed by our backend auth provider with rotating refresh tokens.
• Password reset is performed via a signed, single-use email link.
• Admin-only routes are gated by server-side role checks, not client state.

Data Isolation

• Every user-owned table enforces row-level security so users can only read and write their own rows.
• Sensitive payment fields (Stripe session id, payment status, amount, tier) can only be written by our backend service role, not by end users.
• Test target credentials are encrypted at rest using pgcrypto with a key stored in our backend secret vault and stripped from the plaintext column.

Platform & Hosting

Reynard AI runs on managed cloud infrastructure with TLS in transit and encryption at rest provided by the platform. Backend logic runs in isolated edge functions that validate JWTs before touching user data.

Secrets & API Keys

• Third-party API keys are stored as server-side secrets and never shipped to the browser.
• User-provided AI keys (BYOK) are encrypted before being persisted.
• Stripe webhook signatures are verified server-side before any state change.

Subprocessors

Reynard AI relies on a small set of subprocessors for hosting, database, authentication, payments (Stripe), email delivery, and AI model inference. See our Privacy Policy for the current list and purposes.

Cookies & Analytics

We use first-party cookies for authentication and a consent-gated analytics provider for product analytics. Details and opt-out are available on our Cookies page.

Accuracy & Validation

Reynard is a simulation: it carries no statistical significance and is not fieldwork. We publish no accuracy figure, because none has been measured yet. How we intend to be held to account, and the validation experiment we will run in public, is set out on our Accuracy page.

Retention & Deletion

You can delete individual captures, projects, prompts, and tests from within the app. Account deletion requests can be made via Support and remove associated user data from active systems within 30 days, subject to limited backup retention.

Reporting a Security Issue

If you believe you have found a security vulnerability, please contact us through the Support page. We will acknowledge your report and work with you on a fix. Please do not publicly disclose issues before we have had a chance to respond.

Compliance

Reynard AI is not currently independently certified against SOC 2, ISO 27001, HIPAA, or PCI. We follow the privacy commitments described in our Privacy Policy and handle EU personal data in line with GDPR principles.

Recent Security Fixes

We continuously scan our backend for misconfigurations. The most recent mitigations applied to the production environment:

• Payment-field tampering blocked. A database trigger (reynard_tests_prevent_payment_tampering) rejects any change to stripe_session_id, payment_status, amount_cents, or tier unless the caller is our backend service role. Stripe webhooks remain the single source of truth for payment state.
• Profile role escalation blocked. A matching trigger (prevent_profile_privilege_escalation) prevents users from upgrading their own plan, role, or billing fields.
• Credit balances are server-issued. The client-side insert policy on user_credits was removed; new credit rows are created exclusively by an onboarding trigger and adjusted only by our edge functions.
• Test-target credentials encrypted at rest. Logins on reynard_tests.targets are encrypted with pgcrypto using a key stored in our backend secret vault, and plaintext credentials are stripped from the public column.
• Early-access signups deduplicated. A unique index on the lower-cased email column prevents the same address from being submitted repeatedly.
• Storage buckets owner-scoped. All private buckets (including pdf-shares) restrict reads to the row owner; external sharing uses server-issued signed URLs.

Mitigation approach: prefer server-side enforcement (RLS policies + BEFORE triggers running as the service role) over client-side checks, so a malicious client cannot bypass the rule even with a forged request.