Members & Roles

Vygl’s RBAC has three roles in a strict hierarchy. Each role is a superset of the next: an owner has every admin permission, an admin has every member permission.

The roles

Role	Permissions
Owner	Everything: change org settings, manage members, manage API keys, manage integrations, delete the org (when supported). Created automatically for the user who first signs up an org.
Admin	Members management (invite / remove), API keys, integrations, SCM and registry connections, custom rules, organizational memory, settings.
Member	Create projects, run scans, triage findings, read everything. Can’t manage members, API keys, or integrations.

Roles apply organization-wide — Vygl doesn’t have per-project roles today. A member who can read findings reads all findings in their org. Large orgs needing strict per-team isolation should split into separate organizations.

Inviting a member

1. Open Settings → Members.
2. Click Invite Member.
3. Enter the invitee’s email and pick the role (Member or Admin — the dropdown only exposes those two; Owner is reserved for the org creator).
4. Click Send Invite.

The invitee receives an email with a link valid for 7 days. Clicking it lands them on a sign-up or sign-in page and adds them to the org with the chosen role.

Changing a role

There’s no role-change action today. To shift a teammate from member → admin (or vice versa), remove the member and re-invite at the new role. The new role takes effect on the next sign-in.

Removing a member

From Settings → Members, click the menu next to a member and choose Remove. The user loses org access immediately for new requests. A JWT issued shortly before removal can still authenticate API calls until it expires (default 30 minutes), so for high-stakes off-boarding, also revoke any API keys the user created. If the member belongs to other organizations, those memberships are unaffected.

API keys vs roles

API keys have their own permission system — scopes — which is separate from a user’s role. A key can have narrow permissions like scan:write (can submit scans, can’t read findings) regardless of who created it. See API Keys for the scope list.

Audit trail

Membership changes emit audit events:

• org.member.invite — admin sent an invite.
• org.member.remove — member was removed.

See Audit Log for how to query these.

No per-project roles

“Make this user a viewer of project A but an admin of project B” isn’t supported. The recommended pattern is separate organizations per scope-of-trust boundary.