Inside the Scanners Hunting Exposed AI Infrastructure: 72 Hours of Findings

May 2026

The reconnaissance ecosystem targeting AI infrastructure is now structurally distinct from general internet scanning. Across 72 hours against a research deployment, 460 distinct source IPs sent 11,643 requests; the AI-aware operators in the data enumerated, while operators who exploited targeted credentials rather than AI capabilities. The scanning population separates into five operational classes, each with its own signature, engagement pattern, and implication for defenders.

One observable consequence of the measurement matters for defensive design. Real Ollama deployments on the internet are 79.8% concentrated on canonical port 11434; scanner reconnaissance probing AI-specific paths hit non-canonical ports 79.6% of the time in this dataset. Port obfuscation is a known weak control in security generally, and the data here shows the same logic applies sharply to AI infrastructure with the gap now quantified.

Beneath the scanning observation sits a substantial exposure population. Between 25,000 and 30,000 Ollama hosts are exposed to the internet by structured product classification across Shodan and Censys (snapshot 11 May 2026), Open WebUI shows approximately 63,000 deployments by Censys HTML title classification, and the MCP server ecosystem shows small indexed exposure in current classifier data. The reconnaissance is operating against a real, measurable AI infrastructure surface.

Active exploitation attempts against AI inference endpoints in this dataset: zero. Credential harvesters probing .env files and cloud secrets, PHP exploitation tooling, and legacy CVE probes reached AI ports incidentally because the ports happened to be web-accessible, not because the scanners were AI-aware.

This is an early-stage window for AI infrastructure. Commercial and quasi-commercial operators are cataloguing what is exposed, and the targeted-attack phase remains downstream. The defender's task during this window is not to fight scanner visibility but to apply layered hardening to AI infrastructure ahead of that phase.

The AI-targeted reconnaissance documented here is the leading indicator for where AI-targeted exploitation will go when the capability gap closes.

This article documents what 72 hours of observation surfaced about who scans internet-exposed AI infrastructure and how they behave. The piece covers the exposed AI infrastructure population, the scanning ecosystem, a five-class taxonomy of AI infrastructure scanning operators, the engagement and disengagement patterns observed, the methodology behind the research, and the implications for AI infrastructure defenders. Engagement-extension testing, deeper exploitation pattern observation, and detailed endpoint-level defensive recommendations are deferred to the next iteration's piece.

This research is one iteration in an ongoing programme observing how scanners interact with exposed AI infrastructure. Each iteration produces methodological refinements, substantive findings about the threat landscape, and design implications that shape the next iteration's apparatus.

Get research like this delivered to your inbox. AI infrastructure security analysis grounded in primary research, no fluff.

The AI attack surface: what scanners are hunting

Before looking at scanner behaviour, it helps to know what scanners are finding when they look. Commercial classifiers give the cleanest picture of exposed AI infrastructure on the public internet, and triangulating across more than one classifier is the methodological discipline that produces defensible numbers. Single-classifier queries return counts that differ by an order of magnitude on the same dataset, so the right framing is cross-classifier agreement, not any individual classifier's headline figure.

What the exposure data shows

Shodan's structured product classification returns 25,488 confirmed Ollama hosts on the internet; Censys's structured queries return approximately 30,000 (both snapshots dated 11 May 2026). The two classifiers agree at order of magnitude, which makes 25,000 to 30,000 the defensible exposure figure for confirmed Ollama deployments.

Of the Shodan-confirmed deployments, 20,328 (79.8%) run on canonical port 11434, with the remaining 20% distributed across ports 443, 80, 8080, 8000, and a long tail of operator-chosen alternatives.

The threat surface is named. CVE-2024-37032, an Ollama path traversal that allows remote code execution against versions before 0.1.34, was published by NVD on 31 May 2024 and remains the most-cited reason this exposure population matters to defenders.

Other AI services scale differently. Open WebUI shows approximately 63,000 deployments by Censys HTML title classification and 19,111 by Shodan title match. vLLM exposure is small at around 156 hosts by Shodan keyword search, typically because production vLLM deployments sit behind reverse proxies rather than directly on the public internet.

