Customer responsibilities

Before customer-controlled actions

Use this page before scans, report sharing, ticket exports, connected provider access, repository indexing, patch drafts, pull requests or retests proceed. WebRiskOps can automate product workflows only after the customer has confirmed authorization, scope and approvals for the selected account and project.

• Confirm authorization before scanning
• Check `authorization_status`, `ownership_proof_status`, `accepted_scope_status`, `provider_access_status` and `remediation_approval_status`.
• Keep customer decisions tied to the account, project, client workspace, provider subject and accepted scope that owns the workflow.
• Stop when `CUSTOMER_RESPONSIBILITY_REQUIRED`, `AUTHORIZATION_REQUIRED`, `PROVIDER_ACCESS_REQUIRED` or `REMEDIATION_APPROVAL_REQUIRED` applies.

Confirm responsibility before work starts

Follow the path `Project → Shortest path to first useful report → Domain authorization → Accepted scope → Provider access or report action → Approval or revoke`.

1. Open `/projects/{project}` and review Shortest path to first useful report plus Prove this is your domain before starting a scan. Result: the customer sees which domain or target they are claiming authority to test.
2. Check `authorization_status` and `ownership_proof_status`, then use Create challenge or Check verification when the project requires ownership proof. Result: scans do not start when authorization is missing, disputed or tied to a different account.
3. Accept scope only after public URLs, manual URLs and excluded paths are correct. Result: `accepted_scope_status` reflects the customer-approved pages that WebRiskOps can test.
4. Exclude unsupported, private, personal-data, third-party or client-mismatched paths before running or retesting. Result: customer responsibility is recorded before evidence is created.
5. Before connecting Jira, GitHub, GitLab, CMS, Shopify, GTM, CMP or webhook targets, compare `provider_access_status` and `approved_scope`. Result: connected actions use only provider accounts the customer is allowed to manage.
6. Before a patch draft, pull request or provider task is created, check `remediation_approval_status`. Result: WebRiskOps does not treat generated recommendations as customer-approved changes.
7. Review evidence, severity, confidence and boundary wording before sharing a report, PDF, ticket export or procurement pack. Result: customer-facing output is accepted as technical evidence, not a decision made by WebRiskOps.
8. Revoke provider access when the workflow is complete, unsafe, no longer approved or no longer needed. Result: `revoked_at` records that connected actions should stop.
9. For agency work, confirm the agency client account and project match the authorized customer. Result: provider access, reports and evidence do not cross client workspaces.
10. Continue to the specific workflow page only after the responsibility state is ready. Result: scans, exports, connected access and remediation proceed with a clear customer-controlled boundary.

Customer decisions before scanning

Customers control whether the target can be scanned and what public scope is accepted.

• Confirm domain, site or app authority through ownership proof before live audits.
• Accept only public customer-authorized pages and keep unsupported paths excluded.
• Keep plan, credit and scan-limit choices aligned with the selected project.
• Review discovered pages and manual URLs before running or retesting.
• Stop when authorization, scope or customer account ownership is unclear.

Customer decisions before provider access

Customers also control provider and remediation access decisions.

• Connect only provider accounts, repositories, shops, workspaces and webhook endpoints the customer is allowed to manage.
• Use least-privilege provider scopes and record `approved_scope` before connected actions run.
• Approve remediation, patch, pull request or ticket creation only after reviewing evidence and expected changes.
• Revoke access with a reason when connected work is complete, unsafe or no longer approved.
• Retest after production changes to verify current behavior before publishing new evidence.

Ready and blocked responsibility states

Use these states before allowing a workflow to continue.

• Authorization ready means `authorization_status` and `ownership_proof_status` confirm the customer can test the selected target.
• Scope accepted means `accepted_scope_status` is ready and the customer-approved URLs match the scan or retest.
• Provider access ready means `provider_access_status` and `approved_scope` match the provider action being requested.
• Approval required means `REMEDIATION_APPROVAL_REQUIRED` or `remediation_approval_status` blocks generated changes until the customer approves them.
• Responsibility blocked means `CUSTOMER_RESPONSIBILITY_REQUIRED`, `AUTHORIZATION_REQUIRED` or `PROVIDER_ACCESS_REQUIRED` prevents scan, export, provider or remediation work from proceeding.

Continue after responsibilities are confirmed

When responsibility states are ready, continue to Ownership proof, Accepted scan scope, Access modes and required scopes or Customer approval and PR creation. Use Revoke and no-secret boundaries when access should end, and Non-certification and legal boundaries before report output is shared externally.