---
title: "What stays separate between teams"
description: "The separation promises, stated as outcomes: what one tenant's credentials can and cannot reach."
url: "https://docs.octo.ad/team-copy/what-stays-separate/"
id: "team-copy/what-stays-separate"
type: "reference"
audience: "admin"
dateModified: "2026-11-06"
productArea: "a copy for every team"
tenancyScope: "team copy"
keywords: ["tenant isolation", "separation"]
---

# What stays separate between teams

> The separation promises, stated as outcomes: what one tenant's credentials can and cannot reach.

## Where your data lives

Inside your own tenant boundary. Each tenant's knowledge is separated by architecture, not by policy, and a tenant's credentials cannot reach another tenant's estate. Connections are authenticated and scoped to your tenant. Deployment options and regions are not published on this site; ask the team under early access.

## The property, and what to ask to see

- **Tenant-isolated by design.** Each tenant's knowledge is structurally separated, by architecture, not by policy. A tenant's credentials cannot reach another tenant's estate.
- **Ask to see:** How isolation is enforced, and what a credential from one tenant can address.

## Tenancy, by category

- **What the category typically offers:** Tenants separated by policy and access control.
- **What OCTOPUS does:** Tenant isolation by architecture, not policy: one tenant's credentials cannot reach another tenant's estate, and every connection is authenticated and scoped to its tenant.
- **Question to ask any vendor:** What stops a tenant credential from addressing another tenant's data, structurally?