Session

One firm, one database: making tenant leaks impossible when an AI writes your SaaS

Coding agents made it possible for founders and small studios, many without a software career, to build and sell SaaS. I'm one of them: a mechanical engineer who co-founded a small software studio in Brazil. Our case study is PS JUS, a SaaS for law firms built entirely with Claude Code, where every record is privileged legal information and one firm must never see another's. The lessons apply to any multi-customer product: a CRM, a clinic system, an HR tool.

Why take the risk at all? Because automating repetitive work pays twice. For the company, tasks that used to depend on someone remembering, like checking the official court gazette three times a day or setting up a new customer, run on their own and leave an audit trail. For the people, lawyers and staff stop copying the same data into three places and stop fearing the deadline nobody saw. That only holds if the automation can be trusted with other people's data.

Coding agents reason about the file in front of them. Tenant isolation is an invariant that lives everywhere else. So instead of asking the agent to remember it, we tried to make breaking it structurally impossible, and then kept finding the places where it still leaked.

Four problems every AI-built SaaS runs into, and what we did about each:

1. **Problem:** in a shared database, isolation is a `WHERE tenant_id = ?` in every query, and one the agent forgets leaks a firm's cases while every test passes. **Solution:** we removed the bug class. Each firm runs as its own process, OS user, database file, directory, service and set of secrets. There is no tenant column in the legal tables to forget.
2. **Problem:** physical isolation still leaks through everything that is shared: code defaults, external IDs, caches, the admin panel, backups. We found another firm's name in browser tab titles and in the first-access email, and calendar IDs that are unique per account, not per firm. **Solution:** every external ID is bound to its connection, branding is resolved from the tenant, and the admin panel is a separate process whose database has no table or column for legal content, enforced by a test.
3. **Problem:** tests pass for the wrong reason. One tenant in the fixtures, auto-increment IDs that collide across firms, runners that count printed "OK" lines. **Solution:** an isolation suite that boots two fictitious firms side by side and judges leaks by content canaries, and a runner that must fail two negative controls before it trusts its own count.
4. **Problem:** self-serve sign-up, which we are building for November (today a human still approves each new firm), turns onboarding into code nobody watches, and sensitive data leaks into the agent's context while you build. **Solution:** one provisioning door with human approval, a rehearsal on the exact version and typed confirmation; nothing sensitive in the provisioning payload; fixtures that must declare themselves fake; secrets encrypted per tenant; and code scans that fail the build when a new file breaks a rule.

You don't need to be a programmer to build and sell SaaS with AI. You do need two habits: make the invariants the AI can't see impossible to break, and prove isolation with fictitious customers before a single real record goes in. Every leak in this talk happened in agent-written code, and every one was caught on fake firms.

Marcela Nunez

CEO and Co-founder

Mogi das Cruzes, Brazil

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top