Permissions
Understand the authorization boundaries that apply beyond a successful login.
On this page
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.