Multi-tenancy

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, 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.

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.

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.

Get started

Concepts

Agent project

The CLI

Deploy

Platform

Security

Enterprise

Tutorials

Multi-tenancy

The tenancy stack

What isolation does and does not guarantee

Browser tokens

​The tenancy stack

​What isolation does and does not guarantee

​Browser tokens

The tenancy stack

What isolation does and does not guarantee

Browser tokens