The State of Shadow AI Exposure: We Watched 34,836 AI Services Appear on the Public Internet

Most security research about AI is about the models. This is about the plumbing — the inference servers, vector databases, model registries, notebooks and LLM proxies that teams stand up to actually *run* AI. It is the least glamorous layer, and it is the one leaking.

For 30 days we watched new AI infrastructure appear on the public internet, in near real time, by passively reading Certificate Transparency logs — the same public append-only ledgers that every TLS certificate is published to. Then we checked, politely and non-intrusively, whether each service was asking anyone to log in. This post is what we found, why it happens, the specific software and CVEs involved, what the wider research community has independently measured, and exactly how to lock each thing down. Every internal number is from our own data; every external claim links to its primary source.

One finding up front, because it reframes the whole problem: exposure is not random. It tracks the *default* security posture of the software. The tools that ship with authentication on stay locked; the tools that ship open get left open — at wildly different rates. We will show you the exact numbers.

How we measured this (and what "exposed" honestly means)

Our Shadow-AI radar finds its candidates passively. It tails public Certificate Transparency (CT) logs — the RFC 6962 ledgers operated by Google, Cloudflare, Sectigo and others — and matches newly-issued certificate hostnames against a library of AI/ML service fingerprints (patterns for inference servers, vector stores, LLM proxies, notebooks, model registries, MLOps dashboards, and MCP servers). For each candidate it then runs a liveness check — a short series of identified GET requests, starting over HTTPS — and records one of four states (*corrected 2026-09-27: this paragraph called the radar passive and the check a single request; the method correction below says exactly what it sends*):

Two honesty notes that matter for reading everything below:

What 30 days of AI on the public internet looks like

Of 34,836 AI/ML services observed, 18,778 were recorded as *authenticated* — a label that, as we found later, covered both services we saw demand credentials and services where we could not tell (see the correction below). 700 were confirmed serving with no authentication gate at all (one of them an MCP server, a count withdrawn on 2026-09-29; see the correction below the category chart), and another 14,504 were reachable in states we could not confirm as locked.

Where are the open ones? Overwhelmingly in two categories: LLM proxies/gateways and vector databases. Those are exactly the components teams bolt on quickly to wire an app to a model — and exactly the ones most likely to ship without auth.

The thesis: exposure tracks the software's default posture

Here is the finding that should change how you buy and deploy AI tooling. When we break the confirmed-open services down by the specific software running them, the pattern is stark. Software that ships with authentication on is almost never found open. Software that ships open is found open constantly.

Read that bottom line again. Ollama — which is trivial to reconfigure from its localhost default to OLLAMA_HOST=0.0.0.0 with no auth — was serving unauthenticated in 26 of the 28 instances we fingerprinted. Weaviate was reported here at 62%, and that figure is withdrawn as of 2026-08-06 — see the note below the chart. Meanwhile Jupyter (token auth on by default) and MinIO (credentialed by default) were *confirmed* open in zero of the ~7,900 instances we saw between them — a floor on exposure, not a count of locked instances (see the 2026-09-27 correction above).

This is not because Ollama users are careless and Jupyter users are careful. It is because defaults are destiny. The single highest-leverage security decision in your AI stack is choosing tools that are secure by default — and, for the ones that are not, treating "close the default" as a launch-blocking step, not a follow-up ticket.

The software, and what it does out of the box

We validated the default authentication posture of every major self-hosted AI platform against its own official documentation. The split is clean, and it lines up precisely with what we see exposed.

And in the maintainers' own words — these are not our warnings, they are theirs:

Why an open endpoint is not a small thing: the CVEs

An unauthenticated AI service is not just a data-leak risk; for much of this software it is remote code execution waiting for a visitor. We validated the following CVEs on the NVD, and — importantly — we downloaded the full CISA Known Exploited Vulnerabilities catalog and checked every one. None of these AI-infrastructure CVEs are on CISA KEV yet, even the one under active mass exploitation. The catalogs have not caught up with this attack surface, which is exactly why exposure detection matters more here than "patch what's in KEV."

This is not theoretical — the incidents

Independent researchers have been documenting exactly this class of exposure, at scale, for two years. We link every primary source so you can read the originals:

Why it keeps happening: shadow AI, by the numbers

The reason this surface keeps growing is organizational, not technical. AI infrastructure gets stood up faster than security teams can inventory it — often by people who are not security teams at all.

"97% lacked proper AI access controls" and "an unauthenticated Ollama in 26 of 28 instances" are the same sentence written from two directions.

Where this maps in the frameworks you already use

If you need to file this under a control owner, the mappings are unambiguous — and every identifier below is verified against its primary source:

What to actually do about it

None of this requires exotic tooling. In priority order:

Methodology, limits, and references

Method. Passive Certificate Transparency log discovery (RFC 6962) matched against AI/ML service fingerprints, followed by a GET-only liveness check of several identified requests per host, starting over HTTPS, classified as authenticated / active / resolved / unreachable (*corrected 2026-09-27 — see the method correction above*). Aggregate and host-redacted; no credentials stored, no payloads sent, no exposure "proven" by use. Window 14 June – 14 July 2026, n = 34,836.

Limits. CT-log discovery sees services that get a public TLS certificate for a hostname — it under-counts bare-IP and internal-CA services. Product fingerprinting is best-effort; roughly 62% of observations were not confidently fingerprinted and are excluded from per-software rates. "Confirmed open" counts only clean unauthenticated 200s, so it undercounts true exposure. Country attribution is by hosting ASN, not operator nationality. These are honest floors, and we would rather publish a defensible floor than an impressive ceiling.

Primary sources are linked inline throughout; the key ones: NVD (each CVE), CISA/NSA joint guidance, IBM Cost of a Data Breach 2025, Menlo Security 2025, Oligo Security (ShadowRay 1.0/2.0, ShellTorch), Wiz (NVIDIAScape, Probllama, DeepSeek), Cisco Talos and SentinelLABS+Censys (Ollama censuses), and each platform's official security documentation.

This is the first in a recurring series measuring what is actually exposed on the public internet. If there is a slice of this data you want us to go deeper on, tell us at [email protected].