The permission you give us

When you connect Google Ads, Google gives us a refresh token. It is not your password — it cannot be used to sign in as you, read your email, or touch anything but the advertising account you chose. But it is a key to that account, so it is handled as one.

• It is encrypted before it is stored. AES-256-GCM, a separate random starting value for every token, with the result sealed so that tampering is detected rather than silently accepted. What sits in the database is a block of ciphertext.
• The encryption key is not in the database, not in our source code, and not in any configuration file in the repository. It lives in Google Secret Manager and is handed to the running service at start-up. Somebody who obtained a complete copy of the database would have no way to read a single token out of it.
• It is never sent to your browser. The token is used only by the server, when it talks to Google. It does not appear in any page, any API response, or any file you can download — including the “take your data” export, which leaves it out deliberately.
• It is never written to a log. Our diagnostics print lengths, counts and yes-or-no, never the value.
• Disconnecting really disconnects. When you press Disconnect, the stored token is deleted, not merely marked unused. After that we cannot reach your Google Ads account at all, whatever anybody inside this company does.

Who can reach your data

Every piece of data in the database is stamped with the business it belongs to, and the database itself refuses to return rows belonging to anybody else — not the application deciding to filter them out, but PostgreSQL row-level security applied to every table and enforced even against the account that owns them. A bug in our code that forgot to filter by business would return nothing rather than return somebody else’s campaign.

The application connects as a role with no superuser rights and no ability to bypass those rules, which is also how it connects in testing, so a query that would be refused in production is refused on a developer’s laptop too.

People at FineCompass do not browse customer accounts. Access to the production database is limited to what is needed to keep the service running, and the engine itself runs with the same restrictions as everything else.

What the engine is allowed to do to your advertising

New accounts start in shadow mode: the engine reads, decides and explains, and every change it wants to make is refused at the gate and recorded instead. Nothing reaches Google until you turn that off deliberately.

Even after you do:

• Money never goes up without asking you — not a budget, not a bid ceiling, at any setting.
• Every change is recorded with its reasoning, and carries the action that undoes it.
• Nothing is spent above the monthly ceiling you set, and nothing is spent at all until you set one.
• The engine never touches a campaign that is not yours, which it decides by where the adverts send people rather than by what is in the account.

How the service is run

• Everything is served over HTTPS. There is no unencrypted route into the product.
• The database is not reachable from the public internet. It accepts connections only from our own service, over Google’s internal connector, with TLS required.
• Backups are taken daily and are encrypted at rest like everything else.
• Secrets are granted one at a time to the thing that needs them. The part of the system that serves web pages cannot read the credentials that own the database schema.

Telling us about a problem

If you think you have found a security fault, write to support@finecompass.com. Tell us what you found and how to see it; we will confirm we have read it, and we will not go after anybody who reports something in good faith and gives us a chance to fix it before it is public.