Changed 30 September 2026: the MCP server figure on this page is now the adjudicated count below. It had been the Shadow AI radar's count of MCP-server observations. On that day, all but two of them were Shodan search results addressed by IP and port, matched on MCP terms in the HTTP response Shodan recorded (Shodan data, © Shodan), and the two were certificate hostnames. That radar sends no MCP request, so none of them was ever checked as an MCP server. The count is still on the board, labelled not assessed.
Of 16,921 hostnames checked as MCP candidates, 1,156 validated as protected under RFC 9728 and 15,765 are not assessed. Our own 3 hosts (control servers) are excluded from every count here.
Measured from 25 September 2026 to 26 October 2026 (UTC dates). Counted 26 October 2026, 20:19 UTC. The radar is checking; its last completed check, across all its services, was 26 October 2026, 20:07 UTC.
Refused our request with HTTP 401 or 403, and its OAuth protected-resource metadata (RFC 9728), read from the same origin, names exactly the endpoint we asked and at least one authorization server.
Everything else, each for the reason below. Not assessed is not unprotected, and it is never a finding of exposure.
Asked for credentials, but the metadata did not validate Did not validate is not unprotected: every server counted here refused our request with HTTP 401 or 403. A resource_mismatch server did challenge for OAuth; the resource its metadata names is not the endpoint we asked. | 1,715 |
Metadata names a different resource resource_mismatchThe metadata's resource is absent, or is not identical to the endpoint we asked (RFC 9728 §3.3). | 449 |
Metadata on another origin cross_origin_pointerThe challenge points to metadata on another origin. We record that and never request it. | 94 |
No metadata found bare_challenge_no_prmThe challenge names no metadata URL, and neither well-known metadata URI answered 2xx. | 1,127 |
Metadata URL did not answer pointer_unreachableThe same-origin metadata URL the challenge names did not answer 2xx in full. | 14 |
Metadata pointer not requested pointer_invalidThe challenge's metadata value is not a URL we will request (RFC 9728 §5.1, RFC 9110 §11.2). | 7 |
No authorization server named no_authorization_serversThe metadata names no authorization server; MCP requires at least one. | 5 |
Well-known metadata request got no answer wellknown_unreachableA well-known metadata request got no complete HTTP answer (a timeout, a refused connection, TLS). | 7 |
Metadata answer not a document metadata_invalidThe metadata answer was not a 200 with a JSON object within our size cap (RFC 9728 §3.2). | 12 |
Asked for credentials before our RFC 9728 check existed challenge_unadjudicatedAn HTTP 401 or 403 recorded before we read protected-resource metadata. Each is re-checked in rotation under the current rule. | 241 |
Identified as an MCP server, and did not ask for credentials at the handshake identified_no_challengeIt answered our server/discover request, the older initialize handshake or the older SSE stream as an MCP server does, and did not ask for credentials. This is normal in MCP: authorization is optional in the specification, and a server can answer these requests and still require credentials when a tool is called, at tools/call, which EchelonGraph never sends. So this is not a finding of exposure. | 485 |
Answered, but not as an MCP server not_identified_as_mcpIt answered HTTP, but nothing in the answer identified an MCP server: a web page, an error, a body that is not JSON-RPC. | 2,220 |
No HTTP answer no_http_answerWe could not reach the service: DNS, the connection, TLS or a timeout. | 11,104 |
answered server/discover (not proven modern-only) modern | 26 |
dual-era, a lower bound: the server also named an initialize-era version dual | 8 |
legacy: identified by the initialize handshake or the older SSE stream legacy | 384 |
unknown: nothing identified its revision (every credential challenge is here) unknown | 14,584 |
not yet re-checked since the era probe (#2314) not_measured | 1,919 |
Streamable HTTP: identified by a POST to /mcp streamable_http | 375 |
HTTP+SSE, the deprecated transport: identified by the first event of GET /sse legacy_sse | 43 |
unknown: nothing identified a transport unknown | 14,584 |
not yet re-checked since the era probe (#2314) not_measured | 1,919 |
Where the hosts come from. Every host counted here came from EchelonGraph’s own Certificate Transparency feeds: hostnames in newly issued TLS certificates, which we read from the public CT logs ourselves and from a public CT search index. A hostname is sent an MCP check only when mcp or mcpserver is one of its labels, or a hyphen-separated part of one: so mcp.example.com and mcp-server.example.com are checked, and xmcpy.example.com is not. Shodan is not a source for these counts. Its MCP results are addressed by IP and port, and we do not send them an MCP check: the MCP check is a POST, and our scan opt-out register cannot say whose server a bare address is, so an owner who opted out could not stop it. Hosts under echelongraph.io, the control servers we run to test this check, are excluded from every count. So is every host whose owner opted out of scanning: we do not check it again while the opt-out stands, so its last verdict could not be re-checked, and it is withheld rather than shown as current.
What we send. To each candidate, only these requests, each carrying our User-Agent and a signed receipt, and each asked of the scan opt-out register before it is sent:
server/discover request to /mcp, always first. It asks which protocol versions the server supports and, under the 2026-07-28 revision, opens no session. A server that answers it with a result, or with an error that revision defines, is sent no second POST;initialize handshake, only when server/discover is refused with an HTTP 4xx status other than 401, 403, 405 or 429 that is not a web page, or with a JSON-RPC error;/mcp, only if a POST’s reply opened a session, to release it;/.well-known/oauth-protected-resource/mcp and then /.well-known/oauth-protected-resource only if the first answered with an HTTP status other than 2xx. No redirect is followed;/sse, the stream of the deprecated HTTP+SSE transport, only when /mcp identified nothing and last answered 400, 404 or 405. We read at most its first event and close the connection.We never send tools/list, tools/call, resources/read, prompts/get or any other MCP method.
Why no MCP server is ever counted as open. In MCP the handshake and the authorization boundary are different places. A client has to be able to ask a server what it supports before it can learn how to authenticate, so a server can answer server/discover or the initialize handshake for anyone and still require credentials when a tool is called. Only tools/call, which runs somebody’s tool, could tell the two apart, and we never send it. So this check records a server as protected, on the RFC 9728 rule above, or as not assessed, with its reason; it never records one as open. Authorization is also optional in the MCP specification, so a server that asks for no credentials is not violating it.
When. The verdicts counted above were last checked from 25 September 2026 to 26 October 2026 (UTC dates): the oldest and the newest check among them. Hosts are re-checked in rotation, so each count is as of those dates.
Everything behind the dashboard — the filterable feed with per-row briefings, the risk categories with attacker playbooks, our reproducible method, documented incidents, compliance mappings, and how to cite the dataset.
Every row describes a computer that belongs to someone else. The publishable part — what kind of AI service it is, who hosts it, which country it sits in, which product it runs, and whether it answers without a password — is open on this page for anyone to read, cite or crawl. The one part we hold back is the exact address: the IP and port, plus the request path our scanner used. Published together, those stop being research and start being a targeting list.
The lock is enforced on our servers, not in your browser — the address is simply never sent. Unlocking one endpoint requires accepting a short access agreement, happens one row at a time, and is recorded. What we record when you unlock →
Tuning radar to CT log stream…
Click a category to expand the attacker playbook, blast radius, remediation steps and CVE / OWASP references. Verified counts are confirmed-reachable observations. The MCP Server card shows the adjudicated MCP counts instead: protected, of the hostnames checked.
A subdomain like internal-rag-pipeline.acme.com tells an attacker that you run a RAG architecture, almost always on a default port (FastAPI/Flask 8000–9000). It confirms three things at once: (1) you have an embedding store reachable over HTTPS, (2) you have a backing LLM connected to it, and (3) somewhere in that stack there is privileged data — code, contracts, customer records — being indexed for retrieval.
Wholesale data exfiltration of every document indexed by the pipeline — typically internal wikis, support tickets, contracts, or source code. Successful poisoning attacks turn the LLM into a controlled puppet for every employee that consumes its answers.
*rag**retrieval**knowledge**kb-**eval-**rag-customer**rag-sales*Hostnames matching milvus-*, qdrant-*, chroma-*, weaviate-* signal a bare vector database — not a managed service. These products default to open access for developer convenience; the vast majority of internet-exposed instances accept anonymous reads and writes on their well-known ports (Milvus 19530, Qdrant 6333, Chroma 8000, Weaviate 8080).
Stealing embeddings is provably equivalent to stealing the documents they were built from. A successful read attack therefore exfiltrates years of internal corpus content. A successful write attack lets the attacker dictate what the company's own AI tells employees.
*milvus**qdrant**chroma**weaviate**vector-db**pinecone*Subdomains like openai-internal.startup.io, claude-bridge.acme.com, anthropic-proxy.fintech.ai are the chokepoints where engineering teams stash their model API keys. Every employee request flows through them, which means the proxy holds long-lived API tokens for the upstream model provider.
A direct hit on a single LLM proxy can cost a company hundreds of thousands of dollars in unbudgeted model spend, leak the company's system prompts (which encode product strategy), and expose any tool integrations wired into the agent layer.
*gpt-**claude-**anthropic-**openai-**openai.**llm-proxy**llm-gateway**llm-api**ai-proxy**model-proxy*Hostnames like mlflow-internal.acme.com, ray-dashboard.startup.io, model-registry.fintech.ai expose the build system for AI. These dashboards show every registered model version, every experiment's parameters and metrics, every artifact path, and — critically — the raw prompts and configurations a RAG / agent pipeline shipped to production.
Full model intellectual-property theft + fine-tuning data exposure + remote code execution on the head node. The Ray exposure alone — confirmed at 2,000+ public clusters — is consistently one of the top AI security incidents of the year.
*mlflow**ray**model-registry**registry**training**fine-tune*Subdomains like agent-orchestrator.acme.com or langserve-staging.startup.io expose an autonomous agent — an LLM with tools. The tools are the dangerous part: shell access, filesystem access, internal API calls, browser automation, even cloud account credentials.
Anything a tool the agent has access to can do — usually filesystem read, internal HTTP, and shell execution. A leaked agent endpoint is a direct foothold inside your VPC, no exploit required.
*ai-agent**langserve**langchain**autogen**agent-orchestrator**ai-copilot**agentic**crewai*Hostnames like llm-prompt-cache.acme.com or embeddings-gateway.startup.io are typically a Redis or Memcached instance fronting an LLM. The cache keys are full user prompts; the values are full model responses. Every cache hit is a transcript of an employee asking a private question.
A historical record of every privileged conversation a company's employees had with their AI tooling — typically the most sensitive material in the org, written in plain language. Public exposure is a near-automatic regulator escalation under GDPR / DPDP / HIPAA depending on content.
*cache**embeddings-gateway**prompt-cache**redis-llm*Subdomains like jupyter-internal.acme.com, notebook-staging.startup.io, or lab-ds.fintech.ai expose a full interactive Python execution environment. Jupyter notebooks ship with no authentication in single-user mode. Every running notebook has filesystem access, a built-in terminal, and typically contains API keys, database passwords, and cloud credentials embedded in code cells or .env files in the working directory.
Arbitrary code execution on the host machine with full filesystem access. Exposed notebooks are actively exploited for cryptocurrency mining and as pivot points into internal networks. Stored credentials in notebook cells provide lateral movement to cloud accounts, databases, and internal APIs.
*jupyter**jupyterhub**notebook**nb-**jupyter-lab**lab-ds**ipynb*Subdomains like chat-ai.acme.com, flowise.startup.io, or dify-internal.corp.ai expose a full AI workflow builder. These platforms store API keys for OpenAI, Anthropic, Azure, and local models in a single dashboard. Chat histories contain every question employees asked the AI — often including PII, financial data, legal discussions, and source code. Tool integrations provide access to internal databases, CRMs, and file systems.
Multi-provider API key theft enables LLMjacking ($46K-$100K/day in unauthorized inference bills). Chat history exfiltration exposes every sensitive question employees asked the AI. RCE vulnerabilities (CVE-2025-59528) provide full server compromise. These are the fastest-growing shadow AI surface.
*openwebui**open-webui**flowise**dify**n8n-ai**ai-workflow**ai-builder**chat-ui**chatbot-*Subdomains like inference-api.acme.com, torchserve.startup.io, or vllm-prod.fintech.ai expose production model serving infrastructure. Management APIs allow registering/unregistering models, viewing loaded model metadata, and accessing inference endpoints. TorchServe binds gRPC management ports to 0.0.0.0 by default (CVE-2024-35199), making internal management APIs publicly accessible.
Model poisoning via unauthorized model registration causes every downstream consumer to serve attacker-controlled output. ShellTorch RCE chain provides full server compromise. Model extraction through repeated inference queries enables intellectual property theft of proprietary AI models.
*torchserve**tf-serving**inference-**model-serve**serving-**prediction-**vllm**tgi-**hf-inference**text-gen*Subdomains like airflow.acme.com, dag-scheduler.startup.io, or pipeline-internal.corp.ai expose the orchestration control plane for ML training pipelines. Airflow dashboards reveal every DAG definition (pipeline code), connection credentials (database passwords, cloud API keys), and task execution logs — which frequently contain plain-text secrets (CVE-2024-45784). Variable endpoints expose every stored secret in the system.
Full credential exposure for every connected system — databases, cloud accounts, APIs, model registries. Pipeline manipulation enables training data poisoning that corrupts all downstream models. Task logs contain a historical record of every secret that ever transited the pipeline.
*airflow**dag-**ml-pipeline**data-pipeline**pipeline-**orchestrator-*Subdomains like label-studio.acme.com or annotation-tool.startup.io expose the data labeling platform used to prepare training datasets. These tools contain the raw training data (images, text, audio), annotation guidelines (which reveal model architecture intent), project configurations, and user accounts. CVE-2025-25295 allows reading arbitrary server files via path traversal.
Training data theft reveals the content and scope of AI projects. Modified annotations create poisoned training data that degrades or manipulates model behavior. Path traversal vulnerabilities expose server credentials and internal configuration files.
*label-studio**labelstudio**argilla**annotation-**labeling-**annotate-*Subdomains like minio-ml.acme.com, artifacts.startup.io, or model-storage.corp.ai expose S3-compatible object storage — the default artifact backend for MLflow, Kubeflow, and most ML pipelines. These stores contain trained model weights (intellectual property worth millions), training datasets (often containing PII), experiment artifacts, and configuration files with cloud credentials. MinIO ships with default credentials (minioadmin:minioadmin).
Complete intellectual property theft of every model trained by the organization. Training data exfiltration may contain PII subject to GDPR/HIPAA breach notification. Model poisoning via artifact replacement turns the production AI into an attacker-controlled puppet.
*minio**minio-**artifacts-**model-artifacts**model-storage**ml-storage*Subdomains like tensorboard.acme.com, wandb-internal.startup.io, or metrics-ml.corp.ai expose experiment tracking dashboards. These reveal every model's architecture (layer configurations, attention heads, embedding dimensions), hyperparameter search spaces, training data distributions, loss curves, hardware configurations (GPU types, cluster size), and environment variables.
Model architecture and hyperparameter theft enables competitors to replicate months of R&D. Training data distribution leaks reveal what data the model was trained on (potential regulatory exposure). Environment variables logged during training may contain cloud credentials.
*tensorboard**tb-**wandb**weights-biases**experiment-**metrics-ml*Protected and checked are the AI-Exposure Radar’s adjudicated MCP counts: hostnames checked as MCP candidates, and of those, the ones validated as protected under RFC 9728. Everything else it checked is not assessed, each for a stated reason. The full split, its dates and its method →
The Shadow AI radar’s own count in this category: Shodan search results addressed by IP and port (Shodan data, © Shodan) and certificate hostnames named like MCP servers. That radar sends no MCP request, so it assesses none of them for MCP authorization: 957.
Subdomains like mcp-server.acme.com, mcp-gateway.startup.io, or tool-server.fintech.ai host MCP (Model Context Protocol) endpoints — the emerging standard for connecting LLMs to external tools and data. A server that accepts anonymous tool calls runs them with its own access, reaching whatever its tools reach: files, databases, internal APIs. MCP has specified an authorization framework based on OAuth 2.1 since its 2025-03-26 revision, but the specification makes authorization optional, so whether a given public server demands credentials has to be checked, not assumed. Neither of our radars lists a server's tools or calls one. Our AI-Exposure Radar, which speaks MCP, counts a server as protected only when the server refuses its server/discover request, or the older initialize handshake sent only after that is refused, with HTTP 401 or 403 and its OAuth protected-resource metadata (RFC 9728), read from the same origin, names exactly the resource it was fetched for and lists at least one authorization server; anything short of that is recorded as not assessed, and it never reports an MCP server as open. The Shadow AI radar on this page does not assess MCP authentication: it never sends an MCP request, so a login page or an HTTP 401 or 403 it sees on such a host is recorded as not determined, not as protected. Rows it labelled before that rule keep their old label until they are re-checked.
If an MCP server runs tool calls for anonymous callers, whoever reaches it acts with the server's own credentials, through whichever tools it exposes. Depending on how it was built, that can include internal databases, code repositories, CRM systems or cloud APIs. What is reachable is set by that server's tool catalogue and service account, not by the protocol, and our radar has not measured it for any host: it never calls a tool.
*mcp-server**mcp-proxy**mcp-gateway**model-context**tool-server**mcp-bridge*EchelonGraph monitors Certificate Transparency and Shodan banner-grab data for the following subdomain conventions. Each pattern is a literal substring match against freshly-issued certificate hostnames; a single hostname can match multiple categories. Publishing this list keeps the methodology auditable — anyone with access to crt.sh can reproduce our detection logic.
*rag**retrieval**knowledge**kb-**eval-**rag-customer**rag-sales**milvus**qdrant**chroma**weaviate**vector-db**pinecone**gpt-**claude-**anthropic-**openai-**openai.**llm-proxy**llm-gateway**llm-api**ai-proxy**model-proxy**mlflow**ray**model-registry**registry**training**fine-tune**ai-agent**langserve**langchain**autogen**agent-orchestrator**ai-copilot**agentic**crewai**cache**embeddings-gateway**prompt-cache**redis-llm**jupyter**jupyterhub**notebook**nb-**jupyter-lab**lab-ds**ipynb**openwebui**open-webui**flowise**dify**n8n-ai**ai-workflow**ai-builder**chat-ui**chatbot-**torchserve**tf-serving**inference-**model-serve**serving-**prediction-**vllm**tgi-**hf-inference**text-gen**airflow**dag-**ml-pipeline**data-pipeline**pipeline-**orchestrator-**label-studio**labelstudio**argilla**annotation-**labeling-**annotate-**minio**minio-**artifacts-**model-artifacts**model-storage**ml-storage**tensorboard**tb-**wandb**weights-biases**experiment-**metrics-ml**mcp-server**mcp-proxy**mcp-gateway**model-context**tool-server**mcp-bridge*We publish the method so the dataset is independently verifiable. Anyone with access to Certificate Transparency and Shodan can reproduce our detection logic.
Two public sources, no scraping, no proprietary signals:
Every observation carries one of seven liveness states, so we never publish unverified rows as exposures:
unverified — newly observed, probe pendingactive — answered a protected endpoint with no credentialsauthenticated — authentication observed: a 401/403, a login page, an authentication error in the response body, or a redirect to a login page. Flowise’s API-key refusal counts only from Flowise 3.0.1 on (see 3.)inconclusive — answered, but no probe could tell whether it requires authentication; counted neither as exposed nor as securedresolved — the host answered with an error status (4xx/5xx), a generic or non-AI web page, or an open API we judged intentionally public; or it did not answer at all (a timeout or a refused connection). No exposed response on the last probe — this is not evidence the service is secured.unreachable — the hostname does not resolverechecking — re-verification in flightEach candidate gets several read-only requests, not one. The site root; then up to three of the 22 endpoints we recognise, each one an endpoint the product’s own auth layer guards. Four of the 22: Jupyter /api/status, Ollama /api/tags, Weaviate /v1/objects?limit=0, MLflow /api/2.0/mlflow/experiments/search.
Four more, stated because they are requests too. An IP:port candidate that refuses plain HTTP is retried once over HTTPS. A candidate that answers open on one of those endpoint probes then has its landing page read — that read is how we tell a deliberately public demo from shadow IT, so it is not optional. And if the page redirects in JavaScript, which NAS and appliance web UIs commonly do, we follow it once to the host and port it names. Redirects are followed to a limit of five hops. And when a Flowise API answers with its API-key refusal (a 401), we send one more GET, to its public version endpoint /api/v1/version.
That refusal alone does not show the API is locked: Flowise 2.0.6 to 3.0.0 send it even where their own web UI reaches the API with no sign-in, using a request header we never send. So a version of 3.0.1 or later is counted as authentication observed; 2.0.6 to 3.0.0, a refused version endpoint, or a version we cannot read or place is not determined, unless the service’s own page refused us or showed a login page. The version itself is never published.
That choice is the whole method. An endpoint answering 200 on a hardened install can identify a product but never prove exposure — so we pick endpoints for what a secured instance refuses, and never read a single record to decide.
Detection ≠ compromise. The radar surfaces exposed AI services; it does not assert any service was breached. Owners may have intentional public access (demos, public playgrounds). Some categories are deliberately not adjudicated rather than guessed — a missing verdict costs us coverage, a guessed one costs somebody else their reputation.
Every incident is sourced to a primary advisory, vendor disclosure, or published research.
Three separate incidents within 20 days where Samsung Semiconductor engineers pasted proprietary source code, hardware test scripts, and internal meeting transcripts into ChatGPT — under OpenAI's then-default training-data retention policy. Triggered Samsung's company-wide ban on generative-AI tools.
Anyscale Ray's dashboard endpoint defaults to no authentication. Security researchers found thousands of public Ray clusters via CT-log + Shodan enumeration; the same dashboard accepts job-submission API calls leading to RCE on the head node. Documented attacks deployed cryptominers across enterprise GPU fleets.
A grieving passenger followed AI chatbot guidance on the airline's site for a bereavement-fare refund; the policy didn't exist. British Columbia Civil Resolution Tribunal ruled Air Canada is responsible for what its chatbot says. First major precedent on legal accountability for shadow-AI outputs.
Unauthenticated MLflow tracking servers exposed to the internet allowed `GET /model-versions/get-artifact?path=../../etc/passwd` style requests to traverse the host filesystem. CVSS 9.8. Affected every MLflow ≤ 2.10.0 — including ~3000 instances publicly discoverable via Shodan.
Researchers found dozens of malicious `pickle`-format models on Hugging Face Hub that executed code on load — stealing Hugging Face tokens, AWS credentials, and SSH keys from the data-scientist's machine. Adjacent to ongoing dataset-poisoning research on the same platform.
Wiz Research published a sweep of public Ollama and vLLM endpoints; both inference frameworks default to no authentication. Attackers can enumerate loaded models, send arbitrary prompts (burning customer GPU budget), and in some configurations remote-execute via known model-load CVEs.
Wiz Research discovered a fully open ClickHouse database belonging to DeepSeek, the Chinese LLM provider, exposed on a default port without authentication. Contained API keys, backend logs, and chat-history metadata. Highlighted that even foundation-model labs ship shadow infrastructure.
Multiple security teams (Tenable, Censys, GreyNoise) report 4000+ Jupyter notebook servers reachable on the public internet without authentication. Each provides interactive Python execution against the host — including any embedded credentials in environment variables, AWS/GCP tokens, internal data files.
Independent security researchers documented multiple cases of Claude.ai sessions and Anthropic API logs surfacing in public search-engine indexes via misconfigured analytics or shared-URL endpoints. Anthropic remediated promptly; the case underscored that LLM-front-end deployments need the same indexing hygiene as any web app.
The AI Threat Map plots the Milvus, Qdrant, ChromaDB, Weaviate and Ollama services (and LangServe, Ray and MLflow) that its Shodan searches return, rebuilt every 24 hours. Its methodology lists each search and whether it requires an HTTP 200. Shodan data is owned by Shodan, which holds its copyright (© Shodan). EchelonGraph claims no ownership of it or copyright in it.
MITRE ATLAS catalogues adversary techniques targeting ML systems. AML.T0011 covers the reconnaissance step this radar surfaces.
Exposed MLflow registries, vector databases and Jupyter notebooks are textbook LLM07 instances.
NIST AI RMF MS-2 requires continuous monitoring of AI system risks. Shadow-AI exposure is a measurable external-attack-surface risk.
High-risk AI systems must implement risk management and demonstrate accuracy + robustness. Exposed inference services evidence inadequate controls.
ISO 42001 Annex A.8 requires managing information disclosure. Subdomain leaks via CT logs are an unmanaged disclosure pathway.
EchelonGraph. (2026). Shadow AI Radar — Publicly Observed AI Infrastructure. Retrieved from https://echelongraph.io/shadow-ai-radar@misc{echelongraph_shadow_ai_radar,
author = {EchelonGraph},
title = {Shadow AI Radar — Publicly Observed AI Infrastructure},
year = {2026},
url = {https://echelongraph.io/shadow-ai-radar}
}/api/v1/public/shadow-ai-radar/statsWhat the licence covers. CC BY 4.0 covers only EchelonGraph's own work in this dataset: its AI-category classifications, the verdicts of our own checks, its aggregate counts and its methodology. Shodan data (the country, product and hosting operator of each row found through Shodan) is © Shodan and is not relicensed under CC BY; reusing it requires Shodan's terms (https://static.shodan.io/legal/terms.html). Certificate details read from public Certificate Transparency logs through crt.sh (issuer, SAN count, validity date) are not relicensed under CC BY either.
EchelonGraph-<Radar>/1.0 (+https://echelongraph.io/surface-scanner; opt-out https://echelongraph.io/responsible-disclosure; [email protected]) or, from our radar prober, EchelonGraphBot/1.0 (+https://echelongraph.io/bot), and their HTTP requests to the hosts they check also carry a From: [email protected] header. Some checks are a single identified GET; others send several requests to one host. Confirming an MCP endpoint sends a POST asking the server which protocol versions it supports, a second POST with the older handshake only if the first is refused without a 2026-07-28 error, a DELETE to close any session a POST opened and, if a POST is refused with HTTP 401 or 403, up to two GETs of the server's OAuth protected-resource metadata on the same host; where neither POST finds an MCP endpoint, the older SSE transport's stream is requested with GET, only its first event is read, and the connection is closed. A server that answers the first POST with a DiscoverResult, or with an error the 2026-07-28 revision defines, opens no session and is sent no further POST, so it is not written to; if the POST is refused with HTTP 401 or 403, the metadata GETs above still follow. Confirming an exposed datastore needs a protocol-level exchange, and on Redis our client names itself so the connection is identifiable in your own CLIENT LIST. We never log in, submit credentials or exploit what we find. Who we are, exactly what each check sends, and how to opt out → A radar's HTTP requests to the host it checks also carry a signed receipt you can validate at /verify-scan.