What we store, what we can see, what we can't.

What we store

• Your account: email, plan, which connectors your key unlocks, creation date.
• Your API key: only its SHA-256 hash. The key itself is shown once at creation and cannot be recovered — we literally do not have it. Lose it, and we issue a new one.
• Your credentials: for Search Console, your OAuth client id, client secret, and the refresh token Google issues; for Bing, your API key. All AES-256-GCM encrypted with a key that lives only as a Cloudflare Worker secret — it is not in the database, the code, or the repository.
• A usage counter: one integer per month per customer. Not which tools, not which queries, not which properties' data — a count.
• Property names you have queried (e.g. sc-domain:example.com) — required to enforce per-property plans.

What we can technically see

Honesty over reassurance: in hosted mode the worker decrypts your credentials inside a request to call Google or Bing, and your search data transits the worker's memory on its way to your MCP client. We do not persist, log, or aggregate any of it — the only stored state is listed above — but “transits our infrastructure” is a fact, and an operator with deploy access could in principle alter the code to capture it. If that trust boundary is unacceptable, use self-host mode below, where we never see anything at all.

What we cannot see or do

• Your Google password or account: the OAuth grant is issued to your client with the webmasters scope only. We never hold a grant issued to us.
• Properties beyond what you authorised, or any Google service outside Search Console.
• Your plaintext API key (hash only), or your credentials once the worker secret is unavailable — the KV blobs are ciphertext.
• Your conversations with Claude. Tool calls arrive as isolated JSON-RPC requests with no conversational context.

Never logged, masked readback

Credentials never enter a log line. Upstream error bodies are redacted against your Bing key before any error message is composed, and Google error paths carry only the HTTP status and a truncated body. Status tools (gsc_auth_status, bing_auth_status) return at most a masked last-4 suffix like ••••c91b. These behaviours are enforced by the test suite, not by policy documents.

Retention and deletion

• Credentials live until you delete them (dashboard, or email ai@revenuedealer.com) or your account is deleted — deletion removes the KV entries, not just a flag.
• Usage counters expire automatically after 62 days.
• Cancelling your subscription revokes the key; credentials are deleted 30 days later unless you ask for immediate deletion.
• Revoking the Google grant from your account, or rotating your Bing key, instantly makes our stored copy useless — you do not need us to act.

Self-host mode

The same worker code runs single-tenant in your own Cloudflare account: your KV namespace, your encryption key, your bearer secret, no metering, no BloggerClinic infrastructure in the path at all. Deploy is wrangler deploy plus two secrets; the install page and the repository README carry the exact commands. Licence pricing for self-host is not yet announced.

Infrastructure

Cloudflare Workers + Workers KV. Traffic is TLS end to end; workers are stateless between requests; there is no origin server, database server, or VM to compromise. The admin API that issues keys is bearer-gated with a separate secret and is not reachable from MCP clients.