The workspace boundary
Everything is owned by exactly one workspace, and you always act in exactly one at a time. An agent, run, credential, knowledge base, or channel in one workspace is never visible from another — see Agent isolation & tenancy for how that is kept. Friendly names are scoped to the workspace rather than shared globally, so two teams can each have an agent calledtriage or a credential called github with no collision between them and no way
to detect each other’s.
Belonging to more than one
You can be a member of several workspaces — because you work across teams, or because more than one trusts your verified email domain. When you belong to more than one, a workspace switcher lists them; picking one changes which workspace you are viewing and acting in, and the switch is recorded in the audit log. With a single membership the switcher is hidden.Managing members
Settings → Members lists everyone in the workspace.Inviting
Invite by email. The membership is created immediately and activates on that person’s first sign-in — there is no acceptance step. You can give an invitation a display name so the row is recognizable before they arrive, and assign roles as part of it.Suspending and restoring
1
Suspend to revoke access
Suspension takes effect immediately: live browser sessions stop working on their next request,
and any API keys bound to that person stop authenticating.
2
A suspension is never undone silently
Even if the person’s email domain is still trusted by the workspace, signing in again does not
reactivate them. Only an explicit restore does.
3
History is preserved
Suspending removes access, not work: runs and other records stay attributed to them.
Roles and attributes
Each member holds one or more roles, which decide which policies — and therefore which capabilities — they receive. Roles and attributes are both columns on the Members screen: an attribute is a key–value pair liketeam = payments, and label-scoped grants match against it, so one grant can
give everybody access to their own team’s resources. Editing attributes is itself a governed
capability, so it stays with administrators by default.
See Roles & permissions for the
full model.
Next steps
Roles & permissions
Built-in roles, custom roles, and how a grant is scoped.
Service accounts
The identity automation should use instead of a person’s.
Access explorer
Check what a member can do before and after a change.
Audit log
Invitations, suspensions, and restorations are all recorded.