Skip to main content
An account is your team’s space: agents, runs, integrations, credentials, keys, and members all belong to one, and data is isolated to it. You act in exactly one account at a time even when you belong to several, and nothing in one is reachable from another.

The account boundary

Everything is owned by exactly one account, and you always act in exactly one at a time. An agent, run, credential, knowledge base, or channel in one account is never visible from another — see Agent isolation & tenancy for how that is kept. Friendly names are scoped to the account rather than shared globally, so two teams can each have an agent called triage 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 accounts — because you work across teams, or because more than one trusts your verified email domain. When you belong to more than one, an account switcher lists them; picking one changes which account 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 account.

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 account, 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 like team = 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.