Accounts and roles
Choose a role, create accounts, assign feature permissions, complete authenticator setup, and review the impact of role changes.
Hunt Web separates workspace administration, assessment execution, and result review through three account roles: Admin, Operator, and Viewer. The role sets the account's access model; feature permissions determine the available work within that model. This allows a team to provide scan access to assessment operators and read access to reviewers while keeping account and instance management with administrators.
Dashboard accounts are separate from the target accounts supplied for Greybox testing. A Dashboard Operator may test with one or two application accounts; those application identities do not change the Operator's Dashboard role.
1. Choose the Role That Matches the Work
| Capability | Admin | Operator | Viewer |
|---|---|---|---|
| View Targets, Runs, Results, reports, and Findings | Included for registered Hunt Web features | With the corresponding read permissions | With the corresponding read permissions |
| Add Targets and configure Scopes or Greybox accounts | Included | With the corresponding setup permissions | Unavailable |
| Start profile scans | Included | With Start permission and required setup/read access | Unavailable |
| Pause, resume, and finalize Runs | Included | With Run control permission and required Run access | Unavailable |
| Read Hermes conversations | Included | With conversation and related Run access | With read permissions and related Run access |
| Send Hermes instructions or continue testing | Included, subject to Run eligibility | With Hermes write permission and required Run access | Unavailable |
| Use Assistant | Separate Assistant permission required | Separate Assistant permission required | Unavailable |
| Manage users, instance settings, security audit, and retention policy | Administrative access | Unavailable | Unavailable |
| Manage the account's own profile and security | Available | Available | Available |
Permissions are not scan readiness
These entries describe permissions, not scan readiness. Account status, initial password setup, required MFA, the requested resource, model availability, and the selected Run's state still affect whether an action can proceed.
Admin
Admin manages the workspace and receives built-in access to registered Hunt Web features. Assistant is an exception: it requires an explicit grant even for an Admin.
Operator
Operator is intended for assigned assessment work. Selecting Operator alone does not authorize scanning. An Admin grants the relevant features in the account's permission panel.
Viewer
Viewer is intended for reading permitted assessment information. A Viewer cannot become a scan operator through a write-permission checkbox; the server enforces the read-only role. Reading saved Hermes exchanges is different from sending a new instruction, even when the instruction only asks for a summary.
2. Create a Separate Account for Each Team Member
An active Admin can open Users & Roles → Add account:
- 1Enter the detailsA display name and a unique username.
- 2Select the roleAdmin, Operator, or Viewer, then Create account.
- 3Copy the initial passwordIt is shown once.
- 4Share it privatelyGive the credentials only to the account holder.
- 5Assign the permissionsSelect the account and assign the required feature permissions.
- Enter the display name and a unique username.
- Select Admin, Operator, or Viewer, then choose Create account.
- Copy the generated initial password from Copy the initial password.
- Provide the credentials privately to the account holder.
- Select the new account and assign the required feature permissions.
The initial password is shown once. At first sign-in, the account holder must change it before using other workspace features. Public self-registration is not available. An Admin created through the domain also completes the required authenticator setup described below.
Individual accounts keep role changes, access reviews, and recorded activity associated with the relevant person. Account creation does not configure a model provider or supply credentials for a scanned application.
3. Assign Feature Permissions
Select a person under Users & Roles, then review Feature permissions. Checkbox changes save immediately. The labels explain the effective access:
| Label | Meaning |
|---|---|
| Included with role | Access comes from the role. Removing a duplicate additional grant does not remove that inherited access. |
| Additional permission | An explicit account grant provides access. |
| Not granted | The feature permission is absent. |
| Unavailable for Viewer | The action exceeds the Viewer's read-only role. |
| Account disabled | The account is inactive and cannot use its permissions. |
Hunt Web groups permissions by Targets & Scope, Runs & Reports, Findings, Hermes Chat, Chat Templates, and Health. Reading data, starting scans, controlling Runs, and sending Hermes instructions are separate permissions. A report link does not provide anonymous access to the report.
For an Operator responsible for preparing and running assessments, a practical assignment includes:
- Targets & Scope: view Targets and saved Scopes, add Targets, and set up Scopes and Greybox accounts.
- Runs & Reports: view Runs, investigation, Results and reports; start profile scans; pause, resume and finalize Runs.
- Findings: view verified Findings.
- Hermes Chat: view conversations and continue scans through Hermes when that work is part of the role.
- Chat Templates and Health: grant read access when needed for preparation or operational checks.
Archive/restore permissions can be assigned separately. Assistant access is also a separate choice and requires an enabled instance policy and a configured provider/model. Granting Assistant does not grant Hermes or scan access.
For a reviewer, select Viewer and grant the relevant read permissions: Targets/Scopes, Runs/Results/reports, and Findings form a useful review set. Hermes history, Chat Templates, and Health can be added when required. A read permission does not authorize starting work or changing assessment settings.
The expandable Framework permissions and Framework Project access controls relate to shared framework features. They are not substitutes for Hunt Web scan permissions and do not define the domains or paths in a Run's testing Scope.
4. Complete Password and Authenticator Setup
Open the account menu, then Security / Sessions under Profile. An account with an initial password must change it. An Admin accessing through a domain must also enroll an authenticator before using the main workspace features. Hunt Web directs unfinished onboarding to these controls.
Select Set up authenticator, add the supplied setup key to a compatible authenticator app, and verify its current six-digit code. Save the recovery codes privately when shown. After required setup completes, Go to Dashboard returns to the workspace.
- 1Open Security / SessionsAccount menu, then Profile.
- 2Change the initial passwordRequired if the account has an initial password.
- 3Set up the authenticatorAdd the supplied setup key to an authenticator app.
- 4Verify the six-digit codeEnter the app's current code.
- 5Save the recovery codesKeep them private.
- 6Go to DashboardReturns to the workspace once setup is complete.
Authenticator codes are generated by the enrolled app; Hunt Web does not email them. A saved recovery code is a single-use alternative when the authenticator is unavailable. Recovery codes are not intended to replace the app for routine sign-in.
The domain-Admin enrollment requirement does not automatically impose the same rule on Operator, Viewer, or loopback Admin access. Any account that has already enabled MFA still follows its authenticator sign-in flow. Password recovery does not remove MFA.
5. Review the Impact Before Changing a Role
Role changes apply to subsequent authorized requests. The confirmation dialog explains their consequences:
- Changing to Viewer removes all additional permissions, including read grants. Reassign the read permissions needed for review. Existing framework Project access becomes read-only.
- Changing from Admin removes built-in Admin access. Review the remaining feature grants before expecting the account to perform assessment work.
- Other role changes retain existing additional grants; review them against the new responsibilities.
The last active Admin is protected
At least one active Admin must remain. Hunt Web prevents disabling or demoting the last active Admin. Role changes affect Dashboard access, not the saved identity of Greybox target accounts.
6. Disable and Reenable Accounts Deliberately
Select Disable account and confirm to make an account inactive. This revokes its sessions, additional permissions, and framework Project access. The account can no longer sign in or continue making authorized requests.
Reenabling does not restore grants
Enable account reactivates it but does not restore the removed grants or Project access. Review and reassign the required permissions. Built-in access associated with its current role remains distinct from those removed grants.
Disabling a person is an account-access action, not a substitute for managing running assessments. Use the appropriate Run controls when scan work must also stop. Administrative changes can be reviewed through Settings → Security Audit.
7. Diagnose Missing Access
| Situation | What to check |
|---|---|
| An Admin is directed to Security / Sessions | Complete the required initial password change or authenticator enrollment. |
| An Operator can sign in but cannot start scanning | Review Target/Scope, Run read, and Start permissions; then check Scope, account access, model readiness, and Run state. |
| A Viewer cannot send a Hermes message | Expected read-only behavior. Assign an appropriate role and permissions if execution is required. |
| Assistant is unavailable to an Admin | Check the separate Assistant grant, instance policy, and provider/model configuration. |
| Access disappears after a role change or account reactivation | Review effective permissions; some changes deliberately remove grants. |
| Test Authentication cannot confirm a Greybox account | Inspect the target's session and authentication result. Dashboard role assignment does not establish target login. |
Use the Dashboard Menu Guide for navigation, the scanning workflow for Target and Run setup, and the FAQ and Updates & backup pages for account recovery and installation maintenance.