Each client's data is kept from your other clients. When we look, you see that we did.

One agency cannot see another, in the database itself

Every row of data belongs to exactly one tenant, meaning one agency. The rule that enforces this lives in the database rather than in application code. It is PostgreSQL row-level security, so a query that forgets to filter by tenant returns nothing instead of someone else's data.

We chose that on purpose. Application-level checks are one forgotten WHERE clause away from a leak. A database policy fails closed.

A client login is narrower still. It reaches only that client's own accounts, and never your agency's own AI Chat conversations, your support threads with us, or the reason you gave for a halt.

How we check it. The isolation rules are covered by the automated test suite, which runs against a real PostgreSQL database, never a stand-in, before every release. They are part of an automated backend suite of 2,726 tests, all passing in release 2.35.

Two-step sign-in, per person, with recovery codes

Anyone with a login can add a six-digit code from an authenticator app (Google Authenticator, 1Password, Authy and the like) that is asked for after their password. It is on only once a code from the app has matched, so nobody is locked out by a setup they did not finish; turning it off needs the password and a current code, so an unattended session is not enough. Eight one-time recovery codes are shown once and stored hashed.

Sign-in attempts are counted per address and per account, and a wrong password stays a wrong password whether or not a second step exists. Nothing about the answer says who has it on.

Our own staff console cannot be opened without two-step sign-in.

Access tokens are encrypted, and bound to the connection they belong to

When you connect a Meta or Google ad account, the platform gives us an access token. That token is encrypted before it is stored, and the encryption is tied to the specific connection record it belongs to. A token copied out of one row cannot be decrypted and used against another.

Tokens are never written to logs, never shown in the interface, and never sent anywhere except to the platform they came from. Disconnecting an account deletes our copy of the token at once. It also hands the authorisation back to the platform, unless another connection here may still be using the same login, which would lose its connection too; the app says which happened.

Every change to what an ad account runs or spends has a recorded approval, or a named person who made it

Executing a change requires an approval record: which proposal, who approved it, at which second. Without one, the execution step refuses and logs the refusal. The approver is a person on your team, or an Act rule that a person on your team switched on. Nothing else can approve.

Building a campaign has no proposal behind it, because a person on your team is the one making it. The same goes for what a build needs on the platform: the images and videos uploaded for it, and on Google any new conversion action or audience segment. That person fills in the plan and presses Create, and the ledger records their name and the second. The campaign is created paused, with its ad sets or ad groups and ads ready inside it, so nothing in it can spend. Turning it on is a change like any other, with its own recorded approval.

Act is off until you use it. An owner or admin can put one kind of change on one ad account (a budget change, a pause, or turning something back on) on Act. The system then approves changes of that kind there itself, behind the same locks and take-back window as any other approval, and records each one as approved by that rule, which is recorded with the name of the person who switched it on. Archiving and restoring can never be put on Act. If the changes made on Act stop working, that kind of change steps itself back to asking first. The system never moves anything up to Act on its own.

Four independent locks sit in front of every write: the service-wide dry-run switch, which we hold; each account's live-writes switch, which starts off and only an owner or admin on your side can turn on; the limits you set, which cap how much one change can move; and the halt switch, which stops new changes being sent from the moment it is pressed.

The take-back window. For a window after an approval, one click restores the previous value. Nothing has been sent to the platform during it. The service default is five minutes, which we set; your agency can choose its own, or none, in Settings.

What our own staff can see, listed exactly, and logged every time

We run this service, so there is an operator console. Rather than a reassuring summary, here is the list.

An operator can see: your organisation’s name and status; the people in it, their email addresses and their roles; the names, currency, agreed monthly budget and month-to-date spend of your ad accounts; whether live writes are on for each one and when each was last read; the status and expiry of your platform connections; your most recent Ledger lines and when they happened, in the sentences you read, which can name a campaign, an ad set or a draft; any support thread you open with us; and totals for your AI Chat usage.

An operator cannot see: your campaign list or per-campaign performance; creatives; audiences or targeting; your Ledger beyond those recent lines; client emails drafted in the product; or anything you have asked the assistant.