MCP server exposure is small in current classifier data. Reliable measurement of MCP exposure is itself a methodological challenge given the diversity of MCP implementations and the absence of a stable classifier signature. Whether this category becomes a material exposure surface is a question for ongoing observation.

The exposure surface is real, broad, and unevenly observed by classifiers. Defender posture has to account for what is on the internet, not what should be there.

Who's scanning AI infrastructure

The traffic that hit the deployment splits cleanly into three groups: commercial-grade scanners running structured AI infrastructure characterisation, established internet-wide classifiers expanding their AI awareness, and a long tail of single-shot probes. Each tells a different story about how the AI security threat ecosystem is forming. This section documents what each group looked like in the data.

Structured AI infrastructure scanning at scale

One scanner cluster accounted for 75.7% of all observed traffic. Seven coordinated source IPs running the same tooling executed a 491-path AI infrastructure wordlist against the deployment over a 31-hour active window before disengaging completely.

This deployment is one observation window in an iterative research programme documenting which scanners target exposed AI infrastructure and what they probe for. What this window captured was structured commercial-grade reconnaissance, not opportunistic scanning.

The cluster's observable behaviour:

• Coordinated multi-IP cluster. Four IPs running sustained sweeps with the full 491-path wordlist, three IPs running scout reconnaissance with lighter request volumes. Same tooling fingerprints across all seven.
• Engagement-then-disengage at 31-hour granularity. Two scanning waves with an 18-hour silent gap between them, then a hard cutoff and 41 hours of silence before decommission. The cluster ran on a scheduled window, not continuous activity.
• TLS-first methodology as tooling fingerprint. The cluster attempted TLS connections on every port it encountered and retried with HTTP when TLS failed, with a 1:1 ratio between attempts and retries that is characteristic of the tooling family.
• Self-identifying user-agent during active scan. The operator chose visibility for the reconnaissance component of their tooling, using a user-agent that ties the scan to their tooling family rather than concealing it.
• Pre-engagement probing of nonsense paths. Early in the engagement, the cluster probed paths designed not to exist on any real service. The deployment returned 404, and cluster engagement continued.

Two findings within those observations matter more than the cluster's existence.

Finding 1: the wordlist is port-agnostic. The 491-path wordlist spans MCP discovery (/.well-known/mcp.json, /.well-known/agent.json), Ollama-specific paths (/api/tags), OpenAI-compatible endpoints (/v1/chat/completions), Ray-specific paths (/api/cluster_status), and generic AI endpoints (/api/agents). Cluster IPs probed /.well-known/mcp.json on eight different ports during the observation window, including ports running services that have nothing to do with MCP. The tooling does not model what service should run where; it sends all 491 paths against every port it finds open.

The defensive implication is direct: port obfuscation is not a control against scanning at this depth. The section on reconnaissance behaviour develops this against the real-world Ollama deployment distribution, where the gap between scanner expectation and deployment reality is sharper than I would have predicted before running the measurement.

Finding 2: parallel module execution from the same infrastructure. Within a single sweep window, the same cluster IP used different user-agent versions on different ports: port 8000 received probes flagged as v1.0, port 11434 received probes flagged as v2.0. The version difference is more consistent with parallel scan modules running from the same infrastructure than with a tooling upgrade observed mid-deployment. The cluster's parent operator appears to run multiple scan modules in parallel, each with different scope, all from coordinated infrastructure.

The substantive contribution from this section is not that one operator was identified. The contribution is that structured AI infrastructure characterisation programmes now operate at depth comparable to dedicated commercial reconnaissance, with service-aware tooling, scheduled activity windows, and coordinated multi-IP infrastructure. The same operator behaviour has now been observed across multiple deployments in this research programme, and defender intuitions built around obscurity or unconventional port choices do not hold against tooling at this depth.

Internet-wide classifiers are now AI-aware

Two of the largest internet-wide classifiers, Censys and Shodan, both probed the deployment during the observation window. Their behaviour against AI infrastructure differs in instructive ways. The contrast is methodology-relevant for defenders who rely on commercial classifier data to understand their own exposure.

