Teams and roles

A workspace is your team's space in Vulnara. Every repository, scan, finding and setting belongs to exactly one workspace, and only its members can see them. Each member holds a role that decides what they may do there. The account menu calls a workspace a team, for example Create New Team, and the members screen is Team.

What it is for

• Keeping each team's or customer's data apart.
• Giving people read-only access, or the right to change things, or full control.
• Bringing colleagues in by email, whether or not they already use Vulnara.

How it works

You can belong to several workspaces. The account menu lists them, and choosing one switches the whole app to it. Vulnara remembers your choice when you reload the page.

Every request, from the web app, the CLI, the API or an AI client, names one workspace. Vulnara checks that you belong to it and checks your role there before doing anything.

The roles

• Viewer: read-only access to everything in the workspace. A member with no role set is a viewer.
• Editor: everything a viewer can do, plus changing things: adding and deleting repositories, git workspaces, networks and web applications, starting and cancelling scans, managing schedules, ignore paths, alert rules, remediation templates and triage decisions.
• Admin: everything an editor can do, plus the team and the money: inviting and removing members, changing roles, managing invitations, git tokens and service accounts, transferring git workspaces and networks to another workspace, provisioning and deprovisioning connector agents for networks, changing the plan and managing payment methods.

A higher role always includes the lower ones.

In the app, an action your role does not allow is still shown, but disabled, with a note naming the role it needs.

What you can set

• Workspace name: set when you create it. It must be unique across Vulnara, and it becomes the workspace id you use in the CLI, the API and the GitHub Action.
• Members: who belongs to the workspace.
• Roles: Viewer, Editor or Admin for each member.
• Invitations: pending invitations, which you can revoke.
• AI access: Read or Write for each member, for an AI acting on their behalf. Read is the default.

Do it

Create a workspace

1. Open the account menu and choose Create New.
2. Enter a Name and confirm.

You become its admin, and the app switches to it. API: createTenant. CLI: create_tenant.

Invite a member

1. Go to Settings, then Team.
2. Choose Invite Team Member.
3. Enter their Email and choose Invite.

Vulnara emails them a link, in the language you are using the app in. API: inviteTenantMember.

• Someone who already has a Vulnara account gets a link to an invitation page in the app. It shows the workspace name, with Join Team and Reject Invitation. Until they choose Join Team, they are not a member: they do not appear in the member list and cannot open the workspace or its data.
• Someone with no account gets a sign-up link. Creating the account through it joins them to the workspace.

A new member starts as a viewer. Change their role once they have joined.

Change a member's role

1. Go to Settings, then Team.
2. Select one member and choose to update their roles.
3. Pick the role and save.

API: updateUserRoles.

AI access

The Team screen has an AI Access column. It decides what an AI acting for that member, the chat in the web app or their own MCP client, may do in this workspace:

• Read: the AI may only read data. This is every member's level until an admin changes it.
• Write: the AI may also make a few changes, such as starting a scan or triaging a finding. Neither the chat in the web app nor the MCP server asks for a separate confirmation before it does; an MCP client may still ask you itself.

To change it, select one member, choose Update AI Write Access, pick the level and save. It needs the admin role. The level is set per workspace, and it never goes beyond the member's role, so Write does nothing for a viewer. API: updateUserAiAccess, and myAiAccess for your own level. See AI agents over MCP.

Remove a member

On the Team screen, select the members and choose Remove. API: deleteTenantMember.

Revoke an invitation

Pending invitations are listed on the Team screen. Choose Revoke on one. The invitee can then no longer join. API: deleteInvitation.

Move a git workspace or a network to another workspace

1. In Workspaces, choose Transfer on the git workspace.
2. Enter the id of the destination workspace in New Tenant and confirm.

To transfer, you need the admin role in the current workspace and at least the editor role in the destination. Networks move the same way through the API. API: transferGitEntity and transferNetwork. CLI: transfer_git_entity and transfer_network.

Accept the Platform Terms

Every member accepts the Vulnara Platform Terms for themself, once per workspace. Until you have accepted the current version in a workspace, the web app shows a window you cannot close, naming the version and linking to it. Tick the box to accept and choose Accept. If the terms change, you are asked again, and the window says they changed since the version you accepted. Another member's acceptance does not count for you. The account menu links to the current Platform Terms.

Until you accept, you can still read everything, but every change is refused, whether it comes from the web app, the API, the CLI or an AI acting for you. The API answers it with TERMS_NOT_ACCEPTED. Accepting is the one change that always works. Service accounts are exempt, since they have no screen to accept on.

An account with no email address cannot record an acceptance. API: termsAcceptance and acceptTerms.

Good to know

• Invitations expire after two days. Send a new one if it runs out.
• Existing members cannot be invited again. Inviting someone who is already in the workspace is refused.
• An invitation is personal. Only the person it was sent to can open, accept or reject it.
• Nobody joins without accepting. An invitee is not a member, and does not count as one, until they accept.
• Adding a member does not subscribe them to alerts. Recipients are set on each alert rule.
• Viewers do not see email addresses. In the member list, a viewer sees other members' names and roles, but only their own email address.
• Service accounts are not members. They do not appear on the Team screen and are managed separately. See Service accounts.
• Transfers have to change something. A transfer to the workspace the item is already in is refused. A destination you do not belong to, or where you are only a viewer, is refused with the same error as one that does not exist.
• Plan limits belong to the workspace. Each workspace has its own plan and usage. See Plans, usage and billing.