Assessment Plans
An assessment plan is a saved assessment configuration — an application, a set of policies, and a few run settings — that you can run again and again. Each run is an ordinary assessment: it appears on the Assessments page and has its own report, and it stays linked to the plan that started it. A plan never fixes a version; you choose an existing version every time you run it, which makes plans the way to re-test the same configuration against each new release, or from a CI pipeline.
Open it from the sidebar: WonderBuild → Assessment Plans. The page is available when Assessment Plans is enabled for your project.
You can:
- See every plan with its application, policies, last run and number of runs. Click a plan to open it.
- Create a plan with New Plan, a two-step wizard. Plan holds the fields below. After saving, Automate offers the ways to keep it running: Run now, Set up in CI, and, when Automations are enabled, On every new version, Schedule it and Re-test on a guardrail spike. Each opens its flow already filled in with the plan, and everything there is also on the plan's page. You can also save an existing assessment as one with Save as Plan on the Assessments page.
- Run now — pick one of the application's existing versions and start a run. A run never creates a version; to test a new build, create its version in Application Inventory first.
- Set up in CI — generate a GitHub Actions workflow that runs the plan (see below).
- Add automation to run the plan on a schedule, on every new version, after a guardrail spike, or after another run. See Automations.
- Edit a plan. Existing runs keep the configuration they ran with.
- Delete a plan. Its runs are kept and stay on the Assessments page. Automations that run it are switched off, not deleted. Archiving or deleting a run never changes the plan itself, but an archived run is hidden from the plan's runs, its run count and its last run.
Plan fields:
| Field | Description |
|---|---|
| Plan Name | Name of the plan. Each run is named after it, followed by the time it started. |
| Description | Optional free text. |
| Application | The application every run assesses. It is fixed once the plan is created, so all of a plan's runs are comparable. |
| Policies | The policies every run tests. |
| Reuse prompts from the previous run | When on, a run replays the prompts of the plan's latest completed run instead of generating new ones, so versions are compared on identical attacks. Editing the plan starts fresh with new prompts. |
A plan's page shows its configuration, an Automation section (its CI pipeline, and, when Automations are enabled, every automation that runs the plan), and its Runs — each with its status, attack success rate (ASR), version, what started it (UI or API), and when. Click a completed run to open its report.
Set up in CI:
The wizard produces a ready-to-commit GitHub Actions workflow in three steps:
- Version — choose the existing version the pipeline assesses.
- When to fail — fail the job if the attack success rate is above a percentage you set, how often to check on the run, and how long to wait before failing it.
- Workflow — copy or download the file, save it under
.github/workflows/in your repository, and add an Alice API key as the repository secretALICE_API_KEY. The workflow never contains the key itself.
Run the workflow from your repository's Actions tab. It starts a run of the plan, waits for it to finish, and fails the job if the run fails or its attack success rate is above your threshold, with a link to the report in the job summary. Plans can also be created and run directly through the public API.