Pentestas / help

Hard-refusal policy

Pentestas refuses categories of activity that fall outside the scope of authorised security testing. The refusals are categorical — no engagement scope, no operator flag, and no customer authorisation can override them. Each refusal is enforced at the platform tier (the request is rejected before any byte reaches the network) and logged to the audit trail with the refusal category.

The five categorical refusals are:

1. Mass internet scan

Pentestas refuses to scan targets outside an engagement's declared scope. Sweeping internet-wide ranges (CIDR /8 or similar) is not part of our threat model and is rejected at the API tier — even when the operator pastes the range. Ranges > 1024 hosts require an engagement whose scope covers the CIDR.

2. Persistent backdoor

Pentestas refuses payloads whose purpose is to survive engagement closure: SSH key drop into authorized_keys, cron line install, systemd unit creation, Windows scheduled task creation, registry Run-key writes, web-shell drop into a writable webroot path. We prove exploitability with a non-persistent PoC and stop.

3. Safety of life

Pentestas refuses any probe against medical devices, ICS/SCADA controlling life-support, drug-dosing infrastructure, or autonomous vehicle safety systems. Targets matching known hostname shapes are refused regardless of scope declaration; a separate safety-officer review process exists outside the platform for engagements that genuinely need it.

4. Payment bypass

Pentestas refuses payloads whose purpose is to transfer funds or grant unpaid commercial value (zero-amount checkout, coupon enumeration that completes the purchase, unauthorised balance writes). Vulnerability demonstration on staging endpoints stops at the bug — we do not move money to prove it. The customer's auth model is tested via balance reads, not balance writes.

5. Mass volumetric DoS

Pentestas refuses request rates and connection counts shaped to exhaust customer capacity. Stress testing is a separate engagement class run with the customer's load-testing program; it is not a side effect of vulnerability assessment.

Why this matters commercially

Some pentest tools sell themselves on capabilities like "persistent foothold establishment" or "lateral movement automation". Pentestas does not. The line is the line between a commercial SaaS pentest product and an operator framework you self-host because no SaaS vendor would touch what you want to do. We sit firmly on the SaaS side of that line.

Some of these refusals (volumetric DoS, mass internet scan) are also legal liability — distributing them as a hosted service would make Pentestas a co-defendant when a customer misuses the platform. The categorical refusals protect customers, third parties, and the business.

What this means for you

  • You will never see Pentestas drop an SSH key into authorized_keys to prove RCE — we prove RCE with a one-shot command and stop.
  • You will never see a Pentestas scan target a /16 internet range — engagement scope is enforced before dispatch.
  • You will never see a Pentestas scan complete a checkout for $0 to prove price tampering — we demonstrate the field is mutable and stop.
  • You will never see Pentestas DDoS your application to find a rate-limit gap.

Enforcement

The refusal list is enforced at three layers:

  1. API tier — scan-create returns HTTP 451 Unavailable For Legal Reasons on a categorical refusal.
  2. HTTP client tier — every outbound request goes through core/payload_safety.py, which inspects URL, body, params, JSON, and headers against destructive + persistence + payment-bypass patterns. Matches are blocked before the bytes hit the wire.
  3. Worker tier — destructive chain modules (mass-assign-admin-create, negative-amount transfer, Werkzeug PIN crack) require operator-supplied active_exploitation: true AND demonstrate_destructive: true on the scan, AND are still gated against the categorical refusal list.

Auditing refusals

Every fired refusal lands in the audit_logs table with the category, reason, and a sample of the offending input. Settings → Audit Log shows refusals filtered by action=hard_refusal — useful when explaining to auditors why a particular request was rejected.