Every customer scan must be authorized, scoped and limited before crawler, scanner, report, fix, retest or monitoring work starts.
Authorization questions should start from project scope, target ownership, include/exclude boundaries, private path rules and accepted access mode.
Unsupported or unsafe scope is not bypassed by support, billing state, monitoring, fix credits or customer urgency.
The customer must own the target or have explicit permission for the domain, client site or commercial journey.
Public/private paths, crawl depth, modules and rate limits should be visible before scanner work starts.
Code, CMS, tag or platform access is requested only for remediation workflows that need it.
The user must have the right to scan the domain, storefront, application, or account they add to the product.
Allowed targets include customer-owned public websites, authorized client properties and specific commercial journeys where the customer can confirm permission.
Forbidden scope includes unrelated third-party sites, admin/private systems without authorization, credential-protected areas without accepted access and targets that invite unsafe testing.
Scan setup must define public and private paths, include/exclude boundaries, crawl depth, module selection, rate limits and expected runtime before work starts.
Unsupported scope should block scanner execution, explain the reason, keep an audit trail, and show a revised-scope step or support-form option.
Recurring monitoring requires ongoing authority to check the target and clear customer ownership of alert routing and scan cadence.
Code, CMS, GTM, CMP, or platform access is requested only when a customer chooses a remediation workflow that needs it.