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

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. Access tokens are short-lived (15 minutes); refresh tokens rotate on use. See Authentication — OAuth 2.1 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.

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