Censys probes AI infrastructure directly. The deployment captured a consistent Censys probe sequence: GET /mcp, GET /jsonrpc, then a POST to / with application/json content-type. The same sequence appeared from multiple CensysInspect-identified IPs over the observation window, with roughly two dozen distinct CensysInspect sources logged in total and several executing the identical sequence within hours of each other. The probes use HTTP/2's PRI preface alongside TLS ClientHello, so Censys's discovery methodology is HTTP/2-first, then TLS, then HTTP/1.1 fallback.

This is real-time classifier evolution captured in the data. Censys's tooling is being updated to include AI-specific path probing as part of its standard classifier sweep, and the deployment caught the sweep in flight.

Shodan operates with module-specific quirks and delayed coverage. Shodan first indexed the deployment approximately two days after activation, with only one of the 13 exposed services catalogued during the 72-hour observation window. The indexed service was correctly identified, but the broader exposure remained invisible to Shodan in that timeframe despite Censys having catalogued six of the same 13 services within the same period.

The gap is one of discovery latency rather than capability, observed via passive Shodan querying without on-demand scan requests. Shodan indexes Ollama and Open WebUI deployments at scale globally; what differs from Censys is the timeline for any individual deployment under passive observation. Whether Shodan's coverage of this deployment would close over time, or via Shodan's paid features such as on-demand scanning and continuous Monitor enrolment, is a question the 72-hour passive-query window cannot resolve.

The defensive implication is direct: classifier coverage of AI infrastructure operates at different speeds, with Censys actively probing AI paths in near-real-time while Shodan's baseline crawler operates with a slower discovery cycle. A defender relying on passive Shodan queries alone to audit their own AI infrastructure exposure may be measuring only a fraction of the deployment's current visibility at any given moment; Shodan's paid on-demand scanning and continuous monitoring features close some of that gap for defenders who use them. Triangulating across classifiers is not optional methodology for defenders trying to understand their own AI infrastructure exposure.

Other scanner activity observed

The commercial scanner landscape against AI infrastructure is wider than Censys and Shodan. Several other operators with self-identifying user-agents probed the deployment during the observation window. None of them dominated traffic the way the structured cluster did, but each represents a distinct entrant into the AI-aware scanner population.

Cortex Xpanse (Palo Alto Networks): twelve distinct IPs running attack-surface management probes, identifying themselves via the "Hello from Palo Alto Networks" banner. The probing covered both structural and AI service ports across distributed source infrastructure.

visionheight: five AWS-hosted IPs self-identifying via user-agent, probing four ports including AI service ports across a sustained 12-hour scanning span. The methodology fits Class 5 in the taxonomy, mixing generic and AI-specific paths from the same operator.

Azure-hosted zgrab activity: twenty or more distinct IPs from Microsoft Azure ranges running the Mozilla/5.0 zgrab/0.x user-agent. The pattern is consistent with an academic or research organisation using Azure as hosting infrastructure for zgrab-based measurement tooling, not with Microsoft enterprise security scanning.

libredtail-http: identifiable PHP exploitation tooling observed on five coordinated source IPs running a 44-path playbook of PHPUnit and ThinkPHP exploitation attempts. The tooling is included here because the user-agent and request fingerprint are distinctive enough to be flagged in defender telemetry, not because it represents a commercial scanner.

Shodan-Pull/1.0 atypical signal: seven IPs presenting a user-agent that claims Shodan affiliation, but hosted on an autonomous system that does not match Shodan's actual ASN. The hosting infrastructure suggests a third-party operator using Shodan's API for target discovery, then re-scanning directly from their own infrastructure. The user-agent claim is the observation; attribution beyond that is uncertain.

The defensive implication: multiple commercial and quasi-commercial entities now scan with awareness of AI infrastructure, and any defender relying on classifier ranges from a single vendor underestimates the scanning surface in play.

Five classes of AI infrastructure scanning

The traditional binary of "research scanner versus threat actor" does not capture what was probing this deployment. Five distinct classes emerged from the dataset, each with its own signature and its own implication for defenders.

