When you connect an AI tool to your codebase, you hand it the most sensitive asset your company owns. Not a copy of a spreadsheet. The source, the infrastructure config, the shape of how everything fits together. So the question a careful buyer asks is not "how good is the model." It is "where does my code go, and who else could reach it." That is a data isolation question, and for any AI SaaS working on real code it is the one that decides whether you can adopt the tool at all.

The good news is that isolation is a well-understood problem with a known set of answers. The bad news is that vendors often wave at it with the word "secure" and hope you do not ask the follow-up. This post is the follow-up.

What isolation actually has to guarantee

Strip away the marketing and isolation makes one promise: one customer's data can never be reached by another customer, by accident or on purpose. Not their code, not their logs, not the artifacts a build produced, not the traces of what an agent did. If any of those can leak across the boundary, the tool is not isolated, no matter what the security page says.

That framing matters because the database is only the part everyone remembers. The leak surface is wider than the tables.

The spectrum of approaches

There is no single "isolated" setting. There is a spectrum, from cheap-and-shared to expensive-and-separate, and each point trades cost and operational complexity against how strong the boundary is.

Row-level isolation (a tenant key on shared tables). Everyone lives in the same database, and every row carries a tenant_id that queries filter on. It is the cheapest to run and the easiest to build, which is why so much SaaS starts here. It is also the weakest boundary: the separation is enforced entirely by application code getting every query right, forever. One missing WHERE tenant_id = ? and one customer sees another's data. For low-sensitivity data that risk is often acceptable. For source code, it is a lot of trust to place in never writing a bad query.

Schema-per-tenant. Shared database, separate schema for each customer. A stronger boundary than a shared table, since a query has to name the wrong schema rather than merely forget a filter, but tenants still share the same database engine and its blast radius.

Database-per-tenant. Each customer gets their own database. The boundary is now infrastructure, not application logic, which is a real step up. The cost is operational: more databases to provision, migrate, back up, and monitor.

Separate compute per tenant. The strongest common option: each customer's workloads run in their own isolated environment, not just their own table. Cross-tenant leakage stops being something you prevent with careful code and becomes something the architecture does not allow. It is also the most expensive and the most work to operate, which is exactly why it tends to be reserved for the data that justifies it.

The pattern most mature products land on is tiered: shared infrastructure for low-sensitivity or free-tier usage, and stronger, dedicated isolation for customers whose data or compliance posture demands it. Deciding where your product sits is the same decision covered in single-tenant vs multi-tenant when isolation is the promise.

Isolation is more than the database

Here is the part that catches teams out. You can isolate the database perfectly and still leak, because customer data does not only live in tables. When an AI tool runs against a codebase, that code and its derivatives spread into places that are easy to forget:

  • Secrets and credentials the tool holds to reach the customer's systems.
  • Logs and traces, which can quietly capture snippets of code, file paths, or error output.
  • Caches and temporary files created while the work runs.
  • Model context, the material sent to the model to do a task, which is customer code by another name.
  • Build and run artifacts, the outputs of tests, compiles, and deploys.

Every one of those is a place two tenants could bleed into each other if isolation was only ever designed at the database layer. A serious answer to "how do you isolate my data" covers the whole surface, not just the primary store. This is closely tied to the broader security posture of running an agent on code you do not own, where the same discipline applies to access, not just storage.

How to choose, and what to ask a vendor

Match the strength of the boundary to what the data is worth. Source code, infrastructure configuration, and anything that reveals how your product is built sit at the high end, so they justify the stronger, more expensive end of the spectrum. Treat the choice as a risk decision, not a default.

When you evaluate a vendor, the useful questions are specific:

  • Where does my code physically live while you work on it, and for how long?
  • Is the separation between customers enforced by application code or by infrastructure?
  • What happens to logs, caches, temporary files, and model context, not just the database?
  • Who at your company can access my data, and how is that access logged?

Vague answers to specific questions are themselves an answer.

The honest limitation

Isolation is necessary and it is not sufficient. It shrinks the blast radius of a mistake; it does not remove the need for the other controls. You still want encryption in transit and at rest, least privilege on what any component can reach, and an audit trail of who touched what. Strong isolation also has a real cost in money and operational overhead, and paying for more isolation than your data warrants is its own kind of poor engineering. And no isolation model protects you from a component that is authorized but compromised; that is what least privilege and monitoring are for. Isolation is one layer of defense in depth, not the whole of it.

What it buys you is the ability to answer the question that actually blocks adoption: my data cannot end up in someone else's account, because the architecture does not permit it.

That is the bar we hold ourselves to. At Loopsfinity, each customer's code and data stay isolated from every other customer by construction rather than by careful filtering, because when the asset is your source code, "we are careful" is not a strong enough promise. The specific way we do that is ours. The principle, and the questions above, are yours to use on any vendor you consider, including us. If you want the wider picture of what it takes to trust an agent with production, start with can you trust an AI agent to ship to production.