CyberBot

Define the target and authority

Use CyberBot only for systems you own or are authorized to test. Give the exact website, API, or controlled test environment and describe the purpose of the investigation.

• List the permitted hosts, endpoints, and accounts.
• Identify excluded paths, systems, data, and actions.
• State any operational limits, test window, or requirement to avoid destructive activity.
• Provide test credentials only through the appropriate secure connection flow, not in public reports.

A link, redirect, related company, or discovered host does not add that system to the authorized scope. Update the scope explicitly before testing a different target.

Prepare the environment and follow progress

Open the CyberBot environment manager when preparation is required. On Windows, CyberBot runs in its managed Linux environment through WSL. The desktop manager owns this environment; the runtime is separate from your project files and other WSL distributions.

The manager reports compatibility checks, storage requirements, the selected location, and preparation stages: download, verification, import, installation, and health check. Byte progress applies to stages that have a measured byte total; a health check is a separate stage.

1. Prepare the environment and wait until its health check succeeds.
2. Use Cancel preparation to stop active preparation; closing a dialog is a different action.
3. Use Repair when the manager reports that the environment needs repair.
4. Use Restore previous environment when a healthy previous copy is available.
5. Use Remove environment to remove the managed CyberBot runtime. Keep your reports and project backups separately.

Choose a model and supported effort, then start the investigation within the approved target scope. Review tool activity and evidence as the task runs. The container image is a packaging format; the Windows runtime uses the managed WSL environment.

Scan depth and Ultra

Permissions and scope

Separate a finding, a fix, and a retest

Review a finding’s evidence before acting on it. A repair changes the relevant code or configuration and requires its own file and action authority. The scan’s target permission is not blanket permission to edit or deploy a service.

1. Read the original reproduction conditions and impact.
2. Authorize the repair scope and inspect the proposed change.
3. Review the diff and validation results.
4. Run a retest against the same authorized target and original failure condition.
5. Compare the new evidence with the original finding.

A code change alone does not establish that the live target is fixed. Record which version and environment were retested.

Keep evidence and limits with the report

Keep the report, target scope, findings, reproduction details, and relevant artifacts together. Remove credentials, access tokens, and unrelated personal data before sharing a report.

A clean run means that the checks performed did not establish a finding. It is not proof that the target has no vulnerabilities. If a check failed, was blocked, or was not performed, retain that limitation in the result.

CyberBot is included in Security, Pro, and Max. Its task and managed-agent work uses the selected workspace’s shared allowance.

Files and findings

CyberBot plan availability

• Previous BugBot
• Next Search & sources