> 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 > **Draft — for review before publishing.** This page describes our security posture in good faith and reflects how the system is built. Have it reviewed by your security and legal advisers before it's relied upon as a formal commitment. 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 app.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 app.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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.kula.digital/trust-and-legal/security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.