Disclosure: BlueBear builds a platform with exactly this structure, so we have a commercial interest in the definition. Where we describe implementation detail it is our own and named as such — it is offered as one worked example of the shape, not as the only correct one.
The short answer: a boundary is what cannot cross it
A workspace boundary is the line that decides which agents, credentials, data, records and spending belong together — and which cannot reach across it.
The definition is negative on purpose. Every product has containers; what makes a container a boundary is the set of things that provably cannot leave it. The test is a read: in a folder model, a query that forgets its filter returns everything, because the folder was only a label. In a boundary model, the scope is carried by the request itself, so a query that forgets it returns nothing.
The five things a boundary has to contain
| What is inside | What goes wrong if it is shared |
|---|---|
| Agents — which agents exist here and may run | An agent built for one team is available to another with different rules |
| Connections and credentials — which systems can be reached, with whose keys | The worst one. Revoking one team's integration touches everyone's. |
| Data and memory — documents, retrieved context, conversation history | Retrieval pulls a document from a body of work the reader has no right to see |
| Records — the evidence of what was done here | You cannot export one team's history without exporting everyone's |
| Spend — the budget this work runs against | Cost cannot be attributed, so no one can decide whether the work is worth it |
A boundary that separates only the first is a folder. Most products that describe themselves as having workspaces separate the first three; the last two are where the differences show up, usually about eight months in.
Tenant and workspace: two boundaries, not one
The vocabulary is worth settling because it is used inconsistently.
A tenant is the outer boundary — usually one customer or one legal entity. A workspace is a boundary inside it — usually one team, one project, or one client engagement. The reason for two is that they answer different questions: the tenant answers "whose data is this, contractually", and the workspace answers "which body of work does this belong to, operationally".
In our own gateway both are explicit database structures rather than conventions. A workspace belongs to exactly one tenant, is uniquely named within that tenant rather than globally, and carries a compound uniqueness constraint pairing its identifier with its tenant — so a lookup that supplies the wrong tenant cannot find it at all, rather than finding it and relying on a later check. Deleting a tenant cascades to its workspaces. Those are structural guarantees at the database level rather than rules the application is trusted to remember, and that distinction is the whole difference between a boundary and a convention.
What a real boundary carries, beyond a name
A useful way to evaluate any product's workspace model is to ask what properties the workspace itself holds. Ours carries, among others:
- An access mode — whether the workspace is visible to its creator only, to their organisation, or to everyone in the tenant. Three values, chosen explicitly, rather than an implicit default.
- A compliance standard, deliberately independent of what kind of workspace it is. A voice workspace and a chat workspace can both be under a stricter data-handling regime; the interaction surface and the data rules are separate axes. It is stored as a named value rather than a boolean specifically so that adding a future standard is a new value rather than a new column.
- A compliance configuration with its own endpoints and timeout, which fails closed: uploads into a compliance-managed workspace fail when it is missing or unreachable, rather than proceeding unchecked. Credentials are referenced rather than inlined and resolved at call time.
- An allowed-agent list, enforced at every path that binds a conversation or starts a session — with a deliberate rule that editing it affects new bindings only, because killing a running turn to apply an access change is a worse failure than letting it finish.
- Document access and download policies as two separate axes, because read access does not imply the authority to take a copy away.
You do not need those specific fields. The point is that a workspace which carries only a name and a member list is not yet doing the job — the properties above are the ones that turn "a place where work happens" into "a set of rules that work happens under".
Where the boundary is decided — the one question that matters most
Everything above is undone if the boundary is resolved from the wrong place.
The boundary must be established from the credential presented when the request is admitted — never from a value inside the request. A request that can nominate its own tenant is a request that can nominate someone else's. This is the single most important sentence in the whole subject and it is worth testing literally rather than accepting as a design principle. Workspace boundary access control takes the enforcement apart properly.
If you operate in a regulated industry
Two properties matter more than the rest. First, the compliance regime should attach to the workspace rather than to the account, so one part of the business can operate under stricter rules without imposing them on everyone. Second, the behaviour when a compliance dependency is unavailable should be to stop rather than to continue — and that should be demonstrable, not asserted. Ours is deliberately fail-closed in both the workspace upload path and in tenant privacy resolution, where a privacy-classified tenant with no resolvable policy baseline raises an error instead of falling back to a permissive default. The audit trail requirements list covers the record side.
If you are a platform or engineering lead
Push the boundary into the data model rather than the service layer. Compound uniqueness constraints that include the tenant, foreign keys that cascade, and a request-scoped value that every query is built from are the mechanisms that survive a refactor by someone who was not there when the design was agreed. Multi-tenant AI agent isolation on Kubernetes is the existing technical treatment of the runtime side.
If you resell this to customers
Your boundary is a contractual object, so the three operations to test are revoke one customer, export one customer, and price one customer — each without an engineer writing a query. If any of the three needs a human, it is not yet a boundary you can sell against. White-label brand workspaces explained covers the reseller shape, and multi-tenant isolation for buyers covers what to ask a vendor to demonstrate.
Do this next
Take the five-row table and mark, for your current system, which of the five are genuinely separated and which are shared with a filter. The shared ones are your roadmap, and connections and credentials should be at the top of it because that row is the one that turns a small incident into a large one. Then read workspace boundary access control for the enforcement, or what an AI agent platform is if you are still placing this in a wider category.
Questions people actually search for
- secure enterprise workspace boundary
The line that decides which agents, connections, credentials, data, records and spending belong together, and which cannot reach across. It is secure when the boundary is a property of the request rather than a filter the application remembers to apply - established from the credential presented, carried through every layer, and enforced on read paths as well as write paths. A boundary maintained by convention inside application code is one refactor away from not existing.
- what is a workspace in an ai platform
A container for one body of work and everything it is allowed to touch: the agents that run there, the connections and credentials they may use, the documents and memory they can see, the records of what they did, and the budget they spend against. The reason it exists rather than everything living at the account level is that most organisations need more than one separation - a team, a project, a client, a compliance regime - and those separations have different rules.
- bear workspace
In BlueBear a workspace is the isolation unit inside a tenant. It carries its own agents, connections, documents and spending, an access mode saying who may enter it, and a compliance standard that decides its data-handling rules independently of what kind of workspace it is. A tenant is the outer boundary, usually one customer or one business entity; a workspace is the boundary inside it, usually one team, one project or one client.
- how is a workspace different from a folder
A folder organises; a boundary constrains. The test is what happens on a read: in a folder model, a query that forgets to filter returns everything, because the folder was only a label. In a boundary model the request itself carries the scope, so a query that forgets it returns nothing rather than everything. If a mistake in one line of code can return another team data, you have a folder with a security label on it.
- do I need separate workspaces for each client
If you are doing work for external clients, almost certainly yes - because the things you eventually need per client are revocation, export and billing, and all three are painful to retrofit onto shared structures. Internally the answer depends on whether the separations you care about have different rules. Where two teams have the same connections, the same data sensitivity and the same budget, separate workspaces add administration and buy nothing.