The Scanners Mapping AI Infrastructure Aren't After Your Model. They're After Your Credentials.

Updated July 2026

Exposed AI infrastructure is already being scanned at scale, but the exploitation aimed at it has not arrived to match.

Across 72 hours against a research deployment shaped to look like exposed AI infrastructure, the traffic split into two populations with opposite implications. Most of what hit the deployment was commercial reconnaissance: intelligence platforms and internet-wide classifiers cataloguing AI infrastructure with self-identifying user-agents, scheduled windows, and structured wordlists. The exploitation came from a separate population: generic credential-harvesting tooling. It hit AI ports because the ports were web-accessible. The AI service was never the target; the credentials sitting on the same host were.

Exposed AI infrastructure sits in a reconnaissance-heavy phase that looks like the early stages of the cloud and IoT exposure cycles before them: operators are systematically mapping the ecosystem, and widespread AI-specific exploitation has not arrived to match the visibility. The reconnaissance is a leading indicator for where AI-targeted exploitation goes once operational capability catches up, and it sits inside the wider security risks facing AI agents and their infrastructure.

That gap between reconnaissance and exploitation is a window defenders can use, instrumenting detection and response before the exploitation tail catches up to the mapping.

There is a lot of exposed AI infrastructure to find

The reconnaissance is running against a genuine exposure surface, one large enough to measure across two independent classifiers.

Cross-classifier analysis between Shodan and Censys identified roughly 25,000 to 30,000 publicly exposed Ollama deployments at the time of measurement (11 May 2026), which makes self-hosted AI inference far more exposed than most organisations realise. Open WebUI exposure runs larger still, with Censys HTML-title classification identifying roughly 63,000 deployments indexed on the public internet. Most of the Ollama population sits on the canonical port: Shodan product classification put 79.8% of confirmed hosts directly on port 11434 (Shodan, 11 May 2026).

The exposure carries known consequences. CVE-2024-37032, an Ollama path traversal enabling remote code execution against versions before 0.1.34, is the clearest example of why exposed inference infrastructure is a defensive concern rather than a visibility curiosity (NVD, 2024).

A naive Shodan banner search returned roughly 1,165 Ollama hosts; the structured Shodan product classification on the same data returned 25,488; Censys returned about 30,000. Twenty-fold spread on the same population, depending on how you ask. One source alone is not enough, but Shodan and Censys landing in the same range, roughly 25,000 and 30,000, is what makes the 25-to-30-thousand estimate defensible.

The exact count is not the point. A large, visible AI infrastructure ecosystem already exists, and it is big enough to sustain structured reconnaissance.

The reconnaissance is structured and commercial

One scanner cluster produced 75.7% of all observed traffic. Seven coordinated source IPs ran the same tooling, executing a 491-path AI infrastructure wordlist against the deployment over a 31-hour active window before disengaging completely. Four IPs ran sustained sweeps with the full wordlist; three ran lighter scout reconnaissance. Same tooling fingerprints across all seven.

Two behaviours in that cluster matter more than its existence.

The wordlist is port-agnostic. Those 491 paths span MCP discovery (/.well-known/mcp.json), Ollama endpoints (/api/tags), OpenAI-compatible paths (/v1/chat/completions), Ray cluster paths, and generic AI endpoints. The cluster probed /.well-known/mcp.json on eight different ports, including ports running services that have nothing to do with MCP. The tooling does not model what service should run where. It fires all 491 paths at every open port it finds.

That kills port obfuscation as a control. And the mismatch is measurable, not abstract: scanner reconnaissance hit non-canonical ports 79.6% of the time in this dataset, while real Ollama deployments concentrate 79.8% on canonical port 11434. The scanners look on ports where the deployments mostly aren't, and reach them anyway by covering every open port they find.

The internet-wide classifiers are now AI-aware too. Censys probed the deployment with a consistent sequence, GET /mcp, GET /jsonrpc, then a POST to / with application/json, across roughly two dozen distinct CensysInspect sources. This is classifier evolution captured in flight: Censys tooling being updated to include AI-specific path probing as part of its standard sweep. Shodan, under passive observation, indexed only one of the deployment's 13 exposed services in the 72-hour window, against six for Censys in the same period. That gap is discovery latency, not capability. Shodan indexes Ollama at scale globally; the timeline for any single deployment under passive querying is what differs, and Shodan's paid on-demand scanning closes some of it for defenders who use it.

The practical consequence for anyone auditing their own exposure: a passive Shodan query alone may show a fraction of what is actually visible. Triangulating across classifiers is more work.

The exploitation went after credentials, not AI models

No targeted AI exploitation showed up in the dataset. The dominant pattern was arrive, probe, disengage, with most operators gone before any attempt to interact with an inference endpoint.

The malicious population that did try was not AI-aware. Generic credential-harvesting tooling fired .env and cloud-secret wordlists at whatever was web-accessible. One pair of coordinated DigitalOcean IPs fired an identical 286-path wordlist within 26 seconds of each other, covering AWS, Azure, GCP and OCI credentials, Kubernetes secrets, and Git artefacts. Another variant ran pure .env exhaustion across six webroot prefixes. Ten more IPs in the long tail probed .env and .git/config and nothing else.

