What WebRiskOps does not automatically change
Use automation boundaries to know when WebRiskOps drafts, requests approval, waits for customer evidence, retests or stops instead of changing systems automatically.
Business owners, developers, agencies and reviewers
Feature availability
Product, package, provider and deployment boundaries for this page.
- Available from
- Current documentation
- Providers
- githubwordpresswoocommerceshopifygtmcmp
- Deployment modes
- cloudself-hosted
Before relying on automation
Use this page before telling a customer, agency client, reviewer or developer that WebRiskOps changed a live system. Automation boundaries separate generated guidance, review-only drafts, connected access requests, customer-applied evidence and retest results. WebRiskOps can generate remediation guidance, prepare a patch draft, request scoped access, export a ticket, record customer evidence and run verification. It must not be described as having changed a site, repository, CMS, GTM container or CMP until the workflow records the approved action and verification state.
Check the automation boundary
Follow the path `Report finding → Fix task → Delivery mode → Customer approval or evidence → Retest result`.
- Open /reports/{report} or /fix-tasks/{fixTask} before telling anyone the issue is fixed. Result: source finding, delivery mode, evidence and current status are visible.
- Read the delivery mode: ticket-only, customer-applied evidence, review-only patch or connected access. Result: you know whether WebRiskOps is generating guidance, waiting for evidence, drafting a change or requesting approval.
- Confirm connected access, customer approval, applied evidence or retest result exists before describing any change as completed. Result: work status is based on recorded workflow state.
- Do not claim WebRiskOps has changed a site, repository, CMS, GTM container or CMP until the owning workflow records connected access, customer approval, applied evidence or a retest result. Result: external communication stays tied to recorded product evidence.
- Keep review-only patches, drafts and recommendations in review until the customer approves or applies them. Result: generated guidance is not mistaken for an automatic live change.
- Use retest evidence before marking work fixed or resolved. Result: resolved status depends on verification rather than intent, draft text or ticket creation.
Boundary states
Use the recorded state to describe what happened.
- Guidance generated means WebRiskOps created remediation instructions, not a live change.
- Ticket-only handoff means the customer or external team owns implementation.
- Review-only patch means a draft exists but still needs customer approval or application.
- Connected action approved means provider, scope, approver and task are recorded before action.
- Retest verified means evidence supports fixed, failed or inconclusive status.
Blocked or unsafe states
Stop when the boundary state is not clear.
- No approval means do not create PRs, publish changes or describe a draft as applied.
- Unsafe provider scope means use safe fallback paths or ticket-only fallback.
- Missing customer evidence means wait for customer-applied evidence before retesting.
- Missing retest means do not mark the work fixed.
- Legal boundary unclear means keep report wording technical and avoid certification or guarantee claims.
Continue safely
Continue with the related Connected access requirements page when scoped provider access is needed. Use the related Customer-applied evidence and Retests and monitoring conversion pages before saying a change is verified.
Related documentation
Was this page helpful?
Feedback goes into the product documentation review queue.

