Organization and members

An organization is the account that owns Projects, Environments, Agents, Definitions, and runs. Members receive organization roles and scoped Project or Environment access; the effective permissions are checked on every request.

Members

A member is a person with access to the organization. Adding someone invites them in; removing them ends their own access, and the keys they issued stop working, because every request re-checks the issuer's live membership rather than trusting what was true when the key was minted. A removed member also cannot mint new keys. See API keys for how a key's scope relates to its issuer.

Projects and access grants

Projects are the tenant boundary for workflow resources. Grant access to a Project or Environment using the current Project access-grant APIs, and scope API keys to the same canonical Project, Environment, and Agent coordinates. A Project role does not silently grant access to another Project.

A role and its explicit operations determine what a member can do against the addressed resource. Environment-scoped grants remain Environment-scoped; do not treat a Project identifier as an Environment or Agent identifier.

Organization user groups

An organization can define user groups: POST /api/v1/organizations/current/user-groups creates a named group of members. A user group has no Project access of its own until an organization administrator grants the appropriate Project or Environment operations.

Who can do what

Access in Perstack is ultimately about operations. A member's organization and Project roles determine which resources they can view or change. An API key can only be scoped to what its issuer already has access to, so granting the right roles is also what keeps keys properly scoped downstream.

GET /api/v1/operation-approvals lists approvals in the caller's permitted Project and Environment scope. Whether an approval is visible or actionable still depends on the invocation's canonical Project, Environment, and Agent coordinates, described further in Approvals.

Review access grants when someone's role changes, not just when they join or leave — access that was appropriate for a previous role does not narrow on its own.