API key scoping and member roles
An API key created in the Console can be scoped to a specific workspace. Usage and billing attribution for requests made with that key then roll up under that workspace rather than the organization's default/unscoped pool -- letting an org see and control usage per team or environment without splitting into separate organizations entirely.
Member roles
Members of an organization are assigned org-level role types such as admin and member (and typically a billing-related role), governing administrative capabilities like managing API keys, workspaces, and billing settings within the Console. This site deliberately phrases role names generally rather than asserting an exact enum, since precise naming was not independently re-verified in this build pass -- see the honesty note in the README.
These org-level roles are distinct from Claude.ai's own per-Project roles/sharing model, which governs collaboration on conversations and Project resources inside the consumer chat product, not Console administration.
How this relates to agent identity and permission policies
Org/workspace structure governs human administrative access. It's a separate layer from:
- subagentidentities.com -- which surface an agent acts under (service-account vs. personal-account attribution).
- subagentpermissions.com -- which tools an agent may call and under what default posture.
An org can contain many workspaces, each of which may host agents running under distinct identities and permission policies -- this site doesn't re-explain either of those; it links out.
Source: general, well-established Anthropic Console concepts, combined with this repo's own already-documented Identity and Permission Policy primitives.