The taxonomy is analytical, derived from observed behaviour rather than assumed intent. Four of the five classes represent commercial scanning operators, research entities, or quasi-commercial new entrants; Class 4 is the exception and contains clearly malicious tooling.

Class 1: Fingerprint-based AI infrastructure discovery

Operators running deep AI-specific wordlists, with the structured cluster documented above (the 75.7% traffic operator) as the load-bearing example. The wordlist concentrates on .well-known agent and MCP discovery paths, OpenAI-compatible inference endpoints, Ollama API surface, Ray cluster paths, and vendor-specific dashboards, all sprayed across whatever ports are exposed.

The operator profile fits commercial intelligence platforms or research entities rather than threat actor reconnaissance. Self-identifying user-agents during recon, structured cadence with scheduled windows, and target validation probes are consistent with professional scanning methodology, not opportunistic attack preparation.

For defenders, the observable signal is a single source IP probing 50+ distinct AI paths in a single session. Most will only see this pattern once the source has already mapped a substantial subset of their AI surface, which makes the prevention window narrow. The output is inventory: this class produces target lists, not exploitation attempts.

Class 2: Service-specific discovery

General-purpose commercial classifiers extending their programmes to include AI-specific paths. Censys is the cleanest example in the dataset, with probes of /mcp, /jsonrpc, and /.well-known/agent.json followed by a POST to / with application/json content-type, executed across multiple CensysInspect IPs during the deployment. The probe set is five to ten AI-specific paths, tightly scoped and run alongside the operator's existing non-AI probe set, with a self-identifying user-agent that ties activity to a known commercial scanner.

For defenders, this is protocol-specific probing from established commercial scanner ranges. Security stacks that already filter CensysInspect, ShodanScan, or similar commercial scanner traffic are filtering this class; AI-specific paths from these ranges should not be classified as malicious. The class adds AI awareness to an existing classification taxonomy rather than displacing it.

Class 3: Port-specific discovery

Two sub-patterns separate operators in this class. The first is simple port-specific probing: a single IP probing /api/tags on port 11434 (Ollama) without sweeping any other paths or ports. The deployment recorded one such probe in the observation window, a single curl/8.7.1 request from a single source returning 200, which represents the noise floor of Ollama-aware discovery.

The second sub-pattern is structured multi-vendor characterisation. A different scanner from a single source IP exhibited a more sophisticated pattern: a five-path GET reconnaissance probe covering Ollama (/api/tags), OpenAI-compatible (/v1/models), generic health (/health), LiteLLM proxy (/key/info), and Anthropic-compatible (/anthropic/v1/models) endpoints, with a self-identifying user-agent for the recon phase. One to two seconds later, the same source sent two POST requests to /v1/chat/completions with no user-agent and a structured prompt payload alternating between model names, at approximately 45 minutes between cycles and sustained programmatically across the second half of the deployment.

For defenders, this class probes AI service ports in isolation without generic web path sweeps. Sub-pattern B's recon-and-inference cycle separation suggests separate tooling for each phase, with the operator visible during reconnaissance and unidentified during inference probing. The combination of /anthropic/v1/models and /v1/chat/completions is characteristic of probing for Claude Code gateway endpoints, and the operator profile fits researchers or early-stage commercial AI intelligence rather than threat actor activity.

Class 4: Misdirected legacy scanning

Generic credential-harvesting scanners that hit AI ports because the ports happen to be web-accessible, not because the scanner is AI-aware. The dataset captured several operationally distinct variants: one pair of coordinated DigitalOcean IPs fired an identical 286-path wordlist within 26 seconds of each other, covering AWS / Azure / GCP / OCI credentials, Kubernetes secrets, modern VPS CLIs (Scaleway, Hetzner Cloud, doctl, Fly.io), zero-trust VPN secrets, and Git / SVN artefacts. A second variant ran pure .env exhaustion across six webroot prefixes with 21 file-name suffixes.

A third variant ran 91 paths through six rotating ancient browser user-agents, with intentional MSIE 7.0 and Firefox 3.5.6 spoofing, hitting only structural ports across a 56-hour activity span. An additional 10 distinct IPs in the long-tail single-shot population probed .env and .git/config and nothing else.

