Targets, ownership and testing scope

Only assess systems you own or have explicit permission to test. A public website or an available login is not testing authorisation. Record the responsible owner and agreed scope.

Follow the target-verification challenge displayed for the target. Do not reuse a token from another environment.

The target model supports allowedPathPrefixes, excludedPathPrefixes, maxRequestsPerMinute and maxConcurrency. Record these alongside the hostname, environment and window.

The current target route normalises omitted limits to 60 requests per minute and concurrency to 2. These are onboarding defaults, not guarantees of service safety. Confirm effective limits for the selected assessment.

Each native assessment runs under a fixed scope grant: the tenant, the permitted hosts and paths, active or passive permission, the testing window and an expiry. Every request is checked against that grant, including each redirect hop and the address the hostname resolves to. A request outside the grant is refused and reported as a limitation, not silently skipped.

Requests to one target share a single budget across every module and concurrent assessment. A rate-limit answer or a recognised web-application-firewall challenge pauses all work against that target. A revoked grant stops new requests and further retries. A refused or budget-stopped check is reported as incomplete coverage, never as “no findings”.

Hosted MCP scanning requires an onboarded target owned by the caller and pins an endpoint to that target’s host. Disallowed hosts are rejected; local stdio inspection is a separate CLI workflow.

Agree stop conditions: elevated errors, unexpected writes, service degradation or uncertain authority. Stopping execution cannot necessarily undo an external action already completed.