None of it cared that the host was running AI, because the ports were web-accessible and the credentials behind them were the same prize on any exposed host.

This is the exposure worth checking first. Credential harvesters do not skip a host because it runs AI; a web-accessible port is a web-accessible port, and the .env sweep arrives the same either way. The full timing and validation picture, harvested AWS keys reaching live API calls in under 90 seconds, sits in the companion research: how fast exposed credentials get validated.

One scanner did cross into inference probing, and it is worth a close look because it marks where the gap starts to close. From a single source IP, 30 POST requests hit /v1/chat/completions across the second half of the deployment, carrying canary-prompt payloads that asked for a single-word reply and rotated through model names, at roughly 45-minute intervals. The deployment returned generic placeholder responses rather than content-correct answers. The scanner came back on schedule regardless. It was not checking what the endpoint said. It was confirming the endpoint accepts structured POST payloads and returns valid JSON. That is cataloguing, not exploitation.

Why the population skews so heavily toward reconnaissance is not something the data settles. The likeliest contributor is a capability gap: the deployment was shaped well enough to draw recon but not deep enough to sustain exploitation, so operators probed, hit dead ends, and left. Timing is a factor too, since 72 hours may miss exploitation that follows commercial intelligence pipelines days or weeks later. And AI-specific exploitation may simply still be emerging, concentrated on high-value targets or moving through vectors this deployment could not see. None of those are confirmed. What the window does establish is that the catalogue is being built now, ahead of the attack.

What to do while the window is open

The visibility runs one way: scanners catalogue continuously, while defenders react to what they happen to notice. Closing that gap means either paying for commercial scanning data or running monitoring of your own.

Three things follow.

Assume you are already catalogued. Commercial scanners reach new infrastructure within hours of it going online, at a depth comparable to dedicated security tooling. The question is not whether your AI infrastructure is classified. It is what posture you apply given that it already is.

Layer controls on the services themselves. Port obfuscation fails against a port-agnostic wordlist, and the credential-harvesting class hits AI deployments incidentally regardless of which service answers. What works is layered and applied now: authentication on every AI service endpoint (Ollama ships without it, so this is on you to add), rate-limiting on inference endpoints to catch sustained probing like the 45-minute POST cadence, IP allow-listing for services with no business being public, credential-path filtering at the WAF for .env and .git/config, and patching for AI service CVEs such as CVE-2024-37032.

Treat the quiet as a countdown, not safety. No targeted exploitation observed is not the same as no threat. It is a leading indicator, and the value of the window is that monitoring can go on now, including signatures for the commercial scanner patterns above, before the targeted-attack phase arrives. Instrument during this phase and you are ready for the next one; read the quiet as permanent and you are calibrating to a state that will not hold.

This piece gives the diagnosis and the layered response. The endpoint-level defensive priority work, and the credential-validation timing that shows why the harvesting class moves as fast as it does, live in the companion research linked above and in the exposure management discipline that AI services need to be brought inside.

Methodology and disclosure

The deployment ran a 72-hour observation window, calibrated against earlier iterations of the same research programme. That window captures commercial scanner first-contact, the structured cluster's full discovery-and-sweep cycle, and the late-arrival inference probing. It does not capture operators whose cadence runs on weekly or monthly cycles, which is a known limitation rather than an absence of activity.

The cross-classifier discipline is the methodology contribution worth naming. Exposure claims triangulate across multiple commercial classifiers rather than trusting any single one, because the same population indexed by different methods returned counts that differed twenty-fold. That is applied discipline, not a novel technique, and it matters most for AI infrastructure specifically, where the classifier ecosystem is still calibrating how it handles these services.

Methodology and findings are public; specific apparatus configuration values are not, because configuration values become signatures that let operators identify and avoid the deployment in later iterations (Srinivasa et al., 2023; Sun et al., 2021). The general techniques, anti-fingerprinting configuration and HTTP response shaping, are well documented in public security research (Richards, 2022; Brumen, 2025). Each deployment is decommissioned once the work it informs ships; by the time this publishes, the one described here is offline. I am happy to discuss the research approach with genuine enquiries from other researchers.

References

Brumen, A. (2025). "Recon series #3: HTTP fingerprinting." YesWeHack Learn Bug Bounty, 18 March 2025. https://www.yeswehack.com/learn-bug-bounty/recon-series-http-fingerprinting

NVD. (2024). "CVE-2024-37032: Ollama path traversal." National Vulnerability Database, 31 May 2024. https://nvd.nist.gov/vuln/detail/cve-2024-37032

Richards, T. (2022). "Anti-fingerprinting Configuration for NGINX." August 2022. https://tomrichards.net/2022/08/anti-fingerprinting-configuration-for-nginx/

Srinivasa, S., Pedersen, J. M., & Vasilomanolakis, E. (2023). "Gotta Catch 'em All: A Multistage Framework for Honeypot Fingerprinting." Digital Threats: Research and Practice, 4(3), Article 42. https://doi.org/10.1145/3584976

Sun, Y., Tian, Z., Li, M., Su, S., Du, X., & Guizani, M. (2021). "Honeypot Identification in Softwarized Industrial Cyber-Physical Systems." IEEE Transactions on Industrial Informatics, 17(8), 5542-5551. https://doi.org/10.1109/TII.2020.3044576