> For the complete documentation index, see [llms.txt](https://copilot-docs.bugbase.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://copilot-docs.bugbase.ai/enterprise/enterprise-onboarding-checklist.md).

# Before Your First Run

Access, roles, scope, and approvals to set up before your first run.

Work through this page once, before your first run. It takes about 15 minutes for a Web assessment.

## Access and Roles

{% stepper %}
{% step %}

### Sign in

Open the deployment URL that Bugbase sent you and sign in with the account set up during onboarding, or through your company's single sign-on if it is connected.
{% endstep %}

{% step %}

### Invite your team

An admin opens **Settings -> Users**, selects **Invite User**, and gives each person one role. New users default to **Operator**.

| Role         | Can do                                                                                                                                | Cannot do                                                             |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| **Admin**    | Everything, including inviting users, changing roles, scheduling runs, changing **Settings**, creating API keys, and stopping agents. | –                                                                     |
| **Operator** | Add targets, record browser sessions, start Web and Network runs, cancel and retest, triage findings, and generate reports.           | Schedule runs, change **Settings**, create API keys, or manage users. |
| **Viewer**   | Read dashboards, findings, attack paths, the Exploit Graph, and reports.                                                              | Start runs or change anything.                                        |

Give **Admin** to the people who own the platform, **Operator** to the people who run assessments, and **Viewer** to stakeholders who only read results.
{% endstep %}

{% step %}

### Check your usage

Open **Settings -> Usage** and confirm the workspace has credits or scan hours available. Runs are blocked when usage runs out.
{% endstep %}

{% step %}

### Get approval for active testing

A **Discovery + Assessment** run maps the target and then sends attack traffic to it. Get written approval for the targets, the test window, and the attack vectors or exploit families before your first run. If only mapping is approved for now, use the **Discovery** intent until testing is approved.
{% endstep %}
{% endstepper %}

## Web Assessment

| Item                                                                                   | Where                                             |
| -------------------------------------------------------------------------------------- | ------------------------------------------------- |
| Approved root domains, such as `example.com`. Subdomains are found automatically.      | **Attack Surface -> Target Entities**             |
| Domains whitelisted, and third-party domains blacklisted                               | **Settings -> Domains**                           |
| Ownership verified, when your deployment requires it                                   | **Settings -> Domain Verification**               |
| Third-party APIs kept out of testing                                                   | **Settings -> Trajectories**                      |
| One recorded and validated browser session per role you want to test                   | **Run Assessment -> Scope -> Record new session** |
| Test inboxes for OTP, magic-link, or sign-up flows                                     | **Settings -> Email Identities**                  |
| A rate limit the target can absorb, and the scanner IPs allowed on its WAF or firewall | **Run Assessment -> Scan settings**               |

## Network Assessment

* Choose the network segment for the agent and confirm it can route to the approved subnets.
* Confirm endpoint protection, EDR, firewall, and proxy rules for the agent host.
* Agree which exploit families are allowed, especially AD writes, ADCS abuse, RCE, credential dumping, relay, and data copying. See [Network Assessment Destructive Actions](/enterprise/how-to-trigger-a-network-assessment/network-assessment-destructive-actions.md).
* Agree who cleans up AD and ADCS changes, host changes, and copied files, and who rotates credentials.
* Decide whether PCE Intercept/Inveigh may run, and on which interfaces.

## Cloud Assessment

* Use a dedicated EC2, Azure VM, or Compute Engine host inside the approved scope.
* Attach a dedicated cloud identity with discovery (read) access first. Add active permissions only after scope and cleanup review.
* Confirm provider audit logging and who owns rollback and credential rotation.

See [Cloud Assessment](/enterprise/how-to-trigger-a-cloud-assessment.md).

## Your First Run

For a web application, start with one root domain and the **Discovery + Assessment** intent. It maps the application and tests it in a single run. Follow [Your First Web Run](/enterprise/how-to-trigger-a-web-assessment.md#your-first-web-run).

For a network, start with **Discovery** on one small subnet, review what it found with the system owner, then run **Assessment** with a narrow set of exploit families. See [Network Assessment](/enterprise/how-to-trigger-a-network-assessment.md).

Review the results in **Attack Paths** with stakeholders, then generate reports. See [Analysing Scan Results](/enterprise/analysing-scan-results.md).