> For the complete documentation index, see [llms.txt](https://docs.kula.digital/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kula.digital/trust-and-legal/security.md).

# Security & data handling

This is the technical companion to the plain-English [Is my data safe?](/get-started/trust.md). It's written for security-minded operators, their advisers, and reviewers.

## Tenancy: isolation by database boundary

Per-studio isolation is the load-bearing design decision.

* **Every studio gets its own database.** Each studio's data lives in its own dedicated Postgres database, provisioned per tenant.
* **There is no cross-studio read path.** A request is bound to exactly one studio, derived from the verified token — never from a parameter a caller can set. The connection it runs on points at that studio's database and no other.
* **No shared-table tenancy.** We don't use a shared multi-tenant table keyed by an org id, so there's no class of query that could leak across tenants. Isolation is physical, not a filter that could be forgotten.

## Authentication & access control

* **Two separate identity paths, never mixed.** Operators sign in through a dedicated identity provider; AI clients present a minted access token verified by a separate path. They share no trust.
* **Role-scoped credentials only — no anonymous access.** Every client connects with a credential created in console.kula.digital: a **connect link** (`/connect/{…}/mcp`, OAuth 2.1 with DCR + PKCE) for Claude, or a **role-scoped access token** (bearer) for other clients. The endpoint rejects any request without a valid token. See [OAuth](/for-developers/oauth.md).
* **Permission levels.** Every connect link carries a permission level that controls how much personal data it can ever see; redaction is applied server-side, so a lower level cannot be coaxed into revealing more. See [Permission levels](/connect-claude-and-access/scopes.md).
* **Audience binding.** Credentials are bound to the Kula MCP resource, so they can't be replayed against a different server.

## Revocation

* Connectors are revocable from console.kula.digital.
* Revocation takes effect within about **a minute** — the runtime never trusts a cached authorisation longer than that.
* Closing a connection simply shuts the door a client came through; the studio's data remains in its own database, under the owner's account.

## Encryption

* **In transit:** all client and ingest traffic is over HTTPS/TLS.
* **At rest:** studio databases and stored documents are encrypted at rest by the underlying platforms.
* **Provider secrets** (the keys or tokens you paste when connecting a data source) are stored **AES-256-GCM-encrypted at rest in your studio's own database** — never in plaintext, never shared between studios. The encryption key is held separately in our secrets infrastructure, so the database contents alone can't reveal them. They're used only to read from that provider.

## Auditing

* **Every privileged action is recorded** — token mint and revoke, guarded writes, and sensitive reads — through a single audit path, not scattered ad-hoc logging.
* **`full`-level reads are recorded on every call**, so the most sensitive access always leaves a trail an operator can inspect.

## How data flows in

* Connectors **read** from the tools you authorise and push canonical events into your studio's database over an authenticated, signed channel.
* Data lands verbatim first, then a clean copy is transformed, so re-processing is always safe. The verbatim copy is kept for **30 days** then purged; the transformed data is what the AI reads. See [How connectors work](/your-data-sources/connectors.md).
* The runtime itself is **model-free**: it runs no AI inference over your data. All reasoning happens in the AI client you connect, under your control. (The one exception is optional semantic search, below.)

## Optional semantic search

* Off by default. A studio can opt in to vector search, which converts text to embeddings for similarity matching.
* Embeddings are generated only with the studio's **explicit consent**, and the data stays within our cloud region.

## Data location

* Studio data is stored in the cloud region you're provisioned in. Australian studios' data stays in Australia.

## Sub-processors

We rely on a small set of infrastructure providers — for managed Postgres, cloud hosting and storage, operator sign-in, and the optional embeddings service. The current list and their roles are in the [Privacy policy](/trust-and-legal/privacy.md). We never sell your data.

## What we deliberately do **not** do

* **No money movement.** No charges, refunds, transfers, or payouts.
* **No AI media generation.**
* **No cross-studio reads** — not even for aggregate analytics.
* **No arbitrary database mutation.** Freeform queries are read-only (`SELECT`/`WITH`); writes happen only through specific, scope-gated, audited tools.
* **No writing back to your connected tools.** Connectors read; they never modify the source system.

## Reporting a vulnerability

Please follow [Responsible disclosure](/trust-and-legal/disclosure.md). We welcome good-faith reports and will work with you on a fix.