Automations
An automation does something when something happens: run a plan on every new version, re-test an application when a guardrail policy starts catching more harmful traffic, or alert the team when a run's attack success rate is too high. Each automation has one trigger (When), one or more actions (Do) and a few settings.
Open it from the sidebar: Automations, right under Application Inventory. The page is available when Automations is enabled for your project. Automations can also be added from an assessment plan's page, already set to run that plan.
Note: automations are saved and checked for you today, but not executed yet. Nothing runs and nothing is sent until automations are switched on for WonderSuite. The page shows this as a banner.
You can:
- See every automation with when it fires, what it does, its application, when it last fired, and whether it is enabled.
- Create one with New Automation, a three-step wizard: When, Do, Settings.
- Enable or disable one with its toggle.
- Edit or Delete one from its row menu.
When (the trigger):
| Trigger | Fires when |
|---|---|
| On a schedule | Daily, weekly (on a day of the week) or monthly (on a day from the 1st to the 28th), at a UTC time. The wizard previews the next run times. |
| Guardrail spike | A WonderFence policy on an application catches more harmful traffic than usual. Details below. |
| Version added | A new version of an application is added, from the UI or the public API. Pair it with Run a plan on the new version to test every release without a CI pipeline. |
| Assessment completed | A run of a plan finishes. Set Only when ASR is above to fire only for runs over that attack success rate. |
For a Guardrail spike, choose the application, then:
- Watch every guardrail policy (including ones added later), or choose policies. A spike in any one of them fires the automation.
- Count harmful responses or prompts. Responses mean the application is answering harmfully, that is, failing. Prompts mean harmful requests are reaching it: an attack wave, or benign traffic being over-blocked, which is a reason to run an Over-Refusal assessment.
- Fire when a policy's:
- Incident count reaches a number within 1 hour, 6 hours, 24 hours or 7 days.
- Incident increase grows by a percentage compared with the window before it.
- Violation rate (the share of all messages that were harmful) reaches a percentage, yesterday or over the last 7 days (whole UTC days).
- Rate increase grows by a percentage compared with the period before it, whatever the traffic (whole UTC days).
- At least sets a minimum number of incidents in every mode, so a quiet policy going from 1 to 2 is not treated as a spike.
Do (the actions):
Add one or more actions with Add an action. They run together, in order.
| Action | What it does |
|---|---|
| Run a plan | Runs a plan on a fixed existing version, or, with a Version added trigger, on the new version. Prompts per policy defaults to 25, up to 500. |
| Assess policies | Runs an assessment on an application and version: either the matching policy (the assessment policy that red-teams the guardrail policy that spiked, only with a Guardrail spike trigger) or policies you choose. Up to 500 prompts per policy. |
| Send an email | Emails up to 20 addresses, separated by commas. |
| Post to Slack | Posts to a channel in your workspace's Slack integration. |
| Call a webhook | Sends a JSON POST to an https URL. No authentication header is sent yet. |
An automation never creates a version, and it acts on one application only.
Settings:
| Field | Description |
|---|---|
| Name | Shown on the Automations page, and as the creator of anything the automation starts. |
| Description | Optional notes. |
| Cooldown | After firing, the automation waits this long before it can fire again: 1 hour to 30 days. Not offered for schedules. A Version added automation can choose None to test every version. |
| Enabled | Only enabled automations fire. |
Before you save, This automation shows the whole automation as one sentence.