# 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.

URL: https://paidhelm.com/docs/security/  
Last updated: 2026-11-01

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-server and /.well-known/oauth-protected-resource. Unauthenticated requests receive HTTP 401 with a WWW-Authenticate header 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/adwords and 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/.