Security

No request without permission.

Nothing active is sent to a site until its ownership is proven and someone authorised has given explicit, time-limited permission — and even then only inside the scope they set.

  1. Ownership proofDNS record, file or meta tag
  2. Explicit permissiontime-limited, revocable
  3. Exact scopeone origin, a set budget
  4. Requestonly now, from our gateway

01

Proof of ownership comes first

Before any active test, you prove you control the site with one of three methods: a DNS TXT record, a file on the web server or a meta tag on the home page. The proof belongs to one exact origin and has an expiry date; it is checked again before it expires.

Proving ownership does not start or allow a scan on its own. It is the first of two separate gates.

02

Explicit, time-limited permission

Permission is a separate, recorded step. You choose the scan profile — which limits methods, paths and request budget — and a duration that ends before the ownership proof expires, and you confirm a written statement that you own the site or are authorised to have it tested.

You can revoke permission at any moment. No new scan request is sent under a revoked or expired permission.

03

One exact origin, a set budget

Requests stay on the exact origin you approved: one scheme, host and port. Every scan runs inside a budget of requests, bytes and time, and reaching it stops the scan.

  • Subdomains, including ones found during a scan, are not covered; each needs to be verified as a target of its own.
  • http:// is never scanned; only https:// is accepted.
  • Other ports are other origins.
  • Redirects to another host are not followed.

04

Emergency stop and scan windows

Turn on the emergency stop and nothing more is sent to that site — not even by work that was already queued. Scan windows limit when scans may run, at a pace your servers are comfortable with.

Nothing is sent to a site unless ownership proof and permission are both valid, the emergency stop is off and the scan window is open.

05

Logins stay in an encrypted vault

Signed-in scanning is part of the product: you can give a scan a login form, a cookie, a token or a recorded browser login. Those credentials are handled like this:

  • Encrypted per organisation, with a key that belongs to your organisation only.
  • Decrypted only inside the scan job that uses them, for that job’s duration.
  • Never written to logs, reports, share links or AI inputs — not even partly.
  • Actions with side effects, such as logout, delete, payment and bulk mail, are excluded by default.

06

Scan traffic you can recognise

All scan traffic leaves through one controlled gateway, from a small, fixed set of addresses, with a user agent that names Trustpect. You can allowlist it in your firewall or CDN and recognise it in your logs.

If a firewall blocks a check, the check is reported as inconclusive — never as clean.

07

Partial means partial

A timeout, a firewall block, a lost session, a parsing error or a spent budget makes a result partial, inconclusive or unsupported — never “clean” and never “resolved”. Zero findings means the checks that ran found nothing; coverage shows what did not run.

A finding closes only when an equivalent retest — the same check, with equivalent scope — can no longer reproduce it.

08

The free check is passive

The free check needs no ownership proof because it reads only what any visitor can see. It sends at most 15 requests, uses only read requests, carries no attack payloads and never signs in.

  • The certificate and TLS settings, response headers and cookie flags.
  • Public DNS records: SPF, DMARC, DKIM, DNSSEC and CAA.
  • The home page and a short, fixed list of well-known paths.
  • Public domain names only — no IP addresses, internal names or reserved names.

Results are kept for 24 hours, and each domain and each connection has a daily limit.

09

What we keep, and what we never keep

Findings

Title, severity, location and history.

Masked evidence

Short request and response excerpts, secrets masked.

Scan records

Trigger, profile, coverage and budget.

Proofs and permissions

Who, when and which scope.

Fingerprints

Hashes of DNS, TLS, headers and scripts, to spot change.

Audit log

Sign-ins, exports, shares and deletions.

Never stored or exported

  • Raw page captures, HAR files or browser storage state.
  • Unmasked secrets, tokens or session cookies.
  • Full pages, files or your customers’ data.

10

Report a vulnerability or unwanted traffic

Found a security issue in Trustpect, or seeing scan traffic you did not authorise? Invited users report it through the contact they received with their invitation. For traffic reports, include the time, the host and the source address; we check the permission record and stop anything it does not cover. Good-faith security research is welcome.