Account
Authentication and security
Technical details of PaidHelm's OAuth 2.0 implementation for MCP clients, the Google OAuth scope used, token encryption, revocation, logging and the safety rules built into the tools.
Two OAuth layers
- Client ↔ PaidHelm. Your MCP client (Claude, Cursor…) authenticates to PaidHelm using OAuth 2.0 with dynamic client registration and PKCE. Metadata is published at
/.well-known/oauth-authorization-serverand/.well-known/oauth-protected-resource. Unauthenticated requests receive HTTP 401 with aWWW-Authenticateheader that points the client to the authorization server. - PaidHelm ↔ Google. During that flow PaidHelm redirects you to Google's consent screen requesting
https://www.googleapis.com/auth/adwordsand your email. Google returns a refresh token that PaidHelm encrypts (AES-GCM, key in Cloudflare secrets) before storing.
What is stored
- Email, encrypted refresh token, plan, billing IDs, task counter, cycle dates.
- Tool-call log: tool name, timestamp, customer ID, outcome. 90 days.
- Not stored: report results, campaign contents, conversation text, access tokens beyond their lifetime.
Revocation
Disconnect in the portal, in your MCP client, or at Google (myaccount.google.com → Security → Third-party access). Any of these stops access immediately.
Built-in safety rules
- Campaigns, ad groups and ads are created paused.
- Write tools require explicit resource IDs; there is no "pause everything".
- Removals require the exact object and the assistant confirms before calling.
- Quotas cap the number of operations per cycle, limiting the blast radius of a runaway loop.
Infrastructure
Cloudflare Workers, D1 and KV; TLS everywhere; secrets in Cloudflare's encrypted store; payments by Paddle (no card data at PaidHelm). Full statement on the Security page; DPA at /dpa/.