Configure Auto-pentest

Confirm authorization

Enable Auto-pentest only when you own the target or have written authorization to test it. The target must be the exact linked website selected for the job.

Auto-pentest sends active requests. Testing may create traffic, logs, temporary application effects, or third-party alerts.

Review the target

Before consent, verify the scheme, hostname, and environment. Do not assume that authorization for one host covers another subdomain, tenant, or third-party service.

The scheduled task must contain exactly one target in its Linked websites context. A redirect to an unrelated host does not extend scope. Historical reports, issues, or comments do not grant current consent.

Enable testing

1. Link the exact website to the Guard project.
2. Open Auto-pentest settings.
3. Review the active-testing notice and retention terms.
4. Confirm that you are authorized to test the target.
5. Choose the available issue or safe-fix behavior.
6. Start or schedule the job.

Understand the testing boundary

Guard can send active, target-specific requests and combine the observations with repository evidence. It must not perform denial of service, load testing, resource exhaustion, spam, persistence, lateral movement, credential theft, social engineering, destructive data changes, or real-user-data exfiltration. It uses the least invasive proof that can establish a finding and stops short of a test that could disrupt availability.

Testing stays on the exact authorized target. Missing or ambiguous target context produces a no-active-test outcome.

Choose the provider outcome

• Issue mode creates, reuses, or comments on one primary-risk issue and opens no review request.
• Safe-fix mode can also open one linked PR/MR for a small defensive change with credible repository verification.

The highest-risk finding and the safest autonomous fix can be different. All confirmed findings remain visible in the report even when only one receives provider action. Guard never merges the proposed fix.

Verify the result

Read the exact target, repository revision, confirmed findings, limitations, provider links, and any no-PR reason. If a fix is merged, rerun the relevant repository security audit. Repeat active testing only while authorization is still valid and the linked target is unchanged.

Read the outcome

A run can report a confirmed vulnerability, create or reuse an issue, optionally prepare one bounded safe fix, or finish with no confirmed finding.

No confirmed vulnerability is a valid result. It is not a guarantee that the application contains no vulnerabilities.

Disable or change the target

Disable the schedule before changing environments or transferring ownership. Review authorization again whenever the exact target changes.

For the external-state boundary, see Provider and write matrix.