> 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/authentication/authentication.md).

# Overview

K-AI exposes four auth surfaces, one per caller type. Backend pipelines that ingest into a single instance use static `instance-id` + `api-key` headers on the KAI Instance API. Backends that automate organization, audit, or retrieval workflows with a role use an Organization API key — exchanged for a short-lived Bearer token, or sent directly as a Bearer credential on the Audit and Retrieval APIs and their MCP endpoints. Interactive MCP clients and custom user-level integrations use OAuth 2.1 (Authorization Code + PKCE + Dynamic Client Registration). Browser frontends running under `.kai-studio.ai` use the `kai_auth` HttpOnly cookie. Organization API keys, OAuth 2.1, and cookies all yield a credential accepted by the K-AI Platform, Audit, and Retrieval APIs.

## Choose your auth

| Caller type                                                                     | Auth                                            | Page                                                                           |
| ------------------------------------------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------ |
| Backend pipeline ingesting documents into one instance                          | `instance-id` + `api-key` headers               | [Instance API keys](/knowledge-ai/authentication/api-keys.md)                  |
| Backend automating org / audit / retrieval workflows with a role                | Organization API key → Bearer JWT               | [Organization API keys](/knowledge-ai/authentication/organization-api-keys.md) |
| Autonomous agent platform driving MCP with no human in the loop                 | Organization API key in `Authorization: Bearer` | [Autonomous agents (API key)](/knowledge-ai/k-ai-mcp/autonomous-agents.md)     |
| MCP client (Claude Desktop / Cursor / Le Chat) or custom user-level integration | OAuth 2.1 (Bearer JWT)                          | [OAuth 2.1](/knowledge-ai/authentication/oauth.md)                             |
| Browser frontend on `.kai-studio.ai`                                            | `kai_auth` HttpOnly cookie                      | [Cookies](/knowledge-ai/authentication/cookies.md)                             |

The decision rule is straightforward: a machine-to-machine pipeline scoped to one instance with no identity uses Instance API keys; a backend that needs an organization role across the platform APIs uses an Organization API key; an unattended agent platform uses the same key sent directly in the `Authorization` header, because OAuth would require a human it does not have; anything acting on behalf of a human user uses OAuth 2.1; a first-party browser app reuses the cookie set after login.

## Where to next

* [Instance API keys](/knowledge-ai/authentication/api-keys.md) — static credentials for ingestion pipelines on `https://api.kai-studio.ai`. One key, one instance, no user identity.
* [Organization API keys](/knowledge-ai/authentication/organization-api-keys.md) — role-bearing service-account credentials. Exchange a `ks_org_…` key for a Bearer token that drives the Platform, Audit, and Retrieval APIs under organization RBAC — or send the key itself as the Bearer credential on Audit, Retrieval, and MCP.
* [Autonomous agents (API key)](/knowledge-ai/k-ai-mcp/autonomous-agents.md) — the MCP path for unattended agent platforms: key in the header, no consent screen, and the `401`/`503` retry contract.
* [OAuth 2.1](/knowledge-ai/authentication/oauth.md) — full Authorization Code + PKCE flow with Dynamic Client Registration. Includes Microsoft SSO behaviour and the end-to-end sequence diagram.
* [Cookies](/knowledge-ai/authentication/cookies.md) — `kai_auth` HttpOnly cookie semantics: properties, sliding refresh, logout, cross-subdomain SSO.