Roles and permissions

The six team roles, what each can do, and how protected environments change secret access.

Every team member has exactly one role. The role decides what they can do with secrets in each environment, whether they can manage the team, and whether they can handle billing. Pick the least-privileged role that covers someone’s work: most people need developer, and many need only operator or viewer.

The six roles

Who each role is for, and what it can do with secrets in non-protected and protected environments:

“Write” covers creating, updating, deleting and rotating secrets, and rolling back an environment.

A viewer is also kept out of any environment whose slug is production, even if someone removes its protection. Viewers still see that protected environments exist; they cannot read the secrets in them.

Permission matrix

Team, projects and environments

AI agents

Any member can connect an AI agent over MCP and approve what it may do, up to their own role:

Viewers and billing members cannot give an agent any secret access. The agent’s access is re-checked against the member’s current role on every call, so a downgrade or removal applies to their agents at once. Each member manages only their own agent connections.

Protected environments

Any environment can be marked protected in its settings, by an owner or admin. In a new project, production is protected by default.

Protection is about who may change an environment and who may see it:

• Owner, admin: read and write, as before
• Developer: keeps read access, loses write access
• Operator: unchanged, read-only
• Viewer, billing: no access to its secrets

Use protection for any environment where an accidental change reaches users.

Assigning roles

• Owners and admins choose a role when inviting someone (the dashboard suggests developer) and can change it later from the team page.
• Owner is not assignable. A team has exactly one owner. The assignable roles are admin, developer, operator, viewer and billing.
• Changing someone’s role revokes their CLI logins for the team, their agent connections and the API tokens they created. They sign in again under the new role; rotate any pipeline token they had made first. An agent connection is revoked whole, including the other teams it covered, so they reconnect their agent to keep access to those.

Ownership transfer

The owner can hand ownership to another member from the team settings. The previous owner becomes an admin, and the audit log records team.ownership_transferred.

Deactivated members

Deactivating a member schedules it, with a 7-day grace period:

Both steps are recorded in the audit log. The owner cannot be deactivated. To cut someone off immediately, remove them from the team instead.

API tokens are not role-scoped

An API token carries no member role. It can:

It cannot:

Only owners and admins create tokens, and a token stops working when its creator leaves the team or changes role.