> For the complete documentation index, see [llms.txt](https://k-ai.gitbook.io/knowledge-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/security.md). # Security & isolation K-AI uses a **hybrid tenancy model** — customer data lives in per-customer single-tenant instances; platform management state lives in a multi-tenant management plane that holds no document content. This split is not a deployment convenience: it is the architectural property that makes cross-customer data leakage impossible by construction. ## Hybrid tenancy model ```mermaid flowchart TB subgraph multi["Multi-tenant management plane"] users[Users · Organizations · Groups] billing[Billing · Costs] audit_meta[Audit workflow metadata] retrieval_cfg[Access control · Instructions] end subgraph A["Customer A — K-AI Instance"] dbA[Metadata + semantic graph] vecA[Vector index] blobA[Object storage] end subgraph B["Customer B — K-AI Instance"] dbB[Metadata + semantic graph] vecB[Vector index] blobB[Object storage] end multi -.points to.-> A multi -.points to.-> B ``` The management plane references customer instances by `instance_id` and resolves access on every request. It never holds a copy of customer content. ## Single-tenant K-AI Instance One customer = one dedicated stack: * one Kubernetes pod running the K-AI Instance service, * one PostgreSQL schema for metadata and the semantic graph, * one vector index (managed in SaaS, Snowflake `VECTOR` types in Native App deployments), * one object storage bucket (managed object storage in SaaS, S3-compatible store on-premise, or Snowflake Stage). Machine-to-machine access is gated by an `(instance_id, api_key)` pair, scoped to **exactly one instance**. Keys are not shared across instances and are not shared across customers. Key rotation is a one-click admin action that revokes the previous key immediately. ## Multi-tenant management plane The management plane handles users, organizations, group memberships, RBAC, billing, workflow metadata, and access-control configuration. It is deployed as stateless services backed by dedicated database schemas, one per platform module. The management plane **stores no document content**. It stores pointers to instances, access rules between users and instances, audit-workflow state, cost events, and authentication artifacts. Every operation that needs document content goes through a per-instance call to the underlying K-AI Instance, authenticated with that instance's `api_key`. ## ACL mirroring Source-system ACLs are preserved through ingestion and replayed at retrieval time. A SharePoint document indexed by K-AI carries the SharePoint group membership it was constrained by; a Google Drive file carries its sharing scope. Sources without native ACL extraction (e.g. Confluence) are governed instead by mapped group rules. ACLs are **not flattened** at ingestion. They travel with the document through Layers 2, 3, 4, and are enforced at Layer 5. When a Consumer (human or AI agent) issues a query, the platform computes the set of instances and documents the Consumer is entitled to, taking into account both K-AI's group-based RBAC and the mirrored source ACLs. A document the Consumer cannot see in SharePoint is, by construction, a document K-AI does not return. ## Encryption **At rest.** Encryption is provided by the underlying storage provider — managed storage encryption for SaaS deployments, the customer's KMS for self-managed S3, Snowflake's transparent encryption for Native App deployments. The platform does not implement its own at-rest encryption layer; it inherits the provider's, which is FIPS-compliant in all supported regions. **Secrets.** Service-to-service secrets and connection strings are encrypted at the application layer before they reach any database row. Decryption keys are held in the platform's secret manager (the cloud provider's secret manager or Snowflake secrets, depending on deployment) and are never written to logs or backups. **Tokens.** OAuth 2.1 access tokens and refresh tokens are signed JWTs. The signing key is held by the [Authentication service](/knowledge-ai/authentication/oauth.md). Access tokens are short-lived (15 minutes); refresh tokens rotate on use. See [Authentication — OAuth 2.1](/knowledge-ai/authentication/oauth.md) for the full flow. **In transit.** TLS everywhere. Public endpoints terminate TLS at the ingress with automated certificate management. Internal service-to-service traffic stays inside the Kubernetes cluster network. ## Defence in depth * **TLS everywhere** — public endpoints behind an ingress with automated certificate management. No plaintext HTTP termination. * **Rate limiting** on the Authentication service — rate limits and account lockout protect the auth endpoints against credential stuffing and brute force. * **Microsoft SSO** option — multi-tenant Azure AD / OIDC, available out of the box for enterprise customers. * **Group-based RBAC** at the Retrieval API and Audit API levels — per-instance visibility, instruction cascade (org default → instance → group), enforced transparently on every MCP tool call and every REST call. * **PKCE (`S256` mandatory)** for OAuth 2.1 — protects the authorization-code flow against interception. * **Refresh-token rotation** — every refresh issues a new refresh token and revokes the previous one. * **HttpOnly cookies** (`kai_auth` on `.kai-studio.ai`) for browser frontends. No JavaScript access to the token. See [Authentication — Cookies](/knowledge-ai/authentication/cookies.md). * **No cross-instance reads.** The Instance API rejects any request whose `instance-id` does not match its bound deployment. There is no global admin endpoint that reads across instances. --- # 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, and the optional `goal` query parameter: ``` GET https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.