Security

Emily is used by public affairs professionals whose client work is confidential. This page sets out, plainly, how the service is built and run. It only makes claims we can stand behind: each one is grounded in our infrastructure configuration, our codebase, or the published terms of a named provider. It also says what we do not yet claim.

Where your data lives

• Customer data is stored in a PostgreSQL database hosted by Supabase in AWS eu-west-2 (London). It does not leave the UK/EU region at rest.
• The application layer runs on Vercel. Traffic is encrypted in transit with TLS, and data is encrypted at rest by our infrastructure providers (Supabase on AWS).
• The full list of third parties that process data on our behalf, what each one sees, and where it runs is public on our sub-processors page.

Access control in the database itself

• Row Level Security is enabled on our database tables, so access rules are enforced by PostgreSQL rather than only by application code. Internal tables (billing contracts, sales leads, audit logs) are locked further: they carry no access policies at all and are reachable only by our server-side service role.
• Privileged database functions that can write billing data are executable by the service role only. We learned the hard way that a permissions migration can read correctly and still be wrong on the live database, so we verify these grants against the live database catalog with a preflight check, and a test in our continuous integration suite keeps the posture pinned.
• Administrative actions on customer accounts go through server-side admin verification and are recorded in an audit log.

Application safeguards

• Structured data embedded in public pages is serialised through a dedicated escaping helper, and a continuous integration test fails the build if any page embeds structured data without it. This closes the script-injection route through user-visible shared content.
• Public endpoints carry per-IP rate limits. The unauthenticated AI paths additionally sit under a single global daily request and spend ceiling that fails closed: if the shared counter cannot be reached, the free paths stop serving rather than spend without counting.
• Payments are processed by Stripe on Stripe-hosted checkout pages. Full card details never touch our servers, and incoming billing webhooks are cryptographically signature-verified before they are acted on.

AI models and your data

We do not use your data to train AI models, and we state the basis for that rather than asserting it bare:

• Emily runs on Google's Gemini models served through Vertex AI on Google Cloud. Under the Google Cloud terms that govern Vertex AI, Google does not use customer prompts or outputs submitted to Vertex AI to train its foundation models.
• Document drafting can also run on Anthropic's Claude models under Anthropic's commercial terms, which do not permit training on customer content.
• Our retrieval sub-processors (embeddings and reranking) are listed, with exactly what each receives, on the sub-processors page.

What we do not claim

We do not yet hold SOC 2, ISO 27001 or Cyber Essentials certification, and we will not badge this site as if we did. Most vendors in this market publish nothing about security at all; we would rather publish an honest page than an impressive one. When our certification position changes, it will appear here with a date.

Reporting a vulnerability

If you believe you have found a security issue in Emily, email support@emilypolitics.com with the details. That inbox is monitored by the founding team. Please do not test against other customers' data; we will respond promptly and credit good-faith reports if you would like us to.