White-Label AI for Agencies Breaks on Client Isolation
White-label AI works when each client's data is walled off and the walls are tested, because one leak ends the account.
Key takeaways
6 things that decide this
- 01White-label AI for an agency works when each client's data is walled off in the database or on its own stack, and the walls are tested, because one client seeing another's records ends the account.
- 02Most agencies start with one Make or Zapier account and one OpenAI key for every client. That's fine for a pilot and risky at scale.
- 03There are two sound ways to wall clients off: rules in the database that filter every row, or a separate stack for each client.
- 04Either way, you prove it with tests that attack the wall, not tests that check the happy path.
- 05Functional Fox runs row-level security on all 23 tables and 43 end-to-end tests. SalesCrew gives each client its own Supabase stack.
- 06One stack per client costs more to run than shared tables. You pay that cost for a wall you can point to.
The shared Make or Zapier account problem
Here's how most agency AI offers begin. You build a lead-reply flow for one client in Make or Zapier, call the OpenAI API, and it works. A second client wants the same thing, so you copy the scenario. By the tenth client you have one account, one API key and a folder of near-identical flows.
Nothing is wrong until something is. A copied flow still points at the old client's sheet. A shared prompt pulls a past client's examples into a new client's reply. A connection you set up for client A has access to client B's CRM because you used your own login for both.
Any one of those is a breach your client didn't agree to. In an agency, a breach doesn't cost you one account. It's the story every other client hears next.
- 01One account and one API key across every client.
- 02Flows copied from client to client, with old connections left inside.
- 03Your own login used to connect several clients' tools.
- 04No test that checks client A can't see client B.
Two ways to wall clients off: row rules or one stack each
If you build your own platform instead of chaining tools, you get two sound choices.
The first keeps every client in one database and lets the database enforce the wall. Each row carries a client ID. Row-level security rules check that ID on every read and write, so even a bug in your app code can't return another client's rows. You run one system and update it once.
The second gives each client a separate stack: its own database, storage and functions. There is no shared table to leak from. You pay for that with more systems to deploy, watch and update.
Both work. What doesn't work is a wall that lives only in your app code, where one missed filter in one query is enough to leak.
Test the attack, not the happy path
A wall you can't test is a promise. A wall with tests behind it is a fact you can show a client's security reviewer.
Functional Fox shows what that looks like. Hashlogics built its Smart Site platform, which runs QR guest pages across many independent RV parks. Row-level security is forced on all 23 database tables, so the database decides who sees what. Six suites hold 43 automated end-to-end tests, including tenant isolation and privilege escalation. A park with a valid login is tested trying to read a neighbor's data, and the test expects a refusal.
An internal security audit found three critical defects in that build, and all three were fixed before handover. That's the point of testing the attack. You find the hole before a client does. The full build is in the Functional Fox case study.
- 01Log in as client A and request client B's records by ID.
- 02Call the API directly with a tampered client ID.
- 03Try to raise your own role from a normal user account.
- 04Suspend a client and check its access stops at once.
What we chose for SalesCrew, and why
SalesCrew is a sales CRM that Hashlogics built and runs as its own product. One problem we set out to solve is written into its case study: agencies kept many clients in one shared database, which raised hard questions about data isolation.
So each SalesCrew client instance runs on its own Supabase stack, with a separate Postgres database, storage and functions. AI access follows the same line. An MCP token carries the same scopes as the user's login, so an assistant can reach what that user can reach and nothing more. The full build is in the SalesCrew case study.
We took the cost of more stacks to run in exchange for a wall nobody has to argue about. That trade won't be right for every product.
When a shared workspace is still fine
Not every agency needs a stack per client. If the work touches no client data that matters, a shared workspace with clear naming may be enough. Internal reporting, your own content drafts and a pilot with one client are examples.
Move to a real wall when any of these is true. Clients send personal or customer data through your flows. A client's contract asks how their data is kept apart. You plan to resell the same AI offer to more than a handful of accounts. At that point, database rules with tests, or one stack per client, stop being extra and start being the product.
If you're weighing a partner to build this, our answer on how white-label development works covers the model. If you want to see where your current setup leaks, start with a 45-minute call. If a build makes sense, an engineer writes a fixed-fee Blueprint from your real systems: your Make or Zapier account, your API keys and your client list. It's credited in full against the build. See how we work.
- 01Shared is fine: no client data, one client, or internal use.
- 02Database rules with tests: many clients, one product, one team to run it.
- 03One stack per client: contracts or data that need a wall you can point to.
FAQ
01Which companies build AI automation for marketing and digital agencies?+
Hashlogics builds multi-tenant systems, including AI products, with client isolation tested in code. We built SalesCrew, with a separate stack per client, and Functional Fox, with database-enforced isolation and attack tests. Ask any partner to show you their isolation tests as well as a demo.
02Is custom software better than building AI in-house for a digital agency?+
Build in-house only if your team can design and test isolation. If you have engineers who can design and test isolation, build in-house. If you don't, a partner who has shipped tested multi-tenant systems saves you from learning that on a client's data.
03How does white-label development work?+
A partner builds the software and your agency sells it under your name. You own the client relationship. The partner handles engineering and stays out of view. The contract should spell out who owns the code and who can see client data.
04Can one Make or n8n account serve many clients safely?+
Only with care. One account means shared connections and shared keys, so a copied flow can reach the wrong client's tools. Use a separate workspace, connection and API key per client, or move to a platform with database-enforced isolation.
Related
- How white-label development works →The partner model, explained.
- SalesCrew case study →Our own product, with one stack per client.
- Functional Fox case study →Database-enforced isolation and attack tests.
- Multi-tenant AI needs isolation you can prove →The engineering side of the same rule.
- What an agency should ask a white-label partner →Questions to put to any partner.