For defenders, the AI service is not the target; the credentials on the host are. This is the one class in the taxonomy with clearly malicious purpose, and it matters because AI infrastructure operators sometimes underestimate credential exposure on the assumption that credential harvesters only target traditional web stacks. The class hits AI infrastructure as collateral exposure rather than as objective.

Class 5: Hybrid AI/general scanning

Operators with mixed methodology, probing both generic and AI-specific paths from the same infrastructure. visionheight is the example in the dataset, with a self-identifying user-agent across five AWS-hosted source IPs probing four ports including AI service ports across a sustained 12-hour scanning span. The methodology fits AI-specific paths into a probe set that runs at neither the depth of Class 1 nor the protocol-specificity of Class 2, reading as a general-purpose commercial scanner adding AI awareness incrementally.

For defenders, hybrid methodology indicates the operator is updating tooling to include AI paths. This is most likely an early-stage entrant into AI-aware commercial scanning, evolving the wordlist on each iteration. The output is combined generic web exposure data plus AI-specific data, classified together rather than as separate inventories.

Why the taxonomy matters

The classes are distinguishable by behaviour, and the defensive implications differ. Class 1 represents commercial intelligence operating at depth, and port obfuscation is not a control against it. Class 2 represents commercial classifiers that defenders can deconflict against known ranges.

Class 3 covers research and early-stage commercial AI intelligence reconnaissance for which most defenders have no monitoring. Class 4 contains the malicious tooling in the dataset, and matters because AI operators tend to underestimate credential exposure on the assumption that credential harvesters only target traditional web stacks. Class 5 represents commercial scanning entities adding AI awareness incrementally, with new entrants arriving every quarter.

A response calibrated to "all AI infrastructure scanning is the same threat" misses the point. Four of the five classes are commercial scanning, research, or quasi-commercial activity; Class 4 is the threat exception, and the defensive moves that work against one class do not generalise to the others.

Reconnaissance dominant, with the gap starting to close

Across the observation window, the dominant scanner behaviour against AI infrastructure was reconnaissance, with no targeted AI exploitation captured in the dataset. Most operators arrived, probed, and disengaged before any attempt at active interaction with inference endpoints. The exception is interesting on its own terms and points to where the gap is starting to close.

The structured cluster's 491-path wordlist included /v1/chat/completions and probed it across multiple ports during the observation window, but all probes were GET requests. The cluster did not attempt POST-based inference probing on any endpoint it discovered. This is the cataloguing pattern that defines Class 1 in the taxonomy: the output is a target list, not an exploitation attempt.

The cluster's reconnaissance is also broader than the real deployment surface it targets. Scanner reconnaissance probing AI-specific paths hit non-canonical ports 79.6% of the time in this dataset, while Ollama deployments on the internet concentrate 79.8% on canonical port 11434 (Shodan structured product classification, 11 May 2026). The mismatch holds across the wider scanner population observed in the deployment, not just within the cluster, and quantifies the scanner-deployment gap as measurable rather than abstract.

A different scanner, captured emerging at approximately the 50-hour mark of the deployment, behaved differently. From a single source IP, 30 POST requests to /v1/chat/completions were observed across the second half of the deployment, with structured canary-prompt payloads requesting a single-word response ("respond with ONLY the word 'pong'") and alternating between model names across cycles. Cadence was sustained at approximately 45 minutes between cycles, with 21 or more hours of total engagement and a 57.5% 200-rate against the AI-aware paths it probed.

Most operators arrived, probed AI fingerprint paths and credential paths, and disengaged before any POST exploitation attempt. A smaller population crossed into structured POST inference probing against inference endpoints, exhibiting the vendor-spanning reconnaissance followed by canary-prompt POST validation that the late-arrival scanner illustrates.

A specific observation about that late-arrival scanner's behaviour is worth pulling out. The apparatus returned generic placeholder responses to the canary-prompt POSTs, not content-correct answers to the "respond with 'pong'" instruction. The scanner returned at 45-minute intervals regardless.

