Manage access with groups
A group is a named set of people in your organization. Grant the group a role on a resource once, and everyone in it gets that access. Add someone to the group later and they pick it up automatically.
Groups are available on organization accounts. A personal account has a single member, so there is nobody to share with and no access panel appears.
Roles you can grant
A group receives a role on one deployment, blueprint, or knowledge store at a time. There are four, and each adds to the one before it:
- Viewer reads the resource, including logs and traces. Secret values stay hidden.
- Writer also changes and operates it: redeploy, restart, stop, resume, trigger ingestion.
- Maintainer also grants and revokes access to it.
- Admin also deletes it.
Access control covers the full model: the permissions behind each role, how account roles fit in, and what a denial looks like.
Create a group
Groups live in your organization settings.
Open the Groups page
Go to Settings, then Organization, then Groups. You need to be an account administrator to create or change a group. Other members can see the list.
The group list shows the first few members of each group as avatars. A 3+ marker means the group has more members than the preview shows. Open the group to see the full list.
Give a group access to a resource
Open the deployment, blueprint, or knowledge store you want to share, then select Access.
The button is visible to anyone viewing the resource, but stays disabled until the server confirms you can manage access. That means you need Maintainer or Admin on the resource, or the account administrator role.
Search for the group by name and pick a role. Unassigned groups are also listed below the search field, so you can grant access without typing. The change applies immediately.
The panel lists groups as groups. It does not expand a group into its individual members, so the row you see is the grant you made. People who reach the resource through the account administrator role appear as a separate locked row, because that access comes from the account and cannot be revoked here.
When someone has access two ways
A person can hold a direct role and be in a group that holds a role on the same resource. They get the more permissive of the two. Access is never reduced by adding another grant.
Because of that, the panel disables any direct role that would not raise the person’s effective access. If a group already makes someone a Writer, granting them Viewer directly changes nothing, so the option is unavailable.
Removing a direct role does not remove access that comes from a group. To take away group access, remove the person from the group or remove the group’s grant on the resource.
Archive or delete a group
Archive retires a group without disturbing what it already reaches. Existing grants keep working, and the group shows as a locked row in access panels. You can remove that grant, but you cannot change its role, and the group cannot be given access to anything new. Restore the group to make it usable again.
Delete is permanent. It removes the group and every grant it held, so anyone whose access came only through that group loses it.
Archive when a team is winding down and you want its access to keep working while you unwind it. Delete when the group was a mistake or its access should end now.
Next steps
- Working with accounts: account roles and switching between accounts
- Manually authorize requests: run the same access checks yourself from an agent
- Managing your agents: the deployment surfaces these roles apply to