Security Policy

Last updated: September 3, 2026

This page describes the security measures actually in place today, and section 9 says plainly what is not. We would rather be believed than impressive.

1. Where it runs

• The application runs on Vercel as serverless functions, pinned to the Frankfurt region.
• Data is stored in a managed Neon Postgres database in the EU (Frankfurt). Media is stored in Cloudflare R2.
• Two supporting services we run ourselves — the onboarding website crawler and the memory-graph service — are hosted in the EU.
• Volumetric and malicious traffic is filtered by the hosting platform's own mitigation before it reaches our code.

2. Separating one brand from another

This is the measure we care most about. Every request runs against the database as a specific brand, and row-level security policies in Postgres restrict it to that brand's rows. It is enforced by the database, not by application code remembering to filter — so a missing WHERE clause cannot leak another customer's data.

A test in our build reads the policies deployed on the live database and fails if one is missing or has drifted. A separate end-to-end probe checks that two different brands cannot see each other's connected accounts, posts or comments.

3. Encryption

• In transit: HTTPS/TLS everywhere — to the site, to the app, to the database, and to every vendor we call.
• At rest: our database and object-storage providers encrypt stored data at rest as standard.
• Secrets: API keys and credentials live in the hosting platform's encrypted environment configuration, never in source control. Commits are automatically scanned for leaked secrets.

4. Access

• Sign-in is handled by Clerk, which supports multi-factor authentication and handles session management and brute-force protection.
• Roles inside an organisation decide what a person — and what the agent acting for them — is allowed to do. Write actions are refused server-side for a read-only member, not merely hidden in the interface.
• Credentials for connected vendors are brokered: the AI model never sees a connection's URL, key or token.

5. How we build

• Every change goes through review and an automated build that must pass before it can merge: type checking, a full test suite, secret scanning and static analysis.
• Dependency updates are automated, and vulnerable dependencies are flagged.
• Input at API boundaries is validated against explicit schemas. Database access goes through a query builder with parameterised queries; we do not interpolate SQL.
• Automation conditions are evaluated by a safe expression parser, not by executing code. AI output is never executed.
• Security headers and per-IP rate limiting are applied at the edge on public endpoints.
• Errors are reported to Sentry so failures surface instead of being swallowed.

6. Backups

The database is a managed service with the provider's own backup and point-in-time restore. [COUNSEL: the backup retention window and restore objectives to publish, once confirmed against the database plan in force]

7. If something goes wrong

If we become aware of a security incident affecting your data, we will tell you without undue delay, say what we know, what we do not yet know, and what we are doing. We will follow up with what caused it and what changed as a result. [COUNSEL: the notification deadline and contact route to commit to]

8. Reporting a vulnerability

If you find a security issue, tell us before you tell anyone else. Include what you found and how to reproduce it. We will acknowledge you, keep you updated, and we will not pursue you for a good-faith report that did not damage or exfiltrate data.

Send it through the contact form, or to [COUNSEL: the security contact address to publish]. [COUNSEL: whether to publish a security.txt file and a safe-harbour statement]

9. What we do not have yet

Stated so nobody has to assume. We hold no third-party security certification — no SOC 2, no ISO 27001, no equivalent. We have not commissioned an independent penetration test. We do not offer a service level agreement, a bug bounty, or single sign-on and SCIM provisioning. We will say so here when any of that changes, and not before.

10. Contact

Security questions: use the contact form, or email [COUNSEL: the security contact address to publish].