Responsible Disclosure & Data Transparency

EchelonGraph operates Discovery Radars — the Shadow AI Radar, KEV-Exposure Radar, Exposed Data-Stores Radar, and Leaked Cloud-Credentials Radar. They surface internet-facing security exposures from public data as an early-warning signal. It also covers the on-request Surface Scanner — a consent-gated scan you run against your own domain. This page explains exactly how each of these handles data, and how to request removal.

Seeing “EchelonGraph” in your logs?

If you found a request from us in your server or application logs, that's one of our Discovery Radars making a single, passive, read-only check — the same kind of unauthenticated GET a browser makes when loading a page. 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:

User-Agent: EchelonGraph-<Radar>/1.0 (+https://echelongraph.io/responsible-disclosure; support@echelongraph.io)
From: support@echelongraph.io

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, write to, or read data from your systems — see What we never do 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 support@echelongraph.io with the IP, range, or domain and we'll exclude it from future collection.

The Surface Scanner (runs only when you ask)

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. you@yourdomain.com). 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:

From: support@echelongraph.io
X-EchelonGraph-Surface-Scan: <scan-id>
X-EchelonGraph-Verify: https://echelongraph.io/verify-scan?scan=<scan-id>

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 read-only and non-intrusive: exactly like the Radars, it makes only the kind of unauthenticated requests a browser makes when loading a page. It never logs in, submits credentials, exploits, writes to, or reads private data from your systems — see What we never do below.

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

What data we use (public only)

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.

What we never do

  • We never log in, authenticate, exploit, modify, or extract data from any exposed host, database, or service.
  • 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 download or retain exposed private data.
  • We never publish individual host IPs, repository names, commit URLs, or secret values on our public pages.

How we confirm an exposure (read-only)

To avoid false positives, before recording an internet-facing exposure we make a single anonymous, read-only request — an unauthenticated GET of a status/discovery endpoint, exactly as a browser does when loading a page — to confirm the service truly responds without authentication. 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. We never submit credentials, never send a write/modify request, and never read user data.

Secret masking & storage

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.

Retention & automatic cleanup

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.

Responsible disclosure

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.

Takedown / opt-out

If you operate an asset that appears in our data and want it excluded or removed, email support@echelongraph.io (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.)

Legal basis

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.