/settings/api-keys) to create, copy, review, and revoke keys for the active organization.
What API keys can access
Organization API keys authenticate to platform APIs for the organization they were created in. The key inherits the creator’s organization role and access. That means a key created by an admin can access admin-level platform APIs, while a key created by a builder is limited to builder-level access. Each key also has a scope that narrows (never widens) what that role allows:
Read allows
GET/HEAD requests (minus organization administration, as for Write) and refuses every other method, including read-like POST endpoints such as searches or queries. Use a Write key for those. A Read key is also never treated as a deployer, so trigger webhook URLs (which embed their ingress token) are left out of its responses.
A key can also be restricted to one project, and optionally to specific agents and workflows in it (read or write scope only). It then sees every other project as missing and can only use the resources it names. See Governance.
Keys created before scopes existed are Admin keys, so they keep working exactly as before. Hosted MCP servers need a Write or Admin key, since their tools run workflows.
Keys can optionally expire (30 days, 90 days, 1 year, or never). Expired keys stop authenticating. The Last used time is updated at most once a minute.
Service accounts
A personal key stops working when its creator leaves the organization. For CI and long-lived integrations, owners and admins can instead create a key that acts as a service account: a new, non-human organization member named after the key, with the Builder or Admin role you pick. Nobody can sign in as a service account. Service account keys keep working after the person who created them leaves. They are listed in Governance → People like any member (add a builder service account to the projects it needs). Revoking the key also removes the service account. API keys can be sent as:?token= or ?api_key= query parameters. Prefer headers for new scripts.
API keys and the CLI
API keys have nothing to do with CLI access today. The CLI is authenticated and accessed at the user level, not with org-scoped API keys. When you runluno auth login, you authenticate as a user. From there, the CLI can access every organization you belong to and switch between them. It is not scoped to a single organization the way an API key is.
So use API keys for scripts and external tools hitting the platform API, and use luno auth login for CLI work like luno deploy on your own machine. Hosted sessions (the in-app Luno Builder, MCP workspaces) are already authenticated and never run auth login.
Create a key
Create API keys from the web app or the CLI.Visibility and permissions
API key visibility depends on your organization role:
Any member can revoke their own keys. Owners and admins can revoke keys created by other members.
Revoke a key
Revoke a key when it is no longer needed, when a teammate leaves, or when you think the secret may have been exposed.Use keys in scripts
Store the key in an environment variable and pass it as a header:Next steps
Members
Understand the organization roles API keys inherit.
Organization
Manage organization-wide settings.
CLI reference
See the API key command reference.
Credentials
Store runtime credentials for agents and workflows.