API keys

Issuing one

Who: Any organization member: admins from Settings → API keys, everyone else from API keys in their account menu. Members see and revoke their own; admins see and revoke every key in the organization.
Scope: A key acts as the person who created it, inside their organization, so it grants nothing they do not already have. Domain permissions apply to it exactly as they apply to them. A gateway key is the one exception.
Project: Pick one in the Project field when you create the key. A key scoped to a project acts with its creator’s permissions on that project only: the CI API refuses every other project with a 403, and the MCP server returns an error. All projects gives the key every project its creator can reach.
Lifetime: You choose, up to one year. The key is shown once at creation and stored masked afterwards.
Revoking: From the same page, any time, and it takes effect immediately.

Using one

Keys start with sk-k6-. The CLI reads it from the environment:

Do not paste a key into a command. Literal exports and bearer headers can land in shell history, terminal transcripts, or copied support logs. Load the value from a secret manager, or use a hidden prompt for a short local session.

read -rsp "Cassis API key: " CASSIS_API_KEY
printf '\n'
export CASSIS_API_KEY

The input is not echoed and the secret itself is absent from shell history. For repeat use, replace the prompt with your secret manager’s runtime lookup; keep only the secret reference in scripts.

Configure your non-interactive MCP client to read CASSIS_API_KEY from its environment and send its value as a bearer token in the Authorization header. Connect using the client’s MCP handshake over POST; a plain GET request is not a connection test. See Endpoint and authentication.

With a key scoped to one project, every MCP tool defaults to that project, so the agent can leave out project_id. See MCP endpoint.

In CI, store it as a secret and expose it as CASSIS_API_KEY. See Set up CI.

Treat a key as the person, not the machine. A key issued by an admin carries admin rights everywhere it is pasted. Issue keys from the account that should own the automation, scope each one to the project that automation needs, and revoke rather than reuse when someone leaves.

Gateway keys

For a company MCP gateway that serves many people with one key. Each call runs as the person the gateway names, not as the key’s creator.

Who: Organization admins, with Gateway key turned on. The key stops working if its creator stops being an admin.
Project: Required.
Identity: The gateway names the asker in a header on every request, and the call gets their role and chat history. See Gateway delegation.
New people: Added as Explorers on their first question when your organization has claimed their email domain.
Refused: Suspended members, people awaiting approval, and Cassis staff accounts.
Where: MCP only. The CLI and CI API refuse it.

A gateway key can act as any member on its project, admins included. Give it only to a gateway your company operates.

When you do not need one

Any interactive MCP client that supports OAuth can open a browser for Cassis sign-in and refresh its token automatically. Claude Code, Claude Desktop, and Cursor are examples. See Connect your AI assistant.