One leak ends more than one relationship
There are failures a customer may forgive. A slow page, a missing feature, a support ticket that takes a day. Then there is the one they should not have to negotiate: opening their workspace and seeing data that belongs to someone else, or learning that their data showed up in someone else's.
That is not an ordinary defect queue item. It is a trust failure, a security-review trigger, and often a renewal risk. Worse, it rarely stays contained. The customer who sees the leak tells the peers they compare notes with, and the leak becomes a story that follows you into every deal in that market. You did not just create an incident. You damaged the reference that might have helped win the next one.
The number behind the fear
This is not an abstract worry. It has a price tag. IBM's Cost of a Data Breach Report 2025 put the global average breach cost at USD 4.4 million, a 9% decrease from the prior year driven by faster identification and containment. IBM's 2024 report still shows why customer data is so sensitive: customer personally identifiable information was involved in more breaches than any other record type, at 46% of cases.
That is the category many governed workspaces hold: contracts, controls, findings, personal data, supplier records, and evidence that may also sit inside GDPR, DORA, or customer-contract obligations. The dollar figure is the visible cost. The invisible one, churned customers and deals that never close because your name is attached to a leak, is usually larger and rarely shows up cleanly on the incident report.
Least privilege: the minimum, by default
The discipline that prevents this has a name and a definition. NIST states the principle of least privilege as restricting the access privileges of users, or processes acting for them, to the minimum necessary to accomplish assigned tasks. Read it literally: not the access that is convenient, not the access that avoids a permission request, the minimum necessary.
Every grant beyond that minimum is attack surface you chose to carry. A broad role that lets one team glance into another's data is not a convenience. It is a leak waiting for the wrong click. Least privilege is not about distrust of your people. It is about making sure a mistake by any one person cannot become a breach for everyone. That is why NIST SP 800-53 treats access control as a full control family, and why NIST CSF 2.0 frames identity, authentication, authorization, and managed access as core protection work.
Name the controls that keep walls real
Tenant isolation is not a slogan. It is a stack of controls. SSO and RBAC decide who enters. Workspace boundaries decide what they can see. Connector scoping decides which external systems are readable. Retrieval permissions decide what AI can use. Audit logs show what happened.
The AI boundary matters most because helpful systems are tempted to overreach. NIST SP 800-207 defines zero trust around accurate, least-privilege, per-request access decisions; the same idea applies to AI retrieval. A workspace answer should only use sources the requester can access, inside the workspace they are in, from connectors scoped to that workspace. Convenience cannot be allowed to tunnel through the wall.
Isolation is structural, not a setting
The failure mode with multi-tenant systems is treating separation as configuration. If keeping one customer's data away from another depends on a flag someone set correctly, then it depends on nobody ever setting it wrong. That is not a security model. That is a coin flip you run on every deploy.
Real isolation is architectural. One workspace should not be able to reach another because the system does not provide a normal path, not because a permission happens to be denied today. The boundary has to hold even when a query is malformed, a role is misassigned, or an AI feature is asked a question it should not be able to answer for that tenant. Safe by default means the unsafe path is designed out, not merely switched off.
Governed workspaces that stay separate
This is the boundary we built into the platform. In Sorena SSOT, our Single Source of Truth, each workspace is a governed container. The documents, controls, and evidence inside it are scoped to the people who belong there, and the product is designed so one workspace is not reachable from another.
Access is least-privilege by design: a person sees the workspaces and materials their role requires and nothing beyond. Every action is logged, so access is not just controlled but accountable. The result is that the same platform can serve many customers without turning their evidence into a shared pool that admins have to separate later.
AI has to respect the same walls
The moment you add AI to a shared platform, the isolation question gets sharper. An assistant that can read across workspaces to be more helpful is an assistant that can leak across workspaces when asked the wrong thing. Convenience and containment pull in opposite directions, and containment has to win.
So the AI has to operate inside the same workspace boundary as the human requester. It should answer from that tenant's grounded data and only that tenant's data, and it should not surface a fact that lives in a workspace the asker cannot access. The same rules that govern a human's access must govern the model's reach. An AI feature that quietly ignored the walls would not be a feature. It would be the leak, dressed up as a helpful answer. We make the broader case for keeping models on your terms in bring your own model, keep control.
Connect systems without dissolving the boundary
Isolation cannot mean an island that connects to nothing. Your data still has to flow in from the tools you already run. The trick is to connect those systems without letting the wiring itself become the leak.
Sorena Integrations brings external data into the right workspace under the same scoping and logging that govern everything else. A connection feeds one tenant's governed container, not a shared pool that later has to be sorted out. The boundary that keeps workspaces apart is the same boundary that governs what an integration is allowed to touch. You get the data where it belongs without opening a side door around the walls.
Earn the right to hold their data
Customers do not hand you their most sensitive material because your product is clever. They do it because they believe you will keep it separate, scoped, and accountable. Break that belief once and no feature list wins it back. Isolation and least privilege are not the part of the platform you advertise. They are the part that earns you the right to have anything else worth advertising. Build the walls first. Everything else lives inside them.
Frequently asked questions
What does it mean for one workspace to never see another?+
Each workspace is a governed container whose documents, controls, and evidence are scoped to the people who belong there. The isolation goal is structural: one workspace should not have a normal path into another, and access decisions should be enforced by identity, role, connector scope, retrieval permissions, and audit logs.
How does least privilege reduce the risk of a leak?+
NIST defines least privilege as granting only the minimum access needed to do the job. Every permission beyond that minimum is attack surface. By scoping each person and process to exactly what their role requires, a mistake or misconfiguration has less room to become a cross-customer exposure.
Does the AI assistant respect workspace boundaries?+
Yes. The assistant is designed to answer only from the grounded data inside the active workspace and not from a workspace the asker cannot access. The same access rules that govern a human have to govern the model, so adding AI does not become a new path across tenants.
Sources
- IBM, Cost of a Data Breach Report 2025https://www.ibm.com/reports/data-breach?ref=sorena.io
- IBM, Cost of a Data Breach Report 2024: record global average and top exposed data typeshttps://www.ibm.com/think/insights/whats-new-2024-cost-of-a-data-breach-report?ref=sorena.io
- NIST Computer Security Resource Center, Glossary: least privilegehttps://csrc.nist.gov/glossary/term/least_privilege?ref=sorena.io
- NIST Special Publication 800-207, Zero Trust Architecture (least-privilege per-request access)https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf?ref=sorena.io


