# Permissions

Availability: Release contract.
Last reviewed: 2026-08-28.

Permissions are checked for the actor and the specific resource, not inferred from a key's existence.

## Separate the principals

An account owner or administrator can manage eligible developer resources. A workspace member can have collaboration or business access without account administration. An operator can accept assigned work without owning the customer's data. Platform staff authority is not customer account-administration authority.

The first developer key scope is `identity:read`. Its only approved API result is credential identity. Business resources remain unavailable to these keys in this release.

## Planned resource authorization

Future business contracts must bind the owning account, application, delegated actor when applicable, workspace/resource grants and the requested action. Cross-account agency work needs explicit delegation; selecting an account name is not sufficient.

Reads still need authorization. A “read-only” label does not permit unbounded provider calls or access to raw private evidence.

## Denial is useful information

An inaccessible resource should not leak another account's names, balances, addresses or secret metadata. Missing authority differs from missing configuration or exhausted operational limits.

## Before widening access

Review data access and spending authority separately. A collaborator invitation, saved payment method or approved research result must not silently enable dispatch, publication, purchases or recurring work.