Responsible Disclosure & Data Transparency

If you found a request from us in your server or application logs, that's one of our Discovery Radars checking a single finding. Most send one unauthenticated GET, the kind a browser makes loading a page. Confirming an MCP endpoint or an exposed datastore needs a protocol-level exchange rather than a plain GET, and the exposed-config radar sends up to 48 requests to one host — the full budget is in How we confirm an exposure below. We do this in the open, like Googlebot: every request we send identifies itself, so you always know it is us, which check it was, and why:

The <Radar> names the specific check (e.g. ExposureRadar-Verifier, ShadowAIRadar-Verifier, KEVExposureRadar). The From header is a real inbox you can reach us at. We never log in, submit credentials, exploit, or write to your systems. We do read the body of a file we find exposed, up to a size cap — that is how a leaked secret is detected — and what we read is redacted before storage. See What we never do and How we confirm an exposure below.

Worried someone could spoof our name to frame us? Every genuine probe also carries a signed X-EchelonGraph-Verify receipt. Paste it at echelongraph.io/verify-scan and we'll confirm whether the request was genuinely ours — including what we scanned and when. A request bearing our name with no valid receipt is not us.

Prefer we don't scan your hosts? Email [email protected] with the IP, range, or domain and we'll exclude it from future collection.

Separate from the passive Radars above, the Surface Scanner is an on-request check run against your own domain — we never initiate it on our own. It is consent-gated: it only runs when someone requests a scan of a domain and proves control of it by verifying a same-domain email address (e.g. [email protected]). We do not scan a domain unless its owner has asked us to, and we cap it at one free scan per domain per 24 hours.

Like the Radars, every Surface Scanner request identifies itself in the open. In your server or application logs you'll see:

Every request also carries a signed receipt. A host owner can confirm any scan was genuinely ours — including which domain we scanned and when — at echelongraph.io/verify-scan. A request bearing our name with no valid receipt is not us.

The scan is non-intrusive, but broader than a browser: alongside unauthenticated HTTP it queries your DNS — including zone-transfer (AXFR) requests — connects to your mail exchangers on port 25 to test STARTTLS, and submits non-destructive test values to forms and redirect parameters. It makes exactly one kind of write: an empty marker object into a storage bucket your own site references, to test whether anonymous writes are accepted, which we then delete. Where a bucket permits the upload but refuses the delete, a zero-byte file named .echelon-probe-… may remain and is safe to delete at any time. It never logs in, submits credentials, exploits a finding, or reads private data from your systems. The Terms describe every request type in full.

Prefer we never scan your hosts — even on request? The same takedown / opt-out contact applies: email [email protected] with the IP, range, or domain and we'll exclude it from future collection.

We derive findings exclusively from already-public sources:

• • Internet-wide scan catalogues (e.g. Shodan, Censys) — banner data those services already collected and publish.
• • The public GitHub event stream / GH Archive — commits pushed to public repositories.
• • Public vulnerability data (CVE, CISA-KEV, EPSS).

We do not use private, paywalled, or access-controlled data, and we do not attempt to obtain any.

• • We never log in, authenticate, exploit, or extract data from any exposed host, database or service. Verification is deliberately minimal but it is not always a bare read: confirming a Model Context Protocol endpoint requires a POST, and we then send a DELETE to release the session we opened rather than leave it holding a slot on someone else’s server. Confirming an exposed datastore opens a TCP connection and sends one metadata command — on Redis that command names our client so it is identifiable in your own CLIENT LIST. The Surface Scanner additionally uploads one empty marker object to a bucket your site references, described above
• • We never use, validate, or authenticate with a detected credential. A match means a credential-shaped string appeared in a public commit — not that we confirmed it is live.
• • We never retain exposed private data. Detecting a leaked secret requires reading the file that holds it, so config-file bodies are read; what is read is redacted before storage and the raw value is never written to our database.
• • We never publish individual host IPs, repository names, commit URLs, or secret values on our public pages.

To avoid false positives, before recording an internet-facing exposure we ask the host for it directly. How many requests that takes depends on the radar, and for one of them it is not a single request.

Most radars send one identified GET of an endpoint the product’s own auth layer is meant to guard. The exposed-config radar sends up to 48 to a single host: a HEAD to find the live scheme, one random-path canary to detect a catch-all, 23 known configuration paths, the homepage, up to 10 same-host script bundles, and up to 11 observability-tool probes.

We never submit credentials and never send a write or modify request. We do read response bodies — that is how a leaked secret is detected at all. Of the 23 configuration paths, 22 are read up to a 256 KB cap — enough to find a secret, not enough to take a database — including /.aws/credentials and /.ssh/id_rsa; one, /actuator/heapdump, is truncated to its first 128 bytes with a Range header. What we read is redacted before storage — see Secret masking below. A host serving configuration-shaped content at more than five distinct paths is discarded as a honeypot rather than reported.

If we see any sign of an auth challenge (a login page, HTTP 401/403, an authentication header, or a redirect to a login screen), or the result is inconclusive, we treat it as protected and do not report it.

Detected secrets are redacted before storage — we keep only a masked sample (e.g. AKIA••••••P3) and a salted-hash fingerprint. The raw secret value is never written to our database and is never displayed — in the public surface, the internal disclosure view, or any export. Public surfaces are aggregate-only (counts by type/provider/region); host- and repo-level detail is restricted to our team solely for responsible-disclosure outreach.

Observations auto-expire when an exposure is no longer observed: internet-exposure findings are removed after 14–21 days without re-observation, and leaked-credential findings after 60 days. When a host is secured, a database is locked down, or a credential is rotated, the corresponding record stops being seen and is pruned — so remediated items drop off automatically.

Where we can identify an affected organisation, we aim to notify it privately through its published security or network-abuse contact, sharing only the evidence needed to remediate (e.g. the public commit URL, or the public scan record). We support coordinated disclosure and reasonable remediation windows.

If you operate an asset that appears in our data and want it excluded or removed, email [email protected] (or contact us). Include the asset identifier; we will remove matching records and can suppress future collection for it. (Remediating the exposure also clears it automatically under the retention policy above.)

The radars constitute passive security research over public data, conducted to warn affected parties and the public of real exposures. We do not access protected systems, and we handle data in line with responsible-disclosure norms and applicable law. This page is informational and not legal advice.