Safety boundaries

Confirm project authorization before each network assessment. Workbench checks the project's current authorization and scope before a run can start, but the operator remains responsible for keeping that authorization accurate.

#Keep targets inside project authorization

Review the exact target, approved identities, included scope, and exclusions in Workbench. Authorization for one application does not automatically cover its other subdomains, identity providers, payment services, CDN origins, customer integrations, or newly discovered links. Add a related host only after its owner has approved testing and the project scope has been updated.

For source-only work, select an approved repository revision. A source repository connection does not authorize a network assessment.

#Metadata and link-local destinations

Workbench rejects metadata and link-local target address classes. This control does not expand authorization or provide a network-wide assessment.

#Review evidence drift

Evidence drift signals that stored evidence may no longer match the current finding context. Reopen the related HTTP Record or OAST callback and revalidate it against the authorized target before changing the finding's status. The signal does not confirm or dismiss a finding by itself.

#Production assessments

Prefer staging. Run against production only when it is explicitly authorized. Keep scope narrow, exclude destructive workflows, stay within the approved change window, monitor the target, and keep an operator in Workbench who can stop the run.

#Related guides

• Projects and scans
• Authenticated testing
• Findings and evidence