Trust Center

Security and data

What we actually do, described from the running system. Where something is not in place, we say that too.

Identity and sign-in

Passwords are never visible to us: Passwords are handled by our authentication provider (Supabase Auth). Pinevon never sees or stores one in the clear. Sign-up enforces a password policy (lowercase, uppercase, digit and symbol).
Multiple sign-in methods: Email and password, Google, GitHub and Facebook sign-in, passkeys, and two-factor authentication with an authenticator app. Changing a password can require a fresh verification code.
Abuse protection: A verification challenge (Cloudflare Turnstile) protects sign-in, sign-up, password recovery and public forms, alongside rate limits.
Sessions you can control: You can see your sessions, sign out one device, or sign out every other session. Logging out ends only the session on that device.

Authorization and data separation

Default-deny database access: Row-level security is enabled on our data tables and access is denied unless a policy or a server-only function allows it. An audit of both production databases found no tables without row-level security.
Server-side checks, not hidden buttons: Roles and permissions are checked on the server on every sensitive request. Internal company tools return a plain not-found page to anyone without a role.
One business cannot see another’s data: In Anchor every business-owned row carries a business identifier, enforced by row-level security and again by independent API authorization checks. The AI cannot choose which business to read.

Encryption and storage

Encryption in transit: All Pinevon sites and APIs are served over HTTPS, with HTTP Strict Transport Security (two years, including subdomains).
Encryption at rest: Data is stored with our infrastructure providers (Supabase, Vercel, Render), which provide encryption at rest as part of their platforms. We have not added our own application-level encryption for stored records and have not independently audited the providers’ implementation.
Private files and signed links: Support attachments and backups are stored in private storage. Staff open an attachment through a short-lived signed link, and access is re-checked each time.
Uploads are validated: Uploads are checked for size, declared type and the file’s real contents. Contact-form attachments also pass a safety screen before they are accepted.

Secrets, logging and monitoring

Secrets stay on the server: Service credentials, database keys and AI provider keys live only in server environment configuration and are never bundled into browser code.
Browser security headers: We send X-Frame-Options (deny), X-Content-Type-Options, a Referrer-Policy, a Permissions-Policy and a Content-Security-Policy limited to framing, base URI, plugins and form targets. A full script policy is not deployed yet.
Audit trail: Privileged actions in our internal tools are recorded in an append-only audit log. AI calls are metered and logged with provider, tokens and cost.
Privacy in rate limiting: Rate-limit keys are keyed hashes of the requester’s address, not the address itself.

Resilience

Automated backups: Both the Pinevon and Anchor databases are backed up daily as logical backups to private storage, pruned after 30 days, with failure alerts to the owner. A restore has been rehearsed against backup data. These are not point-in-time or physical backups.
AI outage handling: If an AI provider fails, requests fall back to another configured provider, and a circuit breaker stops repeatedly calling one that is down. Owners are alerted to sustained failures.

Your data

Export and deletion: You can export your account data and delete your account from Settings. For Anchor business data, contact us to export or delete it.
AI providers: Conversation content needed to generate a reply is sent to the configured AI provider (Google Gemini, with Groq, OpenAI and Anthropic as fallbacks). We do not send unrelated account data. Each provider’s terms govern its processing. See the Subprocessors list.
Third-party processors: The providers that process personal data for us, and what for, are listed in the Subprocessors document, with notice before changes for customers under a DPA.

Limits

What we do not have

SOC 2 or ISO 27001 certification or audit
HIPAA compliance or any healthcare regulatory certification
PCI DSS compliance (Pinevon does not handle card numbers; payment providers do)
GDPR “certification” (there is none); we describe our practices in the Privacy Policy and DPA instead
An independent third-party penetration test
End-to-end encryption
A formal, published incident-response programme or uptime guarantee (we do not publish uptime statistics)

Incident handling today: our systems alert the owner by email on backup failures and sustained AI outages, and security reports are handled under the Security Disclosure Policy. We do not yet publish incident reports.

Found something? Tell us privately.

Report an issue Subprocessors