Skip to main content
Artifacts has one authorization layer. Whether a request comes from the web app, REST API, CLI, or MCP server, it’s evaluated as a principal against the same policy — so access behaves identically everywhere.

Principals

A principal is whoever is making a request.
PrincipalUsed by
userSigned-in humans using Better Auth sessions
api_keyScoped bearer tokens for CLI, CI, and automation
agentAgent-owned credentials
oauth_clientOAuth clients such as MCP clients
serviceInternal service actors, including share-link resolution
Principals can also carry scopes and artifact role grants.

Artifact roles

Roles are ranked from most to least privileged:
owner > admin > editor > viewer
Each role unlocks a set of actions:
ActionMeaning
artifact.viewRead metadata and source content
artifact.createCreate artifacts in a namespace
artifact.updateAppend a new version
artifact.restoreRestore an older version as the new head
artifact.diffCompare two versions
artifact.deleteSoft-delete an artifact
artifact.manage_accessRead or update access settings
artifact.create_share_linkCreate share links
artifact.revoke_share_linkRevoke share links
project.viewView projects in a namespace

Public access

Each artifact has two public switches:
{
  "publicView": true,
  "publicEdit": false
}
  • publicView grants viewer access to unauthenticated callers.
  • publicEdit grants editor access to public callers, when the plan allows public edit links.
Private artifacts require an owning user, a workspace member, an email allowlist match, an API key or OAuth principal with permission, or a share link.

Email allowlists

Grant view access to specific people by email:
{
  "publicView": false,
  "publicEdit": false,
  "viewerEmails": ["teammate@example.com"]
}
Email viewers must sign in with a verified email that matches the allowlist. This requires a plan that includes private artifacts and email allowlists. Share links grant viewer or editor access to a single artifact, and can optionally expire:
artifacts share create \
  --artifact-id ARTIFACT_ID \
  --role viewer \
  --expires-at 2026-06-30T12:00:00.000Z
Share links require Pro or Team entitlements.

API key scopes

API keys are bearer credentials with explicit scopes — grant only what each job needs.
ScopePurpose
artifacts:readRead artifacts, versions, diffs, and project lists
artifacts:createCreate artifacts and projects
artifacts:updateAppend versions and restore
artifacts:deleteSoft-delete artifacts
artifacts:shareCreate and revoke share links
artifacts:access:readRead access settings
artifacts:access:writeUpdate access settings
agents:manageManage API keys and agent credentials
artifacts keys create --name ci --scopes artifacts:read,artifacts:create,artifacts:update
Treat API keys as secrets. The raw key is only shown at creation time — store it in a secret manager and pass it through environment variables or stdin.

What each plan unlocks

Some access features are plan-gated:
FeatureFreeProTeam
Private artifactsNoYesYes
Email allowlistNoYesYes
Share linksNoYesYes
Public edit linksNoYesYes
Audit retention7 days90 days365 days
Version history30 days365 days365 days