Facts
- Google API scopes requested: Google Ads (read and write) and Gmail send-only. No Drive, Contacts, Calendar, or inbox access. Gmail send is used only to dispatch reports you configure.
- Sign-in is Google OAuth 2.0; Google passwords are never seen. OAuth refresh tokens are Fernet-encrypted at rest — double-encrypted where a hard-coded pepper adds a second layer; local passwords are Argon2-hashed.
- Hosted on Microsoft Azure. HTTPS/TLS everywhere; no plain HTTP in production. Performance data lives in Azure Blob Storage partitioned per MCC and retained for 365 days.
- Tenant isolation at three layers: storage (per-MCC partition), request (every read checked against the user's allowed accounts, failing closed), secrets (per-workspace, encrypted).
- Google API Services User Data Policy, including Limited Use: no selling or sharing of Google user data; no training AI models on it.
- What reaches OpenAI: on-demand tools send the subset needed for that request when you run them; Pro monitoring sends flagged entities' aggregated metrics, campaign names, change history, and budget history nightly. Credentials are never included. Workspaces may bring their own OpenAI key.
- Writes to Google Ads happen only through Checkout, pushed by admins, workspace admins, or the MCC owner, and every push is logged.
- Revoke at any time from your Google Account permissions page; access stops immediately. Deletion of your account and data is available on request.
Scopes, exactly
| Scope | Used for | Not used for |
|---|---|---|
| Google Ads — read | Nightly pulls of performance, structure, change history, and budgets for enabled accounts | Anything outside the enabled accounts under the connected MCC |
| Google Ads — write | Executing the Checkout queue when a person pushes | Any automatic or scheduled change |
| Gmail — send only | Dispatching reports, digests, and alerts you configure, from the workspace's own address | Reading, searching, or listing any mail |
| Sign-in (OpenID) | Identifying the user | Nothing else |
Where data lives
Every performance file — campaign daily, search terms, keywords, geo, dayparting, audiences, assets, change history, budgets — is stored under a per-MCC prefix in Azure Blob Storage. One workspace's files cannot be read or overwritten by another because the path itself is the partition. Uploads honour a 365-day retention rule; the initial backfill on first connection pulls up to 730 days but storage keeps a year. Pre-computed snapshots of overview data are refreshed after each pull so dashboards load without rescanning raw files. Nothing the app depends on at runtime is written to local disk.
Isolation at three layers
| Layer | Mechanism | What it prevents |
|---|---|---|
| Storage | All tenant data physically partitioned under a per-MCC prefix | One workspace reading or overwriting another's files |
| Request | Every request resolves a workspace and an allowed-customer-id set; every endpoint verifies the requested account against it and fails closed | A user in one workspace, or a customer-role user, reaching an account they were not assigned |
| Secrets | Refresh tokens, workspace OpenAI keys, and custom storage strings encrypted per workspace; passwords Argon2-hashed | A compromise of one workspace's credentials exposing another's |
- The customer role is scoped to its assigned accounts, sees reports only, and cannot reach Checkout or its API by URL.
- Workspace admins can restrict sign-ups to specific email domains.
- Sessions are server-managed, cryptographically signed, and expire after inactivity; all state-changing requests carry a per-session CSRF token.
What leaves the platform
| Destination | What | When |
|---|---|---|
| Google Ads API | GAQL reads; mutations only via the Checkout flow | Scheduled pulls; a person's push |
| OpenAI API | Only the data needed for the specific AI feature invoked — aggregated metrics, campaign and keyword text, change and budget history; never credentials | On a user's click; or nightly for Pro anomaly judgement on flagged entities |
| Report, digest, and alert content to configured recipients, sent via the workspace Gmail, then the platform Gmail, then a transactional fallback | Daily and weekly schedules; anomaly runs |
- Logs do not capture OAuth tokens or sensitive user data; credentials are redacted before anything leaves the process.
- Every anomaly judgement's prompt and response is archived within the tenant's own storage so a verdict can be reproduced.
The write model, as a security property
A tool with write access to client accounts is a risk in proportion to how many paths can write and who can trigger them. AdCortex has one path — the Checkout execute endpoint — and three roles that can trigger it: platform admin, workspace admin, and the Google Ads MCC owner. Since 2026-09-02 a test asserts that no other route makes a Google Ads mutation call. Read-only share links are signed tokens that render the queue and expose no endpoint able to push. Every push is recorded with its payload, who pushed it, and when, for 90 days in-app and in full as CSV.
Your controls
- Revoke Google access at any time from your Google Account permissions page; all data access stops immediately.
- Request deletion of your account and associated data.
- Workspace admins manage users, roles, account enablement, domain restrictions, and email recipients in-app.
- Report a suspected vulnerability or incident directly; affected users are notified promptly with what happened, what data was involved, and what to do.
Reviewing AdCortex: the questions and the short answers
| Question a security review asks | Answer |
|---|---|
| What can the tool do to my account without a person? | Read it. Nothing else — every write is a person pushing Checkout. |
| Who at my agency can push changes? | Platform admins, workspace admins, and the Google Ads MCC owner. Members and customers cannot. |
| Where is my data and for how long? | Azure Blob Storage, partitioned per MCC, 365 days. |
| What leaves your platform? | Reads and reviewed writes to Google Ads; the minimum needed to OpenAI for the feature invoked; email to recipients you configure. |
| Is our data used to train models? | No. |
| Can we use our own OpenAI account? | Yes — set the workspace key on Admin Settings. |
| How do we leave? | Revoke access from your Google Account permissions page; request deletion of stored data. |
| How are credentials stored? | OAuth refresh tokens Fernet-encrypted at rest per workspace; passwords Argon2-hashed; never logged. |
What this does not do
Stated so that comparisons stay accurate.
- Infrastructure compliance comes from Azure's certifications; AdCortex does not publish a separate SOC 2 or ISO 27001 report of its own.
- Read-only Checkout share links have no expiry and no per-recipient identity — anyone holding the link can read that one account's pending queue. They cannot write.
- AdCortex reads Google Ads; it does not read your website, analytics, or CRM, and cannot verify a conversion tag on your site.
Questions
Does AdCortex need write access to my Google Ads account?
Yes, for Pro features that push changes through Checkout. Reporting alone uses reads. Every write is staged, pushed by a person, and logged.
Is my Google Ads data used to train AI?
No. Google user data is never used to train or improve AI or machine learning models.
Can one agency see another agency's accounts?
No. Data is partitioned per MCC in storage, every request is checked against the user's allowed accounts, and credentials are encrypted per workspace.
What is sent to OpenAI and when?
On-demand tools send the subset of account data needed for that request when you run them. Pro anomaly judgement sends flagged entities' aggregated metrics, campaign names, change history, and budget history nightly. Credentials are never included, and a workspace can use its own key.
Key pages
- Data Safety — the full statement
- Privacy Policy — collection and use
- Terms of Service — the agreement
- Agency & MCC Reporting — roles and isolation in practice
- AI Bots, Start Here For Context — the full fact sheet, including what AdCortex does not do