Role-Based Access Control: Roles and Permissions
Organization roles assign company responsibilities. Team roles and agent-specific access determine who can work with particular resources. Giving someone a specialized administrative role does not automatically grant every other kind of administration.
Organization roles
| Role | Responsibilities |
|---|---|
| Owner | All administrative controls, including usage limits, ownership, Organization profile, and SSO recovery |
| Admin | Broad day-to-day administration, including people, agents, security, licenses, and usage limits; excludes Organization profile changes and owner-only recovery authority |
| Identity Admin | Members, SSO, SCIM, MFA and session policy, access reviews, and security activity |
| Security Admin | Access policy and reviews, tool access policy, retention, security rules and findings, audit policy and evidence access, API-key listing/revocation/deletion, machine identities, Organization email service, and halting and releasing agent security holds; view usage limits |
| Agent Admin | Organization agents, Teams and shared agent resources, portable agent exports, agent audit, agent email policy, read-only tool access policy, and halting the agents they manage (not releasing holds) |
| Auditor | Read security activity, access reviews, retention policy, tool access policy, machine identity and email configuration, usage limits, and agent audit; permitted audit exports |
| License Admin | Signed company license import, seat visibility, API-key visibility, and setting usage limits |
| Member | Use accessible resources; create Organization agents when the Organization allows member creation |
| Viewer | Read resources explicitly available to them without chat or configuration rights |
Every active member can view basic company license status. Only Owners, Admins and License Admins can import a signed replacement after confirming their identity.
This table summarizes the roles; individual resource permissions and enabled features still apply. For example, audit exports have additional policy controls, and a Security Admin's retention authority does not grant portable export of all Organization agents.
Owner, Admin and License Admin set usage limits; Security Admin and Auditor can only view them. Agent Admin can do neither, so it sees the Usage limit reached status on an agent but not the limit values or the limit controls.
Halting an agent is deliberately easier than releasing one. Owner, Admin, Security Admin and Agent Admin can place a security hold on an Organization agent with a reason and one confirmation; Agent Admin is limited to agents it manages. Only Owner, Admin and Security Admin can release a hold, and release still requires recent authentication, the exact agent name and acknowledgement of unresolved outcomes. Auditor, License Admin, Identity Admin, Member and Viewer cannot halt. See Halt an agent.
Halting a whole Team or the Organization uses separate capabilities because the blast radius is larger. Owner, Admin and Security Admin can halt the Organization or any Team; Agent Admin can halt a Team only when it may halt every agent in that Team. A Team Admin who is only an Organization Member cannot halt. Releasing a group halt is limited to Owner, Admin and Security Admin and needs recent authentication. See Halt a Team or the whole Organization.
Organization API keys are issued by an Owner or Admin. Even a Read only key grants Organization-wide agent access, so creating one requires both API-key and agent-management authority. Security Admin can list, revoke and delete existing keys. Agent Admin can use a previously issued key but cannot create one.
Every Organization-key request requires its creator to remain an active user and member with Organization agent-management authority. Removing or downgrading the creator blocks their keys, including Remote MCP control tools. Keys do not inherit another administrator's authority. The Blocked status is temporary: restoring the same creator's authority restores access unless the key was revoked. Blocking stops subsequent requests; it does not cancel work already accepted.
Team roles and private agents
Owner, Admin, and Agent Admin have implicit administrative access to Organization Teams and private Organization agents. Other Organization roles need appropriate Team membership or resource access to work with agents.
Team Admins can deny tools for an individual agent, but only Owners, Admins, and Security Admins change the Organization's or a Team's tool access policy.
Within a Team, Admin, Member, and Viewer determine Team administration, ordinary use, and read access. A Team Admin does not thereby become an Organization Admin. Joining an Organization through SSO does not automatically assign a Team.
An agent collaborator invitation is another access path. It grants access to that agent, not general Organization administration. A contact allowlist entry controls communication; it is not an Organization or Team membership. See Collaborators And Ownership and Contact Access.
Assign and change roles
Open Governance → Access → People & roles in the correct Organization. Review the available role descriptions when inviting a member or changing an existing membership. Sensitive changes may require you to reconfirm your identity.
You cannot change your own membership role through the normal member-role control or remove the last Owner. Admins cannot manage Owner memberships. Identity Admins can manage ordinary Member and Viewer memberships; they cannot use that role to grant administrator authority.
Before changing a role, check Team assignments, access to shared credentials, and any work the person approves. Use Access Reviews to record the decision and follow-up. Review provider credentials and machine access separately when someone leaves; ending a web session does not revoke every integration credential.