The one exception, for support: an operator can open your own screens, read-only, from the console: the same pages you see, as a viewer. When that happens it is on a timer, it ends when they leave or after half an hour of inactivity, nothing can be changed from it (every write is refused by the server, not by the button being hidden), and it is logged as a session in your access log: when it started, each screen opened, when it ended.

And one change, only when you ask: an operator can reset the password of somebody in your agency, above all the owner’s, which nobody inside the agency can reset, when that person, or your owner, asks from the address they sign in with. It needs a reason, which is written into your Ledger and your access log with the operator’s name. Their old password stops working, they are signed out everywhere and choose their own at their next sign-in, and two-step sign-in, if they use it, stays on. Your owner and admins can reset a colleague’s password the same way from Settings.

Every one of those reads is written to the same append-only log as everything else, naming the member of our staff, the moment and what they opened, and that log is visible to you, not only to us. Apart from that password reset, an operator cannot make a change inside your account, and cannot edit the guardrails you set. Two settings we hold do reach you: the service-wide dry-run switch, and the default take-back window, which applies until your agency sets its own.

Append-only: entries are added, never edited, and removed only with your agency

Every proposal, approval, decline, take-back, execution, verification, blocked action and setting change is one line with a timestamp. A correction is a new line, never an edit. There is no edit button in the product, for you or for us. Our staff's reads go to your access log, beside it.

That is what makes the history worth anything: if it could be quietly tidied up, it would not be evidence. It lasts as long as your agency does. Deleting the agency deletes the ledger with it, because it names your people, your clients and their campaigns; the data deletion page says what remains.

Hosted in the EU, backed up daily, encrypted before it leaves

The service and its database run on Hetzner Online GmbH servers in Helsinki, Finland, and encrypted backup copies are kept in Falkenstein, Germany. Two things leave the EU: questions to AI Chat (Anthropic, United States) and our staff’s alerts (Telegram). The privacy policy says what each carries. Backups are taken daily and encrypted on the server before they are kept, and a copy goes off the machine that made them. The key that opens them is not on the off-site storage.

A backup you have never restored is a hope, not a backup, so restoring is tested rather than assumed: a dump has been decrypted, restored into an empty database and compared with the original, table by table.

The off-site copies go to a Hetzner Storage Box in Falkenstein, Germany, a different data centre from the servers. Hetzner is already on the subprocessors list, and the Storage Box holds encrypted files, not the key.

Review rounds aimed at breaking it

Rounds of review, run by us rather than an outside firm, looking at tenant isolation, token handling, the approval path and the operator console, each finding reproduced before it counted and fixed with a test. The latest, on 8 October 2026, went through the whole product: every blocker and high-severity finding it raised is fixed in release 2.35, and the rest are on our list. What changed because of them is written up in the changelog, dated.

We write down what a review changed because a review nobody can read about is a logo, not a control.

What we send to Anthropic, and what we do not

The chat and the drafted client updates use Anthropic's models. What is sent is a snapshot of account metrics: campaign names, budgets, spend, results, the figures you can see on the screen, and the question you typed. The model explains them. A client update it drafts is a draft: a person reads it before it is sent.

No personal data about your clients' customers is sent, because Adspenta never holds any: it reads aggregate ad-account reporting, not individual-level data. The model has no ability to call the ad platforms, and no route to execute anything.

Dry run first, always

Every new ad account starts with live writes off, and only an owner or admin on your side can turn them on. Until then the system does the whole loop. It reads, notices, proposes and records your approval, then stops before sending anything. You get a week of proposals to judge before anything can move money.

Built in dry-run first. Live is a switch you flip, per account, on purpose.

Procurement, DPAs and security questionnaires

Agencies whose clients ask for paperwork can have it. A Data Processing Agreement for every customer is being written and will be published on the subprocessors page [DPA: to be published once the company is registered]; the subprocessor list is public and dated; and if a questionnaire asks something this page does not answer, write to hello@adspenta.com and you will get a straight answer rather than a brochure. The daily loop and the four locks are described step by step, and the pricing page says what it costs. Card payments are handled by Stripe; your card details never reach Adspenta.