← All workflows

scalably.io the work

How client isolation works

When you trust an AI system with your business, the first question that matters is: who else can see my data? Here the answer is nobody. Every client runs inside their own sealed environment, with their own files, their own memory, and only the keys they've been given. It isn't a policy. It's a wall. It's one piece of how the whole platform works.

A look under the hood at the boundary that makes multi-client AI safe: what's walled off, how the wall is enforced, and why we build it this way instead of asking the AI to behave.


The short version

One system serves many clients, but each client gets a container of their own: a private, sealed environment that holds only their configuration, their documents, and their assistant's memory of working with them. A client's environment has no path to the wider system and no path to any other client's environment. Your files, your memory, and your credentials are fenced off, and the fence is enforced by the structure of the box, not by trusting the AI inside it to stay in its lane.

That's the core guarantee. The rest of this page is what that wall actually blocks, and why it holds even if the assistant inside gets something wrong.

Your box has no door to anyone else’s Your containerfiles, memory, tools A sealed wallno path out Everyone elseunreachable blocked scalably.io

The whole idea in one line. Your container holds your world, and there is simply no door from it to anyone else's. Other clients aren't restricted, they're unreachable.

What's walled off

Three things, each one sealed separately: your files, your memory, and your credentials. No client can read, reach, or touch another's anything. There is no shared space where things could leak across.

Your files live inside your container and nowhere a neighbour can see. Your memory, everything the assistant has learned about working with you, lives in its own namespace that another client's assistant physically cannot query; the separation is enforced by the memory system itself, not merely requested in a prompt. And your credentials, the keys to the tools and accounts you've connected, are given only to your environment and only for what you're entitled to. A neighbouring client's assistant has no path to any of it.

The wall is structural, not a request

This is the important distinction. The isolation doesn't depend on the AI choosing to respect boundaries. It comes from the container being genuinely sealed, so even a confused, misdirected, or adversarially-prompted assistant simply has nowhere else to go. Good behaviour is nice; walls are better.

A lot of AI safety leans on asking the model to be careful. That's fragile, because models can be confused or manipulated. So the boundary here is built one level down, into the environment. Each container runs with a minimal footprint and tight limits, and it has no route to the host system, to the source code, to the shared data, or to another client's box. The assistant can be as confused as it likes; it can't act on data it has no way to reach. Security by construction beats security by good intentions, every time.

More than one lock on the door A sealed boxthe main wall Only your keysnothing else granted Guards on every movefail safe, or won’t run Your memory alonewalled off by name scalably.io

The sealed box is the main wall, and there's more behind it: only the keys you were granted, guards on every action that fail safe rather than open, and memory walled off by name.

Defense in depth

The sealed box is the main wall, and there are more behind it. Credentials are withheld by default. Guards check the assistant's actions and fail safe. Memory is namespaced at the source. A single mistake doesn't become a breach, because there's never just one thing standing in the way.

Your environment only ever receives the credentials for the integrations you're actually entitled to; everything else is withheld before the environment even starts, and withheld by default if the entitlement is unclear, rather than granted just in case. Inside, a set of guards checks the boundaries on every action the assistant takes, and they're built to fail closed: if a guard can't do its job, the environment won't run at all, instead of running unprotected. Layered like this, no single failure is enough on its own to cross a boundary.

The safest thing to say about any system is the truth. So here it is: isolation is enforced by the walls of the box, it's layered, and it holds even when the AI inside is wrong.

What we won't claim

We won't tell you it's unbreakable, because no honest engineer says that about any system. What we will tell you is exactly what it is: single-tenant isolation with defense in depth and guards that fail safe, built on hardened, industry-standard containerisation.

Overselling security is how trust gets broken later. This is standard, well-understood container isolation, hardened and layered, with your data fenced into a box that has no door to anyone else's. That's a strong, honest position, and it's the real one. If a claim can't survive a careful reader, we don't make it, and that restraint is part of what you're actually trusting when you trust the system with your work.

The bottom line Your files, your memory, your credentials: sealed in a container that other clients cannot reach, enforced by structure rather than by trust, and backed up by layers so one slip isn't a breach. Not unbreakable, nobody's is, but isolated by construction and honest about its limits.
How client isolation worksscalably.io