How the platform is held together
This page describes our own practices. It does not describe the Security signals module, which analyses our clients’ sites; the two subjects are separate.
Last revised:
-
A team only ever sees its own data
Isolation is not a configuration option: it is carried by the schema itself, and cross-team tests ship with every release.
-
No IP address is ever stored
Your server logs are parsed as a stream, on our own infrastructure, without writing a single IP address to a database or sending one to a model.
-
Nothing active without a signed authorisation
Any check that sends a request to your infrastructure requires a signed, versioned, revocable authorisation. Without one, the check does not run.
-
The same rules apply to our own numbers
The discipline that forbids a screen from showing a number without its provenance is the one that forbids a service from leaving a declared boundary.
Per-team isolation
Every piece of business data carries the identifier of the team it belongs to, and every query is filtered by the current team. That filter does not live in the screens: it sits at the model layer, so it also covers background work, exports, and operational commands.
Work that runs outside a session (a scheduled crawl, an overnight sync) cannot inherit a current team: it is given one explicitly, and that is a writing constraint rather than a convention. Cross-team isolation tests ship with every release.
Credentials you entrust to us
Credentials you hand over (HTTP authentication for a staging site, connection tokens for your properties) are encrypted at rest and never shown again once saved. Someone on your team can replace them; nobody can read them back, on your side or on ours.
Access you grant us on third-party services stays yours: an authorisation withdrawn on your side cuts us off immediately, with no action required from us.
Outbound requests are constrained
An audit tool spends its day visiting addresses somebody else supplied. That is the most obvious exposure a product like ours has, and it is treated as such: every request to a user-supplied address goes through a guarded client that refuses internal addresses, loopback addresses, and redirects that lead to them.
The same rule applies in our side services, written in other languages. Equivalence between the implementations is not assumed: it is verified by a shared set of cases that all three run.
Signed authorisation for any active check
Checks that send requests to a client’s infrastructure require a signed, versioned authorisation. The check does not run without one: that is a refusal, not a warning banner.
Every signature is retained, along with the version of the text that was accepted. Revoking the most recent authorisation therefore does not bring an earlier one back to life, and a text later extended with a new check does not apply retroactively to whoever signed the old one.
Server logs
The parser reads your files as a stream, on our infrastructure. It keeps no IP address, writes none to a database, and sends none to a model. Uploaded files are deleted once processed; what remains are aggregates.
It is the only promise of this kind we make, and it is deliberately narrow: it covers the logs, not the whole platform. What leaves, and to whom, is published elsewhere, line by line.
What this page is not
The product includes a module that collects signals on our clients’ sites. It is PASSIVE: it observes what a visitor observes, and it reports. It attempts nothing, forces nothing, and replaces none of the work a specialist team would carry out on your infrastructure.
This page is not about that module. It describes how our own platform is held together: the two subjects share a word and have different objects, and it is the first misunderstanding a buyer raises.
To report a vulnerability or request our contractual documents, email us: we reply within two business days.