The interpretation: the scanner is not validating response content; it is confirming that the endpoint accepts structured POST payloads and returns valid JSON. That is cataloguing behaviour, consistent with intelligence-gathering tooling rather than exploitation.

Three explanations may help account for why the population skews so heavily toward reconnaissance, none of them confirmed by the data.

Capability gap (most likely contributor). The apparatus shaping is enough to attract reconnaissance but not deep enough to attract exploitation. Operators see plausible AI service surface, attempt some recon, find dead ends or weak signals, and disengage. Fingerprinting probes succeed because surface-level shaping is enough; exploitation would fail at the next probe layer because deeper inference simulation is not there.

Timing. Seventy-two hours may be too short to capture exploitation that follows reconnaissance through commercial intelligence platform pipelines. If commercial scanners feed findings into customer products and downstream attackers act on those findings days or weeks later, the observation window misses the exploitation tail.

AI exploitation still emerging. The current threat landscape against AI infrastructure may not yet target it in production-grade ways via direct service exploitation. Real exploitation may concentrate on specific high-value targets, happen via different vectors (insider threat, supply chain, model poisoning), or be limited to research demonstrations rather than in-the-wild operations.

The findings highlight gaps for future iterations of this research to explore, including deeper engagement past the disengagement boundary observed in this window. That work and its findings will be documented separately.

For defenders, the picture is two-sided. The "no exploitation observed" finding is not evidence of safety; it is a leading-indicator window during which detection and response can be instrumented before the exploitation tail catches up. AI infrastructure exposed to the internet is already catalogued by structured AI infrastructure scanners regardless of port choice, and the defensive task is to bring AI services into the same exposure management discipline applied to the rest of the attack surface.

What AI infrastructure operators should infer

The visibility asymmetry between scanners and defenders is structural. Scanners catalogue continuously; defenders react to what they happen to discover. Closing the gap requires either visibility into commercial scanning data, which costs money, or running monitoring experiments such as this study, which cost operational complexity.

Most defenders close that gap incompletely. From there, three implications shape the response.

The catalogue exists. Assume AI infrastructure is classified by commercial intelligence platforms as soon as it goes online. The reconnaissance observed in this deployment shows commercial scanners reaching new infrastructure within hours of activation, and structured AI-aware scanning programmes operating at depth comparable to dedicated security tools. The defensive question is not whether catalogued, but what defensive posture to apply given that the catalogue exists.

Hardening, not hiding. Port obfuscation does not protect AI services against the structured cluster's port-agnostic wordlist and the broader port-mismatch evidence documented earlier. The credential-harvesting class hits AI deployments incidentally because the ports are web-accessible regardless of which service runs on them (Class 4 of the taxonomy); operators sometimes underestimate this on the assumption that credential harvesters only target traditional web stacks. What works is layered defence applied during the cataloguing phase and carried into the targeted-attack phase that follows: authentication on AI service endpoints regardless of platform default (Ollama does not ship with authentication enabled; defenders need to add it), rate-limiting on inference endpoints to catch sustained scanning patterns (the 45-minute POST cadence observed in this dataset is one such signature), IP allow-listing for non-public AI services that have no business being on the open internet, credential-path filtering at the WAF or application layer (for .env, .git/config, and similar paths the credential-harvester class probes), and patching for AI service CVEs such as CVE-2024-37032 in Ollama.

Reconnaissance is one layer of the defence-in-depth picture. The reconnaissance-heavy pattern observed in this window, with no targeted AI exploitation captured in the dataset, reflects an AI ecosystem still in the cataloguing phase rather than an ecosystem at safety. Reconnaissance monitoring is one layer of the broader defensive posture AI infrastructure needs, and the leading-indicator value of this window is that the layer can be added now, alongside the hardening controls above, before the targeted-attack phase catches up. Defenders who use this period to add monitoring on AI infrastructure, including signatures for known commercial scanner patterns documented above, are preparing for what comes next. Defenders who treat the observed absence of targeted exploitation as a permanent state are not.

Three things this article does not support inferring. "We are not under attack" misreads the data because reconnaissance is itself the leading indicator. "Hiding services prevents discovery" is refuted for the dominant scanning class.

