Security and acceptable use

This page is a plain-language summary, not a legal document. The binding terms are the Terms of Service, Privacy Policy and Acceptable Use Policy published in the product — those are the documents you accepted at signup, and they govern wherever this page differs from them. Where this page describes product behaviour rather than policy, it reflects the current implementation and may change with releases.

Authorized targets only

You may only add assets you own, control, or are explicitly authorized in writing to test. You must be able to demonstrate that authorization on request, and you must remove assets promptly when authorization ends.

This is not boilerplate. Perimeter performs real network collection against the targets you configure. Pointing it at systems you don't have permission to assess may be unlawful in your jurisdiction, and it violates the Acceptable Use Policy you agreed to at signup.

Three mechanisms support this in the product. None is a substitute for actually having authorization.

Ownership confirmation. Adding a seed, adding an asset, and importing either all require an explicit confirmation that you own or are authorized to test what you are adding.

Scan authorization. This gates the checks that carry real exposure — port checking and template scanning. It is a signed statement recorded against an organisation, naming the person who granted it, with an expiry date, revocable at any time. Where you confirm on behalf of subsidiaries, the specific subsidiaries you were shown are recorded with it; a subsidiary created afterwards is not covered until someone confirms again. It is deliberately a standalone record on the organisation's settings page rather than a checkbox buried in a scan dialog.

Domain verification. Proves control of a domain or subdomain via a DNS TXT record or an HTTPS token file. Challenges expire and must be renewed, and tokens are stored only as hashes.

Domain verification is an option your organisation turns on, not a default. It is off unless an administrator enables it for the organisation. Without it, passive collection and ordinary browser-equivalent requests will run against a domain you have added without a proof-of-control challenge. It was made optional because the checks that carry genuine exposure moved behind scan authorization instead — what verification still gated was an HTTPS request, a TLS handshake, a CORS preflight and a favicon fetch, which is what any browser does when it loads a page. If you want ownership proof enforced before anything is touched, turn it on.

What Perimeter does to your assets

Collection is passive-first and built from public sources: DNS, Certificate Transparency logs, passive DNS, internet registries (RDAP), and internet-wide scan datasets. Perimeter also performs ordinary HTTPS requests and TLS handshakes against your assets to read response headers, cookies and certificates, and fetches your favicon in order to hash it.

Perimeter never:

• Delivers exploits or attempts to compromise anything
• Performs authenticated or internal scanning
• Attempts to access data behind authentication
• Scans internal or private network targets

Hostnames resolving to loopback, private, link-local or carrier-grade NAT addresses are rejected, as are internal-only domain suffixes, and this is re-checked at connection time.

Standard scans

Beyond ordinary HTTP and TLS collection, the only active check on a standard scan is a single CORS preflight request using a non-routable origin.

Intrusive scans — opt-in, and authorization-gated

Two additional checks exist and run only when you request an Intrusive scan on an organisation that has a valid scan authorization on file:

• TCP port checking. Perimeter opens and closes a connection to each port in a curated list — the same thing any client does. No raw sockets and no third-party port scanner. A refused connection means the port is closed; a timeout is recorded as not evaluated rather than counted as closed, so a result you see is a result we actually observed.
• Template scanning. A signature-based checker that confirms an exposure rather than inferring it. Disabled by default, capped in execution and output, no redirects, and restricted to an allowlist of vetted checks.

Neither runs on an ordinary scan. If your organisation has no scan authorization, they cannot run at all — the option defaults to withheld, and the check is enforced on the server rather than trusted from the request.

Account security

• Two-factor authentication is mandatory for every account. TOTP, 6 digits, 30-second period, with single-use backup codes.
• Passwords must be at least 14 characters with lowercase, uppercase, numeric and special characters.
• Sign-in, two-factor verification and password reset are rate-limited.
• Sessions last 24 hours; you can review and revoke them individually under Settings → Security.
• Single sign-on is available with Google, Microsoft Entra ID and Okta.

Data isolation

Every workspace is a hard isolation boundary. Data access is scoped by workspace on every request, and within Enterprise workspaces further scoped by organization and, for Remediators, by individual assignment.

Integration credentials — cloud provider keys, SSO client secrets, webhook credentials — are encrypted at rest. Two-factor secrets are encrypted. Domain verification tokens are stored only as hashes.

Collection that touches your assets runs on separate infrastructure that holds no database credentials and cannot reach the systems storing your data.

Perimeter staff access

Perimeter staff cannot read your operational data by default. Access requires a time-boxed grant you issue, between 1 and 168 hours, revocable at any time, with revocation effective on the next request. Every grant issued, revoked and used appears in your audit log.

Audit trail

Sensitive actions are recorded with the actor, their IP address, the affected entity and a timestamp. Findings additionally carry an append-only event history covering every status change, assignment and rescan. Exportable to CSV.

Honest reporting

A scan tells you what it actually assessed, separately from whether it finished. A scan that completed but could only assess part of your estate is reported as such, with a per-asset reason for every gap — including assets we withheld because they were outside your scan scope, matched your own exclusion policy, or would have exceeded the asset count your contract includes.

Where a check could not reach a conclusion, it is recorded as inconclusive rather than as a pass. A quiet result is never presented as a clean result.

Privacy and retention

Perimeter is operated in line with GDPR, including your rights of access, rectification and erasure.

Retention periods, the lawful bases for each processing purpose, and the full detail of how to exercise your rights are set out in the Privacy Policy. That document is authoritative — this page deliberately does not restate the periods, so the two can never disagree.

Prohibited use

The Acceptable Use Policy sets out the full terms. In summary, beyond the authorized-targets rule above, it prohibits using findings or scan output to attack third parties; attempting to access other tenants' data or subvert isolation; probing Perimeter itself outside an authorized disclosure programme; circumventing rate limits, quotas or scan-scheduling controls; sharing credentials; and reselling scan data (sharing with your own auditors, regulators, customers and providers is permitted).

Report suspected abuse to Mithras R&D with timestamps, source addresses and log excerpts.

Violations may result in suspension of scanning for specific assets, or suspension or termination of the account. Notice is given where practical; serious abuse may be acted on immediately. The enforcement terms in the Acceptable Use Policy govern.