CrowNest
Concepts

API keys and scopes

How organizations, projects, API keys, and scopes control access to CrowNest.

CrowNest authenticates API requests with org-scoped API keys, and every key carries an explicit list of scopes that defines what it can do. You create keys in the dashboard and revoke them from the dashboard or the API, optionally restricting them to specific projects.

Organizations and projects

An organization is the tenant boundary: every sandbox, artifact, preview, and API key belongs to exactly one organization. A project is a grouping inside an organization for sandboxes, usage, quotas, and API key restrictions. Use projects to separate environments, teams, or agents that share an organization. GET /v1/projects lists the projects your key can see.

Key format and one-time display

API keys look like cn_live_... and are sent as a bearer token:

Request header
Authorization: Bearer cn_live_...

The raw key value is shown once, at creation. CrowNest stores only the prefix, a hash, and the last four characters, so the full key can't be recovered later. Store it in a secrets manager when you create it; if you lose it, revoke the key and create a new one.

Important

API keys can never create other API keys. Grant api_key:read and api_key:revoke only to trusted org-wide automation that rotates or disables credentials.

Scopes

Each scope is a single resource:action string. A request succeeds only if the key holds the scope the endpoint requires; otherwise it returns forbidden.

ScopeGrants
sandbox:createCreate sandboxes.
sandbox:readGet and list sandboxes.
sandbox:killDestroy sandboxes.
sandbox:extendExtend sandbox TTL.
command:runRun and start commands.
command:readGet commands, read logs, and follow log streams.
command:cancelCancel running commands.
code:runRun code and manage code contexts.
workspace_run:createCreate, upload, and start Workspace Runs.
workspace_run:readRead Workspace Run status, events, and evidence.
workspace_run:cancelCancel active Workspace Runs.
file:readList, stat, read, and download workspace files.
file:writeWrite, move, delete files, and create directories.
artifact:createExport artifacts, including command collect.
artifact:readGet, list, and download artifacts.
artifact:deleteDelete artifacts.
preview:createCreate previews.
preview:readGet and list previews.
preview:revokeRevoke previews.
usage:readRead usage and quota information.
api_key:readList and inspect API key metadata.
api_key:revokeRevoke API keys.
project:createCreate projects with an org-wide key.

Some operations need more than one scope: running a command with collect requires command:run plus artifact:create, and creating an artifact requires artifact:create plus file:read. Workspace Runs with explicit artifact collection require workspace_run:create, artifact:create, and file:read.

Dashboard presets

The dashboard offers presets so you don't assemble scope lists by hand:

  • Quickstart Developer — full sandbox, command, file, artifact, Workspace Run, and preview management, plus usage:read. Good for getting started.
  • Project Runtime — the runtime scopes without artifact:delete and preview:revoke. Good for agents that create and use sandboxes but must not remove durable resources.
  • Read Onlysandbox:read, command:read, file:read, artifact:read, workspace_run:read, preview:read, and usage:read. Good for dashboards and monitoring.

You can also pick a custom scope set. We recommend granting the smallest set that covers what the key actually does.

Project-restricted keys

A key is org-scoped by default, but you can restrict it to specific projects when you create it. A restricted key can only act on resources in those projects; requests against anything else return forbidden or not_found. Use project restrictions to keep one agent's credentials away from another project's sandboxes.

API-key management is always org-level. Project-restricted keys cannot list, inspect, or revoke API keys even if they include api_key:read or api_key:revoke.

Next steps

On this page