Webscan Documentation
Lesson 20 · Environments, blast radius & production safety
Phase 5 · Delivery & governance — Lesson 20 of 21 · All lessons
Objective: pull together every safety concept in webscan into one clear picture, so you know exactly what is and isn't safe to run against a live website — and why.
Before you start: you'll get the most from this if you've met scans, exploration (Lesson 12), and journeys (Lesson 13); this lesson connects them.
The core worry
Most webscan features drive a real browser against your site. Reading a page is harmless. But acting — clicking, typing, submitting — can change real data: create accounts, place orders, delete records. On a test site that's fine. On your live production site with real users, it's not. This lesson is about the system that keeps that from happening.
Two definitions that tie it together
- Environment — the label you gave a website (Lesson 3): Development / test, Staging, or Production. It declares how real and fragile the site is.
- Blast radius — how much damage an action could do if it goes wrong. Webscan's guiding principle is to keep the blast radius tiny on production and let you be bold on throwaway environments.
The environment sets the blast radius, and the blast radius decides what each feature is allowed to do.
What's safe on production — feature by feature
Here's the whole picture in one place. "Production" below means a website you've marked as such.
| Feature | On production | Why |
|---|---|---|
| Standard scan | ✅ Safe | It only reads and renders pages — no data-changing actions. |
| Authenticated scan | ✅ Safe | Same as a scan, just logged in via a profile (Lesson 11). |
| Agentic exploration — Read-only | ✅ Safe | Navigate/click/scan only; typing and every non-GET request are blocked at the network layer. |
| Agentic exploration — Full actions | ⛔ Non-production only | It can submit forms and change data. Allowed only on dev/staging (a guarded acknowledgement exists, but the safe default is: don't). |
| Journey — safe steps | ✅ Safe | Navigating and scanning don't change anything. |
| Journey — restricted/destructive steps | ⛔ Blocked on production | Restricted actions can't be enabled on a production website at all — a hard rule. |
| Recorded session | ✅ You drive it | You're the human doing real actions; sensitive input is redacted in your browser (Lesson 15). |
| AI code fixes | ✅ Safe to your site | Fixes are verified in a sandbox and land as a pull request — never written to your live code directly (Lesson 9). |
The pattern: anything that only reads is safe anywhere; anything that can change data is restricted to non-production, and where an exception is technically possible it's gated behind an explicit acknowledgement.
The extra guardrails, always on
Even when actions are allowed (on dev/staging, or full-action exploration), webscan keeps two hard limits:
- A destructive-action denylist — it won't do things that look irreversible (deleting, purging), even if asked.
- A credential/payment block — it won't enter passwords, card numbers, or other sensitive credentials into forms.
These exist so that "full actions" still can't do the truly dangerous things.
Sandbox verification (Tier A and Tier B)
Sandbox — an isolated, throwaway environment where webscan can test a candidate code fix without touching your real site or codebase (Lesson 9). There are two levels:
- Tier A — renders a fixed page and re-checks the finding before proposing a pull request. This is the "Auto-fix in sandbox" you used in Phase 2.
- Tier B — Sandbox build verification — a deeper, opt-in level that can build a framework project to verify a fix. Because building runs untrusted code, it's off by default and lives behind an organisation setting. On the organisation's Sandbox build verification page an owner/admin can Save preference to opt in (it also requires a paid plan and the platform-side backend to be configured).
You don't need Tier B for everyday use; Tier A already verifies fixes safely.
A simple rule to remember
Read anywhere. Act only on dev/staging. Let humans approve anything that reaches production or your codebase.
If you internalise that one line, you'll use every webscan feature safely.
Tips & pitfalls
- Label environments honestly. Marking a live site "development" to unlock full actions removes the very protection that keeps your users safe. The label is a safety control, not a formality.
- Prefer staging for action-based testing. Full-action exploration and restricted journeys belong there.
- A "blocked" result is success, not an error. Blocked by safety / Blocked by safe mode means a guardrail stopped a risky action exactly as designed.
- You never have to trust automation blindly — sandbox verification and human-approved pull requests mean fixes are checked before they land.
Recap
- Environment (dev/staging/production) sets the blast radius, which decides what each feature may do.
- Reading is safe everywhere; data-changing actions are non-production only, with exceptions gated behind explicit acknowledgement.
- A destructive-action denylist and credential/payment block apply even when actions are allowed.
- Sandbox verification (Tier A always; Tier B opt-in) and human-approved pull requests keep fixes from ever touching production unchecked.
Try it yourself
Look at each website you've created and check its environment is labelled correctly. For any production site, confirm your habits match the rule above: scans and read-only exploration are fine; save full actions and restricted journeys for staging.
Previous: ← Lesson 19 · Reports & branding Next: Lesson 21 · Team, roles & governance →