> ## Documentation Index
> Fetch the complete documentation index at: https://docs.karta.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-tenancy

> How Karta isolates one organization's data from another's - auth-enforced org scoping, durable karta boundaries, and per-session isolated runtime environments.

Karta runs as a shared service with **auth-enforced organization scoping**.
Access is **default-deny**: an API key scoped to org A cannot touch org B's
sessions, even by guessing session ids.

```
org A key --> /v1/sessions/{id}
              session ownership:
              sess_1 -> org A   => allowed
              sess_2 -> org B

org B key --> /v1/sessions/sess_1 => 404
```

Every session lookup is checked against the caller's organization. A cross-org
lookup returns `404`, not `403`, so the URL space does not reveal whether
another organization's id exists.

## The tenancy stack

In the hosted product, isolation nests at three levels, each with a different
credential at its boundary:

```
Karta platform
  Organization (your org)
    members and roles
    API keys, BYOK, budgets
    karta (user, virtual employee, job, or fleet member)
      one durable workspace
      sessions
```

Each session also runs in its own
[isolated runtime environment](/concepts/how-karta-works#per-session-isolation),
so the boundary is enforced while code executes as well as in ownership records.

The **org to karta / acting-user** boundary is enforced by the credential, the
session owner, and the karta id. For per-user kartas, your app supplies an
opaque `user_id` or `end_user_id`; Karta keys the karta on it but never treats
the string as an authorization decision by itself. For virtual employees or
backend jobs, your backend supplies a trusted `agent_instance_id` instead.
Format and granularity are your contract.
See
[Kartas & memory](/concepts/instances-and-memory).

## What isolation does and does not guarantee

| Boundary          | Guarantee                                                                            | Your responsibility                                                          |
| ----------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| Organization      | A key or token for one org cannot read another org's sessions by guessing ids.       | Keep API keys server-side and scope them to the operations they need.        |
| Karta             | Memory and durable files are scoped to the stable karta id you choose.               | Choose ids at the right grain for your privacy model.                        |
| Session execution | A running turn is isolated to its session runtime environment.                       | Treat agent tools as privileged integrations and review what they can reach. |
| Browser           | Browser clients use session tokens or publishable embed keys, not org-wide API keys. | Mint tokens from your backend when the browser needs trusted user context.   |

These boundaries do not replace your own application authorization. If an agent
tool calls your backend, your backend still decides what that user, role, or job
can read or change. For prompt-injection and tool-risk review, see the
[Security model](/security/security-model).

## Browser tokens

Browser traffic should never carry a `kt_live_...` API key. Use one of these
instead:

| Browser path                 | What the browser gets                                                          | When to use it                                                            |
| ---------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------- |
| Publishable embed key        | A public `pk_live_...` key that can mint widget sessions from allowed origins. | Public or marketing-site widgets with optional soft or verified identity. |
| Backend-minted session token | A short-lived token scoped to one agent and organization.                      | Signed-in product surfaces where your backend is the trust anchor.        |

Both paths still resolve to the same organization-scoped session model.