Security

Sign-in without passwords

• Accounts use passkeys (WebAuthn). We store only each passkey’s public key, so there is no password database to steal, phish or stuff.
• Every sign-in challenge is issued by the server, used once, expires in five minutes, and is bound to the browser that requested it.
• Passkeys are tied to analytics-power.com from a fixed allowlist, never to whatever host a request claims. Signature counters are checked to help detect cloned authenticators.
• Account recovery uses single-use recovery codes or a single-use email link, stored only as hashes. Recovering only allows registering a new passkey — it cannot read data — and completing it revokes the old passkeys and every other session.
• Sign-up and recovery email requests are protected by a bot check.

Sessions and request protection

• Sessions are server-side records referenced by a __Host- cookie that is HttpOnly, Secure and SameSite=Lax. Revoking a session takes effect on the next request. Sessions last at most 12 hours.
• Every state-changing request made with a session cookie must come from our own origin; cross-site requests are refused.
• Every response carries a strict Content Security Policy (scripts only from our origin, framing forbidden), HSTS, X-Content-Type-Options: nosniff, a Referrer-Policy and a Permissions-Policy.
• Questions are rate-limited per IP address and per workspace.
• Unexpected errors return a generic message and an incident ID. Internal details stay in our logs.

Read-only by design

• Queries are generated from templates over the metric definitions your workspace has approved. An AI model may help choose which approved metric a question refers to, but it never writes SQL.
• Every query is checked before it runs: it must be a single SELECT statement with no write or schema-changing keywords.
• Questions that would export personal data, or that bulk-export, write or delete, are blocked before any query runs, and the block is recorded.

A verifiable audit ledger

• Every question, query, block, sign-in, invitation, role change and configuration change is written to your workspace’s ledger.
• Each entry is hash-chained to the one before it, so an edited or deleted entry breaks the chain. On deployments configured with a ledger signing key, entries are also signed with HMAC-SHA256. The console reports which applies, rather than claiming a signature that is not there.
• The database refuses two entries claiming the same predecessor, so the chain cannot fork under concurrent use. Anyone in the workspace can re-verify the whole chain from the console.

Workspace isolation and access control

• Every record belongs to exactly one workspace, and every query is scoped to the caller’s workspace. No API lets a caller name a different workspace to act on.
• Members have one of four roles — owner, admin, analyst, viewer — and can be limited to specific data sources. Restricted sources are hidden from roles below their classification.
• A source you are not allowed to see returns the same “not found” as one that does not exist, so access errors don’t reveal what exists.
• Cached results are keyed by workspace, role and data-source access, so they never leak between members or workspaces.

Your credentials and your network

• Database credentials and connector tokens are encrypted at rest with AES-256-GCM. Each workspace’s key is derived separately (HKDF), so a value copied into another workspace cannot be decrypted.
• Credentials are write-only: no screen or API returns them after they are saved. If encryption is not configured, storing a credential is refused rather than saved in plain text.
• Your database stays in your network. Production sources are reached through a read-only connector (an MCP server) that you run inside your own network and expose through a tunnel you control. The connector authenticates us with a token, offers read-only tools, and can be switched off by you at any time.
• Connector endpoints must use HTTPS and a public hostname, so the service cannot be pointed at internal addresses.

AI data handling

The language model receives the question, the names of available metrics, and — for the written summary — the column names and up to 20 rows of the result. It never receives credentials, connector tokens or anything else from your sources. If the model is unavailable, answers fall back to template summaries. Details are on Subprocessors.

Infrastructure

The Service runs on Cloudflare Workers with Cloudflare D1 as its database, so all traffic is served over TLS from Cloudflare’s network. Secrets such as encryption and signing keys are held as platform secrets, not in source code.

Certifications

Analytics Power does not currently hold SOC 2, ISO 27001 or other third-party certifications. We are glad to answer security questionnaires and walk your team through the architecture — email matt@coastalcarolinatech.com.

Reporting a vulnerability

If you believe you have found a security issue, email matt@coastalcarolinatech.com with enough detail for us to reproduce it. Our contact details are also published at /.well-known/security.txt.

• We will acknowledge your report within three business days and keep you informed as we fix it.
• Please do not access or modify other people’s data, degrade the service, or use social engineering, and give us reasonable time to fix an issue before you disclose it.
• We will not pursue legal action against good-faith research that follows these guidelines.