Where it runs
The service runs on Google Cloud: the server on Cloud Run, data in Cloud SQL for PostgreSQL, keys in Cloud KMS, secrets in Secret Manager, logs and alerts in Cloud Logging and Monitoring, behind Cloud Load Balancing with Cloud Armor. The infrastructure is defined in code and deployed automatically through a pipeline with a canary gate.
Signing in and connecting
- The console uses Google sign-in; we never see or store a password.
- Ad platforms are connected with OAuth 2.0 using the narrowest scopes the features need. You can revoke the grant from your Google or LinkedIn account at any time.
- Claude connects with an access key you create in the console. Keys are generated with a cryptographic random generator, shown once, and stored only as a keyed hash (HMAC-SHA-256 under a managed key). Revoking a key stops it immediately.
How tokens are protected
OAuth tokens are envelope-encrypted: every record is encrypted with its own data key, and that key is wrapped by a key that lives in Cloud KMS. Tokens are never written to logs, never returned to your browser, and never sent to Claude; the server uses them only to call the platforms on your behalf.
Isolation
Every request runs in the context of exactly one account, and the database enforces that boundary itself with row-level security. There is no cross-account pooling, benchmarking or enrichment, by design and by policy.
Nothing changes without you
Every write follows one path: preview against the platform (Google validates without applying; LinkedIn creates paused), show the diff, wait for your explicit approval, execute, confirm the result, and record it in an immutable audit log. Approvals are single use and expire; an edited change is previewed again. A policy guard refuses actions outside platform policy, such as attempts to get around a disapproval, and records the refusal.
Keeping less
The server stores tokens and account identifiers, not your campaign data. Data that Claude asks for passes through to your conversation. LinkedIn member data is purged by a scheduled job within the 24-hour (profile) and 48-hour (social activity) windows LinkedIn requires, with alerts if a purge fails. Technical logs are kept for 30 days with secrets redacted.
In transit and in operation
- TLS on every connection, with managed certificates.
- Secrets live only in Secret Manager, never in code or container images.
- Alerts on authentication-failure spikes, token-refresh failures and purge failures.
- Pinned platform API versions with a scheduled review of deprecations.
Your controls
- Choose which ad accounts the connector can see.
- Revoke any key, or all keys, in the console.
- Disconnect a platform, which revokes the grant and deletes its tokens.
- Review the audit log of every change made through the service.
Reporting a vulnerability
If you believe you have found a security issue, write to privacy@scalixai.com with the details. We acknowledge reports within two business days and keep you informed while we fix them. Please do not test against accounts you do not own.