Vexta's 7 Team Roles: Who Gets to Scan, Fix, Bill or Just Watch

Role-based access control on a vulnerability scanner means each team member gets exactly the permissions their job needs, not full access by default. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its team system defines 7 distinct roles, from an Owner who holds the license down to a read-only Viewer, so a security team, a consultancy or an internal AppSec group can share one instance without everyone touching the same buttons.

What are the 7 roles and what can each one do?

Owner has full access and holds the license. Admin has full access except license management, which keeps day-to-day administration separate from the one action tied to billing and activation. Settings covers configuration plus everything Engineer and Viewer can do, which suits someone who tunes scan profiles and notification channels but should not be managing other people's accounts.

Billing is scoped to billing only, useful for a finance contact who needs to see invoices and nothing about scan data. Engineer covers scans, findings and assets plus viewer access, which is the working role for a hunter or pentester actually running the tool day to day. Viewer is read-only, built for a stakeholder who needs to see results without being able to change anything. API is API access plus viewer, for a service account wired into a pipeline rather than a person logging in through the browser.

Why does a scanner need 7 roles instead of just admin and user?

A two-tier system forces an uncomfortable choice: either everyone gets admin rights, or everyone gets the same limited view regardless of what they actually do. Neither fits a real team. A consultancy running Vexta across client engagements might have engineers running scans, a lead reviewing and signing off on findings, a billing contact who should never see a client's vulnerability data, and a CI service account that only needs to pull results through the API.

Splitting Settings out from Admin is a smaller but real distinction. Someone tuning WAF-aware throttling, notification channels or scan profiles does not automatically need the ability to manage other users' accounts or the license itself. That separation matters more as a team grows past two or three people, when "everyone is an admin" quietly turns into nobody being sure who changed what.

How does the API role fit into a CI/CD pipeline?

The API role is deliberately narrow: API access plus the same read-only visibility a Viewer gets, nothing more. That is the right shape for a service account sitting inside a build pipeline that pulls findings for a SARIF or JUnit XML export and nothing else. It should never be able to change scan configuration or another user's role, which limits the blast radius if a CI secret ever leaks.

Separating human roles from a machine-facing API role also keeps an audit trail honest. When an action shows up in the log, a narrowly scoped API role means you are not left guessing whether it was a person or a pipeline that triggered it.

What backs the access control itself?

Passwords are stored with bcrypt hashing, and TOTP-based multi-factor authentication is supported on top of that. An admin action audit log records who did what, which is what lets a team answer "who changed this scan's schedule" after the fact instead of guessing. There is also a protected sole-owner rule: the only Owner on an instance cannot be demoted or removed, which closes off the scenario where a team accidentally locks itself out of its own license-holding account.

Multi-seat RBAC across these 7 roles is an Enterprise-tier capability; check the current plan breakdown on the pricing page for exactly what is included at each tier.

What a role setup looks like for a real team

Take a five-person consultancy running Vexta across client engagements. The founder holds Owner. A senior tester who manages scan profiles, notification routing and wordlists gets Settings, since that role covers configuration on top of the standard Engineer and Viewer permissions without touching license or user management. Two junior testers running the day-to-day scans and triaging findings get Engineer. The office manager handling invoices gets Billing, which never exposes a client's findings. A CI pipeline pulling SARIF output into a shared repo gets an API account, scoped to read plus API access and nothing that could change a scan's configuration.

That is six accounts, five people and one service account, each with exactly the access their part of the work requires. If the CI credential ever leaked, the API role's narrow scope means the worst case is someone reading findings they were not supposed to, not someone reconfiguring a scan or removing a teammate's account. The admin action audit log then lets the Owner confirm nothing beyond that happened.

Key takeaways