"Authentication alone is sufficient" overstates a single control; authentication holds against the cluster, but rate-limiting, anomaly detection, and IP-level controls all do work the credential-harvesting and inference-probing classes can otherwise reach.

This article gives the diagnosis and outlines the layered hardening response. Specific endpoint-level guidance and the AI endpoint defensive priority taxonomy live in the substantive follow-up piece and the defensive companion that publishes after it.

Methodology behind the AI infrastructure research deployment

The deployment ran on a 72-hour observation window, calibrated against earlier iterations of the same research programme. Day 1 captured initial reconnaissance from the broad scanner population, Day 2 captured cluster expansion and target-list refresh signals, and Day 3 captured sustained operators continuing into deeper engagement patterns.

The repertoire of structured AI-aware scanners present in this deployment was captured within the first 24 to 31 hours. Beyond that window, additional deployment time accumulates long-tail single-shot probes rather than new structured scanner classes.

What the 72-hour window captured well: commercial scanner first-contact, the structured cluster's discovery and full sweep cycle, multi-vertical operator first contact, Day 2 burst patterns, the late-arrival programmatic inference probing, and parallel scan module activity from the same operator infrastructure. What 72 hours does not capture: long-tail operators with engagement spans past the window, multi-day operator cadence patterns, and any scanning that fires on weekly or monthly cycles in operator infrastructure.

Cross-classifier verification discipline

A specific methodology contribution worth flagging is the cross-classifier discipline applied to exposure claims. Claims about exposed AI infrastructure populations must triangulate across multiple commercial classifiers, not rely on any single classifier's reporting. The verification work for this article surfaced several places where a single-classifier query produced misleading answers.

A naive Shodan banner search returned roughly 1,165 Ollama hosts, the structured Shodan product classification on the same dataset returned 25,488, and Censys returned approximately 30,000. The same scanner classifier indexed by different methods can return counts that differ by 20-fold or more, and methodology that relies on a single classifier's first-pass answer is structurally unreliable.

The Shodan-Censys agreement at order of magnitude (25,488 and 30,000 respectively) is what makes the 25 to 30 thousand exposure number defensible. Either number alone, taken from a single query, would not be.

This is methodology applied, not novelty claimed. The contribution is the discipline brought to AI infrastructure specifically, where the classifier ecosystem is still calibrating its handling of AI services and naive queries are particularly unreliable.

Disclosure

Methodology and findings are public. Specific apparatus configuration values are not. The reason is direct: configuration values become signatures, and once operators know the specific values used, they can identify and avoid the deployment in future iterations of the research (Srinivasa et al. 2023; Sun et al. 2021).

General techniques behind the deployment, including anti-fingerprinting configurations and HTTP response shaping, are well-documented in public security research (Richards 2022; Brumen 2025).

Each deployment used for content is decommissioned after the work it informs ships. By the time this article publishes, the deployment it describes is offline. I am open to discussing the research approach with genuine enquiries from other researchers.

Programme positioning

This research is one iteration of an ongoing programme studying AI infrastructure scanning. The next iteration of findings will be documented in follow-up pieces as the programme continues.

Naming and attribution discipline

Scanners observed during this deployment fall into three editorial categories.

Established commercial scanners with public self-attribution are named throughout: Censys, Shodan, LeakIX, Palo Alto Cortex Xpanse, Netcraft, Internet Measurement, and academic tools like zgrab. They maintain methodology pages or vendor documentation, are extensively documented in existing security research, and naming them adds to a well-established public record.

Other scanners are described by behaviour pattern without naming, where the actor is an early-stage commercial entity still defining its public narrative or where naming would meaningfully expand the operator's profile beyond what they have themselves chosen to publish. The behavioural observations remain the substantive research contribution: knowing that a scanner exists, what wordlist it uses, what cadence it probes at, and what tooling architecture it presents is what serves AI infrastructure defenders.

Personal identifiers observed in user-agent strings (email addresses, handles, names) are not reproduced anywhere in the article. Behavioural patterns associated with them may be discussed; the identifiers themselves are not.

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