Scanning Authorization

By configuring a target, the customer represents that they own or are authorized to test the target, related credentials, connected systems, and data flows.

For production, active, invasive, authenticated, browser, RAG, agent, or tool-use scans, customers must confirm scope and authorization before dispatch.

When a customer starts TXT domain verification, the customer confirms that the workspace owns, controls, or has written authorization to test the domain and covered subdomains.

Domain verification is required for stronger workflows where implemented. It is an operational control and an audit signal, not a substitute for accurate customer scope decisions.

Unless a signed ROE says otherwise, customer scans must stay within the configured target, environment, scan profile, rate limits, request budgets, token budgets, credential scope, and production confirmation settings.

Forbidden activity includes denial-of-service testing, social engineering, phishing, malware, credential stuffing, destructive testing, third-party assets outside scope, and attempts to access or retain data not needed to validate a finding.

Riskier scan workflows should require an affirmative confirmation before dispatch. The confirmation should state that the customer owns or is authorized to test the target, credentials, connected systems, downstream tools, documents, accounts, and data flows, and understands that scans may generate traffic, logs, alerts, synthetic sessions, and evidence artifacts.

Authorization records should include user, workspace, target, scan where available, authorization text version, scan profile, production-mode flag, active/authenticated/browser/RAG/tool-use flags, timestamp, and request metadata such as IP address or user agent where available.

Scans may generate logs, alerts, rate-limit events, synthetic sessions, test documents, or security findings in customer systems.

Customers are expected to use staging or preview environments for first runs and configure request budgets, token budgets, and rate limits appropriate for the target.

Customers can disable scheduled scans, disable targets, revoke API keys, or contact the published support/security channel to request scan suspension. ShakerScan may also stop or rate-limit scan paths if abuse, production impact, or out-of-scope behavior is suspected.

For paid pilots and enterprise scans, the order form or ROE names the emergency contact, approved scan window, source infrastructure, maximum scan rate, and stop procedure.

ShakerScan collects limited evidence needed to explain findings, policy decisions, attestations, and approval records. Evidence can include redacted transcripts, headers, URLs, screenshots, request/response metadata, detector output, and artifact hashes.

Customers must not use production secrets or privileged accounts unless the scan requires them and the customer has approved the risk. Test accounts and least-privilege credentials are preferred.