ElectionsMCP
Security
This page describes the controls that exist today, and — just as importantly — the ones we do not claim yet. If you are deciding whether to put a campaign's data here, the second list should matter to you as much as the first.
Isolation
Every piece of customer data belongs to a workspace, and every request is resolved to a workspace before it can read or write anything. Inside a workspace, campaign content is further limited to the people placed on that campaign: holding an account in the workspace does not by itself grant access to a given campaign's war room, files or discussion.
We treat this boundary as something to be re-proven rather than assumed. It is covered by an adversarial test suite that attempts cross-campaign and cross-workspace reads and writes — signed in, signed out, and with deliberately forged identifiers — and those tests are themselves checked by breaking the control and confirming the tests fail. A boundary that no test can be shown to catch is not a boundary we count.
Authentication
Sign-in is by one-time email link. We do not ask for, transmit or store passwords, so there is no password database to breach and nothing to reuse elsewhere. Sessions are held in an HttpOnly, SameSite=Lax cookie, marked Secure in production.
Programmatic access uses API keys scoped to a workspace. A key can be revoked at any time from your account, and revocation takes effect immediately.
Your files
Files you upload — attachments, imports, campaign documents — are stored in private object storage. They are never publicly addressable. When someone entitled to a file opens it, the server issues a short-lived signed link for that specific object, after checking their workspace and campaign access. Links expire; a copied link stops working.
Data in transit and at rest
All traffic is served over TLS. Data at rest sits in managed Postgres and object storage operated by our hosting providers, with encryption at rest as provided by those platforms. Point-in-time recovery is enabled on the database.
Payments
Card details are handled entirely by Stripe. They do not pass through, and are not stored on, our servers. We hold a Stripe customer identifier, your plan and its status.
Operational practice
- Every change runs an automated suite before it can ship: type checks, a build, browser acceptance walks, a server test suite, and a set of fixed-value invariants that fail the build if a published number moves.
- Published figures are re-checked against the live site on a schedule, not only at deploy time.
- Rate limits protect the API and the streaming endpoints, and requests are attributed to a client address that callers cannot forge by setting a header.
- Database schema requirements are asserted at boot: a server whose database is missing an expected column refuses to serve rather than failing quietly in front of a customer.
- We keep a written incident runbook with a rollback rule, and the rollback path is rehearsed rather than assumed.
What we do not claim
We would rather be believed on the list above than impressive on this one.
- No SOC 2, ISO 27001 or comparable certification. We have not been audited against a formal framework.
- No third-party penetration test has been performed to date.
- No contractual uptime commitment. We publish no SLA and do not offer service credits.
- No customer-managed encryption keys, and no per-workspace key separation beyond what our storage providers apply platform-wide.
- No 24/7 staffed on-call. We are a small operation; alerting is automated, response is best-effort.
- Read-access audit logs are not yet available to customers. We can tell you what a workspace contains; we cannot yet hand you a complete record of who viewed what.
If any of these is a requirement for your organization, tell us before you buy — we would rather lose the sale than have you discover the gap afterwards.
Bringing sensitive data
Voter files, donor records and membership lists are licensed products with their own restrictions, and those restrictions are between you and your provider. Before importing, confirm your licence permits a hosted service to process the data on your behalf. See section 5 of our terms for how responsibility is allocated, and ask us if you need a data processing agreement.
Reporting a vulnerability
If you find a security problem, please tell us at [email protected] before disclosing it publicly, and give us a reasonable chance to fix it. We will acknowledge your report, keep you updated, and credit you if you would like. We will not pursue legal action over good-faith research that respects customer data and avoids degrading the service for others.
Please do not run automated scans or load tests against the production service without asking first — on infrastructure this size, a scan is indistinguishable from an outage.